Funktioniert diese selbstgehostete Anwendung hinter einem Reverse Proxy? Eine Kompatibilitäts-Checkliste
Dass eine Docker-Anwendung über einen Port erreichbar ist, beweist nicht, dass sie unter einer öffentlichen HTTPS-Domain korrekt funktioniert. Nutzen Sie diese evidenzbasierte Checkliste, um kanonische URLs, weitergeleitete Header, Cookies, Uploads, Echtzeitverbindungen und OAuth-Callbacks vor dem Start zu prüfen.
Warum Reverse-Proxy-Kompatibilität ein Kriterium bei der Anwendungsauswahl ist
Ein Reverse Proxy steht zwischen einem Besucher und einer Anwendung. Er kann eine öffentliche Domain an einen internen Dienst weiterleiten und TLS terminieren, sodass die Anwendung nicht zwingend direkt im Internet lauschen muss. Dieses Infrastrukturmuster ist verbreitet, garantiert aber nicht, dass jede selbstgehostete Anwendung dahinter korrekt arbeitet.
Die wichtige Frage ist nicht nur, ob der Container startet oder sein interner Port auf eine Anfrage antwortet. Die Anwendung muss die öffentliche Adresse verstehen, die Nutzer sehen, das ursprüngliche HTTPS-Schema und – soweit relevant und von der Anwendung unterstützt – die ursprüngliche Client-Adresse. Sie muss außerdem mit den Limits und dem Verbindungsverhalten des Proxys für die Funktionen funktionieren, die Ihr Team verwenden möchte.
Behandeln Sie Reverse-Proxy-Kompatibilität als Auswahl- und Abnahmekriterium. Bevor Sie sich für eine Anwendung entscheiden, suchen Sie deren offizielle Bereitstellungsdokumentation und achten Sie auf explizite Hinweise zu Einstellungen für externe URLs, Reverse Proxys, vertrauenswürdige Proxys, weitergeleitete Header, Uploads, Echtzeitverbindungen und externe Authentifizierung. Wenn die Dokumentation dazu schweigt, halten Sie diese Unsicherheit fest und testen Sie den exakten Workflow, den Sie benötigen.
- Setzen Sie „läuft in Docker“ nicht mit „ist bereit für eine öffentliche HTTPS-Domain“ gleich.
- Bevorzugen Sie eine Anwendung mit dokumentierter Konfiguration für ihre externe oder kanonische URL.
- Fordern Sie Nachweise aus einer Testbereitstellung, nicht nur einen erfolgreichen Container-Health-Check.
- Verwenden Sie für Abnahmetests ausschließlich die öffentliche Domain und normale Nutzerpfade; ein direkter interner Port kann Proxy-bezogene Fehler verbergen.
Ordnen Sie den Anfragepfad zu, bevor Sie Einstellungen ändern
Notieren Sie den vollständigen Weg, den eine normale Anfrage nimmt: Browser, öffentlicher DNS-Name, Reverse Proxy, Anwendung und unterstützende Dienste wie Datenbank, E-Mail-Dienst, Identity Provider, Objektspeicherdienst oder Webhook-Ziel. Dadurch wird aus einem vagen Proxy-Problem eine Reihe überprüfbarer Grenzen.
Der Proxy empfängt die öffentliche Anfrage und sendet eine Upstream-Anfrage an die Anwendung. Dabei sieht die Anwendung die ursprünglichen Verbindungsdetails möglicherweise nicht mehr, sofern sie nicht darauf ausgelegt ist, vom Proxy bereitgestellte Anfrage-Header zu verwenden. [Traefik](https://doc.traefik.io/traefik/reference/routing-configuration/http/middlewares/headers/) fügt beispielsweise beim Weiterleiten von Anfragen automatisch X-Forwarded-For, X-Real-Ip, X-Forwarded-Host, X-Forwarded-Port, X-Forwarded-Proto und X-Forwarded-Server hinzu.
[Docker](https://docs.docker.com/engine/network/port-publishing/) erklärt, dass Container-Ports standardmäßig nicht extern erreichbar sind; durch das Veröffentlichen eines Ports wird er außerhalb des Hosts verfügbar. Wenn sich Upstream-Anwendung und Proxy einen Host teilen, kann eine Veröffentlichung nur auf localhost den Zugriff auf den Docker-Host beschränken, statt den Upstream-Dienst remote freizugeben.
- Öffentlicher Hostname oder öffentliche Hostnamen, einschließlich jeder alternativen Domain.
- Erwartetes externes Schema: bei einer öffentlichen Bereitstellung normalerweise HTTPS.
- Proxy-Einstiegspunkte für HTTP und HTTPS.
- Interner Upstream-Hostname und -Port.
- Der Ort der TLS-Grenze.
- Jeder zusätzliche Proxy, Load Balancer, CDN, VPN oder Tunnel vor dem Reverse Proxy.
- Welche Upstream-Ports privat bleiben müssen und welche öffentlich erreichbar sein müssen.
Prüfung 1: Die kanonische externe URL konfigurieren und nachweisen
Viele Anwendungen benötigen eine explizite Einstellung für die Adresse, unter der Nutzer sie erreichen. In der offiziellen Dokumentation kann sie Base URL, Site URL, Public URL, External URL, Server URL, Root URL oder ähnlich heißen. Setzen Sie sie auf die endgültige öffentliche HTTPS-Adresse, einschließlich eines erforderlichen Pfadpräfixes, statt auf einen internen Containernamen, eine private IP-Adresse oder eine HTTP-URL.
Welche Funktionen diese Einstellung beeinflusst, ist anwendungsspezifisch. Prüfen Sie anhand der offiziellen Dokumentation insbesondere, ob sie Links in der Oberfläche, per E-Mail versendete Links, Ziele für das Zurücksetzen von Passwörtern, Webhook-Payloads oder OAuth-Callbacks bestimmt. Eine Abweichung kann beispielsweise zu Weiterleitungen auf einen internen Hostnamen, HTTP-Links von einer HTTPS-Seite oder einem Login-Ablauf führen, der an den falschen Ort zurückkehrt.
Verwenden Sie den endgültigen Hostnamen, bevor Sie Integrationen testen. Eine spätere Änderung einer öffentlichen URL kann Anpassungen in der Anwendung, beim Identity Provider, bei Webhook-Anbietern und in Lesezeichen erfordern. Wenn die offizielle Dokumentation die Einstellung nicht erläutert oder nicht angibt, ob ein Unterpfad unterstützt wird, gehen Sie nicht davon aus, dass eine Bereitstellung unter einem Pfad wie example.com/app sicher ist.
- Setzen Sie die dokumentierte kanonische URL auf die exakte öffentliche HTTPS-URL.
- Öffnen Sie Seiten in einer sauberen Browser-Sitzung und prüfen Sie Weiterleitungen.
- Senden Sie, sofern die Anwendung dies unterstützt, eine E-Mail zum Zurücksetzen des Passworts oder eine Einladung und prüfen Sie, ob der Link die öffentliche Adresse verwendet.
- Erstellen Sie gegebenenfalls einen Freigabelink oder eine öffentliche Ressource und öffnen Sie ihn in einer separaten Sitzung.
- Testen Sie sowohl den reinen Hostnamen als auch jeden vorgesehenen alternativen Hostnamen und wählen Sie anschließend eine kanonische Adresse.
Prüfung 2: Die Grenze für vertrauenswürdige Proxys und weitergeleitete Header festlegen
Ein Reverse Proxy benötigt eine Möglichkeit, Informationen über die empfangene Anfrage weiterzugeben. [RFC 7239](https://www.rfc-editor.org/info/rfc7239/) definiert den standardisierten Header Forwarded für Informationen, die durch Proxys verändert wurden oder verloren gingen, einschließlich Quelladresse, Host und Protokoll. In der Praxis können Anwendungen auch X-Forwarded-*-Header verwenden. Die Dokumentation der Anwendung sollte angeben, welche Header sie liest und wie vertrauenswürdige Proxys deklariert werden.
Vertrauen ist der entscheidende Punkt. Ein Client darf keinen Header liefern können, den die Anwendung als maßgebliche Client-Identität, Host oder Schema behandelt. RFC 7239 weist darauf hin, dass Schlussfolgerungen auf Basis weitergeleiteter Daten davon abhängen, ob den Proxys vertraut wird, die diese hinzugefügt haben. [Traefik](https://doc.traefik.io/traefik/master/reference/install-configuration/entrypoints/) kann so konfiguriert werden, dass weitergeleiteten Header-Daten nur von bestimmten IP-Adressen oder CIDRs vertraut wird; die Dokumentation rät in Produktionsumgebungen von einem Modus mit uneingeschränktem Vertrauen ab.
Halten Sie den Proxy-Adressbereich oder die Netzwerkgrenze fest, der bzw. die von der Anwendung als vertrauenswürdig konfiguriert ist, sofern die Anwendung eine solche Einstellung besitzt. Wenn es mehr als eine Proxy-Schicht gibt, bestimmen Sie, welche Schicht weitergeleitete Header entfernt, überschreibt oder beibehält. Dies ist eine Sicherheitsentscheidung, nicht bloß eine Erleichterung für das Routing.
- Suchen Sie die offizielle Dokumentation der Anwendung zu Reverse Proxys oder vertrauenswürdigen Proxys.
- Ermitteln Sie, ob sie Forwarded, X-Forwarded-Proto, X-Forwarded-Host, X-Forwarded-For oder andere Header verwendet.
- Beschränken Sie das Vertrauen in Header überall dort auf die bekannte Proxy-Grenze, wo die jeweilige Komponente dies unterstützt.
- Vermeiden Sie, die Upstream-Anwendung neben dem Proxy direkt offenzulegen, sofern es dafür keinen konkreten, kontrollierten Bedarf gibt.
- Testen Sie eine normale öffentliche Anfrage und bestätigen Sie, dass die Anwendung das vorgesehene externe Schema und den vorgesehenen Host meldet.
Prüfung 4: Client-IP-Adressen und Audit-Ereignisse überprüfen
Der Umgang mit Client-Adressen ist wichtig, wenn eine Anwendung Login-Verläufe anzeigt, Audit-Ereignisse schreibt, IP-basierte Zugriffskontrollen anwendet, Anfragen drosselt oder Sicherheitsentscheidungen anhand einer Quelladresse trifft. Hinter einem Proxy kann der unmittelbare Kommunikationspartner, den die Anwendung sieht, der Proxy statt des Browsers der betreffenden Person sein.
Erstellen Sie, soweit praktikabel, einen kontrollierten Test mit mindestens zwei unterschiedlichen Client-Netzwerken. Führen Sie eine Aktion aus, die aufgezeichnet werden sollte, und untersuchen Sie anschließend die Audit-Ansicht oder Protokolle der Anwendung gemäß ihrem dokumentierten Verhalten. Das Ziel ist nicht zwingend, jedem Administrator rohe IP-Adressen offenzulegen; es soll sichergestellt werden, dass der von der Anwendung aufgezeichnete Kontext und alle IP-basierten Kontrollen entsprechend Ihrer Richtlinie funktionieren.
Wenn die Anwendung keinen proxybewussten Umgang mit Client-Adressen dokumentiert, sollten Sie nicht annehmen, dass ihre Aktivitätsaufzeichnungen das Netzwerk des ursprünglichen Nutzers identifizieren. Halten Sie diese Einschränkung in der Kompatibilitätsdokumentation fest und bewerten Sie, ob sie Ihre Sicherheits-, Compliance- oder Support-Anforderungen beeinträchtigt.
- Ermitteln Sie Funktionen, die auf Informationen zur Client-Adresse angewiesen sind.
- Prüfen Sie, ob Audit-Aufzeichnungen die Proxy-Adresse oder den erwarteten Client-Kontext anzeigen.
- Testen Sie jede dokumentierte IP-Allowlist-, Blocklist-, Rate-Limit- oder Funktion zur Erkennung verdächtiger Logins über den öffentlichen Pfad.
- Bestätigen Sie, dass nur von vertrauenswürdigen Proxys bereitgestellte Weiterleitungsinformationen akzeptiert werden.
- Entscheiden Sie, wer Audit-Informationen einsehen darf und wie lange sie aufbewahrt werden sollen.
Prüfung 5: Uploads, Anfragegrenzen und lang laufende Anfragen testen
Große Uploads und langsame Anfragen überschreiten mehr als eine Grenze. Die Anwendung kann eine eigene Größenbeschränkung festlegen, während der Proxy eine weitere festlegen kann. Mit dem [Buffering-Middleware von Traefik](https://doc.traefik.io/traefik/middlewares/http/buffering/) wird eine Anfrage, die größer als maxRequestBodyBytes ist, nicht an den Dienst weitergeleitet und erhält HTTP 413. Ein Wert von null bedeutet unbegrenzt, aber unbegrenzt ist nicht automatisch die richtige betriebliche Entscheidung.
Buffering verändert neben den Grenzen auch das Verhalten. Traefik dokumentiert, dass es bei aktiviertem Buffering-Middleware den gesamten Anfrage-Body liest, bevor es ihn weiterleitet, und große Bodies entsprechend dem konfigurierten Schwellenwert möglicherweise auf Datenträger puffert. Bewerten Sie dies anhand der Art und Größe der Dateien, die Ihre Nutzer tatsächlich einreichen müssen, statt nur eine kleine Beispieldatei zu testen.
Lang laufende Vorgänge benötigen eigene Nachweise. Testen Sie den für Nutzer sichtbaren Workflow mit einer erwarteten Dauer und beobachten Sie Fehler auf Browser-, Proxy- und Anwendungsebene. Ein erfolgreicher kleiner Upload beweist nicht, dass ein umfangreicher Import, Export oder eine andere lang andauernde Anfrage zuverlässig funktioniert.
- Definieren Sie die größte normale Datei oder Anfrage für den Dienst sowie einen etwas größeren Fall, der abgelehnt werden soll.
- Testen Sie eine Datei nahe der vorgesehenen akzeptierten Grenze über die öffentliche Domain.
- Bestätigen Sie, wo eine zu große Anfrage abgewiesen wird – im Proxy oder in der Anwendung – und ob die Meldung verständlich ist.
- Prüfen Sie die Auswirkungen auf den Speicherplatz, wenn Anfrage-Bodies auf Datenträger gepuffert werden können.
- Testen Sie eine erwartete lang laufende Nutzeraktion vollständig von Ende zu Ende.
- Halten Sie die konfigurierten und beobachteten Grenzen gemeinsam fest, damit spätere Änderungen keine unbeabsichtigten Regressionen verursachen.
Prüfung 6: OAuth- oder OIDC-Callbacks über die endgültliche öffentliche Domain testen
Wenn die Anwendung OAuth oder OpenID Connect mit einem externen Identity Provider verwendet, testen Sie diese Integration erst, nachdem Hostname, HTTPS und die anwendungsspezifische externe URL festgelegt sind. Maßgeblich sind die Konfiguration und Dokumentation der Anwendung sowie die Einstellungen beim Identity Provider.
[RFC 6749](https://www.rfc-editor.org/info/rfc6749/) legt für OAuth 2.0 fest, dass ein Umleitungsendpunkt eine absolute URI ist. Autorisierungsserver sollen vollständige Redirect-URIs oder mindestens Schema, Authority und Pfad registrieren lassen und eine bereitgestellte Redirect-URI gegen den registrierten Wert prüfen. Wurde redirect_uri in der Autorisierungsanfrage verwendet, muss sie bei einem Authorization-Code-Flow auch in der Token-Anfrage identisch sein.
Registrieren Sie daher die exakte öffentliche HTTPS-Callback-URL, die Ihre Anwendung dokumentiert. Führen Sie den vollständigen Anmelde- und Rückkehrpfad über die öffentliche Domain aus; ein erfolgreicher Zugriff auf eine interne Anwendung oder ein isolierter Test beim Identity Provider genügt nicht.
- Ermitteln Sie die von der Anwendung dokumentierte Callback- oder Redirect-URI.
- Registrieren Sie die exakte öffentliche HTTPS-URI beim Identity Provider.
- Prüfen Sie Schema, Hostname, Pfad und gegebenenfalls erforderliche Parameter gegen die Anwendungsdokumentation.
- Starten Sie die Anmeldung über die endgültige öffentliche Domain und schließen Sie den Rückkehrpfad bis zu einer angemeldeten Sitzung ab.
- Prüfen Sie, dass der Browser während des gesamten Ablaufs auf der vorgesehenen HTTPS-Domain bleibt.
- Dokumentieren Sie die registrierte URI und jede Änderung der öffentlichen Adresse als integrationsrelevante Konfiguration.
Häufige Fragen
Kann jede Docker-Anwendung hinter einem Reverse Proxy betrieben werden?
Nein. Durch das Veröffentlichen eines [Docker-Ports](https://docs.docker.com/engine/network/port-publishing/) kann ein Container erreichbar werden, aber die Anwendung muss außerdem ihre öffentliche URL, das HTTPS-Schema, weitergeleitete Anfragedetails, Sitzungen sowie alle erforderlichen Uploads, Callbacks oder Echtzeitverbindungen korrekt verarbeiten. Prüfen Sie diese Verhaltensweisen anhand der offiziellen Anwendungsdokumentation und einer Testbereitstellung über den öffentlichen Pfad.
Warum leitet eine Anwendung hinter einem Proxy zu HTTP oder einem internen Hostnamen weiter?
Dies deutet häufig darauf hin, dass ihre kanonische externe URL fehlt oder falsch ist oder dass sie vertrauenswürdige Proxy-Informationen über den ursprünglichen Host und das HTTPS-Schema nicht korrekt verwendet. Setzen Sie die dokumentierte öffentliche URL, konfigurieren Sie das Verhalten für vertrauenswürdige Proxys, sofern die Anwendung dies unterstützt, und testen Sie erneut über die endgültige öffentliche Domain.
Welche weitergeleiteten Header sollte ich prüfen?
Prüfen Sie die Header, die von der Anwendung dokumentiert werden. [Traefik](https://doc.traefik.io/traefik/reference/routing-configuration/http/middlewares/headers/) fügt beim Weiterleiten automatisch X-Forwarded-For, X-Real-Ip, X-Forwarded-Host, X-Forwarded-Port, X-Forwarded-Proto und X-Forwarded-Server hinzu. [RFC 7239](https://www.rfc-editor.org/info/rfc7239/) definiert außerdem den standardisierten Header Forwarded. Vertrauen Sie solchen Informationen nur von bekannten Proxy-Grenzen.
Wie sollte ich die Upload-Kompatibilität testen?
Laden Sie eine realistische Datei nahe der vorgesehenen Produktionsgrenze über die öffentliche HTTPS-Adresse hoch und testen Sie anschließend eine größere Datei, die abgewiesen werden sollte. Ermitteln Sie, ob die Ablehnung auf Proxy- oder Anwendungsebene erfolgt. Wenn [Traefik-Buffering](https://doc.traefik.io/traefik/middlewares/http/buffering/) verwendet wird, prüfen Sie dessen Einstellung für die maximale Größe des Anfrage-Bodys sowie das Puffern auf Datenträger.
Benötigen WebSockets eine spezielle Proxy-Konfiguration?
Die Antwort hängt vom Proxy und von der Anwendung ab. [Traefik dokumentiert](https://doc.traefik.io/traefik/master/user-guides/websocket/) WebSocket-Unterstützung über normales HTTP-Routing mit automatischer Upgrade-Verarbeitung. Testen Sie dennoch die genaue Anwendungsfunktion, die Echtzeitkommunikation benötigt, über die endgültige Domain, da sich Authentifizierung, Origin-Validierung, Wiederverbindungsverhalten und Anwendungsanforderungen unterscheiden.
Warum müssen OAuth-Redirect-URLs getestet werden, nachdem die endgültige Domain gewählt wurde?
[OAuth 2.0](https://www.rfc-editor.org/info/rfc6749/) verlangt, dass Umleitungsendpunkte absolute URIs sind, und Autorisierungsserver sollen bereitgestellte Redirect-URIs gegen registrierte Werte prüfen. Bei Authorization-Code-Flows muss die redirect_uri in der Token-Anfrage mit der in der Autorisierungsanfrage verwendeten redirect_uri übereinstimmen, sofern sie dort enthalten war. Registrieren und testen Sie die exakte öffentliche HTTPS-Callback-URL, die Ihre Anwendung dokumentiert.
Quellen und weiterführende Literatur
- Port publishing and mapping — Docker
- EntryPoints Documentation — Traefik Labs
- Headers Documentation — Traefik Labs
- Buffering Documentation — Traefik Labs
- WebSocket User Guide — Traefik Labs
- Challenge Types — Internet Security Research Group / Let’s Encrypt
- RFC 7239: Forwarded HTTP Extension — RFC Editor / IETF
- RFC 6749: The OAuth 2.0 Authorization Framework — RFC Editor / IETF