Proxy per Profil Browser: DNS, Autentikasi, dan Kegagalan

Panduan ini menggunakan perilaku jaringan yang didokumentasikan Chromium sebagai acuan. Browser dan produk lain dapat memilih pendekatan berbeda, dan pengelola browser dapat menambahkan perantara jaringan lokal di sekitar Chromium. Verifikasi perilaku build yang benar-benar Anda gunakan.

Mulai dari empat pertanyaan terpisah

Catatan proxy biasanya memuat skema, endpoint, port, dan terkadang referensi autentikasi. Catatan tersebut menyisakan empat pertanyaan kebijakan yang berbeda:

1. Cakupan: permintaan dan protokol browser mana yang diarahkan ke proxy ini?
2. Resolusi nama: perangkat atau proxy yang menerjemahkan nama host tujuan?
3. Autentikasi: skema klien dan proxy mana yang kompatibel, dan di mana kredensial disimpan?
4. Kegagalan: apakah kesalahan koneksi menghentikan permintaan, mencoba proxy lain, atau beralih ke koneksi langsung?

Menganggap semuanya sebagai satu tombol “proxy aktif” merupakan sumber banyak kejutan. Chromium mendokumentasikan pemilihan proxy sebagai resolusi pada tingkat URL: sebuah URL menghasilkan daftar pilihan proxy yang berurutan, bahkan sebelum tujuan harus diresolusikan. Aturan pengecualian dan rute cadangan menjadi bagian dari keputusan itu.

Cakupan proxy per profil

Kebijakan ProxySettings Google diterapkan pada tingkat profil Chrome. Kebijakan ini dapat memilih mode langsung, sistem, deteksi otomatis, server tetap, atau skrip PAC, disertai pengaturan eksplisit untuk pengecualian dan kewajiban menggunakan PAC.

Batas ini lebih sempit daripada VPN atau namespace jaringan sistem operasi. Ia mengatur permintaan yang ditangani konteks jaringan browser. Ia tidak otomatis mengatur:

• panggilan API milik aplikasi pengelola desktop;
• aplikasi terpisah atau pembaru browser yang berjalan di luar proses;
• DNS dan pemeriksaan konektivitas sistem operasi;
• aplikasi lain yang dibuka dari berkas unduhan;
• helper native ekstensi yang terpisah;
• layanan lokal yang dicapai melalui pengecualian loopback bawaan; atau
• lalu lintas dengan protokol yang tidak dapat dibawa jalur proxy terpilih.

Sebagian komponen tersebut mungkin memiliki dukungan proxy sendiri. Dukungan itu harus dijelaskan dan diuji secara terpisah. Pernyataan produk seperti “lalu lintas profil menggunakan proxy ini” perlu menyebutkan proses dan protokol yang tercakup, bukan menyiratkan bahwa seluruh perangkat menggunakan rute tersebut.

Ikuti satu permintaan HTTPS

Navigasi HTTPS biasa melewati beberapa tahap.

1. Pilih rute

Browser mengevaluasi aturan tetap, skrip konfigurasi proxy otomatis, atau pengaturan sistem. Aturan pengecualian yang cocok dapat memilih koneksi langsung. Daftar proxy dapat menetapkan proxy utama diikuti alternatif, termasuk DIRECT jika koneksi langsung sebagai cadangan diizinkan.

Chromium juga menerapkan pengecualian bawaan untuk localhost dan tujuan link-local. Ini melindungi origin lokal dari pengaturan proxy yang dikendalikan pihak luar, tetapi berarti klaim umum “semua lalu lintas” memerlukan penjelasan batas.

2. Resolusikan dan hubungi proxy

Jika endpoint proxy berupa nama host, perangkat tetap harus meresolusikan dan menghubungi endpoint tersebut. DNS tujuan di sisi proxy tidak menghilangkan pencarian awal ini. Kegagalan pada tahap ini berbeda dari keadaan ketika proxy dapat dihubungi tetapi tidak mampu meresolusikan tujuan.

3. Autentikasi ke proxy

Proxy HTTP yang memerlukan kredensial biasanya mengembalikan 407 Proxy Authentication Required beserta tantangan autentikasi. RFC 9110 mendefinisikan pertukaran tersebut serta kolom Proxy-Authenticate dan Proxy-Authorization.

