proxy_redirect NGINX'ni VPN hostingizga ulamaydi
proxy_redirect allaqachon kelgan javobdagi sarlavhalarni qayta yozadi; u hech qachon upstream'ni tanlamaydi. proxy_pass, backend'gacha bo'lgan marshrut, so'ng sarlavhalarni tekshiring.
Nomida redirect so'zi bor, shuning uchun VPN orqasidagi backend yetib bo'lmaydigan bo'lsa, u location blokiga yopishtiriladi. Hech narsa o'zgarmaydi va aniq xulosa shuki, bu direktiva buzilgan yoki boshqa sintaksis kerak. Aslida bo'lgan narsa soddaroq va kamroq maqtovga loyiq: proxy_redirect allaqachon qaytgan javob ustida ishlaydi va bu joylashtirishda hech bir so'rov u yerga yetib bormagan.
Ikki direktiva, bitta so'rovda ikki lahza
Teskari proksi orqali o'tadigan HTTP so'rovi bir nechta qarorni ketma-ket bosib o'tadi va ikki direktiva shu ketma-ketlikning qarama-qarshi uchlarida turadi. Biri so'rov qayerga borishini tanlaydi. Ikkinchisi qaytayotgan javobdagi ayrim sarlavhalarni tahrirlaydi.
| 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 |
Aynan shu tartib butun javobdir. Agar birinchi satr muvaffaqiyatsiz bo'lgani uchun ikkinchi satr hech qachon ishlamasa, ikkinchi direktiva noto'g'ri sozlanmagan, u shunchaki yetib bo'lmaydigan. Ikkinchi satrni qancha qayta yozsangiz ham, u tahrirlashi kerak bo'lgan javob paydo bo'lmaydi. Birinchi satrdan tashqariga qarab diagnostika qiling, chalkash xatti-harakat yo'qolgan marshrut yoki rad etilgan ulanishga aylanadi.
Upstream tanlash proxy_pass ishi
Faraz qilaylik, NGINX ochiq kirish hostida ishlaydi va o'z VPN'i orqali 10.40.0.20:8080 manzilidagi ilovaga yetadi. O'sha ilovani tanlaydigan parcha mavjud server bloki ichida shunday ko'rinadi:
location / {
proxy_pass http://10.40.0.20:8080;
}Haqiqiy sxema, manzil va portdan foydalaning va buni joylashtirish emas, parcha deb biling. Kirish hosti VPN marshrutini, ruxsat etilgan yo'naltirish yo'lini va o'sha xizmatga ishlaydigan qaytish trafigini ham saqlashi kerak, chunki qog'ozdagi manzilga yetadigan proksi ham yadro roziligiga muhtoj.
proxy moduli ma'lumotnomasi upstream tanlashni javob sarlavhalarini qayta yozishdan alohida tutadi va URI o'z ichiga olgan proxy_pass qiymati mos location prefiksi qanday almashtirilishini o'zgartirishini qayd etadi. Ilova kutgan URLni tekshirmasdan yo'l qismlarini qo'shish yoki olib tashlash marshrutlash nosozligiga o'xshaydigan 404 hosil qilishning ishonchli usuli.
proxy_redirect shaxsiy manzilni oshkor qiladigan javoblarni tuzatadi
Trafik oqishi bilan backend o'zining shaxsiy manzilini ko'rsatuvchi Location sarlavhasi bilan javob berishi mumkin. O'sha sarlavhaga ergashgan brauzer ommaviy kirish nuqtasini tark etadi va hal qila olmaydigan narsaga yetishga urinadi. Qasddan sozlangan javobni qayta yozish shaxsiy URLni ommaviy manzilga moslashtiradi:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;Ikkala tomonni haqiqiy qiymatlar bilan almashtiring. Tor qamrovni ham tushuning: mos Location va Refresh sarlavhalarining matni qayta yoziladi, HTML, JavaScript yoki yuklab olingan fayllarga joylashtirilgan URL esa yozilmaydi.
Agar ilova hamma joyda mutlaq havolalar qursa, mustahkam yechim uning o'z tashqi URL konfiguratsiyasi, proksida o'sib boruvchi qayta yozish qoidalari ro'yxati emas. Chiqish to'g'ri ko'ringuncha qoida qo'shish hech kim sinab ko'rmagan birinchi sahifada yiqiladigan konfiguratsiya hosil qiladi. Ilovaning bitta to'g'ri sozlamasi butun to'plamni almashtiradi.
Sarlavhani qayta yozish nimalarni tuzata olmaydi
Bir nechta qo'shni muammo qayta yo'naltirish muammosiga o'xshaydi, ammo unday emas. Upstreamga yuboriladigan Host sarlavhasi backendning virtual hostiga mos kelishi kerak bo'lishi mumkin. TLS upstream aniq server nomi va sertifikat tekshiruvini talab qilishi mumkin, javob sarlavhasini qayta yozish esa ikkalasiga ham yordam bermaydi.
Cookie qamrovi va domen atributlari ilova va uning konfiguratsiyasiga tegishli. Proksi kun bo'yi sarlavhalarni tashlab yuborishi yoki qayta yozishi mumkin va baribir ikkinchi so'rovda yiqiladigan sessiya hosil qiladi, chunki cookie brauzer hech qachon kirmagan host uchun berilgan. Bu nosozlik vaqti-vaqti bilan ko'rinadi, shuning uchun chiptalar navbatida shuncha uzoq yashaydi. Cookie domenini o'qish odatda tekshiruvni bir daqiqada tugatadi.
Autentifikatsiya va backend tanlashni ham mo'ljallangan ilova bilan cheklab turing. Ommaviy teskari proksi serverning VPN orqali bitta ilovani ochishi kerak, o'sha host yeta oladigan har bir shaxsiy manzilga umumiy darvoza bo'lish o'rniga. Chaqiruvchi so'ragan hamma narsani uzatadigan bitta umumiy location bitta ochiq xizmatni shaxsiy tarmog'ingiz xaritasiga aylantiradi. Upstreamni aniq nomlang va o'sha yerda saqlang.
So'rov yurgan tartibda sinab ko'ring
Ketma-ket uch narsani tasdiqlang: NGINX mo'ljallangan locationni tanladi, backendga so'rovni yakunladi va brauzer keyingi har qanday qayta yo'naltirishga ergashib, subresurslarni yukladi. Har bir qadamning o'z log satrlari bor va ularni tartib bilan o'qish noaniq 502ni aniq topilmaga aylantiradi.
Sizga kerak bo'lgan farq muvaffaqiyatsiz upstream ulanishi bilan yetib bo'lmaydigan shaxsiy nomga yuborilgan brauzer o'rtasidagi. Birinchisi proksi xatolar logida ko'rinadi; ikkinchisi hech qachon kelmaydigan so'rov sifatida ko'rinadi va brauzer hal qila olmaydigan hostdan shikoyat qiladi. Ikki xil muammo, ikki xil fayl va ulardan faqat bittasi proxy_redirect bilan bog'liq.