proxy_redirect forbinder ikke NGINX med din VPN-vært
proxy_redirect omskriver headers i et svar, der allerede er ankommet; det vælger aldrig upstream. Kontrollér proxy_pass, ruten til backend og derefter headere.
Navnet indeholder ordet redirect, så det bliver klistret ind i en location-blok, når et backend bag VPN'en ikke kan nås. Intet ændrer sig, og den oplagte konklusion er, at direktivet er ødelagt eller kræver en anden syntaks. Det, der faktisk skete, er enklere og mindre flatterende: proxy_redirect arbejder på et svar, der allerede er kommet tilbage, og i denne udrulning nåede ingen anmodning så langt.
To direktiver, to øjeblikke i én anmodning
En HTTP-anmodning gennem en omvendt proxy passerer flere beslutninger i rækkefølge, og de to direktiver ligger i hver sin ende af den sekvens. Den ene vælger, hvor anmodningen skal hen. Den anden redigerer visse headers i det svar, der kommer tilbage.
| 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 |
Den rækkefølge er hele svaret. Hvis den anden række aldrig udføres, fordi den første fejlede, er det andet direktiv ikke forkert konfigureret, det er ganske enkelt uopnåeligt. Uanset hvor meget du omskriver den anden linje, skaber det ikke det svar, det skulle redigere. Diagnostiser fra første række og udad, og den forvirrende adfærd opløses til en manglende rute eller en afvist forbindelse.
Valget af upstream hører til proxy_pass
Antag, at NGINX kører på en offentlig indgangsvært og kan nå en applikation på 10.40.0.20:8080 over sin VPN. Det fragment, der vælger den applikation, ser sådan ud, inde i en eksisterende server-blok:
location / {
proxy_pass http://10.40.0.20:8080;
}Brug det rigtige skema, den rigtige adresse og port, og behandl dette som et fragment og ikke som en udrulning. Indgangsværten skal også holde VPN-ruten, en tilladt videresendelsessti og fungerende returtrafik til den tjeneste, fordi en proxy, der kan nå en adresse på papiret, stadig har brug for kernens accept.
Referencen for proxy-modulet holder valget af upstream adskilt fra omskrivning af svarheaders og bemærker, at en proxy_pass-værdi med et URI ændrer, hvordan det matchende location-præfiks erstattes. At tilføje eller fjerne stikomponenter uden at kontrollere den URL, applikationen forventer, er en pålidelig måde at fremstille en 404, der ligner en routingfejl.
proxy_redirect retter svar, der lækker en privat adresse
Når trafikken først løber, kan et backend svare med en Location-header, der angiver sin private adresse. En browser, der følger den header, forlader det offentlige indgangspunkt og forsøger at nå noget, den ikke kan slå op. En bevidst konfigureret svaromskrivning mapper den private URL over på den offentlige:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;Erstat begge sider med rigtige værdier. Forstå også det snævre omfang: matchende tekst i Location- og Refresh-headere bliver omskrevet, mens URL'er indlejret i HTML, JavaScript eller downloadede filer ikke bliver.
Hvis en applikation bygger absolutte links overalt, er den holdbare løsning dens egen konfiguration af ekstern URL, ikke en voksende liste af omskrivningsregler på proxyen. At tilføje regler, indtil outputtet ser rigtigt ud, giver en konfiguration, der fejler på den første side, ingen har testet. Én korrekt applikationsindstilling erstatter hele samlingen.
Hvad en headeromskrivning ikke kan reparere
Flere tilstødende problemer ligner redirect-problemer og er det ikke. Den Host-header, der sendes upstream, skal måske matche backendens virtuelle vært. En TLS-upstream kan kræve et bestemt servernavn plus certifikatvalidering, og omskrivning af en svarheader gør intet for nogen af delene.
Cookie-omfang og domæneattributter hører til applikationen og dens konfiguration. En proxy kan smide eller omskrive headers hele dagen og stadig give en session, der fejler på den anden anmodning, fordi cookien blev udstedt til en vært, browseren aldrig har besøgt. Den fejl ser periodisk ud, og derfor overlever den så længe i en kø af sager. At læse cookiens domæne afslutter normalt undersøgelsen på et minut.
Hold også autentificering og valg af backend begrænset til den tilsigtede applikation. En offentlig omvendt proxy bør eksponere én applikation gennem serverens VPN i stedet for at blive en generel gateway til hver privat adresse, som den vært kan nå. Et enkelt generisk location, der videresender alt, hvad kalderen beder om, forvandler én eksponeret tjeneste til et kort over dit private netværk. Navngiv upstream eksplicit, og hold den der.
Test i den rækkefølge, anmodningen rejser
Bekræft tre ting i rækkefølge: NGINX valgte det tilsigtede location, det gennemførte en anmodning til backend, og browseren fulgte enhver senere redirect og indlæste underressourcerne. Hvert trin har sine egne loglinjer, og at læse dem i rækkefølge forvandler en uklar 502 til en konkret konstatering.
Den forskel, du har brug for, er mellem en mislykket upstream-forbindelse og en browser sendt til et uopnåeligt privat navn. Den første vises i proxyens fejllog; den anden vises som en anmodning, der aldrig ankommer, mens browseren klager over en vært, den ikke kan slå op. To forskellige problemer, to forskellige filer, og kun det ene involverer overhovedet proxy_redirect.