proxy_redirect koplar ikkje NGINX til VPN-verten din
proxy_redirect skriv om headarar i eit svar som allereie er kome; det vel aldri upstream. Kontroller proxy_pass, ruta til backend og deretter headarane.
Namnet inneheld ordet redirect, så det blir lima inn i ein location-blokk når ein backend bak VPN-en ikkje er tilgjengeleg. Ingenting endrar seg, og den openberre konklusjonen er at direktivet er øydelagt eller treng ein annan syntaks. Det som faktisk skjedde, er enklare og mindre smigrande: proxy_redirect arbeider på eit svar som allereie er kome tilbake, og i denne utrullinga kom inga førespurnad nokon gong så langt.
To direktiv, to augneblink i éi førespurnad
Ei HTTP-førespurnad gjennom ein omvend proxy går gjennom fleire avgjerder i rekkjefølgje, og dei to direktiva ligg i kvar sin ende av den sekvensen. Den eine vel kvar førespurnaden går. Den andre redigerer visse headarar i svaret som kjem tilbake.
| 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 rekkjefølgja er heile svaret. Viss den andre linja aldri blir køyrd fordi den første feila, er det andre direktivet ikkje feilkonfigurert, det er rett og slett utilgjengeleg. Uansett kor mykje du skriv om den andre linja, skapar det ikkje svaret ho skulle redigere. Diagnostiser frå første linje og utover, og den forvirrande åtferda løyser seg opp i ei manglande rute eller ei avvist tilkopling.
Valet av upstream høyrer til proxy_pass
Anta at NGINX køyrer på ein offentleg inngangsvert og kan nå ein applikasjon på 10.40.0.20:8080 over VPN-en sin. Fragmentet som vel den applikasjonen ser slik ut, inne i ein eksisterande server-blokk:
location / {
proxy_pass http://10.40.0.20:8080;
}Bruk det verkelege skjemaet, adressa og porten, og handsam dette som eit fragment og ikkje som ei utrulling. Inngangsverten må også halde VPN-ruta, ein tillaten vidaresendingssti og fungerande returtrafikk til den tenesta, fordi ein proxy som når ei adresse på papiret framleis treng samtykket til kjernen.
Referansen for proxy-modulen held valet av upstream skilt frå omskriving av svarheadarar, og nemner at ein proxy_pass-verdi med ein URI endrar korleis det samsvarande location-prefikset blir erstatta. Å leggje til eller fjerne stikomponentar utan å kontrollere URL-en applikasjonen ventar, er ein påliteleg måte å produsere ein 404 som ser ut som ein rutingsfeil.
proxy_redirect reparerer svar som lekker ei privat adresse
Når trafikken først flyt, kan ein backend svare med ein Location-header som namngir den private adressa si. Ein nettlesar som følgjer den headeren forlèt det offentlege inngangspunktet og prøver å nå noko han ikkje kan slå opp. Ei medvite konfigurert svaromskriving mappar den private URL-en til den offentlege:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;Erstatt begge sider med verkelege verdiar. Forstå også det snevre omfanget: samsvarande tekst i Location- og Refresh-headarar blir skriven om, medan URL-ar innebygde i HTML, JavaScript eller nedlasta filer ikkje blir det.
Viss ein applikasjon byggjer absolutte lenkjer overalt, er den varige løysinga hans eigen konfigurasjon for ekstern URL, ikkje ei veksande liste med omskrivingsreglar på proxyen. Å leggje til reglar til utdataa ser riktige ut gir ein konfigurasjon som feilar på den første sida ingen har testa. Éin riktig applikasjonsinnstilling erstattar heile samlinga.
Kva ei header-omskriving ikkje kan reparere
Fleire tilstøytande problem ser ut som redirect-problem og er det ikkje. Host-headeren som blir send oppstraums, må kanskje samsvare med den virtuelle verten til backend-en. Ein TLS-upstream kan krevje eit bestemt servernamn pluss sertifikatvalidering, og omskriving av ein svarheader hjelper ikkje for nokon av delane.
Cookie-omfang og domeineigenskapar høyrer til applikasjonen og konfigurasjonen hans. Ein proxy kan kaste eller skrive om headarar heile dagen og likevel lage ei økt som feilar på den andre førespurnaden, fordi cookien blei gitt ut for ein vert nettlesaren aldri besøkte. Den feilen ser periodisk ut, og difor overlever han så lenge i ein kø av saker. Å lese domenet til cookien avsluttar vanlegvis undersøkinga på eit minutt.
Hald også autentisering og val av backend avgrensa til den tiltenkte applikasjonen. Ein offentleg omvend proxy bør eksponere éin applikasjon gjennom VPN-en til serveren i staden for å bli ein generell gateway til kvar privat adresse som den verten kan nå. Eitt enkelt generisk location som videresend alt den som ringer ber om, gjer éi eksponert teneste om til eit kart over det private nettet ditt. Namngi upstream eksplisitt og hald han der.
Test i den rekkjefølgja førespurnaden reiser
Stadfest tre ting i rekkjefølgje: NGINX valde det tiltenkte location, fullførte ei førespurnad til backend, og nettlesaren følgde kvar seinare omdirigering og lasta underressursane. Kvart steg har sine eigne logglinjer, og å lese dei i rekkjefølgje gjer ein vag 502 om til eit konkret funn.
Skilnaden du treng, er mellom ei mislukka upstream-tilkopling og ein nettlesar send til eit utilgjengeleg privat namn. Den første viser seg i feilloggen til proxyen; den andre viser seg som ei førespurnad som aldri kjem, medan nettlesaren klagar over ein vert han ikkje kan slå opp. To ulike problem, to ulike filer, og berre eitt av dei involverer i det heile proxy_redirect.