proxy_redirect NGINX'ти VPN хостүңүз менен туташтырбайт
proxy_redirect буга чейин келген жооптогу баш жазууларды кайра жазат; ал upstream'ди эч качан тандабайт. proxy_pass, backend'ге барган маршрут, анан баш жазууларды текшериңиз.
Аталышында redirect сөзү бар, ошондуктан VPN артындагы backend жеткиликсиз болгондо аны location блогуна жабыштырышат. Эч нерсе өзгербейт, ал эми ачык тыянак — директива бузулган же башка синтаксис керек. Чынында болгону жөнөкөй жана анча мактоого татыбаган нерсе: proxy_redirect буга чейин кайткан жооп менен иштейт, бул жайгаштырууда эч бир суроо андай алыс жеткен эмес.
Эки директива, бир суроодогу эки учур
Кайта прокси аркылуу өткөн HTTP суроосу бир нече чечимден кезеги менен өтөт, эки директива ошол тизменин карама-каршы учтарында турат. Бири суроо кайда бараарын тандайт. Экинчиси кайтып келген жооптогу айрым баш жазууларды оңдойт.
| 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 |
Ошол тартип — толук жооп. Эгер биринчи сап ката кеткендиктен экинчи сап эч качан аткарылбаса, экинчи директива туура эмес конфигурацияланган эмес, ал жөн гана жеткиликсиз. Экинчи сапты канча жолу кайра жазсаңыз да, ал оңдоого тийиш болгон жооп пайда болбойт. Биринчи саптан сыртка карай диагностика жасаңыз, түшүнүксүз жүрүм-турум жок маршрутка же четке кагылган байланышка айланат.
Upstream тандоо proxy_pass иши
NGINX коомдук кирүү хостунда иштеп, өз VPN аркылуу 10.40.0.20:8080 дарегиндеги колдонмого жетет деп коёлу. Ошол колдонмону тандаган үзүндү бар server блогунун ичинде мындай көрүнөт:
location / {
proxy_pass http://10.40.0.20:8080;
}Чыныгы схеманы, даректи жана портту колдонуңуз, муну жайгаштыруу эмес, үзүндү деп караңыз. Кирүү хосту VPN маршрутун, уруксат берилген өткөрүү жолун жана ошол кызматка иштеген кайтаруу трафигин да кармашы керек, анткени кагаздагы дарекке жеткен проксиге баары бир ядронун макулдугу керек.
proxy модулунун маалымдамасы upstream тандоону жооп баш жазууларын кайра жазуудан өзүнчө кармайт жана URI камтыган proxy_pass мааниси дал келген location префикси кантип алмаштырылаарын өзгөртөөрүн белгилейт. Колдонмо күткөн URL-ды текшербей жол компоненттерин кошуу же алып салуу — маршруттоо кемчилигине окшош 404 алуунун ишенимдүү жолу.
proxy_redirect жеке даректи агызган жоопторду оңдойт
Трафик ага баштаганда backend өзүнүн жеке дарегин атаган Location баш жазуусу менен жооп бере алат. Ошол баш жазууну ээрчиген браузер коомдук кирүү чекитинен чыгып, чече албаган нерсеге жетүүгө аракет кылат. Атайын конфигурацияланган жоопту кайра жазуу жеке URL-ды коомдук дарекке чагылдырат:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;Эки тарапты тең чыныгы маанилер менен алмаштырыңыз. Тар камтылышты да түшүнүңүз: дал келген Location жана Refresh баш жазууларынын тексти кайра жазылат, ал эми HTML, JavaScript же жүктөлгөн файлдарга киргизилген URL-дар жазылбайт.
Эгер колдонмо бардык жерде абсолюттук шилтемелерди куруп чыгарса, туруктуу чечим — анын өзүндөгү сырткы URL конфигурациясы, проксиде өсүп жаткан кайра жазуу эрежелеринин тизмеси эмес. Чыгарылыш туура көрүнгөнгө чейин эреже кошуу — эч ким текшербеген биринчи баракчада кулай турган конфигурация жаратат. Колдонмонун бир туура параметри бүт жыйындыны алмаштырат.
Баш жазууну кайра жазуу эмнени оңдой албайт
Кошуна бир нече маселе кайра багыттоо маселесине окшош, бирок андай эмес. Upstream-ке жөнөтүлгөн Host баш жазуусу backendдин виртуалдык хостунa дал келиши мүмкүн. TLS upstream'ге белгилүү сервер аталышы жана сертификатты текшерүү керек болушу мүмкүн, ал эми жооп баш жазуусун кайра жазуу экөөнө тең жардам бербейт.
Cookie камтылышы жана домен атрибуттары колдонмого жана анын конфигурациясына таандык. Прокси күнү бою баш жазууларды ыргытып же кайра жаза алат, бирок экинчи суроодо кулай турган сессия жаратат, анткени cookie браузер эч качан кирбеген хостко берилген. Бул кемчилик мезгил-мезгили менен болуп көрүнөт, ошондуктан билет кезегинде ушунча узак турат. Cookie доменин окуу адатта бир мүнөттө тергөөнү бүтүрөт.
Аутентификация менен backend тандоону да көздөлгөн колдонмо менен чектеп кармаңыз. Коомдук кайта прокси сервердин VPN аркылуу бир колдонмону ачууга тийиш, ал хост жете алган ар бир жеке дарекке универсалдуу шлюз болуунун ордуна. Чакыруучу сурагандын баарын өткөрүп жиберген бир жалпы location бир ачылган кызматты жеке тармагыңыздын картасына айландырат. Upstream'ди так атаңыз жана ошол жерде кармаңыз.
Суроо жүргөн тартипте сынаңыз
Кезеги менен үч нерсени ырастаңыз: NGINX көздөлгөн location'ду тандады, backend'ге суроону аяктады, браузер кийинки кайра багыттоону ээрчип, кошумча ресурстарды жүктөдү. Ар бир кадамдын өз лог саптары бар, аларды тартип менен окуу бүдөмүк 502'ни так табылгага айландырат.
Сизге керектүү айырма — ийгиликсиз upstream байланышы менен жеткиликсиз жеке атка жөнөтүлгөн браузердин ортосунда. Биринчиси прокси ката логунда көрүнөт, экинчиси эч качан келбеген суроо катары көрүнөт, браузер чече албаган хостко нааразы болот. Эки башка маселе, эки башка файл, жана алардын бирөө гана proxy_redirect'ке тиешелүү.