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 работи на јавен влезен хост и преку својот VPN достигнува апликација на 10.40.0.20:8080. Фрагментот што ја избира таа апликација изгледа вака, во постоечки 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.