Le site est-il hors service pour tout le monde ou juste pour moi ?

Pourquoi une vérification multi-emplacements règle la question

Une requête depuis votre ordinateur portable traverse le cache de votre navigateur, le résolveur DNS de votre système d'exploitation, votre routeur, votre FAI, et n'atteint qu'ensuite le chemin Internet vers le serveur. N'importe laquelle de ces couches peut échouer à elle seule alors que le serveur va parfaitement bien. Lancez la même requête depuis un point de contrôle dans un autre pays et aucune de vos couches locales n'est impliquée. Si elle échoue aussi là-bas, le problème est à destination. Si elle réussit, le problème se trouve entre vous et Internet, et la recherche s'est réduite du monde entier à votre propre machine et votre propre réseau.

La lancer depuis plus d'un emplacement ajoute une troisième réponse possible, et c'est une réponse courante : le site est en ligne à certains endroits et hors service à d'autres. Ce schéma pointe vers une route réseau régionale, un point de présence de CDN, un blocage géographique, ou un changement DNS qui a atteint certains résolveurs et pas d'autres, et non vers un serveur éteint.

Ce qui ne va généralement pas quand c'est seulement vous

• Un cache DNS périmé. Votre résolveur ou votre système d'exploitation détient encore une ancienne adresse IP pour le domaine, donc vous vous connectez à un serveur qui a déménagé.
• Votre FAI ou la route vers l'hôte. Un lien de peering cassé ou un problème de routage affecte tout le monde chez ce fournisseur et personne d'autre.
• Un VPN ou un proxy d'entreprise. Le trafic part depuis un tout autre endroit, et ce point de sortie peut être bloqué, filtré ou simplement lent.
• Le fichier hosts. Une entrée ajoutée il y a des mois pendant des tests remplace encore le vrai DNS, pointant généralement vers une machine qui n'existe plus.
• Le cache du navigateur, un service worker ou une extension. Une page d'erreur mise en cache, un service worker périmé ou un bloqueur de contenu peuvent faire paraître morte une page qui fonctionne.
• Un pare-feu local ou un logiciel de sécurité. Certaines suites bloquent des catégories entières de sites, ou bloquent un port dont le site a besoin.
• Un certificat expiré ou non approuvé sur votre seule machine. Une horloge système erronée fait paraître expiré n'importe quel certificat valide.

Comment vérifier depuis un autre réseau

Le test manuel le plus rapide ne nécessite aucun outil du tout. Coupez le Wi-Fi de votre téléphone et ouvrez le site sur les données mobiles : réseau différent, résolveur DNS différent. S'il se charge là-bas et pas sur votre ordinateur portable, la panne est locale.

Depuis un terminal, demandez directement les en-têtes, puis demandez à un résolveur public quelle IP il pense que le domaine a :

curl -I -sS --max-time 10 https://example.com/
dig +short example.com @8.8.8.8
dig +short example.com

La première ligne vous dit si un serveur a répondu du tout, et avec quel code de statut. Si curl signale un délai de connexion dépassé ou un échec DNS, rien n'a répondu. Si les deux lignes dig sont en désaccord, votre résolveur local détient une adresse différente de celle du résolveur public, et un cache périmé est le coupable probable. Sous Windows, ipconfig /flushdns vide le cache local ; sous macOS, sudo dscacheutil -flushcache ; sur la plupart des systèmes Linux, redémarrer le service de résolution suffit.

Ce que signifie chaque résultat

• Hors service partout. Le serveur, son hébergement, ou son DNS est réellement cassé. Regardez le code de statut : un 502 ou un 503 signifie que quelque chose a répondu et que l'application derrière n'a pas répondu, ce qui est très différent d'une absence totale de réponse.
• Hors service seulement à certains endroits. Suspectez un DNS qui n'a pas fini de se mettre à jour partout, un point de présence de CDN ou une région en difficulté, ou une règle de pare-feu qui bloque certains réseaux ou pays.
• En ligne partout mais pas pour vous. Passez en revue les causes locales ci-dessus, en commençant par le DNS et le VPN.
• En ligne, mais lent partout. Ce n'est pas une panne. Cela en précède souvent une, donc mesurez-le correctement plutôt que de deviner.

Un détail piège souvent les gens. Un site peut être « en ligne » au sens où il renvoie une page et être quand même cassé pour les visiteurs : une vérification qui ne cherche qu'une réponse compte une page d'erreur de base de données comme un succès quand le serveur la renvoie avec un 200. Regardez ce qui est revenu, pas seulement si quelque chose est revenu.

Le découvrir avant un client

Une vérification ponctuelle répond à la question que vous vous posez en ce moment, et seulement parce que vous avez pensé à la poser. Les pannes qui commencent à trois heures du matin, ou qui n'affectent qu'une seule région, sont généralement découvertes par un client en premier. La surveillance programmée exécute la même vérification en continu depuis de nombreux emplacements et vous informe à l'instant où le résultat change, avec l'emplacement et l'erreur associés. HostTracker exécute ces vérifications depuis plus de 300 points de contrôle répartis dans 158 villes et alerte par e-mail, SMS, appel vocal, Slack, Telegram et bien d'autres canaux, de sorte qu'une défaillance régionale a une apparence différente d'une défaillance mondiale dès la première alerte. Le vérificateur de site hors ligne vous donne le statut d'un site à l'instant présent. Si le site répond mais répond lentement, mesurez-le correctement : temps de réponse du serveur.