proxy_redirect NGINX-i VPN serverinizə qoşmur
proxy_redirect artıq gəlmiş cavabdakı başlıqları yenidən yazır; upstream-i heç vaxt seçmir. proxy_pass-ı, backend-ə marşrutu, sonra başlıqları yoxlayın.
Adın içində redirect sözü var, ona görə də VPN-in arxasındakı backend əlçatmaz olduqda o, location blokuna yapışdırılır. Heç nə dəyişmir və aşkar nəticə direktivin xarab olduğu və ya fərqli sintaksis tələb etdiyi olur. Əslində baş verən daha sadə və daha az xoşdur: proxy_redirect artıq geri qayıtmış cavab üzərində işləyir və bu yerləşdirmədə heç bir sorğu o qədər irəli getməyib.
İki direktiv, bir sorğuda iki məqam
Ters proxy-dən keçən HTTP sorğusu bir neçə qərarı ardıcıl keçir və iki direktiv bu ardıcıllığın əks uclarında dayanır. Biri sorğunun hara getdiyini seçir. Digəri geri qayıdan cavabda müəyyən başlıqları redaktə edir.
| 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 |
Bu sıra bütün cavabdır. Əgər ikinci sətir birinci uğursuz olduğuna görə heç vaxt icra olunmursa, ikinci direktiv səhv konfiqurasiya edilməyib, sadəcə əlçatmazdır. İkinci sətri nə qədər yenidən yazsan da, onun redaktə etməli olduğu cavab yaranmayacaq. Birinci sətirdən bayıra doğru diaqnoz qoyun və qarışıq davranış itmiş marşrut və ya rədd edilmiş bağlantı kimi aydınlaşır.
Upstream seçimi proxy_pass-a aiddir
Tutaq ki, NGINX açıq giriş hostunda işləyir və öz VPN-i üzərindən 10.40.0.20:8080 ünvanındakı tətbiqə çata bilir. Həmin tətbiqi seçən fraqment mövcud server blokunun içində belə görünür:
location / {
proxy_pass http://10.40.0.20:8080;
}Real sxem, ünvan və portdan istifadə edin və buna yerləşdirmə kimi deyil, fraqment kimi yanaşın. Giriş hostu həm də VPN marşrutunu, icazəli yönləndirmə yolunu və həmin xidmətə işlək geri trafiki saxlamalıdır, çünki kağız üzərində ünvana çata bilən proxy hələ də kernelin razılığına ehtiyac duyur.
Proxy modulunun sənədləşməsi upstream seçimini cavab başlıqlarının yenidən yazılmasından ayrı saxlayır və qeyd edir ki, URI ehtiva edən proxy_pass dəyəri uyğun location prefiksinin necə əvəz olunduğunu dəyişir. Tətbiqin gözlədiyi URL-i yoxlamadan yol komponentlərini əlavə etmək və ya silmək, marşrut xətası kimi görünən 404 hasil etməyin etibarlı yoludur.
proxy_redirect şəxsi ünvanı sızdıran cavabları düzəldir
Trafik axmağa başlayanda backend öz şəxsi ünvanını göstərən Location başlığı ilə cavab verə bilər. Həmin başlığı izləyən brauzer açıq giriş nöqtəsini tərk edir və həll edə bilmədiyi bir şeyə çatmağa çalışır. Qəsdən qurulmuş cavab yenidən yazması şəxsi URL-i açıq ünvanın üzərinə köçürür:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;Hər iki tərəfi real dəyərlərlə əvəz edin. Dar əhatəni də anlayın: uyğun gələn Location və Refresh başlıq mətnləri yenidən yazılır, HTML, JavaScript və ya yüklənmiş fayllara daxil edilmiş URL-lər isə yox.
Əgər tətbiq hər yerdə mütləq keçidlər qurursa, davamlı həll proxy-də artan yenidən yazma qaydaları siyahısı deyil, onun öz xarici URL konfiqurasiyasıdır. Çıxış düzgün görünənə qədər qayda əlavə etmək, heç kimin sınaqdan keçirmədiyi ilk səhifədə uğursuz olan konfiqurasiya yaradır. Bir düzgün tətbiq parametri bütün toplunu əvəz edir.
Başlıq yenidən yazmasının düzəldə bilmədiyi şeylər
Bir neçə qonşu problem yönləndirmə problemi kimi görünür, amma deyil. Upstream-ə göndərilən Host başlığı backend virtual hostuna uyğun gəlməli ola bilər. TLS upstream-i xüsusi server adı və sertifikat yoxlaması tələb edə bilər və cavab başlığını yenidən yazmaq bunların heç birinə kömək etmir.
Kuki əhatəsi və domen atributları tətbiqə və onun konfiqurasiyasına aiddir. Proxy bütün gün başlıqları ata və ya yenidən yaza bilər və yenə də ikinci sorğuda uğursuz olan sessiya yaradır, çünki kuki brauzerin heç vaxt ziyarət etmədiyi host üçün verilib. Bu uğursuzluq aralıqlı görünür, buna görə də bilet növbəsində bu qədər uzun yaşayır. Kuki domenini oxumaq adətən araşdırmanı bir dəqiqədə bitirir.
Autentifikasiya və backend seçimini də nəzərdə tutulan tətbiqlə məhdudlaşdırın. Açıq ters proxy bir tətbiqi server VPN-i ilə təqdim etməlidir, həmin hostun çata bildiyi hər şəxsi ünvana ümumi şlüzə çevrilmək əvəzinə. Tək ümumi location çağıranın istədiyi hər şeyi yönləndirirsə, bir açıq xidməti şəxsi şəbəkənizin xəritəsinə çevirir. Upstream-i açıq şəkildə adlandırın və onu orada saxlayın.
Sorğunun getdiyi sıra ilə sınaqdan keçirin
Üç şeyi ardıcıl təsdiqləyin: NGINX nəzərdə tutulan location-u seçdi, backend-ə sorğunu tamamladı və brauzer sonrakı yönləndirməni izləyib alt resursları yüklədi. Hər addımın öz log sətirləri var və onları sıra ilə oxumaq qeyri-müəyyən 502-ni konkret tapıntıya çevirir.
Lazım olan fərq uğursuz upstream bağlantısı ilə əlçatmaz şəxsi ada göndərilmiş brauzer arasındadır. Birincisi proxy xəta logunda görünür; ikincisi heç vaxt gəlməyən sorğu kimi görünür və brauzer həll edə bilmədiyi hostdan şikayət edir. İki fərqli problem, iki fərqli fayl və onlardan yalnız biri proxy_redirect ilə bağlıdır.