nginx sert le mauvais site : le piège du server_name manquant

En vérifiant qu'un déploiement récent était bien passé en prod, curl sur https://www.mon-domaine.fr m'a renvoyé... le HTML d'un tout autre site. Pas une erreur, pas un 502 : une vraie réponse 200, avec le contenu d'une autre application self-hébergée sur le même serveur.

Le symptôme

curl -sk https://www.mon-domaine.fr/ | grep -o '<title>[^<]*</title>'
# <title>Titre d'une autre app</title>

Alors que la version sans www fonctionnait parfaitement :

curl -sk https://mon-domaine.fr/ | grep -o '<title>[^<]*</title>'
# <title>Titre du bon site</title>

Premier réflexe : vérifier le certificat TLS réellement envoyé pour chaque nom, avec openssl s_client en forçant le SNI.

echo | openssl s_client -connect www.mon-domaine.fr:443 -servername www.mon-domaine.fr 2>/dev/null \
  | openssl x509 -noout -subject -ext subjectAltName
# subject=CN=autre-domaine.fr
# X509v3 Subject Alternative Name: DNS:autre-domaine.fr

Le certificat renvoyé pour www.mon-domaine.fr est celui d'un autre domaine complètement différent, hébergé sur la même machine. Ce n'est pas un problème DNS (les deux domaines pointaient vers la même IP, ce qui est normal sur un VPS mutualisé entre plusieurs projets) : c'est nginx qui, à la connexion TLS, choisit le mauvais bloc server.

La cause probable

Sur un serveur qui héberge plusieurs sites, chaque bloc server {} de nginx doit déclarer précisément les noms qu'il gère :

server {
    server_name mon-domaine.fr;
    ...
}

Si www.mon-domaine.fr n'est déclaré nulle part (ni comme server_name direct, ni comme alias), nginx ne sait pas à qui donner la requête. Sans directive default_server explicite ailleurs, il retombe silencieusement sur le premier bloc server défini dans la config, quel qu'il soit — ici, celui d'un tout autre projet self-hébergé sur le VPS. Pas de log d'erreur qui saute aux yeux, pas de 404 : juste le mauvais site, servi avec son propre certificat.

Le correctif

Ajouter explicitement www dans le bloc du bon site (ou faire une redirection dédiée vers l'apex) :

server {
    server_name mon-domaine.fr www.mon-domaine.fr;
    ...
}

puis régénérer le certificat pour couvrir les deux noms et recharger :

sudo certbot --nginx -d mon-domaine.fr -d www.mon-domaine.fr
sudo nginx -t && sudo systemctl reload nginx

Ce que je retiens

Sur un VPS qui héberge plusieurs domaines, un server_name oublié ne casse rien de visible en apparence — le serveur répond, en HTTPS, avec un code 200. C'est justement ce qui le rend traître : sans vérifier le certificat réellement servi (openssl s_client -servername ...), rien n'indique qu'on regarde le mauvais site. Un simple test dans un navigateur n'aurait probablement rien montré d'anormal si le cache DNS ou une redirection avait masqué le souci. Le réflexe à garder : tester chaque variante d'un domaine (www et sans www) séparément, pas seulement celle qu'on utilise au quotidien.

---

Des questions sur ce setup ? Écris-moi.