Kebocoran WebRTC dan DNS: cara mencegah eksposur IP

Kebocoran WebRTC terjadi ketika browser mengekspos IP asli Anda melalui permintaan STUN, bahkan saat proxy sedang berjalan. Kebocoran DNS terjadi ketika pencarian domain dialihkan ke ISP Anda alih-alih terowongan proxy. Keduanya menggagalkan tujuan merutekan lalu lintas melalui Nsocks atau penyedia mana pun. Pengujian hanya butuh beberapa menit, dan perbaikan di bawah ini berlaku untuk Chrome, Firefox, dan sesi skrip.

Legenda yang digunakan pada halaman ini: ✅ dikonfirmasi oleh pemeriksaan · ❌ kebocoran atau kontrol yang hilang · ⚠️ perlindungan parsial · 💡 tips praktis. Tidak ada tanda lain yang digunakan.

Apa itu kebocoran WebRTC

Kebocoran WebRTC mengekspos IP lokal atau publik Anda melalui kandidat ice yang dikumpulkan selama koneksi peer-to-peer, apa pun yang dikatakan pengaturan proxy. Browser menggunakan WebRTC untuk panggilan video, dan permintaan stun server berjalan melalui UDP, yang tidak pernah disentuh oleh sebagian besar proxy berbasis HTTP. Bilah alamat tampak terproksi, tetapi browser diam-diam melaporkan hal lain.

💡 Jalankan tes WebRTC Leak sebelum tugas yang berhadapan dengan klien apa pun, bukan setelah ada sesuatu yang terlihat janggal.

Apa itu kebocoran DNS

Kebocoran DNS terjadi ketika resolusi hostname dilakukan di jaringan lokal Anda alih-alih melalui proxy. Kueri DNS mengungkapkan situs mana yang Anda kunjungi, dan resolver yang digunakan sering kali mengekspos jaringan asal. Konfigurasi SOCKS5 standar menyelesaikan DNS secara lokal secara default, dan di situlah paparan ini dimulai.

Jenis kebocoran, penyebab, dan perbaikan

Sebagian besar masalah paparan dapat dilacak ke daftar penyebab yang singkat. Tabel di bawah ini adalah satu-satunya referensi yang digunakan artikel ini, sehingga jenis kebocoran tidak diulang di setiap subjudul. Setiap baris mencantumkan penyebab, cara mendeteksinya, dan perbaikannya.

Cara menguji pengaturan Anda terhadap kebocoran

Hal yang perlu diverifikasi setelah profil diluncurkan

Tes WebRTC Leak yang dipasangkan dengan tes DNS Leak menangkap sebagian besar paparan sebelum mencapai produksi. Langkah-langkah di bawah ini bekerja sama baiknya untuk tab browser maupun sesi skrip. Jalankan kelima langkah setiap kali, bukan hanya saat ada sesuatu yang terasa janggal.

1. Catat IP asli Anda dengan proxy mati.
2. Nyalakan proxy dan pastikan IP yang ditampilkan berubah.
3. Jalankan tes ip Leak dengan pemeriksaan resolver di situs tepercaya.
4. Bandingkan setiap hasil dengan IP asli dan resolver ISP Anda, tandai setiap kecocokan.
5. Ulangi di lingkungan kerja yang sebenarnya, karena hasil tab yang bersih tidak berarti banyak untuk otomatisasi.

Cara mencegah kebocoran DNS dengan socks5h

SOCKS5 biasa menyelesaikan hostname di klien, sedangkan socks5h mengirimkan pencarian tersebut melalui proxy itu sendiri. Satu huruf tersebut menutup jalur DNS Leak yang paling umum secara langsung. Resolusi dns remote menjaga setiap kueri tetap di dalam terowongan, yang penting untuk riset, QA, dan pekerjaan spesifik pasar.

Di mana nama domain diselesaikan

curl --socks5-hostname USERNAME:PASSWORD@PROXY_IP:PORT https://example.com

