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-тің виртуалды хостімен сәйкесуі мүмкін. TLS upstream-ке нақты сервер атауы мен сертификатты тексеру қажет болуы мүмкін, ал жауап тақырыпшасын қайта жазу екеуіне де көмектеспейді.
Cookie ауқымы мен домен атрибуттары қолданбаға және оның конфигурациясына тиесілі. Прокси күні бойы тақырыпшаларды тастай немесе қайта жаза алады, бірақ екінші сұраныста құлайтын сессия жасайды, өйткені cookie браузер ешқашан кірмеген хостқа берілген. Бұл ақау мезгіл-мезгіл болып көрінеді, сондықтан билет кезегінде сонша ұзақ тұрады. Cookie доменін оқу әдетте бір минутта тергеуді аяқтайды.
Аутентификация мен backend таңдауын да көзделген қолданбамен шектеп ұстаңыз. Жария кері прокси сервердің VPN арқылы бір қолданбаны ашуы керек, сол хост жете алатын әрбір жеке мекенжайға әмбебап шлюз болу орнына. Шақырушы сұрағанның бәрін жіберетін бір жалпы location бір ашылған қызметті жеке желіңіздің картасына айналдырады. Upstream-ті анық атаңыз және сол жерде ұстаңыз.
Сұраныс жүретін ретпен сынаңыз
Кезекпен үш нәрсені растаңыз: NGINX көзделген location-ды таңдады, backend-ке сұранысты аяқтады, ал браузер кейінгі кез келген қайта бағыттауды ұстанып, қосымша ресурстарды жүктеді. Әр қадамның өз лог жолдары бар, оларды ретімен оқу бұлыңғыр 502-ні нақты табысқа айналдырады.
Сізге қажет айырмашылық — сәтсіз upstream қосылымы мен қолжетімсіз жеке атауға жіберілген браузер арасындағы. Біріншісі прокси қателер логында көрінеді, екіншісі ешқашан келмейтін сұраныс ретінде көрінеді, ал браузер шеше алмайтын хостқа шағымданады. Екі түрлі мәселе, екі түрлі файл, және олардың тек біреуі ғана proxy_redirect-ке қатысты.