proxy_redirect verbindet NGINX nicht mit Ihrem VPN-Host
proxy_redirect schreibt Header in einer bereits angekommenen Antwort um; es wählt nie den Upstream. Prüfen Sie proxy_pass, die Route zum Backend und dann die Header.
Der Name enthält das Wort redirect, also wird er in einen location-Block geklebt, wenn ein Backend hinter dem VPN nicht erreichbar ist. Es ändert sich nichts, und die naheliegende Schlussfolgerung ist, dass die Direktive kaputt ist oder eine andere Syntax braucht. Was wirklich geschah, ist einfacher und weniger schmeichelhaft: proxy_redirect wirkt auf eine Antwort, die bereits zurückgekommen ist, und in dieser Installation kam keine Anfrage je so weit.
Zwei Direktiven, zwei Momente in einer Anfrage
Eine HTTP-Anfrage durch einen Reverse-Proxy durchläuft mehrere Entscheidungen der Reihe nach, und die beiden Direktiven liegen an entgegengesetzten Enden dieser Folge. Die eine wählt, wohin die Anfrage geht. Die andere bearbeitet bestimmte Header in der Antwort, die zurückkommt.
| Directive | When it acts | What it can change |
|---|---|---|
proxy_pass | Before any bytes leave the proxy | Which upstream receives the request |
proxy_redirect | After the upstream responds | Matching Location and Refresh text |
Diese Reihenfolge ist die ganze Antwort. Wenn die zweite Zeile nie ausgeführt wird, weil die erste fehlgeschlagen ist, ist die zweite Direktive nicht falsch konfiguriert, sie ist schlicht unerreichbar. Egal wie oft man die zweite Zeile umschreibt, die Antwort, die sie bearbeiten sollte, entsteht nicht. Diagnostizieren Sie von der ersten Zeile nach außen, und das verwirrende Verhalten löst sich in eine fehlende Route oder eine abgelehnte Verbindung auf.
Die Wahl des Upstream gehört zu proxy_pass
Angenommen, NGINX läuft auf einem öffentlichen Einstiegshost und erreicht eine Anwendung unter 10.40.0.20:8080 über sein VPN. Das Fragment, das diese Anwendung auswählt, sieht so aus, innerhalb eines bestehenden server-Blocks:
location / {
proxy_pass http://10.40.0.20:8080;
}Verwenden Sie das echte Schema, die echte Adresse und den echten Port, und behandeln Sie dies als Fragment, nicht als Installation. Der Einstiegshost muss außerdem die VPN-Route, einen erlaubten Weiterleitungspfad und funktionierenden Rückverkehr zu diesem Dienst halten, denn ein Proxy, der eine Adresse auf dem Papier erreicht, braucht trotzdem die Zustimmung des Kernels.
Die Referenz des proxy-Moduls hält die Upstream-Auswahl getrennt von der Umschreibung von Antwort-Headern und merkt an, dass ein proxy_pass-Wert mit einer URI ändert, wie das passende location-Präfix ersetzt wird. Pfadkomponenten hinzuzufügen oder zu entfernen, ohne die von der Anwendung erwartete URL zu prüfen, ist ein zuverlässiger Weg, eine 404 zu erzeugen, die wie ein Routingfehler aussieht.
proxy_redirect repariert Antworten, die eine private Adresse preisgeben
Sobald Verkehr fließt, kann ein Backend mit einem Location-Header antworten, der seine private Adresse nennt. Ein Browser, der diesem Header folgt, verlässt den öffentlichen Einstiegspunkt und versucht, etwas zu erreichen, das er nicht auflösen kann. Eine bewusst konfigurierte Antwort-Umschreibung bildet die private URL auf die öffentliche ab:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;Ersetzen Sie beide Seiten durch echte Werte. Verstehen Sie auch den engen Geltungsbereich: passender Text der Header Location und Refresh wird umgeschrieben, in HTML, JavaScript oder heruntergeladenen Dateien eingebettete URLs nicht.
Wenn eine Anwendung überall absolute Links baut, ist die dauerhafte Lösung ihre eigene Konfiguration für externe URLs, nicht eine wachsende Liste von Umschreibregeln auf dem Proxy. Regeln hinzuzufügen, bis die Ausgabe richtig aussieht, erzeugt eine Konfiguration, die auf der ersten ungetesteten Seite scheitert. Eine korrekte Anwendungseinstellung ersetzt die ganze Sammlung.
Was eine Header-Umschreibung nicht reparieren kann
Mehrere benachbarte Probleme sehen wie Redirect-Probleme aus und sind keine. Der zum Upstream gesendete Host-Header muss möglicherweise zum virtuellen Host des Backends passen. Ein TLS-Upstream kann einen bestimmten Servernamen plus Zertifikatsprüfung benötigen, und das Umschreiben eines Antwort-Headers hilft bei beidem nicht.
Cookie-Geltungsbereich und Domänenattribute gehören zur Anwendung und ihrer Konfiguration. Ein Proxy kann den ganzen Tag Header verwerfen oder umschreiben und trotzdem eine Sitzung erzeugen, die bei der zweiten Anfrage scheitert, weil das Cookie für einen Host ausgestellt wurde, den der Browser nie besucht hat. Dieser Fehler wirkt sporadisch, und deshalb überlebt er so lange in einer Ticket-Warteschlange. Das Lesen der Cookie-Domäne beendet die Untersuchung meist in einer Minute.
Halten Sie auch Authentifizierung und Backend-Auswahl auf die vorgesehene Anwendung beschränkt. Ein öffentlicher Reverse-Proxy sollte eine Anwendung über das VPN des Servers bereitstellen, statt zu einem universellen Gateway zu jeder privaten Adresse zu werden, die dieser Host erreichen kann. Ein einziges generisches location, das alles weiterleitet, worum der Aufrufer bittet, macht aus einem exponierten Dienst eine Karte Ihres privaten Netzes. Benennen Sie den Upstream ausdrücklich und lassen Sie ihn dort.
Testen Sie in der Reihenfolge, in der die Anfrage reist
Bestätigen Sie drei Dinge nacheinander: NGINX hat das vorgesehene location gewählt, eine Anfrage an das Backend abgeschlossen, und der Browser ist einer späteren Weiterleitung gefolgt und hat die Unterressourcen geladen. Jeder Schritt hat seine eigenen Logzeilen, und sie in Reihenfolge zu lesen macht aus einer vagen 502 einen konkreten Befund.
Die Unterscheidung, die Sie brauchen, ist die zwischen einer fehlgeschlagenen Upstream-Verbindung und einem Browser, der an einen unerreichbaren privaten Namen geschickt wurde. Ersteres erscheint im Proxy-Fehlerlog; Letzteres erscheint als Anfrage, die nie ankommt, während der Browser sich über einen Host beschwert, den er nicht auflösen kann. Zwei verschiedene Probleme, zwei verschiedene Dateien, und nur eines davon betrifft überhaupt proxy_redirect.