proxy_redirect nepripája NGINX k vášmu VPN hostu
proxy_redirect prepisuje hlavičky v odpovedi, ktorá už dorazila; upstream nikdy nevyberie. Skontrolujte proxy_pass, trasu k backendu a potom hlavičky.
Názov obsahuje slovo redirect, a preto sa vkladá do bloku location, keď je backend za VPN nedostupný. Nič sa nemení a zrejmý záver je, že direktíva je pokazená alebo potrebuje inú syntax. V skutočnosti sa stalo niečo jednoduchšie a menej lichotivé: proxy_redirect pracuje s odpoveďou, ktorá sa už vrátila, a v tomto nasadení sa žiadna požiadavka tak ďaleko nedostala.
Dve direktívy, dva momenty v jednej požiadavke
HTTP požiadavka cez reverznú proxy prechádza niekoľkými rozhodnutiami v poradí a obe direktívy stoja na opačných koncoch tohto sledu. Jedna vyberá, kam požiadavka pôjde. Druhá upravuje určité hlavičky v odpovedi, ktorá sa vracia.
| 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 |
Toto poradie je celá odpoveď. Ak sa druhý riadok nikdy nevykoná, pretože prvý zlyhal, druhá direktíva nie je nesprávne nakonfigurovaná, je jednoducho nedosiahnuteľná. Nech druhý riadok prepisujete akokoľvek, odpoveď, ktorú mal upraviť, nevznikne. Diagnostikujte od prvého riadku smerom von a mätúce správanie sa rozpadne na chýbajúcu trasu alebo odmietnuté spojenie.
Výber upstreamu patrí proxy_pass
Predpokladajme, že NGINX beží na verejnom vstupnom hoste a cez svoju VPN dosiahne aplikáciu na 10.40.0.20:8080. Fragment, ktorý túto aplikáciu vyberá, vyzerá takto, vo vnútri existujúceho bloku server:
location / {
proxy_pass http://10.40.0.20:8080;
}Použite skutočnú schému, adresu a port a berte to ako fragment, nie ako nasadenie. Vstupný host musí tiež držať trasu VPN, povolenú cestu presmerovania a funkčnú návratovú prevádzku k tejto službe, pretože proxy, ktoré na papieri dosiahne adresu, stále potrebuje súhlas jadra.
Referenčná príručka modulu proxy drží výber upstreamu oddelene od prepisovania hlavičiek odpovede a upozorňuje, že hodnota proxy_pass obsahujúca URI mení spôsob nahradenia zodpovedajúceho prefixu location. Pridávanie alebo odstraňovanie častí cesty bez kontroly URL, ktorú aplikácia očakáva, je spoľahlivý spôsob, ako vyrobiť 404, ktorá vyzerá ako chyba smerovania.
proxy_redirect opravuje odpovede, ktoré unikajú súkromnú adresu
Akonáhle prevádzka plynie, backend môže odpovedať hlavičkou Location s vlastnou súkromnou adresou. Prehliadač, ktorý túto hlavičku sleduje, opustí verejný vstupný bod a skúša dosiahnuť niečo, čo nedokáže preložiť. Zámerne nastavené prepisovanie odpovede mapuje súkromnú URL na verejnú:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;Nahraďte obe strany skutočnými hodnotami. Pochopte aj úzky rozsah: zodpovedajúci text hlavičiek Location a Refresh sa prepisuje, ale URL vložené v HTML, JavaScripte alebo stiahnutých súboroch nie.
Ak aplikácia všade zostavuje absolútne odkazy, trvalým riešením je jej vlastná konfigurácia externej URL, nie rastúci zoznam pravidiel prepisovania na proxy. Pridávaním pravidiel, kým výstup nevyzerá správne, vznikne konfigurácia, ktorá zlyhá na prvej strane, ktorú nikto netestoval. Jedno správne nastavenie aplikácie nahradí celú zbierku.
Čo prepis hlavičky nedokáže opraviť
Niekoľko susedných problémov vyzerá ako problémy s presmerovaním, ale nie sú. Hlavička Host odosielaná na upstream môže musieť zodpovedať virtuálnemu hostu backendu. TLS upstream môže vyžadovať konkrétny názov servera a overenie certifikátu a prepis hlavičky odpovede nepomáha ani jednému.
Rozsah cookies a atribúty domény patria aplikácii a jej konfigurácii. Proxy môže celý deň zahadzovať alebo prepisovať hlavičky a napriek tomu vytvoriť reláciu, ktorá zlyhá pri druhej požiadavke, pretože cookie bola vydaná pre host, ktorý prehliadač nikdy nenavštívil. Táto chyba vyzerá občasne, a preto v rade požiadaviek vydrží tak dlho. Prečítanie domény cookie zvyčajne ukončí vyšetrovanie za minútu.
Udržujte autentifikáciu a výber backendu obmedzené na zamýšľanú aplikáciu. Verejná reverzná proxy má vystaviť jednu aplikáciu cez VPN servera a nie stať sa univerzálnou bránou ku každej súkromnej adrese, ktorú tento host dosiahne. Jediný všeobecný location, ktorý preposiela všetko, o čo volajúci požiada, premení jednu vystavenú službu na mapu vašej súkromnej siete. Pomenujte upstream výslovne a nechajte ho tam.
Testujte v poradí, v akom požiadavka putuje
Potvrďte tri veci za sebou: NGINX vybral zamýšľaný location, dokončil požiadavku na backend a prehliadač nasledoval prípadné ďalšie presmerovanie a načítal podzdroje. Každý krok má svoje riadky v logu a ich čítanie v poradí premení neurčitú 502 na konkrétne zistenie.
Rozlíšenie, ktoré potrebujete, je medzi neúspešným spojením s upstreamom a prehliadačom poslaným na nedostupné súkromné meno. Prvé sa objaví v chybovom logu proxy; druhé vyzerá ako požiadavka, ktorá nikdy nedorazí, a prehliadač sa sťažuje na host, ktorý nedokáže preložiť. Dva rôzne problémy, dva rôzne súbory a len jeden z nich vôbec zahŕňa proxy_redirect.