Lister tous les domaines d’un serveur Nginx en une commande

Dernière mise à jour : 12 novembre 2026

Un serveur Nginx héberge souvent plus de sites qu'on ne s'en souvient : un par client, quelques anciens oubliés, des redirections. Avant de les surveiller, il faut savoir lesquels sont là.

Bonne nouvelle : Nginx sait déjà le dire. Il suffit de lui demander sa configuration complète.

La commande

À lancer sur le serveur, avec les droits administrateur :

sudo nginx -T 2>/dev/null \
  | awk '$1=="server_name" {for(i=2;i<=NF;i++){gsub(";","",$i); print $i}}' \
  | grep -v -E '^(_|~|\*)' \
  | sort -u

nginx -T affiche la configuration complète, fichiers inclus, puis awk garde les noms déclarés par server_name, grep écarte les noms spéciaux et sort -u supprime les doublons. Vous obtenez un domaine par ligne.

Pourquoi nginx -T plutôt que sites-enabled

Beaucoup de guides conseillent de lister le dossier /etc/nginx/sites-enabled. Ça marche sur une Debian ou une Ubuntu standard, et pas ailleurs.

Sur RHEL, Rocky ou AlmaLinux, les sites vivent dans conf.d, pas dans sites-enabled.
Un fichier peut en inclure un autre (include), parfois depuis un dossier personnalisé.
Un fichier présent dans sites-enabled peut être inclus nulle part : il est alors sans effet.
Un panneau de gestion (Plesk, par exemple) range ses fichiers où il veut.

nginx -T lit la configuration que Nginx applique vraiment, includes compris. C'est la source la plus fiable.

Les pièges

Le nom _ est une convention pour un bloc « par défaut » : ce n’est pas un domaine.
Un nom qui commence par ~ est une expression régulière, pas un domaine. Un nom à joker (*.exemple.fr) couvre plusieurs sous-domaines sans en nommer aucun.
Un bloc peut n’exister que pour rediriger (return 301) : le domaine est configuré, mais le site est ailleurs.
Un domaine configuré n'est pas forcément en ligne : son DNS peut pointer ailleurs depuis longtemps.
Les blocs server des modules mail et stream ne sont pas des sites web. Si vous en avez, lisez la sortie complète plutôt que la seule liste.
nginx -T affiche toute la configuration, y compris des chemins de clés et parfois des secrets. Ne collez pas sa sortie brute dans un ticket ou une conversation.

Et les sites qui ne passent pas par Nginx ?

Les conteneurs derrière Traefik, un serveur Apache ou Caddy sur la même machine n'apparaissent pas dans cette liste. Apache a sa commande équivalente (apachectl -S), Traefik déclare ses domaines dans les étiquettes des conteneurs. Faire le tour des quatre à la main est possible, mais c'est justement ce qu'on oublie de refaire après chaque nouveau client.

Ce que fait StatOps

L'agent StatOps exécute lui-même nginx -T, extrait les noms server_name et ignore _ et les expressions régulières. Le serveur écarte ensuite localhost, les adresses IP, les jokers et les noms en .local. Il fait la même chose pour Apache, Caddy, Traefik et Docker.

L'agent ne lit que les noms de domaine, pas le contenu des sites. Il tourne sous un utilisateur dédié, avec une règle sudo limitée à quelques commandes en lecture seule, dont nginx -T.

Chaque domaine trouvé apparaît dans le tableau de bord, prêt à être rattaché à un client. Il est alors surveillé (disponibilité, certificat) et figure dans le rapport mensuel. Voir comment surveiller les sites de ses clients.

Questions fréquentes

Comment lister les domaines Nginx sans nginx -T ?

En lisant les fichiers de /etc/nginx à la main avec grep -r server_name. Vous manquerez les fichiers inclus depuis un autre dossier et vous listerez des fichiers inactifs. nginx -T évite ces deux erreurs.

Faut-il être root pour lancer nginx -T ?

Oui ou sudo : Nginx lit des fichiers que seul root peut ouvrir, comme les clés des certificats. L'agent StatOps utilise une règle sudo limitée à cette commande.