proxy_redirect verbënnt NGINX net mat Ärem VPN-Host
proxy_redirect schreift Header an enger Äntwert ëm, déi schonn ukomm ass; en wielt ni den Upstream. Kontrolléiert proxy_pass, d'Route zum Backend an duerno d'Header.
Den Numm enthält d'Wort redirect, also gëtt en an e location-Block gepaakt, wann e Backend hanner dem VPN net erreechbar ass. Näischt ännert sech, an de naheliegend Schluss ass, datt d'Direktiv futti ass oder eng aner Syntax brauch. Wat wierklech geschitt ass, ass méi einfach a manner schmeichelhaft: proxy_redirect schafft op enger Äntwert, déi schonn zréckkomm ass, an an dëser Installatioun ass keng Ufro je esou wäit komm.
Zwee Direktiven, zwee Momenter an enger Ufro
Eng HTTP-Ufro duerch en ëmgedréinten Proxy geet der Rei no duerch verschidden Entscheidungen, an déi zwou Direktiven leien op den entgéintgesate Enden vun dëser Sequenz. Déi eng wielt, wou d'Ufro higeet. Déi aner ännert bestëmmten Header an der Äntwert, déi zréckkënnt.
| 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 |
Dës Rei ass déi ganz Äntwert. Wann déi zweet Zeil ni ausgefouert gëtt, well déi éischt versot huet, ass déi zweet Direktiv net falsch konfiguréiert, si ass einfach net erreechbar. Egal wéi dacks een déi zweet Linn ëmmer erëm schreift, d'Äntwert déi se sollt änneren entsteet net. Diagnostizéiert vun der éischter Zeil no baussen, an d'verwirrend Verhalen löst sech an eng fehlend Route oder eng refuséiert Verbindung op.
D'Auswiel vum Upstream gehéiert zu proxy_pass
Stellt Iech vir, NGINX leeft op engem ëffentlechen Entrées-Host a kann iwwer säin VPN eng Applikatioun op 10.40.0.20:8080 erreechen. De Fragment, deen déi Applikatioun auswielt, gesäit esou aus, bannent engem bestännege server-Block:
location / {
proxy_pass http://10.40.0.20:8080;
}Benotzt de richtege Schema, d'Adress an de Port, a behandelt dëst als Fragment an net als Installatioun. Den Entrées-Host muss och d'VPN-Route, en erlaabte Weiderleedungswee an e funktionéierende Récktrafic op dee Service halen, well e Proxy, deen eng Adress op Pabeier erreecht, ëmmer nach d'Zoustëmmung vum Kernel brauch.
D'Referenz vum proxy-Modul hält d'Auswiel vum Upstream getrennt vum Ëmschreiwen vu Response-Header, a bemierkt, datt e proxy_pass-Wäert mat enger URI ännert, wéi de passenden location-Präfix ersat gëtt. Padekomponenten derbäisetzen oder ewechhuelen ouni d'URL ze kontrolléieren, déi d'Applikatioun erwaart, ass e séchere Wee fir eng 404 ze produzéieren, déi wéi e Routingfehler ausgesäit.
proxy_redirect reparéiert Äntwerten, déi eng privat Adress verroden
Soubal den Trafic fléisst, kann e Backend mat engem Location-Header äntwerten, deen seng privat Adress nennt. E Browser, deen deem Header follegt, verléisst den ëffentlechen Entréespunkt a probéiert eppes z'erreechen, wat en net opléise kann. Eng bewosst konfiguréiert Response-Ëmschreiwung mappt déi privat URL op déi ëffentlech:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;Ersetzt béid Säite mat richtege Wäerter. Verstitt och den enken Ëmfang: de passenden Text vun den Header Location an Refresh gëtt ëmgeschriwwen, awer URLen, déi an HTML, JavaScript oder erofgeluede Fichieren agebett sinn, net.
Wann eng Applikatioun iwwerall absolut Linke baut, ass déi dauerhaft Léisung hir eege Konfiguratioun fir extern URLen, net eng wuessend Lëscht vun Ëmschreifregelen um Proxy. Regelen derbäisetzen, bis d'Ausgab richteg ausgesäit, produzéiert eng Konfiguratioun, déi op der éischter Säit versot, déi kee getest huet. Eng eenzeg richteg Astellung vun der Applikatioun ersetzt déi ganz Sammlung.
Wat eng Header-Ëmschreiwung net ka reparéieren
Verschidde benopte Problemer gesinn aus wéi Redirect-Problemer a sinn et net. Den Host-Header, deen op den Upstream geet, muss vläicht zum virtuelle Host vum Backend passen. En TLS-Upstream brauch vläicht e bestëmmten Servernumm plus Zertifikatsprüfung, an d'Ëmschreiwe vun engem Response-Header hëlleft weder dem engem nach dem aneren.
De Cookie-Ëmfang an d'Domain-Attributer gehéieren zur Applikatioun an hirer Konfiguratioun. E Proxy kann de ganzen Dag Header ewechgeheien oder ëmschreiwen an trotzdeem eng Sessioun produzéieren, déi bei der zweeter Ufro versot, well de Cookie fir en Host ausgestallt gouf, deen de Browser ni besicht huet. Dee Fehler gesäit intermitent aus, dofir iwwerlieft en esou laang an enger Ticket-Schlaang. D'Domain vum Cookie liesen entscheet d'Enquête meeschtens an enger Minutt.
Halt och Authentifikatioun an d'Auswiel vum Backend op d'virgesinn Applikatioun limitéiert. En ëffentlechen ëmgedréinten Proxy soll eng eenzeg Applikatioun iwwer de VPN vum Server exponéieren amplaz en allgemenge Gateway zu all privater Adress ze ginn, déi deen Host erreeche kann. En eenzegen allgemengen location, deen alles weiderleet, wat de Caller freet, verwandelt ee exponéierte Service an eng Kaart vun Ärem private Netzwierk. Nennt den Upstream explizit a hält en do.
Test an der Rei, wéi d'Ufro reest
Bestätegt dräi Saachen an der Rei: NGINX huet de virgesinn location gewielt, eng Ufro un de Backend fäerdeg gemaach, an de Browser ass all méi spéider Redirect gefollegt an huet d'Ënnerressourcen gelueden. All Schrëtt huet seng eege Logzeilen, an se an der Rei ze liesen mécht aus enger vager 502 eng konkret Feststellung.
Den Ënnerscheed, deen Dir braucht, ass tëschent enger gescheiterter Upstream-Verbindung an engem Browser, deen op en onerreechbaren private Numm geschéckt gouf. Déi éischt erschéngt am Feelerlog vum Proxy; déi zweet erschéngt als eng Ufro, déi ni ukënnt, woubäi de Browser iwwer en Host jammert, deen en net opléise kann. Zwee verschidde Problemer, zwee verschidde Fichieren, an nëmmen ee vun deenen zwee betrëfft iwwerhaapt proxy_redirect.