proxy_redirect ba ya haɗa NGINX da host ɗin VPN ɗinka
proxy_redirect yana sake rubuta kanun labarai a cikin amsar da ta riga ta iso; ba ya taɓa zaɓar upstream. Duba proxy_pass, hanyar zuwa backend, sannan kanun labarai.
Sunan yana ɗauke da kalmar redirect, don haka ana liƙa shi cikin block na location sa'ad da ba a iya isa backend bayan VPN ba. Babu abin da ke canjawa, kuma bayyanannen ƙarshe shi ne cewa umarnin ya lalace ko yana buƙatar wata siga. Abin da ya faru a zahiri ya fi sauƙi kuma ba shi da daɗi: proxy_redirect yana aiki ne a kan amsa da ta riga ta dawo, kuma a wannan turawar babu wata buƙata da ta taɓa zuwa haka nesa.
Umarni biyu, lokaci biyu a cikin buƙata ɗaya
Buƙatar HTTP ta hanyar proxy mai juyawa tana wucewa ta hanyoyi da yawa a jere, kuma umarnin biyu suna a ƙarshen wannan jerin. Ɗaya yana zaɓar inda buƙatar za ta je. Ɗayan yana gyara wasu kanun labarai a cikin amsar da ke dawowa.
| 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 |
Wannan tsari shi ne dukan amsar. Idan layi na biyu ba zai taɓa aiki ba saboda na farko ya kasa, umarnin na biyu ba a saita shi ba daidai ba, kawai ba a iya isa gare shi. Ko nawa aka sake rubuta layi na biyu, amsar da ya kamata ya gyara ba za ta bayyana ba. Yi bincike daga layi na farko zuwa waje, kuma halin rikicewar yana warwarewa zuwa hanyar da ba ta nan ko haɗin da aka ƙi.
Zaɓin upstream na proxy_pass ne
A ce NGINX yana gudana a kan host ɗin shiga na jama'a kuma yana iya isa wata manhaja a 10.40.0.20:8080 ta VPN ɗinsa. Sassan da ke zaɓar wannan manhajar suna kama da haka, a cikin block na server da ke akwai:
location / {
proxy_pass http://10.40.0.20:8080;
}
Yi amfani da ainihin tsari, adireshi da tashar jiragen ruwa, kuma ɗauki wannan a matsayin sashe ba turawa ba. Har ila yau dole host ɗin shiga ya riƙe hanyar VPN, hanyar turawa da aka yarda da ita da kuma zirga-zirgar dawowa mai aiki zuwa wannan sabis, domin proxy da zai iya isa adireshi a kan takarda yana buƙatar amincewar kernel.
Tushen jagorar module na proxy yana ajiye zaɓin upstream daban da sake rubuta kanun amsa, kuma yana lura cewa darajar proxy_pass da ke ɗauke da URI tana canza yadda ake maye gurbin prefix na location da ya dace. Ƙara ko cire sassan hanya ba tare da duba URL da manhajar ke tsammani ba hanya ce tabbatacciya ta haifar da 404 da ya yi kama da gazawar turawa.
proxy_redirect yana gyara amsoshin da ke yada adireshi na sirri
Da zarar zirga-zirga ya gudana, backend na iya amsawa da kan Location da ke ambaton adireshinsa na sirri. Mai bincike da ya bi wannan kan yana barin wurin shiga na jama'a kuma yana ƙoƙarin isa wani abu da ba zai iya warwarewa ba. Sake rubutun amsa da aka tsara da gangan yana mai da URL na sirri zuwa na jama'a:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;
Maye gurbin ɓangarorin biyu da ainihin ƙima. Ka fahimci ƙaramin iyaka kuma: ana sake rubuta rubutun kanun Location da Refresh da suka dace, amma URL ɗin da aka saka a cikin HTML, JavaScript ko fayilolin da aka sauke ba a sake rubuta su.
Idan manhaja tana gina cikakkun hanyoyi a ko'ina, maganin dawwama shi ne tsarin URL na waje nata, ba jerin ƙa'idojin sake rubutu da ke ƙaruwa a kan proxy ba. Ƙara ƙa'idoji har sai fitowar ta yi kama da daidai yana haifar da tsarin da zai kasa a shafi na farko da babu wanda ya gwada. Saiti ɗaya daidai na manhaja yana maye gurbin dukan tarin.
Abin da sake rubuta kan ba zai iya gyara ba
Matsaloli da yawa da ke kusa suna kama da matsalolin turawa kuma ba haka suke ba. Kan Host da ake turawa zuwa upstream na iya buƙatar dacewa da host ɗin kama-da-wane na backend. TLS upstream na iya buƙatar takamaiman sunan uwar garke da tabbatar da takardar shaida, kuma sake rubuta kan amsa ba ya taimaka wa ɗaya daga cikinsu.
Iyakar kuki da sifofin yankin suna cikin manhaja da tsarinta. Proxy na iya jefar da kai ko sake rubuta kanun kwana ɗaya kuma har yanzu ya haifar da zama da zai kasa a buƙata ta biyu, domin an ba da kukin ga host ɗin da mai bincike bai taɓa ziyarta ba. Wannan gazawar tana kama da ta lokaci-lokaci, shi ya sa take daɗewa a jerin tikiti. Karanta yankin kukin yawanci yana kawo ƙarshen binciken cikin minti ɗaya.
Riƙe tabbatarwa da zaɓin backend a kan manhajar da aka nufa kuma. Proxy mai juyawa na jama'a yakamata ya fallasa manhaja ɗaya ta VPN ɗin uwar garke maimakon ya zama ƙofa ta gama gari zuwa kowane adireshi na sirri da wannan host zai iya isa. location guda ɗaya na gama gari da ke tura duk abin da mai kira ya nema yana mai da sabis ɗaya da aka fallasa zuwa taswirar cibiyar sadarwarka ta sirri. Ambaci upstream a bayyane kuma ka barshi a can.
Gwada a cikin tsarin da buƙatar take tafiya
Tabbatar da abubuwa uku a jere: NGINX ya zaɓi location ɗin da aka nufa, ya kammala buƙata zuwa backend, kuma mai bincike ya bi duk wata turawa ta gaba ya loda ƙananan kayan aiki. Kowane mataki yana da nasa layukan log, kuma karanta su a jere yana mai da 502 mara bayani zuwa takamaiman bincike.
Bambancin da kuke buƙata shi ne tsakanin haɗin upstream da ya kasa da mai bincike da aka tura zuwa sunan sirri da ba a iya isa ba. Na farko yana bayyana a log ɗin kuskuren proxy; na biyu yana bayyana a matsayin buƙatar da ba ta taɓa zuwa ba, yayin da mai bincike ke korafin host ɗin da ba zai iya warwarewa ba. Matsaloli biyu daban-daban, fayiloli biyu daban-daban, kuma ɗaya ne kawai daga cikinsu ya shafi proxy_redirect kwata-kwata.