Quand un site est en panne, vérifiez d’abord qu’il l’est pour tout le monde, et pas seulement pour vous. Travaillez ensuite de l’extérieur vers l’intérieur : le DNS, la connexion, le certificat TLS, le CDN ou le proxy, le serveur web et enfin l’application et ses dépendances. L’erreur affichée vous indique généralement par quelle couche commencer, et chaque étape ci-dessous propose un test rapide qui la confirme ou l’écarte.
Prenez des notes au fur et à mesure : ce que vous avez vérifié, à quelle heure et ce que vous avez constaté. Elles accélèrent le passage de relais et facilitent la rédaction du postmortem.
Étape 1 : en panne pour tout le monde, ou seulement pour vous ?
Collez l’adresse dans le vérificateur Is it down?. Il demande la page depuis Stockholm, en Suède, suit jusqu’à cinq redirections et considère comme disponible toute réponse inférieure à HTTP 500. Essayez ensuite le site sur votre téléphone, Wi-Fi désactivé.
Si le site fonctionne de l’extérieur mais pas chez vous, le problème est proche de vous : un VPN, une entrée dans le fichier hosts, le cache DNS de votre box, une extension de navigateur ou un pare-feu qui a bloqué votre adresse IP après trop d’échecs de connexion. Essayez une fenêtre de navigation privée et un autre réseau avant de toucher au serveur.
Lisez le message d’erreur
L’erreur exacte désigne la couche qui a échoué. Notez-la avant de commencer à modifier quoi que ce soit.
Ce que vous voyezCouche probableCommencez àDNS_PROBE_FINISHED_NXDOMAIN, « Impossible de trouver l’adresse IP du serveur »DNS ou domaineÉtape 2ERR_CONNECTION_REFUSED, ERR_CONNECTION_TIMED_OUTRéseau ou serveurÉtape 3« Votre connexion n’est pas privée », NET::ERR_CERT_DATE_INVALIDCertificat TLSÉtape 4Cloudflare 521, 522, 525 ou 526, ou une page d’erreur du CDNDu CDN à l’origineÉtape 5500, 502, 503 ou 504Serveur web ou applicationÉtape 6Une page qui se charge mais reste blanche ou affiche une erreurApplication ou dépendanceÉtape 7
Étape 2 : vérifiez le DNS et le domaine
Si le nom ne se résout pas, rien d’autre ne compte. Demandez au DNS ce qu’il répond pour votre domaine et comparez avec l’adresse de votre serveur :
dig +short example.com A
dig +short www.example.com
dig +short example.com NS
Aucune réponse : vérifiez si l’enregistrement du domaine a expiré avec le vérificateur d’expiration de domaine. Un domaine expiré perd souvent ses serveurs de noms ou pointe vers la page de parking du registrar.
La mauvaise adresse : quelqu’un a modifié un enregistrement, ou les serveurs de noms ont été déplacés chez un fournisseur qui n’a pas vos enregistrements. Comparez la réponse avec celle attendue grâce à l’outil DNS lookup.
Correcte pour certains, fausse pour d’autres : une modification récente est encore en cours de diffusion. Les résolveurs conservent l’ancienne réponse jusqu’à l’expiration de son TTL : c’est la propagation DNS.
Notre guide sur DNS_PROBE_FINISHED_NXDOMAIN passe en revue les causes DNS une par une.
Étape 3 : le serveur est-il joignable ?
Avec la bonne adresse, testez si le serveur accepte les connexions sur les ports web :
nc -vz example.com 443
curl -sv -o /dev/null https://example.com/
Connexion refusée : la machine répond, mais rien n’écoute sur le port. Le serveur web s’est arrêté ou a planté. Redémarrez-le et lisez son journal pour comprendre pourquoi.
Délai dépassé : les paquets ne mènent nulle part. Le serveur est éteint, un pare-feu ou un groupe de sécurité bloque le trafic, ou le réseau intermédiaire a un problème. Consultez la page de statut et la console de votre hébergeur.
Ne vous fiez pas au seul ping. Beaucoup d’hébergeurs bloquent l’ICMP : un serveur peut donc ne pas répondre au ping tout en servant parfaitement le site, ou répondre au ping alors que le serveur web est arrêté.
Étape 4 : vérifiez le certificat TLS
Un problème de certificat rend le site inaccessible à tout le monde d’un coup, avec un avertissement du navigateur en pleine page, alors que le serveur lui-même va bien. Passez l’hôte dans le vérificateur SSL, ou regardez en ligne de commande :
openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 -noout -dates -subject
Les causes habituelles sont un certificat expiré après l’échec d’un renouvellement automatique, un certificat émis pour un autre nom ou un certificat intermédiaire manquant. Les erreurs de certificat SSL expliquées associe chaque avertissement du navigateur à sa solution.
Étape 5 : écartez le CDN ou le proxy
Si un CDN ou un reverse proxy se trouve devant le site, une page d’erreur peut venir du proxy et non de votre serveur. Les codes 52x de Cloudflare indiquent précisément où ça a cassé :
521 : le serveur d’origine a refusé la connexion.
522 : la connexion à l’origine a expiré.
525 : la négociation TLS avec l’origine a échoué.
526 : le certificat de l’origine n’est pas valide.
Pour tester l’origine sans le CDN, envoyez la requête directement à son adresse IP en conservant le nom d’hôte. Remplacez 203.0.113.10 par l’adresse de votre origine :
curl -sv -o /dev/null –resolve example.com:443:203.0.113.10 https://example.com/
Si l’origine répond correctement, regardez du côté du CDN : sa page de statut, les règles de pare-feu modifiées récemment, et s’il dispose toujours de la bonne adresse de l’origine. Si l’origine échoue aussi, passez au serveur.
Étape 6 : vérifiez le serveur web et l’application
Un code de statut 5xx signifie que la requête a atteint votre stack et que quelque chose y a échoué. Le code permet d’affiner :
500 : l’application a levé une erreur. Voir 500 Internal Server Error.
502 : le serveur web n’a pas obtenu de réponse valide du processus applicatif derrière lui, souvent parce que ce processus a planté. Voir 502 Bad Gateway.
503 : le service est surchargé ou en mode maintenance. Voir 503 Service Unavailable.
504 : l’application a mis trop de temps à répondre. Voir 504 Gateway Timeout.
Chaque code a sa propre page dans la référence des codes de statut HTTP. Sur le serveur, trois vérifications trouvent la plupart des causes :
df -h # un disque plein bloque bases de données, journaux et uploads
free -m # un manque de mémoire tue des processus
tail -n 50 /var/log/nginx/error.log # ou les journaux de votre serveur web et de l’app
Demandez-vous ensuite ce qui a changé. Un déploiement, une mise à jour d’extension, une modification de configuration ou une clé d’API expirée dans la dernière heure est la cause la plus probable, et revenir en arrière est souvent plus rapide que déboguer en production.
Étape 7 : vérifiez les dépendances
Votre site peut être en bonne santé alors que quelque chose dont il a besoin ne l’est pas. Une base de données à court de connexions, un serveur de cache arrêté, ou un fournisseur de paiement, d’e-mail ou de connexion en panne suffisent à casser des pages qui se chargent par ailleurs. Consultez les pages de statut de vos fournisseurs, et vérifiez les plus gros sur Is it down?, qui suit des services connus et leurs pannes récentes.
Quand le site est en ligne mais cassé
Certaines pannes répondent 200 : une liste de produits vide, un bouton de paiement qui ne fait rien, un message d’erreur dans une page par ailleurs normale. Un code de statut ne les détecte pas. Vérifiez que la page contient ce qu’elle doit contenir, et parcourez le parcours qui compte, comme la connexion ou le paiement, comme le ferait un client.
Pendant la réparation : prévenez les gens
Publiez une courte mise à jour dès que vous savez qu’il y a un problème, même si vous pouvez seulement dire que vous enquêtez, et annoncez l’heure de la prochaine mise à jour. Le générateur de mises à jour de statut en rédige une pour chaque étape, et le plan de communication d’incident précise qui dit quoi, et où.
Raccourcir la prochaine panne
Dans la plupart des pannes, le plus long est de s’en apercevoir. Avec une surveillance externe, vous apprenez le problème par une alerte plutôt que par un client, et vous partez de preuves plutôt que de suppositions. Voici ce qu’Uptimecheck vous apporte :
Des vérifications toutes les minutes depuis Stockholm, Londres et New York, chaque échec étant confirmé depuis un second emplacement avant que vous ne soyez alerté. Voir la surveillance de disponibilité.
Des preuves dans l’incident : l’adresse résolue par le DNS, les redirections, le certificat, les en-têtes et le début de la réponse, plus une capture d’écran quand le serveur a répondu ou un traceroute quand il n’a pas répondu. Voir comment fonctionnent les incidents et les preuves.
Des temps de réponse découpés en phases : DNS, connexion, TLS, serveur et téléchargement, pour qu’une couche lente se repère avant de tomber en panne.
Des rappels avant expiration pour les certificats et les domaines, et des alertes quand les enregistrements DNS changent.
Des vérifications de mots-clés et des parcours qui détectent une page qui répond 200 mais qui est cassée. Voir la surveillance des parcours.
Si un moniteur indique une panne alors que le site fonctionne chez vous, pourquoi un moniteur est en panne alors que votre site fonctionne explique comment interpréter la différence.
Soyez prévenu avant vos clients. Essayez Uptimecheck gratuitement pendant 14 jours, sans carte bancaire.