Site Web Indisponible, mais le Serveur Est Accessible ? Tracez la Défaillance de DNS à l’Application

« SSH fonctionne, le site ne fonctionne pas » — Commencez par la bonne question

Les alertes commencent à se déclencher, les utilisateurs disent que le site est mort, et votre premier test vous donne une étrange sorte de soulagement : SSH vous laisse encore entrer. Ce moment semble rassurant parce que le serveur n’a pas disparu. Mais c’est aussi là que beaucoup de mauvais dépannage commence, parce que « je peux encore me connecter » n’est pas la même chose que « le site web devrait fonctionner ».

La question utile n’est pas « qu’est-ce que je peux redémarrer en premier ? » C’est « quelle couche a échoué en premier ? » Une session SSH fonctionnelle prouve que la machine est accessible sur le port 22. Elle ne prouve pas que le domaine se résout correctement. Elle ne prouve pas :

• que les ports 80 et 443 sont accessibles
• que HTTPS est sain
• que l’application derrière le serveur web répond

Ce guide est construit autour de cette distinction, et il reste concentré sur le diagnostic plutôt que d’essayer de devenir un manuel complet de nginx, DNS, TLS, Docker ou base de données.

⚠️ Avertissement : Redémarrer aveuglément nginx, Docker, PHP-FPM ou l’ensemble du VPS dans les premières minutes d’un incident peut effacer les indices dont vous avez besoin. Collectez d’abord une série de preuves, puis modifiez uniquement la couche qui a réellement échoué.

La Carte de Triage d’Une Minute

Avant d’aller en profondeur, orientez-vous. La forme de la défaillance vous indique souvent quelle couche mérite l’attention en premier, même si vous ne connaissez pas encore la cause racine.

Traitez le tableau suivant comme un raccourci de triage, pas comme un verdict final.

Ce qui importe, c’est la première étape cassée. Si DNS échoue, les couches ultérieures sont du bruit. Si 443 répond mais TLS échoue, l’application n’est pas encore votre première question. Le modèle mental ci-dessous est ce qui rend cette séquence logique au lieu d’aléatoire.

Pourquoi SSH ne prouve pas que le site web fonctionne

SSH et le trafic web sont des chemins différents avec des rôles différents. SSH sur le port 22 prouve que vous pouvez atteindre la machine par sa porte de gestion à distance. Un site web dépend des ports 80 et 443, plus des couches derrière eux. Ce sont des tests séparés, donc « serveur accessible » et « site web accessible » ne sont pas des déclarations interchangeables.

Le moyen le plus simple de le visualiser est comme un immeuble de bureaux. DNS aide un visiteur à trouver l’adresse de l’immeuble. Les ports 80 et 443 sont l’accueil pour les visiteurs publics. Le serveur web est la réceptionniste qui accepte la demande et décide où elle va ensuite. L’application est le bureau qui fait le vrai travail. Une base de données ou une autre dépendance peut se trouver plus loin dans l’immeuble. SSH est une entrée complètement différente. C’est utile pour le personnel, mais cela ne prouve pas que l’accueil est ouvert ou que le transfert au bureau fonctionne.

Browser
  ↓
DNS lookup
  ↓
IP address
  ↓
Port 80 / 443
  ↓
Web server
  ↓
App / upstream
  ↓
Database / dependency

Quand les gens disent qu’un service « écoute », ils veulent dire qu’il accepte réellement les connexions sur le point de terminaison attendu. C’est la distinction qui transforme un vague moment « le serveur est actif » en un chemin de demande traçable.

C’est important car HTTPS peut échouer avant que l’application ne réponde, et les défaillances de proxy ou d’application peuvent survenir après que le frontend soit déjà accessible. Le prochain mouvement est donc toujours le même : regarder de l’extérieur d’abord et trouver la dernière étape réussie de la demande.

Étape 1 : Reproduire la défaillance de l’extérieur du serveur

