proxy_redirect tidak menghubungkan NGINX ke hos VPN anda

Namanya mengandungi perkataan redirect, jadi ia ditampal ke dalam blok location apabila backend di belakang VPN tidak dapat dicapai. Tiada apa yang berubah, dan kesimpulan yang jelas ialah direktif itu rosak atau memerlukan sintaks lain. Apa yang sebenarnya berlaku lebih mudah dan kurang menyenangkan: proxy_redirect bertindak pada respons yang sudah pun kembali, dan dalam penggunaan ini tiada permintaan pernah sampai sejauh itu.

Dua direktif, dua detik dalam satu permintaan

Permintaan HTTP melalui proksi terbalik melalui beberapa keputusan mengikut urutan, dan kedua-dua direktif berada di hujung bertentangan jujukan itu. Satu memilih ke mana permintaan pergi. Yang lain menyunting pengepala tertentu dalam jawapan yang kembali.

Urutan itulah keseluruhan jawapannya. Jika baris kedua tidak pernah dilaksanakan kerana yang pertama gagal, direktif kedua bukan salah konfigurasi, ia hanya tidak dapat dicapai. Walau berapa kali baris kedua ditulis semula, respons yang sepatutnya disuntingnya tidak akan wujud. Diagnosis dari baris pertama ke luar, dan tingkah laku mengelirukan itu berakhir sebagai laluan yang hilang atau sambungan yang ditolak.

Memilih upstream ialah tugas proxy_pass

Katakan NGINX berjalan pada hos masuk awam dan boleh mencapai aplikasi di 10.40.0.20:8080 melalui VPNnya. Serpihan yang memilih aplikasi itu kelihatan seperti ini, di dalam blok server yang sedia ada:

location / {
    proxy_pass http://10.40.0.20:8080;
}

Gunakan skema, alamat dan port sebenar, dan anggap ini sebagai serpihan bukannya penggunaan. Hos masuk juga mesti menyimpan laluan VPN, laluan penghantaran yang dibenarkan dan trafik balik yang berfungsi ke perkhidmatan itu, kerana proksi yang boleh mencapai alamat di atas kertas masih memerlukan persetujuan kernel.

Rujukan modul proxy memisahkan pemilihan upstream daripada penulisan semula pengepala respons, dan menyatakan bahawa nilai proxy_pass yang mengandungi URI mengubah cara awalan location yang sepadan diganti. Menambah atau membuang komponen laluan tanpa memeriksa URL yang dijangkakan aplikasi ialah cara yang boleh dipercayai untuk menghasilkan 404 yang kelihatan seperti kegagalan penghalaan.

proxy_redirect membetulkan jawapan yang membocorkan alamat peribadi

Sebaik sahaja trafik mengalir, backend boleh menjawab dengan pengepala Location yang menamakan alamat peribadinya. Pelayar yang mengikuti pengepala itu meninggalkan titik masuk awam dan cuba mencapai sesuatu yang tidak dapat diselesaikannya. Penulisan semula respons yang dikonfigurasi dengan sengaja memetakan URL peribadi kepada yang awam:

proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;

Gantikan kedua-dua belah dengan nilai sebenar. Fahami juga skop yang sempit: teks pengepala Location dan Refresh yang sepadan ditulis semula, tetapi URL yang tertanam dalam HTML, JavaScript atau fail yang dimuat turun tidak.

Jika aplikasi membina pautan mutlak di merata tempat, penyelesaian tahan lama ialah konfigurasi URL luaran aplikasi itu sendiri, bukan senarai peraturan penulisan semula yang semakin bertambah pada proksi. Menambah peraturan sehingga output kelihatan betul menghasilkan konfigurasi yang gagal pada halaman pertama yang tiada siapa uji. Satu tetapan aplikasi yang betul menggantikan seluruh koleksi.

Apa yang penulisan semula pengepala tidak dapat baiki

Beberapa masalah bersebelahan kelihatan seperti masalah ubah hala tetapi bukan. Pengepala Host yang dihantar ke upstream mungkin perlu sepadan dengan hos maya backend. Upstream TLS mungkin memerlukan nama pelayan tertentu serta pengesahan sijil, dan menulis semula pengepala respons tidak membantu kedua-duanya.

Skop kuki dan atribut domain milik aplikasi dan konfigurasinya. Proksi boleh membuang atau menulis semula pengepala sepanjang hari dan masih menghasilkan sesi yang gagal pada permintaan kedua, kerana kuki itu dikeluarkan untuk hos yang tidak pernah dilawati pelayar. Kegagalan itu kelihatan berselang-seli, itulah sebabnya ia bertahan lama dalam barisan tiket. Membaca domain kuki biasanya menamatkan siasatan dalam satu minit.

Kekalkan pengesahan dan pemilihan backend terhad kepada aplikasi yang dimaksudkan juga. Proksi terbalik awam sepatutnya mendedahkan satu aplikasi melalui VPN pelayan dan bukannya menjadi gerbang serba guna ke setiap alamat peribadi yang boleh dicapai oleh hos itu. Satu location generik yang memajukan apa sahaja yang diminta pemanggil mengubah satu perkhidmatan yang terdedah menjadi peta rangkaian peribadi anda. Namakan upstream secara eksplisit dan kekalkan ia di situ.

Uji mengikut urutan permintaan bergerak

Sahkan tiga perkara mengikut urutan: NGINX memilih location yang dimaksudkan, melengkapkan permintaan ke backend, dan pelayar mengikuti sebarang ubah hala kemudian serta memuatkan sub-sumber. Setiap langkah mempunyai baris log sendiri, dan membacanya mengikut urutan menjadikan 502 yang kabur sebagai penemuan yang khusus.

Perbezaan yang anda perlukan ialah antara sambungan upstream yang gagal dan pelayar yang dihantar ke nama peribadi yang tidak dapat dicapai. Yang pertama muncul dalam log ralat proksi; yang kedua muncul sebagai permintaan yang tidak pernah tiba, dengan pelayar mengeluh tentang hos yang tidak dapat diselesaikannya. Dua masalah berbeza, dua fail berbeza, dan hanya satu daripadanya melibatkan proxy_redirect sama sekali.