« Impossible d'accéder à ce site » : les six codes derrière une seule phrase, et lequel est le vôtre

Chrome affiche « Impossible d’accéder à ce site » pour au moins six échecs différents, qui n’ont presque rien en commun si ce n’est l’ordre dans lequel ils surviennent. L’un signifie que le nom n’existe pas. L’un signifie que la machine a répondu puis a raccroché. L’un signifie que le wifi de votre visiteur a lâché.

La phrase est toujours la même car c’est la seule chose honnête que le navigateur puisse dire d’une page qu’il n’a jamais reçue. Ce qui les distingue, c’est le petit code gris affiché en dessous, et ce code constitue à lui seul le diagnostic.

L’ordre dans lequel les choses se produisent

Le chargement d’une page traverse quatre étapes, et chacune a sa propre façon d’échouer. Lire les codes dans cet ordre est ce qui leur donne un sens.

1. Trouver l’adresse. Le navigateur demande à un résolveur vers quelle IP pointe le nom d’hôte.

2. Ouvrir une connexion. Il tente de joindre cette IP sur ce port.

3. La sécuriser. Pour HTTPS, il valide un certificat.

4. Demander la page. Il envoie la requête et attend une réponse.

Un échec à la première étape ne peut pas être la faute de votre serveur, puisque rien ne l’a encore atteint. Un échec à la quatrième étape l’est presque certainement. Le code vous indique à quelle étape vous êtes arrivé, et cela vaut mieux que n’importe quelle description du symptôme.

Les codes, dans cet ordre

DNS_PROBE_FINISHED_NXDOMAIN et ERR_NAME_NOT_RESOLVED correspondent à la première étape. La description que Chromium donne du second est « Le nom d’hôte n’a pas pu être résolu ». Le nom n’existe pas, du moins pour le résolveur qui a répondu. Apparenté, et plus précis : ERR_NAME_RESOLUTION_FAILED, « Une erreur s’est produite lors d’une tentative de résolution de nom (DNS) », qui correspond à un échec de la recherche elle-même plutôt qu’à un retour vide.

Une faute de frappe produit cette erreur. Un enregistrement DNS qui ne s’est pas encore propagé aussi, tout comme un domaine expiré le week-end, ou un filtre DNS d’entreprise ou de contrôle parental qui refuse de répondre pour votre domaine. Ce dernier cas compte plus qu’il n’y paraît : pour la personne concernée, votre site n’existe tout simplement pas, alors qu’il fonctionne parfaitement de votre côté.

ERR_CONNECTION_REFUSED correspond à la deuxième étape, et c’est l’échec le plus instructif de cette liste. Quelque chose a répondu. Une machine à cette adresse a activement dit non, ce qui signifie que le DNS a fonctionné, que la route a fonctionné, et qu’un hôte est bien présent mais que rien n’écoute sur ce port. Mauvais port, service qui s’est arrêté, conteneur qui n’est pas revenu après un déploiement.

ERR_CONNECTION_TIMED_OUT est la deuxième étape qui échoue en silence : « La tentative de connexion a expiré. » Rien n’a dit non, rien n’a dit oui. Un pare-feu qui abandonne les paquets plutôt que de les rejeter ressemble exactement à cela, tout comme un serveur trop occupé pour accepter la connexion.

ERR_ADDRESS_UNREACHABLE relève du routage : « L’adresse IP est inaccessible. Cela signifie généralement qu’il n’existe aucune route vers l’hôte ou le réseau spécifié. » Les paquets n’ont nulle part où aller.

ERR_INTERNET_DISCONNECTED correspond à « La connexion Internet a été perdue », et c’est le seul cas que vous pouvez cesser d’investiguer immédiatement. C’est le réseau propre au visiteur, et aucun rapport fondé là-dessus ne vous apprend quoi que ce soit sur votre site.

ERR_EMPTY_RESPONSE correspond à la quatrième étape : « Le serveur a fermé la connexion sans envoyer aucune donnée. » Celui-ci est généralement le vôtre. Quelque chose a accepté la connexion puis a disparu sans répondre : un processus qui a planté en cours de requête, un proxy qui a abandonné, un worker tué faute de mémoire.

