proxy_redirect kopplar inte NGINX till din VPN-värd
proxy_redirect skriver om rubriker i ett svar som redan har kommit; det väljer aldrig upstream. Kontrollera proxy_pass, rutten till backend och sedan rubrikerna.
Namnet innehåller ordet redirect, så det klistras in i ett location-block när en backend bakom VPN:et inte går att nå. Inget ändras, och den självklara slutsatsen är att direktivet är trasigt eller kräver annan syntax. Det som faktiskt hände är enklare och mindre smickrande: proxy_redirect arbetar på ett svar som redan har kommit tillbaka, och i den här driftsättningen kom ingen begäran någonsin så långt.
Två direktiv, två ögonblick i en begäran
En HTTP-begäran genom en omvänd proxy passerar flera beslut i ordning, och de två direktiven ligger i varsin ände av den sekvensen. Det ena väljer vart begäran tar vägen. Det andra redigerar vissa rubriker i svaret som kommer tillbaka.
| 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 ordningen är hela svaret. Om den andra raden aldrig körs eftersom den första misslyckades, är det andra direktivet inte felkonfigurerat, det är helt enkelt oåtkomligt. Hur mycket den andra raden än skrivs om skapas inte det svar den skulle redigera. Diagnostisera från första raden och utåt, och det förvirrande beteendet löses upp i en saknad rutt eller en avvisad anslutning.
Valet av upstream tillhör proxy_pass
Anta att NGINX körs på en offentlig ingångsvärd och når en applikation på 10.40.0.20:8080 via sitt VPN. Fragmentet som väljer den applikationen ser ut så här, inne i ett befintligt server-block:
location / {
proxy_pass http://10.40.0.20:8080;
}Använd det riktiga schemat, adressen och porten, och behandla detta som ett fragment och inte som en driftsättning. Ingångsvärden måste också hålla VPN-rutten, en tillåten vidarebefordringsväg och fungerande returtrafik till den tjänsten, eftersom en proxy som når en adress på papper fortfarande behöver kärnans medgivande.
Referensen för proxy-modulen håller valet av upstream åtskilt från omskrivning av svarsrubriker, och noterar att ett proxy_pass-värde med en URI ändrar hur det matchande location-prefixet ersätts. Att lägga till eller ta bort sökvägskomponenter utan att kontrollera URL:en som applikationen förväntar sig är ett tillförlitligt sätt att producera en 404 som ser ut som ett routningsfel.
proxy_redirect reparerar svar som läcker en privat adress
När trafiken väl flödar kan en backend svara med en Location-rubrik som namnger sin privata adress. En webbläsare som följer den rubriken lämnar den offentliga ingångspunkten och försöker nå något den inte kan slå upp. En medvetet konfigurerad svarsomskrivning mappar den privata URL:en till den offentliga:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;Byt ut båda sidor mot riktiga värden. Förstå också den snäva omfattningen: matchande text i Location- och Refresh-rubrikerna skrivs om, medan URL:er inbäddade i HTML, JavaScript eller nedladdade filer inte gör det.
Om en applikation bygger absoluta länkar överallt är den hållbara lösningen dess egen konfiguration för extern URL, inte en växande lista med omskrivningsregler på proxyn. Att lägga till regler tills utdata ser rätt ut ger en konfiguration som fallerar på den första sida som ingen testade. En enda korrekt applikationsinställning ersätter hela samlingen.
Vad en rubrikomskrivning inte kan reparera
Flera närliggande problem ser ut som redirect-problem och är det inte. Host-rubriken som skickas till upstream kan behöva matcha backendens virtuella värd. En TLS-upstream kan kräva ett specifikt servernamn plus certifikatvalidering, och omskrivning av en svarsrubrik hjälper inte för något av dem.
Cookie-omfattning och domänattribut tillhör applikationen och dess konfiguration. En proxy kan slänga eller skriva om rubriker hela dagen och ändå producera en session som fallerar på den andra begäran, eftersom cookien utfärdades för en värd som webbläsaren aldrig besökte. Det felet ser intermittent ut, och därför överlever det så länge i en biljettkö. Att läsa cookiens domän avslutar oftast utredningen på en minut.
Håll också autentisering och val av backend begränsade till den avsedda applikationen. En offentlig omvänd proxy bör exponera en enda applikation via serverns VPN i stället för att bli en generell gateway till varje privat adress som den värden kan nå. Ett enda generiskt location som vidarebefordrar allt anroparen ber om förvandlar en exponerad tjänst till en karta över ditt privata nätverk. Namnge upstream explicit och håll den kvar där.
Testa i den ordning begäran färdas
Bekräfta tre saker i ordning: NGINX valde det avsedda location, slutförde en begäran till backend, och webbläsaren följde eventuell senare omdirigering och laddade underresurserna. Varje steg har sina egna loggrader, och att läsa dem i ordning förvandlar en vag 502 till ett konkret fynd.
Skillnaden du behöver är mellan en misslyckad upstream-anslutning och en webbläsare skickad till ett oåtkomligt privat namn. Det första syns i proxyns fellogg; det andra syns som en begäran som aldrig anländer, medan webbläsaren klagar på en värd den inte kan slå upp. Två olika problem, två olika filer, och bara ett av dem involverar över huvud taget proxy_redirect.