Comment configurer Nginx pour écouter sur plusieurs ports

Nginx peut écouter sur plusieurs ports simultanément en ajoutant plusieurs directives `listen` dans un ou plusieurs blocs `server` dans sa configuration. Chaque directive `listen` lie Nginx à une combinaison IP/port spécifique, permettant à une seule instance de serveur de gérer le trafic HTTP, HTTPS et les applications personnalisées sur des ports distincts sans exécuter de processus séparés.

Cette capacité est essentielle pour les environnements multi-locataires, la séparation des ports staging/production, les architectures de proxy inverse et le routage de microservices — le tout depuis une seule instance de VPS Hosting.

Prérequis

Avant de continuer, confirmez les points suivants :

• Nginx est installé et le service est actif (`systemctl status nginx`)
• Vous disposez des privilèges `root` ou `sudo` sur le serveur
• Vous comprenez la différence entre `/etc/nginx/nginx.conf` (configuration globale) et `/etc/nginx/sites-available/` (blocs de configuration par site)
• Les règles de pare-feu (`ufw`, `iptables`, ou un groupe de sécurité cloud) autorisent le trafic sur les ports que vous souhaitez ouvrir
• Des certificats SSL valides sont disponibles si vous configurez des ports HTTPS (auto-signés ou émis par une CA)

Architecture de configuration Nginx : ce que vous devez savoir en premier

Nginx utilise un modèle de configuration hiérarchique : le contexte `http` contient un ou plusieurs blocs `server`, chacun pouvant contenir une ou plusieurs directives `listen`. Comprendre cette hiérarchie permet d’éviter les erreurs de configuration les plus courantes.

Directives clés impliquées :

• `listen [address:]port [ssl] [http2] [default_server]` — lie le bloc serveur à un port spécifique et une IP optionnelle
• `server_name` — correspond à l’en-tête `Host` pour router les requêtes vers le bon bloc
• `default_server` — désigne le bloc serveur qui gère les requêtes ne correspondant à aucun autre `server_name`

Emplacements des fichiers de configuration par distribution :

Sur les systèmes basés sur Debian, les fichiers dans `sites-available/` doivent être liés symboliquement à `sites-enabled/` pour prendre effet :

“`bash

sudo ln -s /etc/nginx/sites-available/example.conf /etc/nginx/sites-enabled/

“`

Étape 1 : Ouvrir le fichier de configuration Nginx

Pour une modification globale affectant tous les hôtes virtuels :

“`bash

sudo nano /etc/nginx/nginx.conf

“`

Pour une configuration spécifique à un site (recommandée pour la production) :

“`bash

sudo nano /etc/nginx/sites-available/example.conf

“`

L’utilisation de fichiers spécifiques aux sites est fortement préférée. Cela isole les modifications, simplifie le retour en arrière et empêche une seule erreur de configuration de mettre hors service tous les services hébergés.

Étape 2 : Configurer plusieurs directives listen dans un seul bloc serveur

La configuration multi-port la plus simple lie un bloc serveur à plusieurs ports. Nginx appliquera une logique de routage identique quel que soit le port par lequel le client s’est connecté.

“`nginx

server {

listen 80;

listen 8080;

server_name example.com;

root /var/www/html;

index index.html index.htm;

location / {

try_files $uri $uri/ =404;

}

access_log /var/log/nginx/example_access.log;

error_log /var/log/nginx/example_error.log warn;

}

“`

Ce que cela fait :

• `listen 80;` — accepte le trafic HTTP standard
• `listen 8080;` — accepte le trafic sur le port HTTP alternatif (courant pour les environnements de développement, les API internes ou les vérifications de santé des équilibreurs de charge)
• Les deux ports servent un contenu identique depuis `/var/www/html`

Cas particulier — liaison à une adresse IP spécifique : Sur un serveur avec plusieurs interfaces réseau (par exemple, une IP publique et une IP LAN privée), vous pouvez restreindre l’interface sur laquelle Nginx écoute :

“`nginx

listen 192.168.1.10:8080;

listen 0.0.0.0:80;

“`

