Workflow d'indisponibilité
Comment vérifier si un site web est indisponible
Utilisez une méthode claire pour distinguer une vraie panne de site, un problème DNS, un échec SSL, un port fermé ou une réponse techniquement en ligne mais inutilisable.
Quand un site ne se charge plus, la première question est souvent trop large : « est-il indisponible ? » En pratique, il faut d'abord répondre à une question plus précise. La requête a-t-elle échoué avant la fin du DNS, pendant la connexion, pendant TLS ou seulement après une réponse HTTP du serveur ? C'est ce qui sépare un diagnostic utile d'une simple supposition de disponibilité.
Commencer par tout le chemin de requête
Une vérification de site donne la réponse générale la plus rapide, car elle couvre DNS, TCP, TLS, redirections et réponse HTTP finale en un seul passage.
Ne pas appeler chaque échec une panne
Un 403, 429 ou 503 signifie encore que le serveur a répondu. C'est très différent d'un échec DNS, d'une connexion refusée ou d'une erreur de handshake TLS.
Utiliser des outils ciblés pour isoler la couche
DNS, SSL, port, ping et traceroute deviennent utiles après une première vérification qui indique où le chemin a commencé à échouer.
01
Quand cette page est utile
Ce parcours sert aux dix premières minutes de dépannage, avant de modifier des enregistrements ou d'accuser l'hébergement.
Le site ne se charge pas chez vous
Vous devez savoir si l'échec est visible depuis un serveur public ou s'il peut être limité à votre navigateur, réseau de bureau, VPN ou FAI.
Un client dit que le site est indisponible
Vous voulez une réponse rapide et défendable avant escalade. Un rapport qui sépare HTTP, DNS, SSL et réseau vaut mieux qu'un simple oui ou non.
La supervision signale un problème
Vous avez besoin d'un second regard public pour comprendre si l'incident ressemble à une panne applicative, un souci de routage ou un problème de confiance.
02
Un premier diagnostic pratique
L'objectif est de passer de symptômes larges à une couche précise sans plonger trop tôt dans les outils bas niveau.
Lancez le vérificateur de site sur l'URL exacte
Utilisez le vrai nom d'hôte et le bon schéma si possible. Il faut la chaîne de redirections, l'URL finale, les temps et le résultat HTTP visible dans le même rapport.
Lisez le point d'échec, pas seulement le titre
Une erreur DNS, un avertissement TLS, un délai dépassé et un HTTP 503 ressemblent tous à « le site est indisponible », mais ils mènent à des responsables et actions différents.
Confirmez la couche avec l'outil dédié
Si le premier résultat pointe vers les certificats, ouvrez le vérificateur SSL. S'il pointe vers la résolution de nom, ouvrez Recherche DNS. Si la connexion ne s'ouvre jamais, utilisez le vérificateur de port, puis Ping ou Traceroute si le chemin paraît suspect.
Déterminez si le résultat prouve un problème global
Un serveur public peut prouver qu'une localisation a vu l'échec. Il ne peut pas prouver que chaque région, FAI ou navigateur a vu la même chose.
03
Ce que signifient les résultats courants
Ces interprétations comptent le plus lorsque quelqu'un demande si un site est vraiment indisponible.
Réponse HTTP avec code de statut
La requête a atteint une application, un CDN ou un service de périphérie. Le site peut rester inutilisable, mais le nom d'hôte s'est résolu et quelque chose a répondu en HTTP.
Échec DNS ou absence d'enregistrement utile
Le problème commence avant qu'un serveur web puisse répondre. Vérifiez A, AAAA, CNAME, NS et le comportement du résolveur avant de toucher au SSL ou au code applicatif.
Erreur TLS ou de certificat
L'hôte était assez joignable pour commencer HTTPS, mais la confiance ou la négociation de protocole a échoué. Les utilisateurs peuvent voir un blocage de sécurité même si le serveur est techniquement en ligne.
Connexion fermée, refusée ou en délai dépassé
Le service web n'a pas accepté de connexion fonctionnelle depuis le point de test actif. Cela indique souvent un pare-feu, un listener arrêté, un problème d'origine ou un filtrage amont.
04
Quel outil ouvrir ensuite
Utilisez la page dédiée qui correspond au premier signal clair, au lieu de deviner à partir d'une erreur ambiguë.
Meilleur premier contrôle pour « le site ne se charge pas », car il montre tout le chemin de requête et le premier point d'échec.
Vérificateur de site webRéponses DNS structuréesOuvrez ceci quand les noms semblent incorrectsÀ utiliser après NXDOMAIN, réponses vides, IP obsolètes ou écart entre le nom d'hôte et l'infrastructure attendue.
Recherche DNSCertificat et TLSUtilisez ceci quand la confiance HTTPS bloqueIdéal pour les certificats expirés, les noms d'hôtes non couverts, les certificats auto-signés et la prise en charge TLS visible.
Vérificateur SSLDisponibilité TCPUtilisez ceci si le service n'écoute peut-être pasUn test de port propre sépare les erreurs applicatives web d'une connexion qui ne s'établit jamais sur 80 ou 443.
Vérificateur de port05
Erreurs qui font perdre du temps
Ces raccourcis ralentissent le triage parce qu'ils mélangent plusieurs couches dans une conclusion floue.
- Traiter chaque réponse non-200 comme la preuve que tout le site est indisponible.
- Tester seulement la page d'accueil alors que l'échec réel se produit sur une page de connexion, de paiement ou d'API redirigée.
- Passer directement à traceroute avant de confirmer que le site répond en HTTP ou écoute sur le port attendu.
- Supposer qu'un ou deux échecs côté serveur prouvent un problème global pour toutes les régions et tous les navigateurs.