Sebagian besar pustaka scraping secara default menggunakan socks5 biasa kecuali diberi tahu sebaliknya, jadi memeriksa string koneksi bernilai tiga puluh detik. ✅ Dukungan socks5h yang terdokumentasi menghemat satu langkah.

Cara mengontrol WebRTC di browser

Browser hadir dengan kebijakan penanganan IP WebRTC yang berbeda-beda, dan tidak ada yang menjanjikan anonimitas penuh sendirian. Firefox memungkinkan Anda menonaktifkan WebRTC sepenuhnya melalui about:config, sementara Chromium mengandalkan kebijakan yang sama atau ekstensi karena tidak ada tombol bawaan. Kebijakan yang diatur untuk menonaktifkan UDP non-proxied memaksa kandidat ice melalui proxy aktif.

• ✅ Firefox: media.peerconnection.enabled diatur ke false, atau ice.no_host untuk perlindungan parsial
• ✅ Chromium: kebijakan penanganan IP diatur untuk menonaktifkan UDP non-proxied
• ⚠️ Ekstensi membantu, tetapi pembaruan dapat mereset pengaturan
• ❌ Menganggap proxy memblokir WebRTC secara otomatis, sebagian besar tidak

Uji ulang setelah setiap pembaruan browser, karena vendor mengubah perilaku default lebih sering daripada yang disarankan catatan rilis. Kebijakan yang buruk sering menjadi penyebab terbesar WebRTC Leak di lapisan ini. Obfuscation mDNS menyembunyikan IP lokal, tetapi sisi publik membutuhkan perbaikannya sendiri.

Lalu lintas IPv6 dan rute yang tidak melalui terowongan

Lalu lintas IPv6 lolos dari proxy yang hanya dibangun untuk IPv4, dan celah tersebut adalah salah satu jalur paparan yang paling sering terlewat saat ini. Koneksi dual-stack dapat menampilkan alamat IPv4 yang bersih melalui proxy sementara IPv6 dirutekan keluar melalui ISP asli. Sebagian besar alat pemeriksa IP hanya menampilkan hasil IPv4. WebRTC ip Leak melalui antarmuka IPv6 yang tidak melalui terowongan tampak identik dengan sesi yang bersih.

💡 Nonaktifkan IPv6 di tingkat adapter jika pengaturan proxy tidak mencakupnya, atau pastikan perutean dual-stack sebelum menjalankan apa pun yang berhadapan dengan klien.

Konsistensi: IP, DNS, zona waktu, dan bahasa

Lulus tes masih menyisakan celah jika sinyal lain tidak sejalan. Tes DNS Leak saja tidak akan menangkap ketidaksesuaian zona waktu antara jam sistem dan wilayah proxy. Bahasa, tata letak keyboard, dan locale semuanya memasok gambaran yang sama yang dibangun sebuah platform dari sebuah sesi. Risiko ini berlipat ganda di beberapa profil klien, dan pembahasan lebih mendalam ada di panduan kami tentang mengelola beberapa profil browser.

Daftar periksa pra-penerbangan untuk tugas otomatisasi

Tugas browser otomatis dan headless membutuhkan pemeriksaan yang dapat diulang sebelum setiap kali dijalankan, bukan pengaturan sekali saja. Daftar ini berbeda dari langkah manual di atas, karena skrip gagal secara diam-diam dengan cara yang langsung disadari oleh penguji. Anggap ini sebagai standar minimum sebelum produksi.

• ✅ Catat IP keluar per permintaan, bukan hanya saat sesi dimulai
• ✅ Gagal cepat jika IP yang dicatat berada di luar rentang yang diharapkan
• ✅ Periksa ulang kebocoran setelah pembaruan browser atau driver apa pun
• ✅ Pastikan resolusi remote aktif dalam string koneksi
• ✅ Periksa perutean IPv6 secara terpisah dari IPv4
• ✅ Pastikan zona waktu dan locale sesuai dengan wilayah proxy
• ⚠️ Anggap hasil lulus minggu lalu sudah kedaluwarsa, bukan yang terkini
• ❌ Jangan lewati pemeriksaan karena "kemarin sudah berhasil"

