« Le site est tombé » recouvre quatre pannes très différentes avec quatre responsables différents. Ces quatre commandes, dans l'ordre, la situent - et chacune est rapide.

1. Le nom se résout-il ?

dig yourdomain.com +short

Pas de réponse veut dire DNS : le domaine, les serveurs de noms ou l'enregistrement. Rien côté serveur ne peut y remédier, et y redémarrer des services est du temps perdu.

2. L'adresse répond-elle ?

ping -c 3 1.2.3.4
curl -sI --max-time 10 http://1.2.3.4/

Un ping refusé alors que curl répond, c'est normal : beaucoup d'hébergeurs bloquent l'ICMP. Si aucun des deux ne répond, la machine est éteinte ou le pare-feu est fermé.

3. Le serveur web tourne-t-il ?

systemctl status nginx
ss -tulpn | grep -E ":80|:443"

Rien en écoute sur le 443 avec un enregistrement DNS qui marche : voilà toute la réponse.

4. Que renvoie-t-il réellement ?

curl -sI https://yourdomain.com/ | head -1

Un code de statut ici confie le problème au bon article : 502 c'est PHP, 504 un délai dépassé, 403 des permissions ou une règle, 500 l'application.

N'est-ce que vous ?

Avant toute chose, vérifiez depuis un téléphone en données mobiles. Un cache DNS local, un VPN ou un blocage du fournisseur d'accès touche une seule personne et ressemble exactement à une panne - et la moitié des pannes signalées, c'est cela.

Si tout ce qui précède est bon

  • Un CDN devant, en panne alors que l'origine se porte bien.
  • Un certificat expiré : le site charge en http et refuse en https.
  • Une règle de pare-feu qui a bloqué un pays, ou votre propre adresse après trop de tentatives de connexion.
Notez ce que vous trouvez à chaque étape. Donner au support « dig répond, le port 443 est fermé », c'est une correction en quelques minutes ; lui donner « le site est tombé », c'est une conversation.