proxy_redirect ferbynt NGINX net mei jo VPN-host
proxy_redirect oerskriuwt koppen yn in antwurd dat al oankommen is; it kiest nea de upstream. Kontrolearje proxy_pass, de rûte nei de backend, en dan de koppen.
De namme befettet it wurd redirect, dus wurdt it yn in location-blok plakt as in backend efter de VPN net berikber is. Der feroaret neat, en de foar de hân lizzende konklúzje is dat de rjochtline stikken is of oare syntaksis nedich hat. Wat der echt barde is ienfâldiger en minder flaaikjend: proxy_redirect wurket op in antwurd dat al weromkommen is, en yn dizze útrôl kaam gjin inkel fersyk ea sa fier.
Twa rjochtlinen, twa mominten yn ien fersyk
In HTTP-fersyk troch in omkearde proxy giet efterinoar troch ferskate besluten, en de twa rjochtlinen steane oan de tsjinoerstelde einen fan dy searje. Ien kiest wêr't it fersyk hinne giet. De oare bewurket bepaalde koppen yn it antwurd dat weromkomt.
| 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 |
Dy folchoarder is it hiele antwurd. As de twadde rigel nea útfierd wurdt om't de earste mislearre, is de twadde rjochtline net ferkeard konfigurearre, se is gewoan net berikber. Hoe folle de twadde rigel ek oerskreaun wurdt, it antwurd dat er bewurkje moast ûntstiet net. Diagnostearje fan de earste rigel nei bûten, en it betiizjende gedrach lost op yn in ûntbrekkende rûte of in wegere ferbining.
It kiezen fan de upstream heart by proxy_pass
Stel dat NGINX op in iepenbiere yngongshost draait en in applikaasje op 10.40.0.20:8080 berikke kin fia syn VPN. It fragmint dat dy applikaasje kiest sjocht der sa út, binnen in besteand server-blok:
location / {
proxy_pass http://10.40.0.20:8080;
}Brûk it echte skema, adres en poarte, en behannelje dit as in fragmint en net as in útrôl. De yngongshost moat ek de VPN-rûte, in tastiene trochstjoerde paad en wurkjend weromferkear nei dy tsjinst hâlde, want in proxy dy't in adres op papier berikt, hat noch altyd de ynstimming fan de kernel nedich.
De referinsje fan de proxy-module hâldt de kar fan upstream los fan it oerskriuwen fan antwurdkoppen, en merkt op dat in proxy_pass-wearde mei in URI feroaret hoe't it oerienkommende location-prefiks ferfongen wurdt. Paadkomponinten tafoegje of fuorthelje sûnder de URL te kontrolearjen dy't de applikaasje ferwachtet, is in betroubere manier om in 404 te meitsjen dy't liket op in rûteflater.
proxy_redirect reparearret antwurden dy't in privee adres lekke
Sadree't ferkear streamt, kin in backend antwurdzje mei in Location-kop dy't syn privee adres neamt. In browser dy't dy kop folget ferlit it iepenbiere yngongspunt en besiket iets te berikken dat er net oplosse kin. In opsetlik konfigurearre antwurdoerskriuwing byldet de privee URL op de iepenbiere ôf:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;Ferfang beide kanten troch echte wearden. Begryp ek de smelle omfang: oerienkommende tekst fan de koppen Location en Refresh wurdt oerskreaun, mar URL's dy't yn HTML, JavaScript of downloade bestannen ynbêde binne net.
As in applikaasje oeral absolute keppelings bout, is de duorsume oplossing syn eigen konfiguraasje foar eksterne URL, net in groeiende list oerskriuwregels op de proxy. Regels tafoegje oant de útfier goed liket, jout in konfiguraasje dy't mislearret op de earste side dy't nimmen teste. Ien goede ynstelling fan de applikaasje ferfangt de hiele samling.
Wat in kop-oerskriuwing net reparearje kin
Ferskate oanbuorjende problemen lykje op trochferwizingsproblemen en binne dat net. De Host-kop dy't nei upstream stjoerd wurdt, moat miskien oerienkomme mei de firtuele host fan de backend. In TLS-upstream kin in spesifike servernamme plus sertifikaatferifikaasje nedich hawwe, en it oerskriuwen fan in antwurdkop helpt by gjin fan beide.
Cooky-omfang en domeinattributen hearre by de applikaasje en syn konfiguraasje. In proxy kin de hiele dei koppen fuortsmite of oerskriuwe en dochs in sesje meitsje dy't by it twadde fersyk mislearret, om't de cooky útjûn is foar in host dy't de browser nea besocht hat. Dy flater liket tuskenskofts, en dêrom oerlibbet er sa lang yn in kaartsje-rige. It domein fan de cooky lêze einiget it ûndersyk meastentiids yn in minút.
Hâld ek autentikaasje en de kar fan backend beheind ta de bedoelde applikaasje. In iepenbiere omkearde proxy soe ien applikaasje fia it VPN fan de server bleatstelle ynstee fan in algemiene poarte te wurden nei elk privee adres dat dy host berikke kin. Ien algemien location dat alles trochstjoert wat de oanropper freget, feroaret ien bleatstelde tsjinst yn in kaart fan jo privee netwurk. Neam de upstream eksplisyt en hâld him dêr.
Test yn de folchoarder wêryn't it fersyk reizget
Befêstigje trije dingen efterinoar: NGINX keas it bedoelde location, it foltôge in fersyk nei de backend, en de browser folge elke lettere trochferwizing en lade de subboarnen. Eltse stap hat syn eigen logrigels, en se yn folchoarder lêze makket fan in ûndúdlike 502 in konkreet befyn.
It ûnderskied dat jo nedich hawwe is tusken in mislearre upstream-ferbining en in browser dy't nei in net berikbere privee namme stjoerd is. It earste ferskynt yn it flaterlog fan de proxy; it twadde ferskynt as in fersyk dat nea oankomt, wylst de browser klaget oer in host dy't er net oplosse kin. Twa ferskate problemen, twa ferskate bestannen, en mar ien fan beide hat wat mei proxy_redirect te meitsjen.