Commencez par le côté client, pas de l’intérieur du VPS. Si possible, testez d’abord depuis un autre réseau ou appareil pour ne pas confondre un cache DNS local, une ancienne entrée /etc/hosts, ou un problème de pare-feu/VPN local avec une véritable panne serveur.

Utilisez une requête externe détaillée pour voir jusqu’où la requête progresse avant d’échouer :

curl -v --connect-timeout 5 --max-time 15 https://example.com/

curl -v n’est pas un outil réservé aux experts ici. Lisez-le comme une trace de progression. Si le nom ne se résout jamais, vous êtes dans la branche DNS. Si la connexion s’établit puis affiche Connection refused, l’hôte a répondu mais rien d’utile n’accepte le trafic là-bas. Si cela s’arrête jusqu’au délai d’expiration, pensez au filtrage, au routage, ou à un blocage plus profond plus tard dans le chemin de la requête. Si vous recevez une réponse HTTP, même une page d’erreur, vous avez déjà dépassé la couche de connexion et êtes dans une branche supérieure.

💡 Conseil : Comparez IPv4 et IPv6 tôt. Un enregistrement AAAA oublié peut rendre la panne incohérente car certains clients préfèrent IPv6 en premier et d’autres non.

Exécutez le même test une fois par famille de protocoles quand la double pile est en jeu :

curl -4 -v --connect-timeout 5 --max-time 15 https://example.com/
curl -6 -v --connect-timeout 5 --max-time 15 https://example.com/

Si IPv4 fonctionne et IPv6 échoue, ou l’inverse, vous avez déjà réduit l’incident plus vite qu’un redémarrage de service ne l’aurait jamais fait. Si la défaillance commence à la résolution de nom ou au choix de destination, DNS est la prochaine branche propre à vérifier.

Étape 2 : Vérifier le DNS et confirmer la bonne destination

Avant de déboguer nginx, confirmez que le domaine envoie réellement les visiteurs vers le serveur que vous pensez. C’est particulièrement important après les migrations, les changements d’IP, les ajustements CDN ou les modifications partielles d’enregistrements.

Vérifiez d’abord les enregistrements publics :

dig +short A example.com
dig +short AAAA example.com

Ces deux lignes répondent à une question très pratique : où l’internet croit-il que example.com se trouve en ce moment ? Une forme d’échec courante est que SSH par IP atteint le nouveau VPS, mais le domaine pointe toujours vers l’ancienne adresse. Une autre est que l’enregistrement A a été mis à jour, mais l’enregistrement AAAA pointe toujours quelque part d’obsolète. Dans ce cas, seule une partie de votre trafic échoue.

📝 Remarque : curl --resolve est plus sûr que de modifier le DNS public en plein incident. Il vous permet de tester l’origine que vous avez l’intention d’utiliser tout en gardant le nom d’hôte et SNI intacts.

Utilisez curl --resolve pour forcer un test contre l’IP que vous attendez sans toucher aux enregistrements publics :

curl --resolve example.com:443:203.0.113.10 https://example.com/

Si cela fonctionne tandis que le domaine public échoue toujours, le serveur peut être correct et le DNS peut toujours être la couche cassée. Une remarque CDN délimitée vaut la peine d’être gardée à l’esprit ici. Si votre origine est verrouillée pour accepter le trafic uniquement à partir des plages d’IP CDN, un test d’origine directe peut échouer simplement parce que l’origine s’attend à du trafic edge, pas à des requêtes publiques arbitraires. Une fois la destination confirmée, la question suivante est de savoir si quelque chose d’utile répond sur 80 ou 443 là.

Étape 3 : Vérifier ce qui écoute sur 80/443

Basculez maintenant vers le serveur et posez une question précise : y a-t-il réellement quelque chose qui accepte les connexions web sur les ports attendus ? La machine peut être active, SSH peut fonctionner, et nginx peut même être installé. Pourtant, les ports web publics peuvent toujours n’avoir aucun listener utile.

