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.