Chromium tidak menggunakan nama pengguna dan kata sandi yang disisipkan dalam pengaturan proxy manual. Dokumentasi proxynya menyatakan bahwa autentikasi mengikuti alur kredensial biasa milik browser. Karena itu, pengelola profil memerlukan integrasi eksplisit untuk tantangan yang didukung, bukan janji bahwa setiap string user:password@host akan berfungsi.

4. Bangun koneksi ke tujuan

Dengan proxy HTTP, Chromium menyerahkan resolusi nama tujuan kepada proxy. Untuk tujuan HTTPS, browser meminta proxy membuat terowongan CONNECT, lalu menjalankan TLS ujung ke ujung dengan tujuan melalui terowongan tersebut.

Proxy tetap mengetahui nama host tujuan dan metadata koneksi. Jika sambungan klien ke proxy menggunakan HTTP biasa, permintaan CONNECT dan nama hostnya tidak terlindungi pada sambungan itu. Proxy HTTPS menambahkan TLS antara browser dan proxy, sehingga metadata tersebut terlindungi dari pengamat di antara keduanya. Namun, proxy sendiri tetap dapat melihat tujuan yang diminta.

Dalam keadaan normal, proxy tidak dapat membaca isi halaman HTTPS di dalam terowongan. Intersepsi TLS adalah model kepercayaan berbeda: klien mempercayai otoritas sertifikat yang memungkinkan perantara mengakhiri dan membangun ulang TLS. Hal itu tidak boleh disamakan begitu saja dengan penerusan biasa.

Pihak yang meresolusikan DNS bergantung pada skema proxy

Perilaku Chromium yang didokumentasikan berbeda menurut jenis proxy:

Rute terpilih	Resolusi nama tujuan di Chromium	Batas penting
Langsung atau dikecualikan	Resolver perangkat atau browser	Lalu lintas tujuan keluar tanpa proxy profil
Proxy HTTP	Sisi proxy	Transportasi HTTP biasa antara klien dan proxy memperlihatkan permintaan HTTP; HTTPS menggunakan CONNECT
Proxy HTTPS	Sisi proxy	Klien harus memvalidasi sertifikat TLS proxy
Proxy SOCKS4	Sisi klien	Hanya tujuan IPv4; Chromium tidak menerapkan cadangan SOCKS4a
Proxy SOCKS5	Sisi proxy	Chromium menggunakannya untuk permintaan URL melalui TCP dan mendokumentasikan tidak adanya dukungan autentikasi SOCKS5

RFC 1928 memungkinkan permintaan SOCKS5 membawa nama domain dan mendefinisikan beberapa pengenal metode autentikasi. Kemampuan protokol tidak menjamin implementasi klien. Saat ini Chromium mengirim nama tujuan ke proxy SOCKS5, tetapi menyatakan bahwa klien SOCKS5 bawaannya tidak mendukung metode autentikasi proxy. Karena itu, akses SOCKS5 dengan nama pengguna dan kata sandi dari suatu penyedia mungkin memerlukan perantara yang didukung atau skema proxy lain. Konfirmasikan implementasi browser sebelum menerima konfigurasi tersebut.

DNS-over-HTTPS menambahkan lapisan lain. Kebijakan DnsOverHttpsMode Chrome membedakan automatic, yang dapat kembali ke DNS tidak aman, dari secure, yang menggagalkan resolusi jika DNS aman gagal. Kebijakan yang sama didokumentasikan berlaku pada tingkat browser, sedangkan ProxySettings berlaku pada tingkat profil. Perbedaan ini mengingatkan bahwa kata “profil” pada satu pengaturan tidak berarti semua kontrol DNS memiliki cakupan yang sama.

Produk yang menjalankan setiap profil dalam proses browser terpisah dapat membentuk batas efektif yang lebih sempit, tetapi itu merupakan pilihan implementasi. Ujilah. Bukti harus membedakan:

• resolusi endpoint proxy;
• resolusi tujuan yang diminta;
• DNS untuk permintaan langsung atau yang dikecualikan;
• pencarian awal dan mekanisme cadangan DNS aman; serta
• DNS yang dilakukan komponen di luar konteks jaringan browser profil.

Autentikasi menyangkut kompatibilitas sekaligus penanganan rahasia

