proxy_redirect tidak menghubungkan NGINX ke host VPN Anda
proxy_redirect menulis ulang header pada respons yang sudah tiba; ia tidak pernah memilih upstream. Periksa proxy_pass, rute ke backend, lalu header.
Namanya mengandung kata redirect, jadi kata itu ditempelkan ke dalam blok location ketika backend di belakang VPN tidak dapat dijangkau. Tidak ada yang berubah, dan kesimpulan yang jelas adalah direktif itu rusak atau membutuhkan sintaksis yang berbeda. Yang sebenarnya terjadi lebih sederhana dan kurang menyanjung: proxy_redirect bekerja pada respons yang sudah kembali, dan dalam penerapan ini tidak ada permintaan yang sampai sejauh itu.
Dua direktif, dua momen dalam satu permintaan
Permintaan HTTP melalui proxy terbalik melewati beberapa keputusan secara berurutan, dan kedua direktif berada di ujung berlawanan dari urutan itu. Satu memilih ke mana permintaan pergi. Yang lain menyunting header tertentu dalam jawaban yang kembali.
| 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 |
Urutan itulah seluruh jawabannya. Jika baris kedua tidak pernah dijalankan karena baris pertama gagal, direktif kedua tidak salah konfigurasi, ia hanya tidak dapat dijangkau. Sebanyak apa pun baris kedua ditulis ulang, respons yang seharusnya dieditnya tidak akan tercipta. Diagnosis dari baris pertama ke luar, dan perilaku membingungkan itu bermuara pada rute yang hilang atau koneksi yang ditolak.
Memilih upstream adalah urusan proxy_pass
Misalkan NGINX berjalan di host masuk publik dan dapat menjangkau aplikasi di 10.40.0.20:8080 melalui VPN-nya. Fragmen yang memilih aplikasi itu terlihat seperti ini, di dalam blok server yang sudah ada:
location / {
proxy_pass http://10.40.0.20:8080;
}Gunakan skema, alamat, dan port sebenarnya, dan perlakukan ini sebagai fragmen, bukan penerapan. Host masuk juga harus memegang rute VPN, jalur penerusan yang diizinkan, dan lalu lintas balik yang berfungsi ke layanan itu, karena proxy yang dapat menjangkau alamat di atas kertas tetap memerlukan persetujuan kernel.
Referensi modul proxy memisahkan pemilihan upstream dari penulisan ulang header respons, dan mencatat bahwa nilai proxy_pass yang berisi URI mengubah cara prefiks location yang cocok diganti. Menambah atau menghapus komponen jalur tanpa memeriksa URL yang diharapkan aplikasi adalah cara andal menghasilkan 404 yang tampak seperti kegagalan perutean.
proxy_redirect memperbaiki jawaban yang membocorkan alamat privat
Setelah lalu lintas mengalir, backend dapat menjawab dengan header Location yang menyebutkan alamat privatnya. Peramban yang mengikuti header itu meninggalkan titik masuk publik dan mencoba menjangkau sesuatu yang tidak dapat diresolusinya. Penulisan ulang respons yang dikonfigurasi dengan sengaja memetakan URL privat ke publik:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;Ganti kedua sisi dengan nilai sebenarnya. Pahami juga cakupan sempitnya: teks header Location dan Refresh yang cocok ditulis ulang, sedangkan URL yang tertanam di HTML, JavaScript, atau berkas unduhan tidak.
Jika sebuah aplikasi membangun tautan absolut di mana-mana, perbaikan yang tahan lama adalah konfigurasi URL eksternalnya sendiri, bukan daftar aturan penulisan ulang yang terus bertambah di proxy. Menambah aturan sampai keluarannya terlihat benar menghasilkan konfigurasi yang gagal di halaman pertama yang tidak diuji siapa pun. Satu pengaturan aplikasi yang benar menggantikan seluruh kumpulan.
Apa yang tidak bisa diperbaiki penulisan ulang header
Beberapa masalah yang berdekatan tampak seperti masalah pengalihan dan sebenarnya bukan. Header Host yang dikirim ke upstream mungkin harus cocok dengan host virtual backend. Upstream TLS mungkin memerlukan nama server tertentu plus verifikasi sertifikat, dan menulis ulang header respons tidak membantu keduanya.
Cakupan cookie dan atribut domain adalah milik aplikasi dan konfigurasinya. Proxy dapat membuang atau menulis ulang header sepanjang hari dan tetap menghasilkan sesi yang gagal pada permintaan kedua, karena cookie diterbitkan untuk host yang tidak pernah dikunjungi peramban. Kegagalan itu tampak berselang-seling, itulah sebabnya ia bertahan lama di antrean tiket. Membaca domain cookie biasanya mengakhiri penyelidikan dalam satu menit.
Jaga juga autentikasi dan pemilihan backend agar tetap terbatas pada aplikasi yang dimaksud. Proxy terbalik publik seharusnya mengekspos satu aplikasi melalui VPN server, bukan menjadi gerbang serba guna ke setiap alamat privat yang dapat dijangkau host itu. Satu location generik yang meneruskan apa pun yang diminta pemanggil mengubah satu layanan yang terekspos menjadi peta jaringan privat Anda. Sebutkan upstream secara eksplisit dan pertahankan di sana.
Uji dalam urutan perjalanan permintaan
Konfirmasi tiga hal secara berurutan: NGINX memilih location yang dimaksud, menyelesaikan permintaan ke backend, dan peramban mengikuti pengalihan berikutnya serta memuat sub-sumber daya. Setiap langkah punya baris log sendiri, dan membacanya berurutan mengubah 502 yang samar menjadi temuan yang spesifik.
Perbedaan yang Anda butuhkan adalah antara koneksi upstream yang gagal dan peramban yang dikirim ke nama privat yang tidak terjangkau. Yang pertama muncul di log galat proxy; yang kedua muncul sebagai permintaan yang tidak pernah tiba, dengan peramban mengeluh tentang host yang tidak dapat diresolusinya. Dua masalah berbeda, dua berkas berbeda, dan hanya satu di antaranya melibatkan proxy_redirect sama sekali.