proxy_redirect tengir NGINX ekki við VPN-hýsinguna þína
proxy_redirect endurskrifar hausa í svari sem þegar er komið; það velur aldrei upstream. Athugaðu proxy_pass, leiðina að bakendanum og svo hausana.
Nafnið inniheldur orðið redirect, svo það er límt inn í location-blokk þegar ekki er hægt að ná í bakenda bak við VPN. Ekkert breytist, og augljós ályktun er sú að tilskipunin sé brotin eða þurfi aðra setningagerð. Það sem raunverulega gerðist er einfaldara og minna hrósandi: proxy_redirect vinnur á svari sem þegar er komið til baka, og í þessari uppsetningu komst engin beiðni nokkurn tíma svo langt.
Tvær tilskipanir, tvö augnablik í einni beiðni
HTTP-beiðni gegnum öfugt proxy fer í gegnum nokkrar ákvarðanir í röð, og tilskipanirnar tvær liggja á gagnstæðum endum þeirrar röðar. Önnur velur hvert beiðnin fer. Hin breytir ákveðnum hausum í svarinu sem kemur til baka.
| 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 |
Sú röð er allt svarið. Ef seinni línan keyrir aldrei því fyrri mistókst, er seinni tilskipunin ekki rangt stillt, hún er einfaldlega óaðgengileg. Sama hversu mikið seinni línan er endurskrifuð, svarið sem hún átti að breyta verður ekki til. Greindu frá fyrstu línu og út, og ruglingsleg hegðun leysist í vantar leið eða hafnaða tengingu.
Val á upstream tilheyrir proxy_pass
Gerum ráð fyrir að NGINX keyri á opinberum inngangshýsingu og nái í forrit á 10.40.0.20:8080 um VPN-ið sitt. Búturinn sem velur það forrit lítur svona út, inni í núverandi server-blokk:
location / {
proxy_pass http://10.40.0.20:8080;
}Notaðu raunverulega skemu, vistfang og port, og meðhöndlaðu þetta sem bút en ekki uppsetningu. Inngangshýsingin verður líka að halda VPN-leiðinni, leyfðri framsendingarleið og virkri afturumferð til þeirrar þjónustu, því proxy sem nær vistfangi á pappír þarf samt samþykki kjarnans.
Tilvísun proxy-einingarinnar heldur vali á upstream aðskildu frá endurskrifun svarshausta, og bendir á að gildi proxy_pass sem inniheldur URI breytir því hvernig samsvarandi location-forskeyti er skipt út. Að bæta við eða fjarlægja slóðarhluta án þess að athuga slóðina sem forritið væntir er áreiðanleg leið til að búa til 404 sem lítur út eins og leiðarvilla.
proxy_redirect lagar svör sem leka einkavistfangi
Þegar umferð flæðir getur bakendi svarað með Location haus sem nefnir einkavistfang sitt. Vafri sem fylgir þeim haus yfirgefur opinbera inngangspunktinn og reynir að ná í eitthvað sem hann getur ekki leyst. Viljandi stillt endurskrifun svars varpar einkaslóðinni yfir á þá opinberu:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;Skiptu báðum hliðum út fyrir raunveruleg gildi. Skildu líka þrönga umfangið: samsvarandi texti Location og Refresh hausa er endurskrifaður, en slóðir sem eru felldar inn í HTML, JavaScript eða niðurhalaðar skrár ekki.
Ef forrit byggir algildar krækjur alls staðar er varanleg lausn eigin stilling þess fyrir ytri slóð, ekki vaxandi listi endurskrifunarreglna á proxyinu. Að bæta við reglum þar til úttakið lítur rétt út framleiðir stillingu sem bregst á fyrstu síðunni sem enginn prófaði. Ein rétt stilling forritsins kemur í stað alls safnsins.
Hvað endurskrifun hauss getur ekki lagað
Nokkur nágrannavandamál líta út eins og vandamál með endurbeiningu og eru það ekki. Host-hausinn sem sendur er til upstreams þarf kannski að passa við sýndarhýsingu bakendans. TLS-upstream gæti þurft tiltekið þjónsheiti auk vottorðsstaðfestingar, og endurskrifun svarshaus gerir ekkert fyrir hvort tveggja.
Umfang vafrakaka og lénseiginleikar tilheyra forritinu og stillingum þess. Proxy getur hent eða endurskrifað hausa allan daginn og samt framleitt lotu sem bregst á seinni beiðninni, því vafrakakan var gefin út fyrir hýsingu sem vafrinn heimsótti aldrei. Sú bilun virðist koma og fara, og þess vegna lifir hún svona lengi í miðasölu. Að lesa lén vafrakökunnar endar rannsóknina venjulega á mínútu.
Haltu líka auðkenningu og vali á bakenda innan við fyrirhugað forrit. Opinbert öfugt proxy ætti að birta eitt forrit gegnum VPN þjónsins í stað þess að verða almenn hlið að hverju einkavistfangi sem sú hýsing nær í. Eitt almenn location sem sendir áfram allt sem kallað er eftir breytir einni birtri þjónustu í kort af einkanetinu þínu. Nefndu upstream skýrt og haltu honum þar.
Prófaðu í þeirri röð sem beiðnin fer
Staðfestu þrjá hluti í röð: NGINX valdi fyrirhugaða location, kláraði beiðni til bakendans, og vafrinn fylgdi hverri síðari endurbeiningu og hlóð undirbjörgunum. Hvert skref hefur sínar eigin logglínur, og að lesa þær í röð breytir óljósu 502 í ákveðna niðurstöðu.
Greinin sem þú þarft er milli misheppnaðrar upstream-tengingar og vafra sem sendur er á óaðgengilegt einkanafn. Fyrra tilvikið birtist í villulogi proxysins; síðara tilvikið birtist sem beiðni sem kemur aldrei, með vafrann kvartandi um hýsingu sem hann getur ekki leyst. Tvö ólík vandamál, tvær ólíkar skrár, og aðeins annað þeirra tengist proxy_redirect yfirhöfuð.