proxy_redirect nu conectează NGINX la gazda ta VPN
proxy_redirect rescrie anteturi într-un răspuns care a sosit deja; nu alege niciodată upstream-ul. Verifică proxy_pass, ruta către backend, apoi anteturile.
Numele conține cuvântul redirect, așa că este lipit într-un bloc location atunci când un backend din spatele VPN-ului nu poate fi atins. Nimic nu se schimbă, iar concluzia evidentă este că directiva este stricată sau are nevoie de altă sintaxă. Ce s-a întâmplat de fapt este mai simplu și mai puțin măgulitor: proxy_redirect acționează asupra unui răspuns care s-a întors deja, iar în această instalare nicio cerere nu a ajuns atât de departe.
Două directive, două momente într-o singură cerere
O cerere HTTP printr-un proxy invers trece prin mai multe decizii în ordine, iar cele două directive stau la capetele opuse ale acelei secvențe. Una alege unde merge cererea. Cealaltă editează anumite anteturi din răspunsul care se întoarce.
| 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 |
Acea ordine este tot răspunsul. Dacă a doua linie nu se execută niciodată pentru că prima a eșuat, a doua directivă nu este configurată greșit, este pur și simplu inaccesibilă. Oricât ai rescrie a doua linie, răspunsul pe care trebuia să îl editeze nu va apărea. Diagnostichează de la prima linie spre exterior, iar comportamentul confuz se reduce la o rută lipsă sau la o conexiune refuzată.
Alegerea upstream-ului aparține lui proxy_pass
Să presupunem că NGINX rulează pe un host de intrare public și ajunge la o aplicație la 10.40.0.20:8080 prin VPN-ul său. Fragmentul care alege acea aplicație arată așa, într-un bloc server existent:
location / {
proxy_pass http://10.40.0.20:8080;
}Folosește schema, adresa și portul reale și tratează asta ca un fragment, nu ca o instalare. Hostul de intrare trebuie să țină și ruta VPN, o cale de redirecționare permisă și trafic de retur funcțional către acel serviciu, pentru că un proxy care atinge o adresă pe hârtie are totuși nevoie de acordul nucleului.
Referința modulului proxy ține selecția upstream-ului separată de rescrierea anteturilor de răspuns și notează că o valoare proxy_pass care conține un URI schimbă modul în care este înlocuit prefixul location corespunzător. Adăugarea sau eliminarea componentelor de cale fără verificarea URL-ului pe care îl așteaptă aplicația este o modalitate sigură de a produce un 404 care arată ca o eroare de rutare.
proxy_redirect repară răspunsurile care scurg o adresă privată
Odată ce traficul curge, un backend poate răspunde cu un antet Location care îi numește adresa privată. Un browser care urmează acel antet părăsește punctul de intrare public și încearcă să atingă ceva ce nu poate rezolva. O rescriere de răspuns configurată intenționat mapează URL-ul privat pe cel public:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;Înlocuiește ambele părți cu valori reale. Înțelege și aria îngustă: textul anteturilor Location și Refresh care se potrivesc este rescris, iar URL-urile încorporate în HTML, JavaScript sau fișiere descărcate nu.
Dacă o aplicație construiește linkuri absolute peste tot, soluția durabilă este configurația proprie de URL extern, nu o listă tot mai mare de reguli de rescriere pe proxy. Adăugarea de reguli până când ieșirea arată bine produce o configurație care eșuează pe prima pagină pe care nimeni nu a testat-o. O singură setare corectă a aplicației înlocuiește toată colecția.
Ce nu poate repara o rescriere de antet
Câteva probleme vecine arată ca probleme de redirecționare și nu sunt. Antetul Host trimis către upstream poate trebui să corespundă hostului virtual al backend-ului. Un upstream TLS poate avea nevoie de un nume de server anume plus verificarea certificatului, iar rescrierea unui antet de răspuns nu ajută la niciuna.
Aria cookie-urilor și atributele de domeniu aparțin aplicației și configurației sale. Un proxy poate arunca sau rescrie anteturi toată ziua și tot poate produce o sesiune care eșuează la a doua cerere, pentru că cookie-ul a fost emis pentru un host pe care browserul nu l-a vizitat niciodată. Acea eșuare pare intermitentă, de aceea supraviețuiește atât de mult într-o coadă de tichete. Citirea domeniului cookie-ului încheie de obicei investigația într-un minut.
Păstrează și autentificarea și selecția backend-ului limitate la aplicația dorită. Un proxy invers public ar trebui să expună o singură aplicație prin VPN-ul serverului în loc să devină o poartă generică spre fiecare adresă privată pe care acel host o poate atinge. Un singur location generic care redirecționează tot ce cere apelantul transformă un serviciu expus într-o hartă a rețelei tale private. Numește upstream-ul explicit și ține-l acolo.
Testează în ordinea în care călătorește cererea
Confirmă trei lucruri în succesiune: NGINX a ales location-ul dorit, a finalizat o cerere către backend, iar browserul a urmat orice redirecționare ulterioară și a încărcat subresursele. Fiecare pas are propriile linii de log, iar citirea lor în ordine transformă un 502 vag într-o constatare concretă.
Distincția de care ai nevoie este între o conexiune upstream eșuată și un browser trimis către un nume privat inaccesibil. Prima apare în logul de erori al proxy-ului; a doua apare ca o cerere care nu sosește niciodată, browserul plângându-se de un host pe care nu îl poate rezolva. Două probleme diferite, două fișiere diferite, și doar una dintre ele implică proxy_redirect.