Vérifiez d’abord les listeners :

sudo ss -ltnp

Une sortie vide pour :80 ou :443 signifie que rien d’utile n’écoute là. Un listener sur 127.0.0.1 signifie que le service n’accepte les connexions que depuis la machine locale. Un listener sur 0.0.0.0 signifie qu’il est lié sur les interfaces IPv4. [::] signifie généralement les interfaces IPv6. Ne supposez pas que la liaison IPv6 garantit automatiquement le chemin IPv4 dont vous avez besoin.

Utilisez ensuite un petit bundle de santé nginx avant de modifier quoi que ce soit :

sudo systemctl status nginx --no-pager -l
sudo nginx -t
sudo journalctl -u nginx --since '-30 minutes' --no-pager

• Si systemctl indique active (running), cela prouve seulement que le processus de service existe
• nginx -t vous indique si la config est valide
• journalctl montre si un rechargement récent a échoué, si un fichier de certificat a disparu, ou si un vhost s’est cassé au démarrage.

Pour les lecteurs Apache, la syntaxe équivalente de vérification est apachectl configtest. Une fois que vous savez que quelque chose écoute, la preuve suivante est plus spécifique : le bon site répond-il localement quand vous supprimez le réseau externe de l’équation ?

💡 Conseil : Testez d’abord la config, puis préférez reload à un redémarrage aveugle quand c’est approprié. Un reload valide la nouvelle config et conserve les anciens workers si la nouvelle config est mauvaise ; un redémarrage aveugle est beaucoup plus brutal au milieu d’un incident.

Étape 4 : Tester le site localement avec le bon hôte et SNI

C’est le bifurcation la plus importante de toute l’investigation. Un simple curl 127.0.0.1 peut être trompeur. De nombreux serveurs hébergent plusieurs sites et choisissent la réponse en fonction de l’en-tête Host ou, pour HTTPS, SNI. Vous ne demandez pas si quelque chose répond localement. Vous demandez si le chemin du site correct répond localement.

Utilisez des tests locaux qui préservent la logique du nom d’hôte :

curl -I http://127.0.0.1/ -H 'Host: example.com'
curl -v --resolve example.com:443:127.0.0.1 https://example.com/

# Only as a one-off diagnostic if you already know the cert is bad:
curl -vk --resolve example.com:443:127.0.0.1 https://example.com/

Un succès significatif est la page attendue, la redirection attendue, ou la réponse d’application attendue du site correct. Ce n’est pas l’hôte nginx par défaut, le mauvais certificat, ou un simple « il a retourné du HTML ». À partir de là, il y a trois résultats clairs : succès local, comportement de site incorrect ou certificat par défaut local, ou échec/timeout local. Un bon résultat local pointe vers des vérifications de pare-feu, fournisseur, CDN ou routage. Un mauvais résultat local vous garde à l’intérieur de la pile, dans les branches en amont ou TLS.

Étape 5 : Si cela fonctionne localement mais pas en externe, tracez le chemin réseau

Une fois que le test local est bon, arrêtez de douter de nginx un moment. La pile du site est probablement active sur le serveur, et la pièce manquante se trouve généralement quelque part entre le visiteur et ce service local qui fonctionne. Commencez par le pare-feu de l’hôte car c’est la limite externe la plus proche que vous contrôlez.

Inspectez les règles côté hôte avec l’outil que votre système utilise réellement, et faites une vérification rapide de la cohérence pour l’auto-blocage pendant que vous y êtes :

sudo nft list ruleset

# Or, on systems still using iptables directly:
sudo iptables-save
sudo ip6tables-save

# Fast sanity check for self-inflicted blocking:
sudo fail2ban-client status

