proxy_redirect ne konektas NGINX al via VPN-gastiganto
proxy_redirect reverkas kapliniojn en respondo, kiu jam alvenis; ĝi neniam elektas la upstream. Kontrolu proxy_pass, la itineron al la backend, poste la kapliniojn.
La nomo enhavas la vorton redirect, do ĝi estas enmetata en blokon location kiam backend malantaŭ la VPN ne atingeblas. Nenio ŝanĝiĝas, kaj la evidenta konkludo estas, ke la direktivo estas difektita aŭ bezonas alian sintakson. Tio, kio fakte okazis, estas pli simpla kaj malpli flata: proxy_redirect agas sur respondo, kiu jam revenis, kaj en ĉi tiu deplojo neniu peto iam tiom malproksimen alvenis.
Du direktivoj, du momentoj en unu peto
HTTP-peto tra inversa prokurilo trapasas plurajn decidojn laŭvice, kaj la du direktivoj staras ĉe la kontraŭaj finoj de tiu sinsekvo. Unu elektas, kien la peto iras. La alia redaktas certajn kapliniojn en la respondo, kiu revenas.
| 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 |
Tiu ordo estas la tuta respondo. Se la dua vico neniam plenumiĝas, ĉar la unua malsukcesis, la dua direktivo ne estas malĝuste agordita, ĝi simple neatingeblas. Kiom ajn oni reverku la duan linion, la respondo, kiun ĝi devis redakti, ne ekestos. Diagnozu de la unua vico eksteren, kaj la konfuza konduto solviĝas en mankantan itineron aŭ rifuzitan konekton.
La elekto de upstream apartenas al proxy_pass
Supozu, ke NGINX funkcias sur publika enirgastiganto kaj povas atingi aplikaĵon ĉe 10.40.0.20:8080 tra sia VPN. La fragmento, kiu elektas tiun aplikaĵon, aspektas tiel, ene de ekzistanta bloko server:
location / {
proxy_pass http://10.40.0.20:8080;
}Uzu la realan skemon, adreson kaj porton, kaj traktu tion kiel fragmenton, ne kiel deplojon. La enirgastiganto ankaŭ devas teni la VPN-itineron, permesitan plusendan vojon kaj funkciantan revenan trafikon al tiu servo, ĉar prokurilo, kiu povas atingi adreson surpaperen, ankoraŭ bezonas la konsenton de la kerno.
La referenco de la modulo proxy tenas la elekton de upstream aparte de la reverkado de respondaj kaplinioj, kaj rimarkigas, ke valoro proxy_pass enhavanta URI ŝanĝas kiel la kongrua location-prefikso estas anstataŭigata. Aldoni aŭ forigi vojerojn sen kontroli la URL-on, kiun la aplikaĵo atendas, estas fidinda maniero produkti 404, kiu aspektas kiel enkursiga fiasko.
proxy_redirect riparas respondojn, kiuj likas privatan adreson
Post kiam trafiko fluas, backend povas respondi per kaplinio Location nomanta sian privatan adreson. Retumilo sekvanta tiun kaplinion forlasas la publikan enirpunkton kaj provas atingi ion, kion ĝi ne povas solvi. Intence agordita responda reverkado mapas la privatan URL-on sur la publikan:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;Anstataŭigu ambaŭ flankojn per realaj valoroj. Komprenu ankaŭ la mallarĝan amplekson: kongrua teksto de la kaplinioj Location kaj Refresh estas reverkata, dum URL-oj enmetitaj en HTML, JavaScript aŭ elŝutitaj dosieroj ne estas.
Se aplikaĵo konstruas absolutajn ligilojn ĉie, la daŭra solvo estas ĝia propra agordo de ekstera URL, ne kreskanta listo de reverkaj reguloj sur la prokurilo. Aldoni regulojn ĝis la eligo aspektas ĝusta produktas agordon, kiu fiaskas sur la unua paĝo, kiun neniu testis. Unu ĝusta agordo de la aplikaĵo anstataŭigas la tutan kolekton.
Kion kaplinia reverkado ne povas ripari
Pluraj apudaj problemoj aspektas kiel alidirektaj problemoj kaj ne estas. La kaplinio Host sendata al upstream eble devas kongrui kun la virtuala gastiganto de la backend. TLS-upstream eble bezonas specifan servilan nomon plus atestilan kontrolon, kaj reverkado de responda kaplinio helpas al neniu el ili.
La amplekso de kuketoj kaj domajnaj atributoj apartenas al la aplikaĵo kaj ĝia agordo. Prokurilo povas la tutan tagon forĵeti aŭ reverki kapliniojn kaj tamen produkti seancon, kiu fiaskas ĉe la dua peto, ĉar la kuketo estis eldonita por gastiganto, kiun la retumilo neniam vizitis. Tiu fiasko aspektas intermita, kaj tial ĝi postvivas tiel longe en bileta vico. Legi la domajnon de la kuketo kutime finas la enketon en unu minuto.
Tenu ankaŭ aŭtentikigon kaj elekton de backend limigitaj al la celita aplikaĵo. Publika inversa prokurilo devus elmeti unu aplikaĵon tra la VPN de la servilo anstataŭ fariĝi ĝenerala enirejo al ĉiu privata adreso, kiun tiu gastiganto povas atingi. Unu ĝenerala location, kiu plusendas ĉion, kion la alvokanto petas, transformas unu elmetitan servon en mapon de via privata reto. Nomu la upstream eksplicite kaj tenu ĝin tie.
Testu laŭ la ordo, laŭ kiu vojaĝas la peto
Konfirmu tri aferojn sinsekve: NGINX elektis la celitan location, ĝi finis peton al la backend, kaj la retumilo sekvis ajnan postan alidirekton kaj ŝargis la subrimedojn. Ĉiu paŝo havas siajn proprajn protokolajn liniojn, kaj legi ilin laŭorde transformas svagan 502 en konkretan konstaton.
La distingo, kiun vi bezonas, estas inter malsukcesa upstream-konekto kaj retumilo sendita al neatingebla privata nomo. La unua aperas en la erara protokolo de la prokurilo; la dua aperas kiel peto, kiu neniam alvenas, dum la retumilo plendas pri gastiganto, kiun ĝi ne povas solvi. Du malsamaj problemoj, du malsamaj dosieroj, kaj nur unu el ili entute koncernas proxy_redirect.