Ceci est essentiel dans les configurations de serveurs multi-hébergés pour éviter l’exposition publique non intentionnelle des services internes.

Étape 3 : Configurer HTTPS sur plusieurs ports

HTTPS nécessite le paramètre `ssl` sur la directive `listen` et des chemins valides vers le certificat et la clé. L’exemple suivant lie HTTPS au port standard 443 et à un port personnalisé 8443 :

“`nginx

server {

listen 443 ssl;

listen 8443 ssl;

server_name example.com;

ssl_certificate /etc/nginx/ssl/example.com.crt;

ssl_certificate_key /etc/nginx/ssl/example.com.key;

Modern TLS hardening

ssl_protocols TLSv1.2 TLSv1.3;

ssl_ciphers HIGH:!aNULL:!MD5;

ssl_prefer_server_ciphers on;

ssl_session_cache shared:SSL:10m;

ssl_session_timeout 10m;

root /var/www/html;

index index.html;

location / {

try_files $uri $uri/ =404;

}

}

“`

Pourquoi le port 8443 est couramment utilisé :

• Permet le trafic HTTPS dans les environnements où le port 443 est bloqué par des pare-feux en amont
• Utilisé en développement/staging pour exécuter un serveur sécurisé sans conflit avec un service de production sur le port 443
• Requis par certains frameworks d’application (Tomcat, proxies Node.js) qui exposent HTTPS sur des ports non standard

Piège critique : Omettre `ssl_protocols` et `ssl_ciphers` laisse Nginx utiliser des valeurs par défaut potentiellement faibles. Définissez toujours explicitement les paramètres TLS, en particulier sur les serveurs traitant des données sensibles. Si vous avez besoin d’un certificat de confiance plutôt qu’un certificat auto-signé, les SSL Certificates d’une CA reconnue éliminent les avertissements du navigateur et satisfont aux exigences modernes HSTS.

Étape 4 : Servir différents contenus sur différents ports

Lorsque les ports doivent servir des applications distinctes — par exemple, un site web public sur le port 80 et un panneau d’administration interne sur le port 8080 — utilisez des blocs `server` séparés :

“`nginx

server {

listen 80;

server_name example.com;

root /var/www/public;

index index.html;

location / {

try_files $uri $uri/ =404;

}

}

server {

listen 8080;

server_name example.com;

root /var/www/admin;

index index.html;

Restrict admin panel to internal network only

location / {

allow 10.0.0.0/8;

allow 192.168.0.0/16;

deny all;

try_files $uri $uri/ =404;

}

}

“`

Cas d’utilisation réels pour la séparation de contenu par port :

• Port 80/443 : Site web public
• Port 8080 : API REST interne ou point de terminaison de microservice
• Port 8443 : Tableau de bord d’administration sécurisé restreint par liste d’autorisation IP
• Port 9000 : Point de terminaison de métriques pour le scraping Prometheus (jamais exposé publiquement)
• Port 3000/5000 : Proxy inverse vers une application Node.js ou Python

Étape 5 : Utiliser Nginx comme proxy inverse sur plusieurs ports

Un schéma de production courant consiste à utiliser Nginx pour proxifier différents ports vers différents serveurs d’application backend :

“`nginx

server {

listen 80;

server_name app.example.com;

location / {

proxy_pass http://127.0.0.1:3000;

proxy_http_version 1.1;

proxy_set_header Upgrade $http_upgrade;

proxy_set_header Connection 'upgrade';

proxy_set_header Host $host;

proxy_cache_bypass $http_upgrade;

}

}

server {

listen 8080;

server_name app.example.com;

location / {

proxy_pass http://127.0.0.1:4000;

proxy_http_version 1.1;

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

}

}

“`

Ce schéma est la colonne vertébrale des déploiements conteneurisés sur un Dedicated Server où plusieurs conteneurs Docker s’exécutent sur différents ports internes et Nginx agit comme point d’entrée externe unique.

Étape 6 : Valider la configuration

Ne redémarrez jamais Nginx sans avoir d’abord testé la syntaxe de la configuration. Une erreur de syntaxe empêchera le service de se recharger, mettant hors service tous les sites hébergés.

