Le site est-il en panne ?

Pourquoi un second point de vue tranche

Votre demande de page quitte votre appareil, traverse votre routeur Wi-Fi, votre fournisseur d’accès et un résolveur DNS, puis seulement elle part vers le serveur du site. Une panne n’importe où sur le trajet vous donne le même onglet blanc. De votre fauteuil, un serveur mort et un routeur perdu se ressemblent exactement.

Une requête envoyée depuis un autre réseau ne partage aucun de vos équipements. Si elle obtient une réponse, le serveur est vivant et la panne se trouve de votre côté du trajet. Si elle échoue aussi, vous pouvez arrêter de redémarrer votre routeur.

Ce que fait le test, dans l’ordre

1. Résolution du nom. Il demande à un résolveur public les enregistrements A (IPv4) et AAAA (IPv6) de l’hôte. Aucune adresse du tout met fin au test avec « Introuvable » et une réponse NXDOMAIN indique que le nom n’existe pas. Un hôte qui n’a qu’une adresse IPv6 reçoit un avertissement, car beaucoup de réseaux ne peuvent toujours pas l’atteindre.
2. Requête avec validation du certificat. Il se connecte, envoie une requête de page normale et suit jusqu’à six redirections une par une, en chronométrant chaque étape. Chaque étape dispose de 8 secondes pour se connecter et de 15 secondes au total.
3. Nouvel essai sans validation. Si le certificat TLS était le seul obstacle, une seconde tentative l’ignore. Un site qui répond ainsi est signalé « Certificat rejeté ». Il fonctionne, mais tous les navigateurs afficheront un avertissement.
4. HTTP simple. Si HTTPS n’a pas pu se connecter du tout, il essaie http://.
5. L’autre écriture. Si tout a échoué, il essaie le même domaine avec ou sans www. et vous dit quand celui-là fonctionne.

Lire le verdict

Sous le verdict, vous obtenez les adresses trouvées, l’IP atteinte, la version HTTP, le temps de connexion et jusqu’au premier octet, ainsi que l’émetteur du certificat et sa date d’expiration. Un certificat qui a moins de 14 jours devant lui est signalé, car aucune panne ne se voit venir plus facilement.

Quand il nous répond et pas à vous

Avancez de votre appareil vers l’extérieur :

Le navigateur

Ouvrez la page dans une fenêtre privée. Cela écarte d’un coup les extensions et un cookie abîmé.

Le réseau

Chargez le site sur un téléphone en données mobiles. Si ça marche là, la cause est dans votre réseau domestique ou de bureau, ou chez votre fournisseur.

Le DNS

Lancez nslookup example.com puis nslookup example.com 1.1.1.1. Deux réponses différentes signifient que votre résolveur garde un ancien enregistrement. Videz le cache local (ipconfig /flushdns sous Windows, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder sous macOS) ou changez de résolveur pour 1.1.1.1 ou 8.8.8.8. La vérification de propagation DNS montre quels résolveurs ont le nouvel enregistrement.

Un blocage qui vous vise

Les sites bloquent souvent les filtres d’entreprise et les adresses de sortie des VPN. Un serveur peut aussi bannir une adresse IP après plusieurs mots de passe erronés, ce qui enferme dehors tout un bureau pendant que le reste du monde entre.

Ce qu’une seule requête ne peut pas dire

C’est une tentative unique depuis un seul endroit. Un site qui bloque certains pays, ou un CDN en difficulté dans une région, peut nous répondre et échouer chez vous sans que rien ne cloche dans votre équipement. Le test n’exécute pas non plus de JavaScript : une application qui renvoie le statut 200 puis affiche un écran vide compte comme en ligne.