Les échecs de certificat relèvent eux aussi de la troisième étape, mais ils affichent leur propre écran plutôt que celui-ci. Savoir lequel des cinq vous concerne est une autre question, et la famille ERR_CONNECTION_* fait l’objet de son propre article qui détaille la distinction entre refus et réinitialisation.

Faible

Le client dit que le site est en panne. Tout semble normal de notre côté. On lui a demandé de vider son cache.

Meilleur

DNS_PROBE_FINISHED_NXDOMAIN, uniquement sur son réseau de bureau, fonctionne avec les données mobiles. Leur filtre DNS, pas notre serveur. Confirmé que l'enregistrement se résout depuis trois résolveurs publics.

Quelle moitié de la liste est vraiment la vôtre

Triez-les selon qui peut les corriger, et la liste se scinde presque à parts égales, ce qui est précisément ce qui la rend utile.

En général de leur côté : les échecs DNS lorsqu’ils sont filtrés ou mis en cache localement, la déconnexion Internet, l’adresse inaccessible, et un délai d’attente causé par leur réseau plutôt que par votre charge.

En général du vôtre : connexion refusée, réponse vide, et un délai d’attente lorsque vos serveurs sont réellement saturés.

Vraiment ambigu, et à vérifier en premier : un échec DNS qui se reproduit depuis un résolveur public relève de votre enregistrement, pas de leur réseau. Cette vérification prend dix secondes et tranche la plus grande catégorie de la liste. Sur n’importe quelle machine :

nslookup example.com 1.1.1.1
nslookup example.com 8.8.8.8

Si les deux répondent avec votre IP et que le visiteur obtient quand même NXDOMAIN, le problème se situe entre lui et son résolveur. Si aucun ne répond, c’est votre enregistrement, et le compte à rebours a commencé dès sa dernière modification.

Le problème du signalement, qui est le vrai problème

Chacun des codes ci-dessus apparaît sur une page générée par le navigateur. Votre site n’a jamais tourné. Il n’y a ni console, ni entrée dans l’onglet réseau, ni erreur que votre outil de suivi puisse capter, et rien qu’un outil embarqué dans la page puisse enregistrer, y compris le nôtre.

Toute cette catégorie ne vous parvient donc que si quelqu’un vous la signale, et il le fera mal, car il n’y a rien à copier à l’écran hormis une phrase et un code dont il n’a aucune raison de penser qu’il compte. La plupart de ces signalements arrivent sous la forme « votre site est en panne », de la part de quelqu’un pour qui c’est effectivement le cas.

Ce qui rend la question de suivi particulièrement précieuse, et particulièrement simple. Pas « merci de reproduire avec la console ouverte », ce qui est impossible ici. Trois choses à demander à la place :

• Le code, tel qu’il apparaît en entier dans le petit texte gris sous le message.
• Si cela se produit sur un autre réseau, les données mobiles étant le test le plus simple.
• Si quelqu’un d’autre parvient à y accéder, ce qui distingue en un seul message une panne globale d’un problème de résolveur propre à une seule personne.

Trois réponses suffisent généralement à savoir laquelle des quatre étapes a échoué avant même d’avoir regardé un serveur. Est-ce votre bug ou leur panne applique le même raisonnement aux services qui fonctionnent mais en mode dégradé.

Ce qu’il faut en retenir

« Impossible d’accéder à ce site » est une catégorie, pas un diagnostic, et les six échecs qu’elle regroupe se répartissent à peu près également entre ce que vous pouvez corriger et ce que vous ne pouvez pas.

Lisez le code, déterminez à laquelle des quatre étapes il appartient, et vérifiez le DNS depuis un résolveur public avant de croire quoi que ce soit d’autre. Et quand vous ne parvenez pas à reproduire le problème, rappelez-vous que l’impossibilité d’accéder à un site est le seul échec pour lequel votre propre machine est l’instrument le moins utile que vous possédiez : la vôtre résout, se connecte et fonctionne.

La liste de ces erreurs établie par Chromium, avec la définition en une ligne de chacune, se trouve dans net_error_list.h.