proxy_redirect nepřipojí NGINX k vašemu VPN hostu
proxy_redirect přepisuje hlavičky v odpovědi, která už dorazila; upstream nikdy nevolí. Zkontrolujte proxy_pass, trasu k backendu a potom hlavičky.
Název obsahuje slovo redirect, a tak se vloží do bloku location, když je backend za VPN nedostupný. Nic se nezmění a zřejmý závěr je, že direktiva je rozbitá nebo potřebuje jinou syntaxi. Skutečnost je jednodušší a méně lichotivá: proxy_redirect pracuje s odpovědí, která už dorazila, a v tomto nasazení se žádný požadavek tak daleko nedostal.
Dvě direktivy, dva okamžiky v jednom požadavku
HTTP požadavek přes reverzní proxy prochází několika rozhodnutími v pořadí a obě direktivy stojí na opačných koncích této posloupnosti. Jedna volí, kam požadavek půjde. Druhá upravuje určité hlavičky v odpovědi, která se vrací.
| 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 |
To pořadí je celá odpověď. Pokud se druhý řádek nikdy nevykoná, protože první selhal, druhá direktiva není špatně nastavená, je prostě nedosažitelná. Ať druhý řádek přepisujete jakkoli, odpověď, kterou měl upravit, nevznikne. Diagnostikujte od prvního řádku směrem ven a matoucí chování se rozpadne na chybějící trasu nebo odmítnuté spojení.
Výběr upstreamu patří proxy_pass
Předpokládejme, že NGINX běží na veřejném vstupním hostu a přes svou VPN dosáhne aplikace na 10.40.0.20:8080. Fragment, který tuto aplikaci vybírá, vypadá takto, uvnitř existujícího bloku server:
location / {
proxy_pass http://10.40.0.20:8080;
}Použijte skutečné schéma, adresu a port a berte to jako fragment, ne jako nasazení. Vstupní host musí také držet trasu VPN, povolenou cestu přesměrování a funkční zpětný provoz k této službě, protože proxy, které na papíře dosáhne adresy, stále potřebuje souhlas jádra.
Referenční příručka modulu proxy drží výběr upstreamu odděleně od přepisování hlaviček odpovědi a upozorňuje, že hodnota proxy_pass obsahující URI mění způsob nahrazení odpovídajícího prefixu location. Přidávání nebo odebírání částí cesty bez kontroly URL, kterou aplikace očekává, je spolehlivý způsob, jak vytvořit 404, která vypadá jako chyba směrování.
proxy_redirect opravuje odpovědi, které unikají soukromou adresu
Jakmile provoz plyne, backend může odpovědět hlavičkou Location s vlastní soukromou adresou. Prohlížeč, který tuto hlavičku sleduje, opustí veřejný vstupní bod a zkouší dosáhnout něčeho, co nedokáže přeložit. Záměrně nastavené přepisování odpovědi mapuje soukromou URL na veřejnou:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;Nahraďte obě strany skutečnými hodnotami. Pochopte i úzký rozsah: přepisuje se odpovídající text hlaviček Location a Refresh, ale URL vložené v HTML, JavaScriptu nebo stažených souborech ne.
Pokud aplikace všude sestavuje absolutní odkazy, trvalým řešením je její vlastní konfigurace externí URL, ne rostoucí seznam pravidel přepisu na proxy. Přidáváním pravidel, dokud výstup nevypadá správně, vznikne konfigurace, která selže na první stránce, kterou nikdo neotestoval. Jedno správné nastavení aplikace nahradí celou sbírku.
Co přepis hlavičky nedokáže opravit
Několik sousedních problémů vypadá jako problémy s přesměrováním, ale není. Hlavička Host posílaná upstreamu může muset odpovídat virtuálnímu hostu backendu. TLS upstream může vyžadovat konkrétní název serveru a ověření certifikátu, a přepis hlavičky odpovědi nepomůže ani jednomu.
Rozsah cookies a atributy domény patří aplikaci a její konfiguraci. Proxy může celý den zahazovat nebo přepisovat hlavičky a přesto vytvořit relaci, která selže při druhém požadavku, protože cookie byla vydána pro host, který prohlížeč nikdy nenavštívil. Tato chyba vypadá občasně, a proto v frontě požadavků vydrží tak dlouho. Přečtení domény cookie obvykle ukončí vyšetřování během minuty.
Udržujte autentizaci a výběr backendu omezené na zamýšlenou aplikaci. Veřejná reverzní proxy má vystavit jednu aplikaci přes VPN serveru, místo aby se stala univerzální bránou ke každé soukromé adrese, kterou tento host dosáhne. Jediný obecný location, který předává vše, o co volající požádá, promění jednu vystavenou službu v mapu vaší soukromé sítě. Pojmenujte upstream výslovně a nechte ho tam.
Testujte v pořadí, v jakém požadavek putuje
Potvrďte tři věci za sebou: NGINX vybral zamýšlený location, dokončil požadavek na backend a prohlížeč sledoval případné další přesměrování a načetl podzdroje. Každý krok má své řádky v logu a jejich čtení v pořadí promění neurčitou 502 v konkrétní zjištění.
Rozlišení, které potřebujete, je mezi neúspěšným spojením s upstreamem a prohlížečem poslaným na nedostupné soukromé jméno. První se objeví v chybovém logu proxy; druhé vypadá jako požadavek, který nikdy nedorazí, a prohlížeč si stěžuje na host, který nedokáže přeložit. Dva různé problémy, dva různé soubory a jen jeden z nich vůbec zahrnuje proxy_redirect.