Chromium mendokumentasikan Basic, Digest, Negotiate, dan NTLM untuk proxy HTTP. Proxy HTTPS menambahkan saluran terlindungi antara klien dan proxy, serta dapat mendukung sertifikat klien. Autentikasi SOCKS4 dan SOCKS5 tidak diimplementasikan oleh klien proxy bawaan Chromium, meskipun spesifikasi SOCKS5 memiliki metode autentikasi.

Skema yang kompatibel pun dapat tidak aman pada transportasi yang salah. RFC 7617 menjelaskan bahwa kredensial Basic hanya dikodekan dengan Base64 dan memerlukan saluran terlindungi seperti TLS. Autentikasi Basic ke proxy HTTP biasa memperlihatkan kata sandi proxy kepada siapa pun yang dapat mengamati sambungan tersebut.

Pengelola profil sebaiknya memisahkan data berikut:

• metadata endpoint yang bukan rahasia, seperti skema, host, port, dan label penyedia;
• referensi rahasia yang digunakan layanan siklus hidup atau jaringan;
• nilai kredensial dalam penyimpanan terlindungi;
• status koneksi yang telah disamarkan untuk antarmuka dan jejak audit; serta
• rincian diagnostik yang hanya tersedia melalui alur dukungan terkontrol.

Layar biasa, log, API, ekspor, dan keluaran otomatisasi tidak memerlukan kata sandi proxy. Operator biasanya perlu mengetahui bahwa autentikasi gagal, skema mana yang diminta, endpoint mana yang terlibat, dan apakah terjadi peralihan ke rute cadangan.

Bentuk kegagalan dan gejalanya

Kegagalan	Gejala yang mungkin muncul	Batas yang perlu diperiksa
Skema proxy salah	Negosiasi TLS atau protokol gagal	Apakah endpoint HTTPS dinyatakan sebagai HTTP, atau sebaliknya?
Nama host proxy tidak dapat diresolusikan	Koneksi gagal sebelum mencapai proxy	Resolver mana yang melakukan pencarian awal?
Port proxy tidak dapat dijangkau	Waktu habis atau koneksi ditolak	Apakah proxy lain atau DIRECT berada di urutan berikutnya?
Tantangan autentikasi tidak didukung	407 atau permintaan masuk berulang	Apakah browser mengimplementasikan skema yang diminta?
Kredensial salah atau kedaluwarsa	407 setelah kredensial dikirim	Apakah referensi rahasia berhasil diambil, dan nilainya disamarkan dari keluaran?
Sertifikat proxy HTTPS gagal	Koneksi aman ke proxy ditolak	Apakah validasi sertifikat tetap berjalan?
Proxy tidak dapat meresolusikan tujuan	Kegagalan host atau terowongan di proxy	Apakah klien menghindari percobaan ulang langsung ke tujuan?
CONNECT ditolak	Navigasi HTTPS ke tujuan tersebut gagal	Apakah penolakan dianggap sebagai kebijakan, bukan izin untuk melewatinya?
Berkas PAC tidak tersedia	Pemilihan proxy tersendat atau rute berubah	Apakah PAC wajib, atau Chromium dapat menggunakan DIRECT tanpa pemberitahuan?
Pola pengecualian terlalu luas	Situs tertentu terhubung langsung	Apakah aturan host persis, subdomain, port, dan bawaan dipahami?
WebRTC menggunakan antarmuka lain	Jalur media berbeda dari lalu lintas halaman	Apakah UDP tanpa proxy dinonaktifkan untuk profil?
Koneksi lama bertahan setelah perubahan	Rute lama tetap aktif sementara	Apakah koneksi dikosongkan atau profil dimulai ulang?
Perekaman diagnostik terlalu rinci	URL, nama host, atau rahasia masuk ke berkas dukungan	Mode penyamaran dan aturan retensi mana yang berlaku?

Mekanisme cadangan Chromium menyimpan keadaan. Proxy yang mengalami kegagalan pada tingkat koneksi dapat ditandai bermasalah dan dipindahkan ke belakang entri lain untuk sementara. Jika daftar berisi DIRECT, permintaan berikutnya dapat keluar tanpa proxy. Penolakan CONNECT ditangani berbeda karena mungkin merupakan kebijakan tujuan yang disengaja, bukan proxy yang tidak tersedia.

