Container hinter deiner Domain (Reverse Proxy)

Dein Container lauscht auf 127.0.0.1:8123 — Besucher kommen aber über deinedomain.de auf Port 443. Die Brücke schlägt der nginx-Reverse-Proxy, den Plesk ohnehin vor Apache betreibt: Er nimmt die Anfrage an der Domain entgegen (inklusive TLS) und reicht sie an den Container weiter. Auf unseren Managed Servern verkabeln wir das per Ticket für dich; auf Servern mit Root-Zugriff kannst du es selbst hinterlegen.

Voraussetzungen

• Ein laufender Container mit HTTP-Dienst auf einem lokalen Port — siehe Rootless Docker: Grundlagen.
• Ein gültiges Zertifikat auf der Domain — Let’s Encrypt aktivieren, TLS terminiert der Proxy.

Das Standard-Snippet

So sieht die nginx-Anbindung aus, die wir für die (Sub-)Domain hinterlegen — Ziel-Port an den Container anpassen:

location / {
    proxy_pass http://127.0.0.1:8123;
    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;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_redirect off;
}

Die X-Forwarded-*-Header sagen der Anwendung im Container, wer wirklich anfragt und dass die Verbindung außen per HTTPS lief — wichtig für korrekte Links, Logins und Logs.

Je nach Anwendung sind drei Ergänzungen sinnvoll:

    # Für Apps mit Live-Verbindungen (WebSockets, z. B. Dashboards):
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";

    # Für große Uploads (Standard-Limit von nginx: 1 MB):
    client_max_body_size 100m;

    # Für langlaufende Anfragen (Importe, Streams):
    proxy_read_timeout 300s;

So läuft die Einrichtung

1. Starte deinen Container mit lokalem Port-Mapping, z. B. -p 127.0.0.1:8123:80, und teste ihn per curl http://127.0.0.1:8123.
2. Entscheide, unter welcher (Sub-)Domain der Dienst laufen soll, und aktiviere dort das Zertifikat.
3. Öffne ein Ticket mit Domain und Container-Port — wir hinterlegen das Snippet. Mit Root-Zugriff trägst du es selbst in Plesk unter Apache & nginx Einstellungen → Zusätzliche nginx-Anweisungen der Domain ein.
4. Teste über die Domain — inklusive Login und allem, was Redirects erzeugt.

Wenn Plesk über doppeltes location / meckert

Je nach Domain-Konfiguration kollidiert ein eigenes location / mit dem von Plesk generierten Block. Der etablierte Ausweg: das Snippet als location ~ / eintragen — der Regex-Match hat Vorrang und umgeht den Konflikt, der Rest bleibt identisch.

Wenn etwas schiefläuft

Die Domain zeigt 502 Bad Gateway

nginx erreicht den Container nicht — falscher Port, Container gestoppt oder ohne 127.0.0.1-Mapping gestartet.

Lösung: docker ps (läuft er?), dann curl http://127.0.0.1:<port> direkt auf dem Server. Antwortet der Container lokal, aber die Domain nicht: Ticket — dann sitzt der Fehler in der Verkabelung.

Die App erzeugt http://-Links oder Redirect-Schleifen

Die Anwendung weiß nicht, dass sie hinter einem TLS-terminierenden Proxy läuft.

Lösung: Prüfen, ob die App X-Forwarded-Proto auswertet (viele brauchen dafür eine Option wie „trusted proxies” oder eine Basis-URL-Einstellung). Der Header wird vom Snippet bereits gesetzt.

WebSocket-Verbindungen brechen sofort ab

Die Upgrade-Header fehlen im Proxy-Block.

Lösung: Die zwei Upgrade/Connection-Zeilen aus den Ergänzungen oben mit aufnehmen (bzw. per Ticket ergänzen lassen).

Verwandte Artikel

• Rootless Docker: Grundlagen — warum Container nur auf hohen, lokalen Ports lauschen.
• Varnish als HTTP-Cache — derselbe Proxy-Baukasten, nur mit einer Cache-Schicht dazwischen.
• Let’s Encrypt aktivieren — TLS für die Domain vor dem Container.

Du kommst nicht weiter?

Verkabelung gewünscht oder die Kette klemmt? Ticket im Kundencenter öffnen — nenn Domain, Container-Port und was der curl-Test lokal ergibt.