Un site inaccessible échoue à une étape précise. Le nom ne se résout pas, la connexion n’aboutit pas, le certificat est refusé, ou le serveur répond un code d’erreur. Chaque étape a un correctif différent. Redémarrer PHP quand le domaine a expiré ne change rien. Tout mélanger coûte l’heure où les visiteurs partent.
Lire le message avant d’agir
Depuis un réseau qui n’est pas celui du bureau (partage 4G), en navigation privée, notez la phrase exacte du navigateur ou le code.
| Ce que vous voyez | Étape en échec | Piste |
|---|---|---|
« Serveur introuvable », NXDOMAIN | DNS | Domaine, enregistrements, résolveur |
| Tourne longtemps, puis délai | Réseau ou serveur muet | Pare-feu, mauvaise IP, machine arrêtée |
| Avertissement de certificat | TLS | Date, nom, chaîne. Voir l’incident certificat |
403 | Droit d’accès | Pare-feu, pays, fichier d’auth |
500 | Application | PHP, base, plugin, déploiement |
502, 503, 504, 522 | Proxy ou origine saturée | Maintenance, timeout, hébergeur |
| Page d’un autre site | Mauvais vhost ou DNS | L’IP ne sert plus votre contenu |
Les familles 4xx et 5xx sont détaillées dans différence entre 4xx et 5xx. Un 503 prévu pour une maintenance n’est pas une panne à « réparer » comme un 500 : gérer une 503. Un 522 est typiquement le proxy qui n’obtient pas de réponse de l’origine : erreur 522.
Quatre commandes pour situer l’étape
À lancer depuis une machine qui voit la même panne, en remplaçant le domaine :
``bash
dig exemple.fr A +short
curl -sI --max-time 20 https://exemple.fr
curl -sI --max-time 20 http://exemple.fr
``
dig sans réponse, ou une IP inattendue, fixe le travail sur le DNS et le registrar. La propagation se vérifie comme dans propagation DNS. Si le nom expire ces jours-ci, ouvrez le registrar avant l’hébergeur : renouvellement du domaine.
curl qui échoue au handshake TLS : lisez la date et le nom du certificat. Ce n’est pas une erreur PHP. Si le certificat est déjà dépassé, suivez SSL expiré : que faire.
curl qui affiche HTTP/1.1 500 (ou 503) : le TLS et le DNS fonctionnent. Regardez le journal PHP ou du serveur web à l’heure de l’essai, et le dernier déploiement. Un plugin ajouté il y a une heure se désactive plus vite qu’une restauration complète.
Aucun de ces essais ne vaut s’il est lancé sur le serveur lui-même vers localhost. Localhost peut répondre pendant que le pare-feu ou le DNS public, eux, ne laissent personne entrer. Le contrôle utile vient de l’extérieur. Un service comme SiteGarde interroge l’URL comme un visiteur, et montre le code réellement servi.
Si seulement certains le voient
Vous, oui, un client, non : cache, DNS de son opérateur, ou blocage de son pays. Le cas géographique est dans site inaccessible depuis certains pays. Vous, non, le reste du monde, oui : votre résolveur, votre fichier hosts, ou un pare-feu de bureau. Demandez à quelqu’un hors de l’entreprise, ou utilisez le test de disponibilité depuis un autre réseau.
Décider de la suite
- DNS ou domaine : registrar et zone, pas le thème.
- Certificat : renouvellement ou installation de la chaîne, puis rechargement du serveur web.
5xxjuste après une mise à jour : revenir à la version précédente du déploiement si les données n’ont pas bougé.- Fichiers ou base détruits : là, et seulement là, le plan de reprise.
- Maintenance voulue : page
503servie ailleurs si l’origine est arrêtée, sinon elle tombe avec le serveur.
Notez l’heure, le symptôme et la couche. La personne d’astreinte suivante ne doit pas recommencer par « vider le cache » si vous avez déjà prouvé que le nom ne se résout plus.