“`bash

sudo nginx -t

“`

Sortie attendue en cas de succès :

“`

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok

nginx: configuration file /etc/nginx/nginx.conf test is successful

“`

Si des erreurs apparaissent, la sortie indiquera le fichier et le numéro de ligne. Corrigez tous les problèmes signalés avant de continuer.

Pour un rechargement sans interruption (préféré à un redémarrage complet en production) :

“`bash

sudo systemctl reload nginx

“`

Un redémarrage complet n’est nécessaire que lors de la modification de `worker_processes`, `user`, ou d’autres directives au niveau du processus maître :

“`bash

sudo systemctl restart nginx

“`

Étape 7 : Vérifier que Nginx écoute sur les bons ports

Après avoir appliqué la configuration, confirmez que Nginx s’est lié aux ports attendus en utilisant `ss` (préféré à la commande obsolète `netstat`) :

“`bash

sudo ss -tlnp | grep nginx

“`

Exemple de sortie :

“`

LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=1234,fd=6))

LISTEN 0 511 0.0.0.0:8080 0.0.0.0:* users:(("nginx",pid=1234,fd=7))

LISTEN 0 511 0.0.0.0:443 0.0.0.0:* users:(("nginx",pid=1234,fd=8))

LISTEN 0 511 0.0.0.0:8443 0.0.0.0:* users:(("nginx",pid=1234,fd=9))

“`

Si un port n’apparaît pas, vérifiez :

1. La syntaxe de la directive `listen` dans le fichier de configuration
2. Si un autre processus occupe déjà ce port : `sudo ss -tlnp | grep :8080`
3. Si `nginx -t` s’est exécuté sans erreurs
4. Les politiques SELinux ou AppArmor qui peuvent bloquer la liaison sur des ports non standard

Test avec curl depuis la ligne de commande (plus fiable qu’un navigateur pour le débogage) :

“`bash

curl -I http://example.com

curl -I http://example.com:8080

curl -Ik https://example.com

curl -Ik https://example.com:8443

“`

L’indicateur `-I` récupère uniquement les en-têtes. Une réponse `200 OK` ou `301 Moved Permanently` confirme que le port est actif et que Nginx répond correctement.

Étape 8 : Ouvrir les ports du pare-feu

Écouter sur un port dans Nginx est insuffisant si le pare-feu hôte bloque les connexions entrantes. Assurez-vous que les ports sont autorisés :

UFW (Ubuntu/Debian) :

“`bash

sudo ufw allow 80/tcp

sudo ufw allow 443/tcp

sudo ufw allow 8080/tcp

sudo ufw allow 8443/tcp

sudo ufw reload

“`

firewalld (CentOS/RHEL/AlmaLinux) :

“`bash

sudo firewall-cmd –permanent –add-port=8080/tcp

sudo firewall-cmd –permanent –add-port=8443/tcp

sudo firewall-cmd –reload

“`

iptables (direct) :

“`bash

sudo iptables -A INPUT -p tcp –dport 8080 -j ACCEPT

sudo iptables -A INPUT -p tcp –dport 8443 -j ACCEPT

“`

Sur l’infrastructure cloud (AWS EC2, DigitalOcean, Hetzner), vous devez également mettre à jour le groupe de sécurité ou les règles de pare-feu cloud au niveau du fournisseur — les modifications du pare-feu au niveau de l’hôte seules ne sont pas suffisantes.

Comparaison : configurations Nginx mono-port vs. multi-ports

Pièges courants et comment les éviter

Conflit de port avec des services existants : Le port 80 peut déjà être utilisé par Apache. Exécutez `sudo ss -tlnp | grep :80` avant de configurer. Arrêtez les services en conflit ou reconfigurez-les pour utiliser des ports différents.

Conflits `default_server` : Si plusieurs blocs serveur omettent `default_server` ou si plusieurs blocs le revendiquent pour le même port, Nginx utilisera le premier bloc dans l’ordre des fichiers. Soyez explicite :

