proxy_redirect kobler ikke NGINX til VPN-verten din

Navnet inneholder ordet redirect, så det limes inn i en location-blokk når en backend bak VPN-en ikke kan nås. Ingenting endres, og den åpenbare konklusjonen er at direktivet er ødelagt eller trenger en annen syntaks. Det som faktisk skjedde, er enklere og mindre flatterende: proxy_redirect arbeider på et svar som allerede er kommet tilbake, og i denne utrullingen kom ingen forespørsel så langt.

To direktiver, to øyeblikk i én forespørsel

En HTTP-forespørsel gjennom en omvendt proxy passerer flere beslutninger i rekkefølge, og de to direktivene ligger i hver sin ende av den sekvensen. Den ene velger hvor forespørselen går. Den andre redigerer visse headere i svaret som kommer tilbake.

Den rekkefølgen er hele svaret. Hvis den andre linjen aldri utføres fordi den første feilet, er det andre direktivet ikke feilkonfigurert, det er rett og slett uoppnåelig. Uansett hvor mye du skriver om den andre linjen, skaper det ikke svaret den skulle redigere. Diagnostiser fra første linje og utover, og den forvirrende oppførselen løser seg opp i en manglende rute eller en avvist tilkobling.

Valget av upstream tilhører proxy_pass

Anta at NGINX kjører på en offentlig inngangsvert og kan nå en applikasjon på 10.40.0.20:8080 over VPN-en sin. Fragmentet som velger den applikasjonen ser slik ut, inne i en eksisterende server-blokk:

location / {
    proxy_pass http://10.40.0.20:8080;
}

Bruk det virkelige skjemaet, adressen og porten, og behandle dette som et fragment og ikke som en utrulling. Inngangsverten må også holde VPN-ruten, en tillatt videresendingssti og fungerende returtrafikk til den tjenesten, fordi en proxy som når en adresse på papiret fortsatt trenger kjernens samtykke.

Referansen for proxy-modulen holder valget av upstream atskilt fra omskriving av svarheadere, og bemerker at en proxy_pass-verdi med en URI endrer hvordan den samsvarende location-prefiksen erstattes. Å legge til eller fjerne stikomponenter uten å kontrollere URL-en applikasjonen forventer, er en pålitelig måte å produsere en 404 som ser ut som en rutingsfeil.

proxy_redirect retter svar som lekker en privat adresse

Når trafikken først flyter, kan en backend svare med en Location-header som navngir dens private adresse. En nettleser som følger den headeren forlater det offentlige inngangspunktet og prøver å nå noe den ikke kan slå opp. En bevisst konfigurert svaromskriving mapper den private URL-en til den offentlige:

proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;

Erstatt begge sider med virkelige verdier. Forstå også det snevre omfanget: samsvarende tekst i Location- og Refresh-headere skrives om, mens URL-er innebygd i HTML, JavaScript eller nedlastede filer ikke gjør det.

Hvis en applikasjon bygger absolutte lenker overalt, er den varige løsningen dens egen konfigurasjon for ekstern URL, ikke en voksende liste med omskrivingsregler på proxyen. Å legge til regler til utdataene ser riktige ut gir en konfigurasjon som feiler på den første siden ingen har testet. Én riktig applikasjonsinnstilling erstatter hele samlingen.

Hva en header-omskriving ikke kan reparere

Flere tilstøtende problemer ser ut som redirect-problemer og er det ikke. Host-headeren som sendes oppstrøms, må kanskje samsvare med backendens virtuelle vert. En TLS-upstream kan kreve et bestemt servernavn pluss sertifikatvalidering, og omskriving av en svarheader hjelper ikke for noen av delene.

Cookie-omfang og domeneattributter tilhører applikasjonen og dens konfigurasjon. En proxy kan kaste eller skrive om headere hele dagen og likevel produsere en økt som feiler på den andre forespørselen, fordi cookien ble utstedt for en vert nettleseren aldri besøkte. Den feilen ser periodisk ut, og derfor overlever den så lenge i en kø av saker. Å lese cookiens domene avslutter vanligvis undersøkelsen på et minutt.

Hold også autentisering og valg av backend begrenset til den tiltenkte applikasjonen. En offentlig omvendt proxy bør eksponere én applikasjon gjennom serverens VPN i stedet for å bli en generell gateway til hver privat adresse som den verten kan nå. Ett enkelt generisk location som videresender alt den som ringer ber om, gjør én eksponert tjeneste om til et kart over ditt private nettverk. Navngi upstream eksplisitt og hold den der.

Test i den rekkefølgen forespørselen reiser

Bekreft tre ting i rekkefølge: NGINX valgte det tiltenkte location, fullførte en forespørsel til backend, og nettleseren fulgte en eventuell senere redirect og lastet underressursene. Hvert trinn har sine egne logglinjer, og å lese dem i rekkefølge gjør en vag 502 om til et konkret funn.

Forskjellen du trenger, er mellom en mislykket upstream-tilkobling og en nettleser sendt til et uoppnåelig privat navn. Den første vises i proxyens feillogg; den andre vises som en forespørsel som aldri kommer, mens nettleseren klager over en vert den ikke kan slå opp. To forskjellige problemer, to forskjellige filer, og bare ett av dem involverer i det hele tatt proxy_redirect.