Wie man Nginx so konfiguriert, dass es auf mehreren Ports lauscht

Nginx kann gleichzeitig auf mehreren Ports lauschen, indem mehrere `listen`-Direktiven innerhalb eines oder mehrerer `server`-Blöcke in seiner Konfiguration hinzugefügt werden. Jede `listen`-Direktive bindet Nginx an eine bestimmte IP/Port-Kombination, sodass eine einzelne Serverinstanz HTTP-, HTTPS- und benutzerdefinierten Anwendungsverkehr auf verschiedenen Ports verarbeiten kann, ohne separate Prozesse auszuführen.

Diese Fähigkeit ist für Multi-Tenant-Umgebungen, Staging/Produktions-Port-Trennung, Reverse-Proxy-Architekturen und Microservice-Routing unverzichtbar – alles von einer einzigen VPS Hosting-Instanz aus.

Voraussetzungen

Bestätigen Sie vor dem Fortfahren Folgendes:

• Nginx ist installiert und der Dienst ist aktiv (`systemctl status nginx`)
• Sie haben `root`- oder `sudo`-Rechte auf dem Server
• Sie verstehen den Unterschied zwischen `/etc/nginx/nginx.conf` (globale Konfiguration) und `/etc/nginx/sites-available/` (seitenspezifische Konfigurationsblöcke)
• Firewall-Regeln (`ufw`, `iptables` oder eine Cloud-Sicherheitsgruppe) erlauben Datenverkehr auf den Ports, die Sie öffnen möchten
• Gültige SSL-Zertifikate sind verfügbar, wenn HTTPS-Ports konfiguriert werden (selbstsigniert oder von einer CA ausgestellt)

Nginx-Konfigurationsarchitektur: Was Sie zuerst wissen müssen

Nginx verwendet ein hierarchisches Konfigurationsmodell: Der `http`-Kontext enthält einen oder mehrere `server`-Blöcke, von denen jeder eine oder mehrere `listen`-Direktiven enthalten kann. Das Verständnis dieser Hierarchie verhindert die häufigsten Fehlkonfigurationsfehler.

Beteiligte Schlüsseldirektiven:

• `listen [address:]port [ssl] [http2] [default_server]` — bindet den Serverblock an einen bestimmten Port und eine optionale IP
• `server_name` — gleicht den `Host`-Header ab, um Anfragen an den richtigen Block weiterzuleiten
• `default_server` — legt fest, welcher Serverblock Anfragen verarbeitet, die keinem anderen `server_name` entsprechen

Speicherorte der Konfigurationsdateien nach Distribution:

Auf Debian-basierten Systemen müssen Dateien in `sites-available/` mit `sites-enabled/` verknüpft werden, damit sie wirksam werden:

“`bash

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

“`

Schritt 1: Nginx-Konfigurationsdatei öffnen

Für eine globale Änderung, die alle virtuellen Hosts betrifft:

“`bash

sudo nano /etc/nginx/nginx.conf

“`

Für eine seitenspezifische Konfiguration (empfohlen für die Produktion):

“`bash

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

“`

Die Verwendung seitenspezifischer Dateien wird dringend empfohlen. Sie isoliert Änderungen, vereinfacht das Rollback und verhindert, dass eine einzelne Fehlkonfiguration alle gehosteten Dienste zum Absturz bringt.

Schritt 2: Mehrere listen-Direktiven in einem einzelnen Serverblock konfigurieren

Das einfachste Multi-Port-Setup bindet einen Serverblock an mehrere Ports. Nginx wendet identische Routing-Logik an, unabhängig davon, über welchen Port der Client verbunden ist.

“`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;

}

“`

Was dies bewirkt:

• `listen 80;` — akzeptiert Standard-HTTP-Datenverkehr
• `listen 8080;` — akzeptiert Datenverkehr auf dem alternativen HTTP-Port (üblich für Entwicklungsumgebungen, interne APIs oder Load-Balancer-Integritätsprüfungen)
• Beide Ports liefern identische Inhalte aus `/var/www/html`

