Warum leitet ein Reverse-Proxy eine App auf die Domain einer anderen App weiter?

Ein Reverse-Proxy kann eine App an die Domain einer anderen App weiterleiten, wenn das Backend oder die Middleware Weiterleitungen anhand des falschen öffentlichen Hostnamens erstellt.

In einem selbst gehosteten ZimaSpace-Stack können mehrere Apps denselben Proxy nutzen, während jede ihre eigene öffentliche Basis-URL erwartet. Wenn Host, X-Forwarded-Host, Schema, Middleware oder eine kanonische URL auf App-Ebene auf einen anderen Dienst verweist, kann die erste Seite korrekt geladen werden und die nächste 301-, 302- oder Login-Callback-Weiterleitung die Domain wechseln.

Host und Schema prüfen, die an das Backend gesendet werden

Erfassen Sie die Request-Header am Proxy und am Backend, während Sie die Weiterleitung reproduzieren.

Eine fokussierte Implementierungsanleitung für Reverse-Proxys auf weitergeleiteten Host und weitergeleitetes Schema, die das Backend erreichen hilft dabei, diesen Zweig einzugrenzen, da sie dasselbe konkrete Problem behandelt, statt nur das zugrunde liegende Protokoll zu definieren.

Korrigieren Sie die Proxy-Header, bevor Sie Anwendungs-URLs ändern. Ein Backend kann keine korrekte absolute Weiterleitung erstellen, wenn es davon ausgeht, dass die Anfrage einen anderen Host verwendet hat.

X-Forwarded-Host gezielt prüfen

Einige Frameworks verwenden beim Erzeugen absoluter URLs X-Forwarded-Host anstelle des ursprünglichen Host-Headers.

Eine fokussierte Erklärung zu HTTP-Headern auf X-Forwarded-Host bewahrt den öffentlichen Hostnamen hilft dabei, diesen Zweig einzugrenzen, da sie dasselbe konkrete Problem behandelt, statt nur das zugrunde liegende Protokoll zu definieren.

Vergleichen Sie diesen Header zwischen der funktionierenden und der fehlgeleiteten App. Entfernen Sie globale Überschreibungen, die jedes Backend auf eine Domain zwingen.

Prüfen, ob die App absolute URLs erzeugt

Suchen Sie nach Framework-Einstellungen, die Proxy-Headern vertrauen und kanonische Links oder Weiterleitungen erstellen.

Ein praxisnaher Blogbeitrag zur Fehlersuche bei Proxys auf absolut falsche URLs hinter einem Proxy hilft dabei, diesen Zweig einzugrenzen, da er dasselbe konkrete Problem behandelt, statt nur das zugrunde liegende Protokoll zu definieren.

Beheben Sie das Vertrauen des Frameworks in Proxy-Header oder die Einstellung der öffentlichen URL, anstatt jede Weiterleitung am Edge umzuschreiben.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

App-Basis-URL oder kanonische Domain überprüfen

Viele selbst gehostete Apps speichern eine Website-URL unabhängig von der Proxy-Regel.

Eine fokussierte praxisnahe Fallstudie zu einer App hinter einem Proxy auf die Basis-URL der Anwendung kann den Proxy-Hostnamen überschreiben hilft dabei, diesen Zweig einzugrenzen, da sie dasselbe konkrete Problem behandelt, statt nur das zugrunde liegende Protokoll zu definieren.

Vergleichen Sie die gespeicherten Anwendungs-URLs nach Migrationen oder Wiederherstellungen. Eine kopierte Datenbank kann den kanonischen Hostnamen einer anderen App-Umgebung enthalten.

Weiterleitungs-Middleware vor dem Backend prüfen

Eine Proxy-Regel kann Schema oder Host absichtlich umschreiben, bevor die Anfrage überhaupt die Anwendung erreicht.

Eine fokussierte Traefik-Anleitung für das Homelab auf Weiterleitungs-Middleware kann den Host ersetzen hilft dabei, diesen Zweig einzugrenzen, da sie dasselbe konkrete Problem behandelt, statt nur das zugrunde liegende Protokoll zu definieren.

Deaktivieren Sie die verdächtige Weiterleitungs-Middleware nur für einen Test-Router. Trennen Sie die Erzwingung von HTTPS von domainübergreifenden Weiterleitungen.

OAuth- und OIDC-Callback-URLs prüfen

Authentifizierungsabläufe machen häufig einen falschen öffentlichen Hostnamen sichtbar, weil der Anbieter eine exakte Weiterleitungs-URI validiert.

Ein fokussierter Artikel zur OIDC-Fehlersuche auf OIDC-Callbacks hängen von der öffentlichen Proxy-URL ab hilft dabei, diesen Zweig einzugrenzen, da er dasselbe konkrete Problem behandelt, statt nur das zugrunde liegende Protokoll zu definieren.

Vergleichen Sie Issuer, Callback, weitergeleitete Header und App-Basis-URL gemeinsam. Das normale Laden einer Seite beweist nicht, dass der Login-Callback-Pfad korrekt ist.

Den exakten Home-Server-Pfad erneut testen

Wiederholen Sie nach der Änderung einer einzigen Variable denselben NAS- oder selbst gehosteten Ablauf mit demselben Client, statt auf einen anderen Test auszuweichen, der möglicherweise einen anderen Pfad verwendet.

Die zugehörige ZimaSpace-Anleitung auf der angrenzende Netzwerkpfad zum Home-Server hilft dabei, die abschließende Überprüfung an dieselbe selbst gehostete Umgebung zu binden.

Die Fehlerbehebung ist erst abgeschlossen, wenn das ursprüngliche Problem nach einer erneuten Verbindung, einem Neustart des Dienstes und einer zweiten kontrollierten Übertragung oder Anfrage weiterhin behoben ist.

Häufig gestellte Fragen

Kann DNS einen HTTP-301- oder HTTP-302-Status verursachen?

DNS liefert nur eine Adresse zurück. Die Weiterleitung wird vom Proxy, der Authentifizierungsschicht oder der Anwendung erzeugt.

Warum wird die richtige App geladen, bevor der Browser die Domain wechselt?

Die anfängliche Proxy-Route kann korrekt sein, während das Backend später eine absolute Weiterleitung anhand einer falschen Basis-URL oder eines falschen weitergeleiteten Hosts erzeugt.

Sollte ich jeden Location-Header am Proxy umschreiben?

Nein. Beheben Sie zuerst die Quelle des falschen Hostnamens. Eine umfassende Umschreibung von Antworten kann Fehler in der Anwendungskonfiguration verdecken.