Cette sortie affiche uniquement la couche du système d’exploitation invité. Elle n’affiche pas le filtrage côté fournisseur, les groupes de sécurité ou les règles de pare-feu au niveau du panneau qui se trouvent en dehors du VPS lui-même. Sur un VPS AlexHost, par exemple, le pare-feu machine et les contrôles réseau au niveau du panneau sont des questions distinctes. Les deux importent quand les tests locaux fonctionnent mais que les visiteurs publics échouent toujours.

⚠️ Avertissement : Si Docker publie des ports sur l’hôte, ne supposez pas que la sortie UFW raconte toute l’histoire. Docker peut acheminer le trafic des conteneurs publiés via NAT avant les chaînes habituelles d’UFW. Cela signifie que « UFW semble bon » ne signifie pas toujours que le chemin des paquets est bon.

Les CDN et les équilibreurs de charge méritent aussi leur propre branche ici. L’origine peut être saine et toujours inaccessible directement parce que seules les plages IP de périphérie sont autorisées à communiquer avec elle. Quand vous avez besoin de la preuve que les paquets arrivent du tout, utilisez tcpdump comme outil oui-ou-non :

📝 Remarque : Un test d’origine directe échoué derrière une liste blanche CDN pointe généralement vers la politique de périphérie, pas vers une origine morte. Dans cette configuration, l’origine est conçue pour faire confiance au chemin CDN, pas à chaque visiteur direct.

sudo tcpdump -ni any 'tcp port 80 or tcp port 443'

Si vous ne voyez aucun paquet SYN du tout, le trafic n’atteint pas le serveur. Si les SYN arrivent et qu’aucun SYN-ACK ne part, le serveur ou le chemin du pare-feu bloque toujours la transmission. Si aucun de ces modèles ne semble être le bloqueur, les défaillances restantes se trouvent généralement derrière le frontend dans la transmission en amont.

Étape 6 : Si le Frontend Répond mais le Site Est Toujours Cassé, Suivez l’Upstream

Dans cette branche, le serveur web est accessible, mais le prochain saut derrière lui n’est pas assez sain pour compléter la requête. Ici, « upstream » signifie le service auquel nginx transmet la requête ensuite : un processus d’application, un runtime soutenu par socket, un conteneur, ou une autre dépendance interne.

Les pages statiques fonctionnant tandis que la connexion, la recherche, le paiement, ou les routes API échouent est un indice fort que le frontend est présent et que l’échec commence au transfert derrière lui.

📝 Note : Traitez 502 comme « le prochain saut a répondu mal » et 504 comme « le prochain saut a répondu trop lentement ». Les deux sont des signes pour suivre le chemin upstream plutôt que de s’arrêter au frontend.

Inspectez le transfert actif, puis testez l’upstream directement :

sudo nginx -T

# Direct HTTP upstream example
curl -i http://127.0.0.1:3000/

# Unix-socket-backed HTTP example
curl --unix-socket /run/app.sock http://localhost/

Dans la sortie nginx, recherchez des directives telles que proxy_pass, fastcgi_pass, ou uwsgi_pass. Vous vérifiez si nginx pointe vers la bonne cible, sur le bon protocole, sur le bon port ou socket. Si des conteneurs sont impliqués, ajoutez une courte vérification de santé du conteneur au lieu de deviner :

docker ps
docker logs --tail 50 <container_name>
docker inspect --format '{{json .State.Health}}' <container_name>
docker port <container_name>

Si le test direct de l’application échoue, le problème est derrière le serveur web. S’il fonctionne directement mais échoue via nginx, la configuration du transfert est la branche à inspecter. La disponibilité de la base de données n’importe que comme vérification de dépendance ici, pas comme une exploration approfondie séparée. Si ce motif d’échec upstream se répète continuellement, c’est le bon moment pour passer à un guide de dépannage dédié au lieu d’étirer un incident en conjectures.

Étape 7 : Isoler les défaillances TLS et de certificat

Cette branche est plus étroite : quelque chose répond sur le port 443, mais le navigateur ne peut toujours pas établir une session HTTPS propre et fiable. Une connexion TCP réussie au port 443 ne prouve pas que le certificat, la correspondance du nom d’hôte ou le chemin de négociation est sain.