Daftar singkat hanya bernilai jika ada yang bertanggung jawab atasnya, jadi sematkan di tempat yang terlihat tim sebelum tugas berjalan langsung.

Kesalahan umum

Sebagian besar masalah paparan berulang berasal dari celah proses, bukan dari jenis kebocoran yang tidak dikenal. Tim sering memeriksa sekali saat pengaturan dan melewatkan pengujian ulang setelah pembaruan dirilis. Menguji di tab biasa, alih-alih lingkungan yang sebenarnya, memberi rasa aman palsu. Mengandalkan hanya dasbor penyedia, alih-alih pemeriksa independen, melewatkan hal yang memang tidak dirancang untuk ditangkapnya. Memperlakukan satu WebRTC Leak sebagai kejadian sekali saja, alih-alih kegagalan proses, menjamin pengulangan.

Bagaimana pengaturan proxy memengaruhi risiko kebocoran

Disklosure: Nsocks adalah layanan kami, dan bagian ini menjelaskan bagaimana pengaturan kami menangani risiko di atas. Kami menjual proxy residensial dan proxy IP statis, keduanya dengan resolusi DNS remote di sisi proxy. Sebagian besar tiket dukungan tentang WebRTC Leak dapat dilacak ke satu baris pada tabel di atas. Tabel tersebut mencantumkan arti setiap fitur dalam praktik sehari-hari, bukan bahasa pemasaran.

Tidak ada dari semua ini yang menggantikan konfigurasi tingkat browser atau kebiasaan pengujian ulang. Proxy menangani perutean; browser yang memutuskan apa yang diungkapkannya. Tim yang menjalankan tes WebRTC Leak sebelum setiap sesi klien melihat lebih sedikit kejutan. Coba demo Nsocks untuk melihat detail koneksi, atau daftar untuk akses dasbor.

Poin utama

• Jalankan tes kebocoran untuk WebRTC dan DNS sebelum setiap sesi klien, bukan hanya sekali.
• socks5h memindahkan resolusi ke proxy, menutup jalur paparan yang paling umum.
• IPv6 membutuhkan pemeriksaan tersendiri, karena sebagian besar alat IP hanya menampilkan IPv4 secara default.
• Konsistensi antara IP, DNS, zona waktu, dan locale sama pentingnya dengan satu tes.
• Pengujian ulang setelah pembaruan menangkap sebagian besar kebocoran yang digambarkan tim sebagai "mendadak."

Disklosure dan sumber data

Artikel ini diterbitkan oleh Nsocks. Kami menjual proxy dan memiliki kepentingan komersial pada bagian yang menjelaskan pengaturan kami sendiri. Alat pengujian dan pengaturan browser yang dirujuk adalah milik pemiliknya masing-masing, termasuk vendor browser dan layanan pemeriksa independen. Detail diperiksa pada Agustus 2026, dan perilaku dapat berubah antarversi, jadi verifikasi ulang flag terlebih dahulu.

Pertanyaan yang sering diajukan

Apa itu kebocoran WebRTC?

Browser mengungkapkan IP asli Anda melalui STUN atau kandidat ICE meskipun proxy aktif.

Bagaimana cara menguji kebocoran DNS?

Jalankan pemeriksaan resolver di situs pengujian kebocoran dan bandingkan dengan lokasi proxy Anda.

Apa perbedaan antara SOCKS5 dan socks5h?

SOCKS5 menyelesaikan hostname secara lokal; socks5h mengirimkan pencarian tersebut melalui server proxy.

Apakah menonaktifkan WebRTC merusak panggilan video?

Ya, menonaktifkannya menghentikan panggilan sepenuhnya, jadi pembatasan ICE parsial bekerja lebih baik.

Bisakah IPv6 mengekspos IP asli saya?

Ya, jika proxy hanya menangani lalu lintas IPv4, IPv6 juga dapat melewatinya.

Seberapa sering saya harus menguji ulang pengaturan otomatisasi saya?

Setelah setiap pembaruan browser atau driver, plus secara berkala tanpa kecuali.