Sonderfall – Bindung an eine bestimmte IP-Adresse: Auf einem Server mit mehreren Netzwerkschnittstellen (z. B. einer öffentlichen IP und einer privaten LAN-IP) können Sie einschränken, auf welcher Schnittstelle Nginx lauscht:

“`nginx

listen 192.168.1.10:8080;

listen 0.0.0.0:80;

“`

Dies ist bei Multi-Homed-Server-Konfigurationen entscheidend, um eine unbeabsichtigte öffentliche Exposition interner Dienste zu verhindern.

Schritt 3: HTTPS auf mehreren Ports konfigurieren

HTTPS erfordert den `ssl`-Parameter bei der `listen`-Direktive sowie gültige Zertifikat-/Schlüsselpfade. Das folgende Beispiel bindet HTTPS sowohl an den Standard-Port 443 als auch an einen benutzerdefinierten Port 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;

}

}

“`

Warum Port 8443 häufig verwendet wird:

• Ermöglicht HTTPS-Datenverkehr in Umgebungen, in denen Port 443 durch vorgelagerte Firewalls blockiert ist
• Wird in der Entwicklung/im Staging verwendet, um einen sicheren Server zu betreiben, ohne mit einem Produktionsdienst auf Port 443 in Konflikt zu geraten
• Wird von einigen Anwendungs-Frameworks (Tomcat, Node.js-Proxys) benötigt, die HTTPS auf nicht standardmäßigen Ports bereitstellen

Kritische Falle: Das Weglassen von `ssl_protocols` und `ssl_ciphers` lässt Nginx möglicherweise schwache Standardwerte verwenden. Definieren Sie TLS-Parameter immer explizit, insbesondere auf Servern, die sensible Daten verarbeiten. Wenn Sie ein vertrauenswürdiges Zertifikat anstelle eines selbstsignierten benötigen, beseitigen SSL-Zertifikate von einer anerkannten CA Browser-Warnungen und erfüllen moderne HSTS-Anforderungen.

Schritt 4: Unterschiedliche Inhalte auf verschiedenen Ports bereitstellen

Wenn Ports unterschiedliche Anwendungen bereitstellen müssen – beispielsweise eine öffentliche Website auf Port 80 und ein internes Admin-Panel auf Port 8080 – verwenden Sie separate `server`-Blöcke:

“`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;

}

}

“`

Praxisnahe Anwendungsfälle für portbasierte Inhaltsseparation:

• Port 80/443: Öffentlich zugängliche Website
• Port 8080: Interne REST-API oder Microservice-Endpunkt
• Port 8443: Sicheres Admin-Dashboard, eingeschränkt durch IP-Allowlist
• Port 9000: Metriken-Endpunkt für Prometheus-Scraping (niemals öffentlich zugänglich)
• Port 3000/5000: Reverse Proxy zu einer Node.js- oder Python-Anwendung

Schritt 5: Nginx als Reverse Proxy auf mehreren Ports verwenden

Ein gängiges Produktionsmuster ist die Verwendung von Nginx, um verschiedene Ports an verschiedene Backend-Anwendungsserver weiterzuleiten:

“`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;

}

}

“`

Dieses Muster ist das Rückgrat containerisierter Deployments auf einem Dedicated Server, auf dem mehrere Docker-Container auf verschiedenen internen Ports laufen und Nginx als einziger externer Einstiegspunkt fungiert.

Schritt 6: Konfiguration validieren

Starten Sie Nginx niemals neu, ohne zuvor die Konfigurationssyntax zu testen. Ein Syntaxfehler führt dazu, dass der Dienst beim Neuladen fehlschlägt und alle gehosteten Websites zum Absturz bringt.

“`bash

sudo nginx -t

“`

Erwartete Ausgabe bei Erfolg:

“`

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

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