“`nginx

listen 80 default_server;

“`

IPv6 non couvert : Ajouter `listen 80;` ne lie qu’à IPv4. Pour les serveurs dual-stack, ajoutez :

“`nginx

listen [::]:80;

listen [::]:8080;

“`

SELinux bloquant les ports non standard : Sur RHEL/CentOS avec SELinux en mode enforcing, Nginx ne peut pas se lier à des ports absents de sa politique sans autorisation explicite :

“`bash

sudo semanage port -a -t http_port_t -p tcp 8080

sudo semanage port -a -t http_port_t -p tcp 8443

“`

Oublier de recharger après les modifications : Les modifications de configuration n’ont aucun effet tant que Nginx n’est pas rechargé. Automatisez cela dans les pipelines CI/CD avec une étape `nginx -t && systemctl reload nginx` post-déploiement.

Matrice de décision pratique

Utilisez cette liste de contrôle pour déterminer le bon schéma de configuration multi-port pour votre scénario :

• Même contenu, plusieurs ports — Utilisez plusieurs directives `listen` dans un seul bloc `server`
• Contenu différent par port — Utilisez des blocs `server` séparés avec des répertoires `root` distincts
• Applications backend différentes par port — Utilisez des blocs `server` séparés avec `proxy_pass` pointant vers différentes adresses upstream
• Sécuriser un port non standard — Ajoutez `ssl` à la directive `listen` et référencez vos chemins de certificat ; assurez-vous que le SAN du certificat couvre le domaine
• Restreindre un port au trafic interne — Ajoutez des directives `allow`/`deny` ou liez `listen` à une IP privée uniquement
• Fonctionnement sur un VPS avec cPanel — Vérifiez que la configuration Apache/Nginx intégrée de cPanel n’entre pas en conflit ; utilisez l’« Include Editor » de cPanel ou un répertoire de configuration Nginx dédié
• Gestion de plusieurs options de panneau de contrôle — Consultez les VPS Control Panels disponibles pour en trouver un qui expose la gestion des ports Nginx via une interface graphique

FAQ

Nginx peut-il écouter sur le même port dans plusieurs blocs serveur ?

Oui. Plusieurs blocs `server` peuvent partager le même port. Nginx les différencie en utilisant la directive `server_name`, qui correspond à l’en-tête HTTP `Host`. Si aucun `server_name` ne correspond, le bloc `default_server` gère la requête.

L’ajout de ports listen supplémentaires affecte-t-il les performances de Nginx ?

La surcharge est négligeable. Chaque directive `listen` ajoute un descripteur de fichier au processus maître Nginx. La limite pratique est le plafond de descripteurs de fichiers ouverts du système (`ulimit -n`), et non le nombre de ports. Pour les déploiements à fort trafic, ajustez `worker_rlimit_nofile` et `worker_connections` dans `nginx.conf`.

Comment rediriger tout le trafic du port 8080 vers le port 80 ?

Utilisez un bloc serveur dédié avec une directive `return` :

“`nginx

server {

listen 8080;

server_name example.com;

return 301 http://example.com$request_uri;

}

“`

Pourquoi Nginx n’écoute-t-il pas sur un port même si la configuration semble correcte ?

Les quatre causes les plus courantes sont : (1) la configuration n’a pas été rechargée après modification, (2) un autre processus est déjà lié à ce port, (3) une règle de pare-feu bloque le port, ou (4) SELinux/AppArmor empêche la liaison. Examinez chaque cause systématiquement en utilisant `ss -tlnp`, `nginx -t`, et les commandes de statut du pare-feu.

Puis-je utiliser différents certificats SSL pour différents ports HTTPS sur le même domaine ?

Oui. Chaque bloc `server` possède ses propres directives `ssl_certificate` et `ssl_certificate_key`. Deux blocs serveur peuvent écouter respectivement sur les ports 443 et 8443 et référencer des fichiers de certificat entièrement différents, même pour le même `server_name`. Ceci est utile lors de la rotation des certificats ou de l’exécution d’un certificat hérité aux côtés d’un nouveau pendant une période de transition.