Kegagalan PAC perlu mendapat perhatian khusus. Chromium mendokumentasikan bahwa berkas PAC yang tidak tersedia dapat membuat browser beralih diam-diam ke koneksi langsung, kecuali PAC ditetapkan wajib. Kebijakan ProxySettings Chrome menyediakan ProxyPacMandatory khusus untuk mencegah peralihan langsung tersebut.

WebRTC dan UDP memerlukan keputusan tersendiri

Halaman dapat menggunakan jalur WebRTC yang tidak sama dengan permintaan URL HTTP dan HTTPS biasa. Kebijakan WebRtcIPHandling bawaan Chrome dapat menggunakan semua antarmuka yang tersedia. Mode disable_non_proxied_udp membatasi WebRTC ke TCP pada antarmuka publik, kecuali proxy yang dikonfigurasi mendukung UDP.

Kebijakan tersebut didokumentasikan berlaku pada tingkat profil, sehingga relevan untuk proxy profil, tetapi tetap merupakan kontrol terpisah. Pengaturan ini dapat menurunkan kinerja media atau merusak alur kerja yang membutuhkan UDP langsung. Pilih dan uji konsekuensinya secara eksplisit. Jangan mengklaim seluruh lalu lintas tertahan dalam proxy hanya berdasarkan keberhasilan memuat halaman.

Tentukan apakah kegagalan harus memblokir atau menjaga ketersediaan

Koneksi langsung sebagai cadangan dapat dibenarkan untuk profil penjelajahan umum yang mengutamakan ketersediaan. Namun, itu tidak aman untuk alur kerja yang otorisasi, privasi, atau validitas pengujian regionalnya bergantung pada jalur keluar tertentu.

Kebijakan profil yang baik menyatakan perilaku yang dimaksud:

• Proxy wajib: hentikan permintaan jaringan terkait ketika jalur terpilih tidak dapat digunakan.
• Sekumpulan proxy yang disetujui: coba hanya alternatif yang disebutkan dan memiliki kebijakan setara.
• Koneksi langsung cadangan diizinkan: tunjukkan bahwa rute berubah dan catat peristiwa tanpa nilai rahasia.
• Pengecualian eksplisit: dokumentasikan kategori tujuan dan alasan akses langsung diperlukan.

Antarmuka harus memperlihatkan status rute sebelum peluncuran dan setelah kegagalan. Peralihan diam-diam dari proxy ke koneksi langsung mengubah kesalahan jaringan menjadi kesalahan integritas: alur kerja tampak berhasil, tetapi menggunakan jalur yang salah.

Matriks validasi yang aman

Uji dengan endpoint dan zona DNS yang Anda miliki atau diizinkan untuk diperiksa. Catat hasil yang diharapkan sebelum menjalankan pengujian.

1. Cocokkan skema proxy yang dinyatakan dengan transportasi endpoint sebenarnya.
2. Pastikan HTTP, HTTPS, WebSocket, dan perilaku WebRTC yang diperlukan berfungsi.
3. Amati alamat keluar pada tujuan yang dikendalikan.
4. Amati resolver yang menerima pencarian tujuan dan resolver yang melakukan pencarian awal nama host proxy.
5. Kedaluwarsakan kredensial uji dan pastikan tidak ada nilai mentah yang muncul di antarmuka, log, atau keluaran otomatisasi.
6. Buat proxy uji tidak dapat dijangkau dan pastikan hasilnya sesuai konfigurasi: memblokir koneksi atau menggunakan rute cadangan.
7. Tolak satu tujuan CONNECT yang dikendalikan dan pastikan penolakan kebijakan tidak berubah menjadi akses langsung.
8. Buat PAC uji tidak tersedia dan pastikan kewajiban PAC tetap berlaku.
9. Jalankan kasus pengecualian host persis, subdomain, lokal, link-local, IPv4, dan IPv6 yang diperlukan alur kerja.
10. Ubah proxy saat koneksi aktif dan verifikasi kapan rute baru mulai berlaku.
11. Rekam hanya rincian diagnostik yang diperlukan pengujian, lalu periksa retensi dan penghapusannya.

Panduan NetLog Chromium memperlakukan pencatatan jaringan sebagai persoalan privasi dan keamanan. Mode tersamarkan dapat menghilangkan kolom sensitif, sedangkan mode lebih rinci mungkin memuat cookie atau header autentikasi. Berkas dukungan harus ditangani berdasarkan mode perekaman sebenarnya, bukan nama berkasnya.