“`

Wenn Fehler auftreten, gibt die Ausgabe die Datei und Zeilennummer an. Beheben Sie alle gemeldeten Probleme, bevor Sie fortfahren.

Für ein Neuladen ohne Ausfallzeit (gegenüber einem vollständigen Neustart in der Produktion bevorzugt):

“`bash

sudo systemctl reload nginx

“`

Ein vollständiger Neustart ist nur erforderlich, wenn `worker_processes`, `user` oder andere Direktiven auf Master-Prozess-Ebene geändert werden:

“`bash

sudo systemctl restart nginx

“`

Schritt 7: Überprüfen, ob Nginx auf den richtigen Ports lauscht

Bestätigen Sie nach dem Anwenden der Konfiguration, dass Nginx sich an die erwarteten Ports gebunden hat, indem Sie `ss` verwenden (gegenüber dem veralteten `netstat` bevorzugt):

“`bash

sudo ss -tlnp | grep nginx

“`

Beispielausgabe:

“`

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))

“`

Wenn ein Port nicht erscheint, prüfen Sie:

1. Die `listen`-Direktiven-Syntax in der Konfigurationsdatei
2. Ob ein anderer Prozess diesen Port bereits belegt: `sudo ss -tlnp | grep :8080`
3. Ob `nginx -t` ohne Fehler bestanden hat
4. SELinux- oder AppArmor-Richtlinien, die die Bindung an nicht standardmäßige Ports blockieren könnten

Testen mit curl über die Befehlszeile (zuverlässiger als ein Browser zum Debuggen):

“`bash

curl -I http://example.com

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

curl -Ik https://example.com

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

“`

Das `-I`-Flag ruft nur Header ab. Eine `200 OK`- oder `301 Moved Permanently`-Antwort bestätigt, dass der Port aktiv ist und Nginx korrekt antwortet.

Schritt 8: Firewall-Ports öffnen

Das Lauschen auf einem Port in Nginx ist unzureichend, wenn die Host-Firewall eingehende Verbindungen blockiert. Stellen Sie sicher, dass die Ports erlaubt sind:

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 (direkt):

“`bash

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

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

“`

Bei Cloud-Infrastrukturen (AWS EC2, DigitalOcean, Hetzner) müssen Sie auch die Sicherheitsgruppen- oder Cloud-Firewall-Regeln auf Anbieterebene aktualisieren – Änderungen an der Host-Firewall allein sind nicht ausreichend.

Vergleich: Einzel-Port- vs. Multi-Port-Nginx-Konfigurationen

Häufige Fallstricke und wie man sie vermeidet

Port-Konflikt mit bestehenden Diensten: Port 80 wird möglicherweise bereits von Apache verwendet. Führen Sie `sudo ss -tlnp | grep :80` aus, bevor Sie konfigurieren. Stoppen Sie konfliktverursachende Dienste oder konfigurieren Sie sie so, dass sie andere Ports verwenden.

`default_server`-Konflikte: Wenn mehrere Serverblöcke `default_server` weglassen oder mehrere Blöcke es für denselben Port beanspruchen, verwendet Nginx den ersten Block in der Dateireihenfolge. Seien Sie explizit:

“`nginx

listen 80 default_server;

“`

IPv6 nicht abgedeckt: Das Hinzufügen von `listen 80;` bindet nur an IPv4. Für Dual-Stack-Server fügen Sie hinzu:

“`nginx

listen [::]:80;

listen [::]:8080;

“`

SELinux blockiert nicht standardmäßige Ports: Auf RHEL/CentOS mit SELinux im Durchsetzungsmodus kann Nginx ohne explizite Genehmigung keine Ports binden, die nicht in seiner Richtlinie enthalten sind:

“`bash

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

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

