So beheben Sie einen Reverse-Proxy, der eine Domain nach dem Hinzufügen einer Catch-all-Regel an die falsche App weiterleitet

Ein Reverse Proxy kann eine Domain an die falsche App senden, wenn eine neue Catch-all-Route umfassender matcht oder Vorrang vor der vorgesehenen Host-Regel erhält.

Dies ist enger gefasst als eine allgemeine Weiterleitung auf die falsche Domain oder ein DNS-Problem. Der entscheidende Test ist, ob die korrekte Domain weiterhin die erwartete Proxy-IP und das erwartete Zertifikat erreicht, der Proxy aber erst dann das falsche Backend auswählt, nachdem die neue Standardroute vorhanden ist. Vergleichen Sie die Routenübereinstimmungen und Prioritäten, bevor Sie DNS, Basis-URLs der Anwendung oder Zertifikate ändern.

Nachweisen, dass die Catch-all-Regel die Backend-Auswahl geändert hat

Senden Sie dieselbe Anfrage an die Domain, bevor und nachdem Sie ausschließlich die neue Catch-all- oder Standardroute deaktiviert haben. Protokollieren Sie das Proxy-Zugriffsprotokoll, den ausgewählten Router oder Server-Block, die Backend-Adresse, die Antwortkennung und das Zertifikat.

Ein praktischer Leitfaden zum Nginx-Standardserver warnt, dass Catch-all-Regeln Datenverkehr abfangen können, selbst wenn bereits mehrere explizite virtuelle Hosts vorhanden sind.

Wenn die Deaktivierung des Fallbacks die vorgesehene App sofort wiederherstellt, lassen Sie DNS und die Backend-Anwendung unverändert. Als Nächstes muss die spezifische Route Vorrang erhalten, ohne das sichere Fallback-Verhalten für unbekannte Hostnamen zu entfernen.

Prüfen, ob die spezifische Host-Regel noch exakt matcht

Vergleichen Sie den angeforderten Hostnamen Zeichen für Zeichen mit der vorgesehenen Routenregel. Berücksichtigen Sie dabei Subdomain, Grenzen von Wildcards, abschließende Punkte in Testtools und die Frage, ob die Regel auf demselben HTTP- oder HTTPS-Einstiegspunkt lauscht wie die Catch-all-Route.

Ein Leitfaden zu Reverse Proxies für mehrere Apps zeigt, dass Hostnamenregeln unterschiedliche Backends auswählen, aber nur dann, wenn der eingehende Host zu der Regel passt, die der Proxy tatsächlich geladen hat.

Beheben Sie einen unvollständigen oder falsch geschriebenen Host-Matcher, bevor Sie die Priorität anpassen. Die Priorität einer Regel zu erhöhen, die nie matcht, macht die Konfiguration nur schwerer nachvollziehbar.

Routenpriorität mit der Catch-all-Route vergleichen

Bei Proxies, die explizite oder abgeleitete Prioritäten unterstützen, prüfen Sie, welche Regel gewinnt, wenn sowohl der spezifische Host als auch der breite Fallback dieselbe Anfrage matchen können. Protokollieren Sie die ausgewertete Regel, nicht nur die Reihenfolge in der Konfigurationsdatei.

Ein Traefik-Catch-all-Beispiel weist dem Fallback bewusst eine niedrigere Priorität als den tatsächlichen Routen zu, sodass spezifische Dienste zuerst ausgewertet werden.

Setzen Sie den Fallback unter alle vorgesehenen Anwendungsrouten und testen Sie erneut. Lösen Sie das Problem nicht, indem Sie jedem Router willkürlich extrem hohe Zahlen zuweisen. Verwenden Sie stattdessen ein einfaches, dokumentiertes Prioritätsschema, das auch nach dem Hinzufügen weiterer Apps Bestand hat.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Den Standardserver auf Nginx-ähnlichen Proxies prüfen

Ermitteln Sie bei Nginx und ähnlichen Konfigurationen, welcher Server-Block für die jeweilige Listening-Adresse und den jeweiligen Port zum Standard wird, wenn kein Hostname matcht. Der zuerst geladene Block kann zum Fallback werden, wenn kein expliziter Standard definiert ist.

Ein fokussierter Artikel zur Nginx-Fehlerbehebung erklärt, warum nicht übereinstimmende Hosts Standardserver erreichen, anstatt stillschweigend abgewiesen zu werden.

Verwenden Sie eine neutrale Standardantwort oder einen Fehlerdienst, statt eine echte Anwendung zum Fallback zu machen. So kann ein unbekannter oder falsch geschriebener Hostname nicht versehentlich eine andere selbst gehostete App offenlegen.

HTTP- und HTTPS-Fallbacks getrennt prüfen

Eine für Port 80 hinzugefügte Catch-all-Route verhält sich nicht automatisch genauso auf Port 443. TLS-Routing, SNI, separate Einstiegspunkte oder eine zweite Catch-all-Route können dazu führen, dass nur HTTPS-Anfragen die falsche App erreichen.

Ein Caddy-Fehlerbehebungsfall beschreibt, dass sich eine Catch-all je nach Protokoll unterschiedlich verhält, und zeigt, warum die protokollspezifische Route direkt getestet werden muss.

Fordern Sie denselben Hostnamen sowohl über HTTP als auch über HTTPS an und protokollieren Sie den ausgewählten Handler. Beheben Sie den Fallback auf dem betroffenen Einstiegspunkt, statt den funktionierenden Protokollpfad zu ändern.

Den Fallback neutral halten und jede bekannte Domain erneut testen

Nachdem Sie den Match-Bereich oder die Priorität korrigiert haben, sollte der Fallback eine neutrale 404-, 421- oder kontrollierte Fehlerseite zurückgeben, statt jeden unbekannten Hostnamen an eine Produktions-App weiterzuleiten. Testen Sie anschließend jede bekannte selbst gehostete Domain einmal.

Eine Übersicht zur Reverse-Proxy-Architektur betont, dass der Proxy das Backend bestimmt, nachdem die Anfrage den Proxy erreicht hat. Deshalb kann die korrekte DNS-Auflösung allein nicht beweisen, dass das Routing korrekt funktioniert.

Die Fehlerbehebung ist abgeschlossen, wenn jeder bekannte Hostname seine vorgesehene App erreicht und ein unbekannter Hostname ausschließlich den neutralen Fallback erhält. Der zugehörige ZimaSpace-Artikel über einen Reverse Proxy, der auf eine andere Domain weiterleitet, ist der nächste Ansatz, wenn der Proxy das richtige Backend auswählt, die Anwendung aber anschließend die Domain ändert.

Häufig gestellte Fragen

Kann DNS dazu führen, dass eine Catch-all-Route gewinnt?

DNS kann die Anfrage an die falsche Proxy-IP senden. Sobald der korrekte Proxy jedoch den vorgesehenen Hostnamen empfängt, ist das Matching der Routen eine Entscheidung des Proxies. Prüfen Sie beide Ebenen getrennt.

Sollte die Catch-all-Route an eine Dashboard-App weiterleiten?

In der Regel nicht. Ein neutrales Fehlerziel ist sicherer, da Tippfehler und unbekannte Hostnamen nicht versehentlich eine echte Administrations- oder Medienanwendung offenlegen können.

Warum erreicht nur HTTPS die falsche App?

HTTPS kann einen anderen Listener, SNI-Pfad, Zertifikatsstandort oder eine andere Fallback-Regel als HTTP verwenden. Testen Sie beide Einstiegspunkte unabhängig voneinander, bevor Sie das globale Routing ändern.