proxy_redirect не повезује NGINX са вашим VPN хостом
proxy_redirect преписује заглавља у одговору који је већ стигао; никада не бира upstream. Проверите proxy_pass, руту до backend-а, затим заглавља.
Назив садржи реч redirect, па се убацује у location блок када backend иза VPN-а није доступан. Ништа се не мења, а очигледан закључак је да је директива покварена или захтева другачију синтаксу. Оно што се стварно догодило једноставније је и мање ласкаво: 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 ради на јавном улазном хосту и може да достигне апликацију на 10.40.0.20:8080 преко свог VPN-а. Фрагмент који бира ту апликацију изгледа овако, унутар постојећег server блока:
location / {
proxy_pass http://10.40.0.20:8080;
}Користите стварну шему, адресу и порт и третирајте ово као фрагмент, а не као распоређивање. Улазни хост такође мора да држи VPN руту, дозвољену путању прослеђивања и исправан повратни саобраћај ка тој услузи, јер прокси који на папиру достигне адресу ипак треба пристанак језгра.
Референца proxy модула држи избор upstream-а одвојено од преписивања заглавља одговора и напомиње да вредност proxy_pass која садржи URI мења начин на који се замењује одговарајући location префикс. Додавање или уклањање делова путање без провере URL-а који апликација очекује поуздан је начин да настане 404 који изгледа као грешка рутирања.
proxy_redirect поправља одговоре који одају приватну адресу
Када саобраћај крене, backend може да одговори заглављем Location које наводи његову приватну адресу. Прегледач који следи то заглавље напушта јавну улазну тачку и покушава да достигне нешто што не може да разреши. Намерно конфигурисано преписивање одговора пресликава приватни URL на јавни:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;Замените обе стране стварним вредностима. Разумите и уски обим: одговарајући текст заглавља Location и Refresh се преписује, а URL-ови уграђени у HTML, JavaScript или преузете датотеке не.
Ако апликација свуда гради апсолутне линкове, трајно решење је њена сопствена конфигурација за спољни URL, а не растућа листа правила за преписивање на проксију. Додавање правила док излаз не изгледа исправно ствара конфигурацију која пада на првој страници коју нико није тестирао. Једно исправно подешавање апликације замењује целу колекцију.
Шта преписивање заглавља не може да поправи
Неколико суседних проблема изгледа као проблеми са преусмеравањем, али нису. Заглавље Host које се шаље ка upstream-у можда мора да се поклопи са виртуелним хостом backend-а. TLS upstream може да захтева одређено име сервера и проверу сертификата, а преписивање заглавља одговора не помаже ни за једно.
Обим колачића и атрибути домена припадају апликацији и њеној конфигурацији. Прокси може цео дан да одбацује или преписује заглавља и ипак произведе сесију која пада на другом захтеву, јер је колачић издат за хост који прегледач никада није посетио. Тај квар изгледа повремено, зато тако дуго преживљава у реду за тикете. Читање домена колачића обично завршава истрагу за минут.
Држите и аутентификацију и избор backend-а ограничене на предвиђену апликацију. Јавни обрнути прокси треба да изложи једну апликацију преко VPN-а сервера уместо да постане универзална капија ка свакој приватној адреси коју тај хост може да достигне. Један општи location који прослеђује све што позвалац затражи претвара једну изложену услугу у мапу ваше приватне мреже. Именујте upstream изричито и задржите га тамо.
Тестирајте редом којим захтев путује
Потврдите три ствари по реду: NGINX је изабрао предвиђени location, завршио захтев ка backend-у и прегледач је следио свако касније преусмеравање и учитао подресурсе. Сваки корак има своје лог линије, а њихово читање по реду претвара нејасан 502 у конкретан налаз.
Разлика која вам је потребна је између неуспеле upstream везе и прегледача послатог на недоступно приватно име. Прво се појављује у логу грешака проксија; друго изгледа као захтев који никада не стигне, а прегледач се жали на хост који не може да разреши. Два различита проблема, две различите датотеке, и само један од њих уопште укључује proxy_redirect.