proxy_redirect verbind NGINX nie met jou VPN-gasheer nie
proxy_redirect herskryf koptekste in 'n antwoord wat reeds aangekom het; dit kies nooit die upstream nie. Kontroleer proxy_pass, die roete na die backend, en dan die koptekste.
Die naam bevat die woord redirect, daarom word dit in 'n location-blok geplak wanneer 'n backend agter die VPN nie bereik kan word nie. Niks verander nie, en die ooglopende gevolgtrekking is dat die richtlyn stukkend is of ander sintaksis nodig het. Wat gebeur het, is eenvoudiger en minder vleiend: proxy_redirect werk op 'n antwoord wat al teruggekom het, en in hierdie ontplooiing het geen versoek ooit so ver gekom nie.
Twee richtlyne, twee oomblikke in een versoek
'n HTTP-versoek deur 'n omgekeerde proxy gaan in volgorde deur verskeie besluite, en die twee richtlyne le aan die teenoorgestelde kante van daardie reeks. Die een kies waarheen die versoek gaan. Die ander wys sekere koptekste in die antwoord wat terugkom.
| 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 |
Daardie volgorde is die hele antwoord. As die tweede ry nooit uitgevoer word nie omdat die eerste een gefaal het, is die tweede richtlyn nie verkeerd opgestel nie, dit is bloot onbereikbaar. Geen hoeveelheid herskryf aan die tweede reël sal die antwoord skep wat dit moes wysig nie. Diagnoseer van die eerste ry af uitwaarts, en die verwarrende gedrag los op in 'n ontbrekende roete of 'n geweierde verbinding.
Die keuse van die upstream hoort by proxy_pass
Veronderstel NGINX draf op 'n publieke intreehost en kan 'n toepassing by 10.40.0.20:8080 oor sy VPN bereik. Die brokkie wat daardie toepassing kies, lyk so, binne 'n bestaande server-blok:
location / {
proxy_pass http://10.40.0.20:8080;
}Gebruik die werklike skema, adres en poort, en behandel dit as 'n brokkie eerder as 'n ontplooiing. Die intreehost moet ook die VPN-roete hou, 'n toegelate aanstuurpad en werkende terugkeerverkeer na daardie diens, want 'n proxy wat 'n adres op papier kan bereik, het steeds die kernel se instemming nodig.
Die verwysing vir die proxy-module hou die keuse van die upstream apart van die herskryf van antwoordkoptekste, en dit wys daarop dat 'n proxy_pass-waarde met 'n URI daarin verander hoe die ooreenstemmende location-voorvoegsel vervang word. Om padkomponente by te voeg of te verwyder sonder om die URL te kontrolleer wat die toepassing verwag, is 'n betroubare manier om 'n 404 te produseer wat soos 'n roeteringsfout lyk.
proxy_redirect herstel antwoorde wat 'n private adres lek
Sodra verkeer vloei, kan 'n backend antwoord met 'n Location-kopteks wat sy private adres noem. 'n Blaaier wat daardie kopteks volg, verlaat die publieke intreepunt en probeer iets bereik wat dit nie kan oplos nie. 'n Doelbewus opgestelde antwoordherskrywing beeld die private URL op die publieke een af:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;Vervang beide kante met werklike waardes. Verstaan ook die noue omvang: ooreenstemmende teks in die Location- en Refresh-koptekste word herskryf, en URL's wat in HTML, JavaScript of afgelaaide lêers ingebed is, word nie.
As 'n toepassing oral absolute skakels bou, is die blywende oplossing sy eie eksterne-URL-konfigurasie, nie 'n groeiende lys herskryfreëls op die proxy nie. Om reëls by te voeg totdat die uitset reg lyk, lewer 'n konfigurasie wat faal op die eerste bladsy wat niemand getoets het nie. Een korrekte toepassingsinstelling vervang die hele versameling.
Wat 'n kopteksherskrywing nie kan herstel nie
Verskeie aangrensende probleme lyk soos herleidingsprobleme en is dit nie. Die Host-kopteks wat stroomop gestuur word, moet dalk by die backend se virtuele gasheer pas. 'n TLS-upstream het dalk 'n spesifieke bedienernaam plus sertifikaatverifikasie nodig, en die herskryf van 'n antwoordkopteks doen niks vir enigeen van die twee nie.
Die omvang van koekies en domeinattribute hoort by die toepassing en sy konfigurasie. 'n Proxy kan heeldag koptekste laat val of herskryf en steeds 'n sessie lewer wat by die tweede versoek faal, want die koekie is uitgereik vir 'n gasheer wat die blaaier nooit besoek het nie. Daardie faling lyk wisselvallig, en daarom oorleef dit so lank in 'n kaartjiery. Om die koekiedomein te lees, beëindig gewoonlik die ondersoek binne 'n minuut.
Hou ook stawing en die keuse van die backend beperk tot die beoogde toepassing. 'n Publieke omgekeerde proxy behoort een toepassing deur die bediener se VPN bloot te lê eerder as om 'n algemene poort te word na elke private adres wat daardie gasheer kan bereik. 'n Enkele generiese location wat alles aanstuur wat die oproeper vra, verander een blootgelate diens in 'n kaart van jou private netwerk. Noem die upstream uitdruklik en hou dit daar.
Toets in die orde waarin die versoek beweeg
Bevestig drie dinge in volgorde: NGINX het die beoogde location gekies, dit het 'n versoek na die backend voltooi, en die blaaier het enige latere herleiding gevolg en die subbronne gelaai. Elke stap het sy eie logreëls, en om dit in volgorde te lees, verander 'n vae 502 in 'n spesifieke bevinding.
Die onderskeid wat jy nodig het, is tussen 'n mislukte upstream-verbinding en 'n blaaier wat na 'n onbereikbare private naam gestuur is. Die eerste verskyn in die proxy-foutlog; die tweede verskyn as 'n versoek wat nooit aankom nie, terwyl die blaaier kla oor 'n gasheer wat dit nie kan oplos nie. Twee verskillende probleme, twee verskillende lêers, en net een van hulle het enigsins met proxy_redirect te doen.