Inspectez le certificat réellement servi :

openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com -brief

C’est ici que vous détectez les formes d’échec courantes : le mauvais nom d’hôte, un certificat expiré, une chaîne incomplète, ou un renouvellement qui n’a jamais été terminé correctement. En termes simples, SNI indique au serveur quel nom d’hôte vous aviez l’intention d’utiliser. -verify_hostname vérifie si le certificat qu’il a servi correspond à ce nom d’hôte. Après la récupération, validez le chemin de renouvellement pour que cela ne devienne pas la prochaine panne :

⚠️ Avertissement : Si vous comptez sur la validation HTTP-01 pour le renouvellement de certificat, le port entrant 80 doit être accessible. Une règle de pare-feu ou du fournisseur bloquant le port 80 peut discrètement casser les renouvellements bien avant que les utilisateurs ne signalent que HTTPS semble mort.

sudo certbot renew --dry-run

Étape 8 : Vérifier la Pression des Ressources Avant de Conclure que C’est Aléatoire

Certains incidents ne sont pas du tout des défaillances de connectivité. Le chemin est techniquement intact, mais le serveur est trop affamé, bloqué ou surchargé pour répondre à temps. C’est à ce moment qu’un site peut sembler « partiellement vivant » d’un côté et toujours sembler mort pour les utilisateurs.

Exécutez un petit bundle de ressources de première passe :

df -h
df -i
free -h
uptime
vmstat 1 5
sudo journalctl -k -g 'oom|out of memory|killed process'

Lisez les résultats en motifs, pas isolément.

• df -h montre l’épuisement ordinaire du disque.
• df -i détecte l’épuisement des inode, où l’espace semble exister mais le système de fichiers ne peut pas créer plus d’entrées.
• free -h est important surtout quand la mémoire disponible s’effondre et que l’activité de swap augmente.
• uptime peut montrer une charge élevée même quand le CPU n’est pas saturé, ce qui signifie souvent que les tâches attendent sur la pression du disque ou de la mémoire plutôt que sur un calcul actif.
• Les lignes du journal du noyau concernant les événements OOM vous indiquent si le système a commencé à tuer des processus pour survivre.

Les graphiques du fournisseur peuvent confirmer la chronologie. Sur un VPS AlexHost, ils peuvent être utiles pour vérifier si les pics de RAM, disque ou I/O correspondent à la panne. Mais les preuves du terminal doivent toujours guider le diagnostic. Cette section n’est pas un guide de tuning ; c’est la branche qui vous dit que le site peut échouer sous pression plutôt que d’échouer à router.

Pensez par couches, pas en panique

Quand SSH fonctionne mais le site web ne s’ouvre pas, gardez la chaîne courte et reproductible :

1. reproduire l’échec en externe
2. identifier la dernière étape réussie
3. confirmer DNS et destination
4. vérifier un vrai listener sur 80/443
5. tester le bon site localement
6. se brancher sur le chemin réseau, upstream, TLS, ou ressources

💡 Conseil : Ne fermez pas votre dernière session SSH qui fonctionne jusqu’à ce que vous ayez confirmé qu’une nouvelle connexion fonctionne toujours et que vous ayez toujours un chemin d’accès de secours, comme l’accès à la console du fournisseur. Pendant un incident en direct, préserver le contrôle est aussi important que de corriger le premier symptôme.

Gardez les habitudes légères : surveillez en externe, conservez les logs, et testez les certificats avec certbot renew –dry-run. Sécurisez l’accès avec des sauvegardes et un chemin console. Les outils du fournisseur — pare-feu, graphiques, console (y compris AlexHost) — doivent soutenir le dépannage, pas le remplacer. Concentrez-vous sur la correction de la première couche cassée afin que chaque incident soit géré avec des preuves plus claires et moins de panique.