proxy_redirect ne povezuje NGINX s vašim VPN hostom

Naziv sadrži riječ redirect, pa se ubacuje u location blok kada se backend iza VPN-a ne može dosegnuti. Ništa se ne mijenja, a očigledan zaključak je da je direktiva pokvarena ili traži drugačiju sintaksu. Ono što se stvarno dogodilo jednostavnije je i manje laskavo: proxy_redirect radi na odgovoru koji se već vratio, a u ovom postavljanju nijedan zahtjev nije dotle stigao.

Dvije direktive, dva trenutka u jednom zahtjevu

HTTP zahtjev kroz obrnuti proxy prolazi kroz nekoliko odluka po redu, a dvije direktive stoje na suprotnim krajevima tog niza. Jedna bira kamo zahtjev ide. Druga uređuje određena zaglavlja u odgovoru koji se vraća.

Taj poredak je cijeli odgovor. Ako se drugi red nikada ne izvrši jer je prvi pao, druga direktiva nije pogrešno konfigurisana, ona je jednostavno nedostupna. Koliko god prepisivali drugi red, odgovor koji je trebalo urediti neće nastati. Dijagnostikujte od prvog reda prema vani i zbunjujuće ponašanje svodi se na rutu koja nedostaje ili odbijenu vezu.

Odabir upstreama pripada proxy_pass-u

Pretpostavimo da NGINX radi na javnom ulaznom hostu i može dosegnuti aplikaciju na 10.40.0.20:8080 preko svog VPN-a. Fragment koji bira tu aplikaciju izgleda ovako, unutar postojećeg server bloka:

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

Koristite stvarnu shemu, adresu i port i tretirajte ovo kao fragment, a ne kao postavljanje. Ulazni host takođe mora držati VPN rutu, dopuštenu putanju prosljeđivanja i ispravan povratni saobraćaj prema toj usluzi, jer proxy koji na papiru može dosegnuti adresu ipak treba pristanak kernela.

Referenca proxy modula drži odabir upstreama odvojeno od prepisivanja zaglavlja odgovora i napominje da vrijednost proxy_pass koja sadrži URI mijenja način na koji se zamjenjuje odgovarajući location prefiks. Dodavanje ili uklanjanje dijelova putanje bez provjere URL-a koji aplikacija očekuje pouzdan je način da nastane 404 koji izgleda kao greška rutiranja.

proxy_redirect popravlja odgovore koji odaju privatnu adresu

Kad saobraćaj krene, backend može odgovoriti zaglavljem Location koje navodi njegovu privatnu adresu. Preglednik koji slijedi to zaglavlje napušta javnu ulaznu tačku i pokušava dosegnuti nešto što ne može razriješiti. Namjerno konfigurisano prepisivanje odgovora preslikava privatni URL na javni:

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

Zamijenite obje strane stvarnim vrijednostima. Razumijte i uski obim: odgovarajući tekst zaglavlja Location i Refresh se prepisuje, a URL-ovi ugrađeni u HTML, JavaScript ili preuzete datoteke ne.

Ako aplikacija svuda gradi apsolutne linkove, trajno rješenje je njena vlastita konfiguracija vanjskog URL-a, a ne rastući spisak pravila prepisivanja na proxyju. Dodavanje pravila dok izlaz ne izgleda ispravno stvara konfiguraciju koja pada na prvoj stranici koju niko nije testirao. Jedna ispravna postavka aplikacije zamjenjuje cijelu zbirku.

Šta prepisivanje zaglavlja ne može popraviti

Nekoliko susjednih problema izgleda kao problemi s preusmjeravanjem, ali nisu. Zaglavlje Host koje se šalje upstreamu možda mora odgovarati virtualnom hostu backenda. TLS upstream može tražiti određeno ime servera plus provjeru certifikata, a prepisivanje zaglavlja odgovora ne pomaže ni jednom od toga.

Obim kolačića i atributi domena pripadaju aplikaciji i njenoj konfiguraciji. Proxy može cijeli dan izbacivati ili prepisivati zaglavlja i ipak proizvesti sesiju koja pada na drugom zahtjevu, jer je kolačić izdat za host koji preglednik nikada nije posjetio. Taj kvar izgleda povremeno, zato tako dugo preživljava u redu zahtjeva. Čitanje domena kolačića obično završava istragu za minutu.

Držite autentifikaciju i odabir backenda ograničene na predviđenu aplikaciju. Javni obrnuti proxy treba izložiti jednu aplikaciju kroz VPN servera, umjesto da postane univerzalni prolaz do svake privatne adrese koju taj host može dosegnuti. Jedan generički location koji prosljeđuje sve što pozivalac traži pretvara jednu izloženu uslugu u kartu vaše privatne mreže. Imenujte upstream izričito i zadržite ga tamo.

Testirajte redom kojim zahtjev putuje

Potvrdite tri stvari po redu: NGINX je odabrao predviđeni location, dovršio je zahtjev prema backendu, a preglednik je slijedio svako kasnije preusmjerenje i učitao podresurse. Svaki korak ima svoje linije loga, a njihovo čitanje po redu pretvara nejasan 502 u konkretan nalaz.

Razlika koja vam treba je između neuspjele veze s upstreamom i preglednika poslanog na nedostupno privatno ime. Prvo se pojavljuje u logu grešaka proxyja; drugo izgleda kao zahtjev koji nikada ne stiže, a preglednik se žali na host koji ne može razriješiti. Dva različita problema, dvije različite datoteke, i samo jedan od njih uopće uključuje proxy_redirect.