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-тэй огт холбоотой.