“`

Vergessen, nach Änderungen neu zu laden: Konfigurationsänderungen haben keine Wirkung, bis Nginx neu geladen wird. Automatisieren Sie dies in CI/CD-Pipelines mit einem Post-Deploy-`nginx -t && systemctl reload nginx`-Schritt.

Praktische Entscheidungsmatrix

Verwenden Sie diese Checkliste, um das richtige Multi-Port-Konfigurationsmuster für Ihr Szenario zu bestimmen:

• Gleicher Inhalt, mehrere Ports — Verwenden Sie mehrere `listen`-Direktiven in einem einzelnen `server`-Block
• Unterschiedlicher Inhalt pro Port — Verwenden Sie separate `server`-Blöcke mit unterschiedlichen `root`-Verzeichnissen
• Unterschiedliche Backend-Anwendungen pro Port — Verwenden Sie separate `server`-Blöcke mit `proxy_pass`, die auf verschiedene Upstream-Adressen verweisen
• Einen nicht standardmäßigen Port absichern — Fügen Sie `ssl` zur `listen`-Direktive hinzu und referenzieren Sie Ihre Zertifikatspfade; stellen Sie sicher, dass das SAN des Zertifikats die Domain abdeckt
• Einen Port auf internen Datenverkehr beschränken — Fügen Sie `allow`/`deny`-Direktiven hinzu oder binden Sie `listen` nur an eine private IP
• Betrieb auf einem VPS mit cPanel — Überprüfen Sie, ob die integrierte Apache/Nginx-Konfiguration von cPanel keine Konflikte verursacht; verwenden Sie den „Include Editor” von cPanel oder ein dediziertes Nginx-Konfigurations-Drop-in-Verzeichnis
• Verwaltung mehrerer Control-Panel-Optionen — Prüfen Sie verfügbare VPS Control Panels, um eines zu finden, das die Nginx-Port-Verwaltung über eine GUI bereitstellt

FAQ

Kann Nginx auf demselben Port über mehrere Serverblöcke lauschen?

Ja. Mehrere `server`-Blöcke können denselben Port teilen. Nginx unterscheidet zwischen ihnen mithilfe der `server_name`-Direktive, die den HTTP-`Host`-Header abgleicht. Wenn kein `server_name` übereinstimmt, verarbeitet der `default_server`-Block die Anfrage.

Beeinträchtigt das Hinzufügen weiterer listen-Ports die Nginx-Leistung?

Der Overhead ist vernachlässigbar. Jede `listen`-Direktive fügt dem Nginx-Master-Prozess einen Dateideskriptor hinzu. Das praktische Limit ist die Obergrenze für offene Dateideskriptoren des Systems (`ulimit -n`), nicht die Anzahl der Ports. Für Hochlast-Deployments passen Sie `worker_rlimit_nofile` und `worker_connections` in `nginx.conf` an.

Wie leite ich den gesamten Datenverkehr von Port 8080 auf Port 80 um?

Verwenden Sie einen dedizierten Serverblock mit einer `return`-Direktive:

“`nginx

server {

listen 8080;

server_name example.com;

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

}

“`

Warum lauscht Nginx nicht auf einem Port, obwohl die Konfiguration korrekt aussieht?

Die vier häufigsten Ursachen sind: (1) Die Konfiguration wurde nach der Bearbeitung nicht neu geladen, (2) ein anderer Prozess ist bereits an diesen Port gebunden, (3) eine Firewall-Regel blockiert den Port, oder (4) SELinux/AppArmor verhindert die Bindung. Gehen Sie jede Ursache systematisch mit `ss -tlnp`, `nginx -t` und Firewall-Statusbefehlen durch.

Kann ich unterschiedliche SSL-Zertifikate für verschiedene HTTPS-Ports auf derselben Domain verwenden?

Ja. Jeder `server`-Block hat seine eigenen `ssl_certificate`- und `ssl_certificate_key`-Direktiven. Zwei Serverblöcke können auf den Ports 443 bzw. 8443 lauschen und auf völlig unterschiedliche Zertifikatsdateien verweisen, selbst für denselben `server_name`. Dies ist nützlich beim Rotieren von Zertifikaten oder beim Betrieb eines Legacy-Zertifikats neben einem neuen während einer Übergangsphase.