Uji Tingkat Lanjut IP & Kebocoran DNS: Periksa Keamanan Jaringan Anda

Menganalisis anonimitas jaringan Anda... Anda akan dialihkan secara otomatis setelah selesai.
Status Stack Jaringan ?
IPv4 ?
Menunggu...
DNS IPv4 ?
Menunggu...
IPv6 ?
Menunggu...
DNS IPv6 ?
Menunggu...
Prioritas ?
Menunggu...
Tipe NAT ?
Menunggu...
Latensi ke Proksi
Menunggu...
Jitter Jaringan
Menunggu...
Kebocoran WebRTC
Menunggu...
Kebocoran DNS ?
Menunggu...
Status Proksi Jaringan
Menunggu...
Split-Tunnel
Menunggu...
Tingkat Anonimitas
Menunggu...
IP Egress Terdeteksi Alamat IP publik yang terlihat oleh server
Memindai...
Server DNS Terdeteksi Lokasi server resolver domain
View Full DNS Health Check →
Memindai...
Latensi Jaringan & Uji Kecepatan Perkiraan Kuota:10 MB
Menunggu uji kecepatan...
Unduh
--
Mbps
Unggah
--
Mbps
Ping
--
ms
Klik paket kuota untuk memulai tes:
Menjalankan Uji Konektivitas & Latensi...

Tanya Jawab Umum Tentang Deteksi IP & Jaringan

Pelajari perbedaan antara IP pusat data dan residensial, mekanisme penilaian risiko, dan penyebab kebocoran DNS/WebRTC.

Banyak pengguna percaya membeli "proksi residensial" akan sepenuhnya menyamarkan mereka sebagai pengguna rumah biasa. Namun, mesin penilaian risiko modern melihat jauh melampaui tag klasifikasi statis dalam basis data GeoIP (seperti IP2Location atau MaxMind). Bahkan ketika IP keluar terdaftar sebagai alamat ISP/residensial, gateway proksi penerusan hampir selalu berjalan di server Linux yang dihosting di cloud, memperkenalkan kontradiksi lintas lapisan yang nyata: Pertama, tanda tangan tumpukan protokol transport: server keluar mentransmisikan urutan opsi TCP standar Linux (MSS, SACK_PERM, TS, NOP, WS) selama jabat tangan SYN awal daripada opsi Windows atau Apple. Kedua, perbedaan MTU jalur: koneksi PPPoE perumahan biasanya menunjukkan MTU 1492 (atau 1400–1430 pada seluler), sedangkan Ethernet pusat data mentah adalah standar 1500 (MSS=1460). Ketika sistem anti-penipuan mendeteksi IP residensial disertai dengan MTU pusat data dan tumpukan TCP Linux, sistem mengklasifikasikan koneksi sebagai proksi otomatis.

💡 Uji koneksi Anda dengan Uji Anonimitas Proksi kami untuk melihat di mana TCP Anda berakhir.

Tidak ada ikatan fisik tetap antara alamat IP dan lokasi geografis fisik. Hasil lokasi bergantung pada basis data GeoIP komersial yang digunakan oleh setiap situs dan siklus pembaruannya: Pertama, sumber basis data dan model telemetri berbeda—penyedia (seperti MaxMind, IP2Location, DB-IP) memberi bobot pengumuman BGP, entri registri whois, dan probe latensi jaringan secara berbeda, dengan interval penyegaran mulai dari hari hingga bulan. Kedua, perutean Anycast dan pengiriman edge CDN: penyedia seperti Cloudflare mengumumkan blok IP yang sama dari ratusan pusat data global, merutekan paket Anda ke kolokasi edge terdekat. Ketiga, penugasan ulang IP lintas batas: ketika penyedia hosting mengalokasikan kembali blok IP yang terdaftar di satu negara ke server di negara lain, basis data yang kedaluwarsa melaporkan asal historis. Alat kami menggabungkan pemeriksaan silang multi-basis data dengan multilaterasi penundaan kecepatan cahaya RTT fisik untuk memverifikasi wilayah fisik sebenarnya.

Skor Penipuan IP (atau Skor Risiko) adalah indeks numerik (biasanya 0 hingga 100) yang digunakan oleh mesin risiko untuk mengukur kemungkinan bahwa suatu koneksi berasal dari aktivitas yang kasar, bot, atau terselubung. Faktor evaluasi inti meliputi: Pertama, reputasi historis dan daftar penyalahgunaan: apakah IP telah terlibat dalam credential stuffing, scraping, spamming, atau pemindaian dalam jendela 24–72 jam terakhir. Kedua, tipe ASN dan infrastruktur: pusat data (hosting) dan rentang proksi/VPN publik membawa risiko dasar yang lebih tinggi daripada broadband perumahan atau operator seluler. Ketiga, multi-endpoint dan konsistensi protokol: apakah suatu sesi menunjukkan titik keluar dual-stack terpisah (IPv4 dan IPv6 berbeda), divergensi lokasi resolver DNS, atau paparan IP lokal WebRTC.

💡 Gunakan Uji Split Tunneling kami untuk mengidentifikasi kebocoran perutean yang dapat meningkatkan skor risiko Anda.

Bahkan dengan VPN atau proksi aktif, identitas asli Anda dapat bocor melalui saluran sampingan: Pertama, Kebocoran DNS: ketika peramban Anda menyelesaikan nama host, jika perangkat lunak proksi gagal menangkap permintaan DNS tingkat OS, kueri langsung menuju tanpa enkripsi ke server DNS ISP lokal Anda (Internet Positif), mengungkapkan domain yang dikunjungi dan lokasi asli. Kedua, Kebocoran WebRTC: WebRTC adalah teknologi peramban untuk komunikasi peer-to-peer real-time. Saat memulai koneksi, WebRTC melewati lapisan proksi HTTP/SOCKS dan mengirimkan paket STUN UDP secara langsung, memperlihatkan alamat IP lokal dan publik asli Anda. Beranda kami menguji titik keluar DNS dan status WebRTC Anda secara real-time.

💡 Untuk memeriksa kebocoran Canvas tingkat perangkat keras, audio, dan WebRTC, kunjungi Uji Sidik Jari Peramban.

Panel tumpukan jaringan beranda menjalankan tiga probe terkait secara paralel: satu menghubungi domain dengan hanya rekaman A (iptestv4.myipdns.com), satu menghubungi domain dengan hanya rekaman AAAA (iptestv6.myipdns.com), dan yang ketiga menghubungi domain dual-stack dengan kedua keluarga rekaman. Dua yang pertama adalah wajib—setiap nama host hanya menyelesaikan ke satu keluarga alamat, tidak meninggalkan pilihan bagi sistem Anda, sehingga menangkap IP keluar Anda yang sebenarnya pada IPv4 dan IPv6 secara independen. Probe ketiga tidak dipaksakan; melainkan mengamati keluarga alamat mana yang dipilih sistem Anda sendiri, yang ditampilkan di kolom "Protokol Pilihan": hasil ini ditentukan oleh kebijakan pemilihan alamat OS dan peramban Anda (Happy Eyeballs, RFC 8305: ketika dual-stack tersedia, coba IPv6 terlebih dahulu, mundur ke IPv4 hanya saat gagal), tidak ditentukan oleh kami. Menempatkan ketiganya secara berdampingan sangat penting karena banyak klien proksi dan VPN hanya menerowongkan IPv4: jika titik keluar IPv4 Anda berada di ASN proksi sementara titik keluar IPv6 Anda tetap berada di ISP perumahan Anda, dan protokol yang disukai menampilkan IPv6, maka saat mengunjungi situs web dual-stack sebagian besar lalu lintas Anda tidak pernah melalui terowongan—ini adalah bentuk paling umum dari "VPN aktif namun identitas asli terungkap", dan tidak memunculkan kesalahan sama sekali.

⚠ Kami hanya dapat memberi tahu Anda apakah titik keluar keluarga ganda Anda berakhir di jaringan yang berbeda; kami tidak dapat menilai bagaimana perangkat lunak proksi Anda harus dikonfigurasi. Sebaliknya, IPv6 yang ditampilkan sebagai tidak tersedia tidak berarti aman; itu mungkin hanya berarti jaringan Anda tidak memiliki IPv6, atau bahwa proksi Anda menonaktifkan IPv6 sepenuhnya—yang terakhir sering kali merupakan perilaku yang dimaksudkan.

Kami tidak membaca pengaturan sistem lokal Anda—peramban tidak dapat membacanya sama sekali, dan halaman web mana pun yang mengklaim membaca konfigurasi DNS lokal Anda hanyalah menebak. Pendekatan sebenarnya adalah menguji secara terbalik: situs kami mengoperasikan server DNS otoritatif, menghasilkan subdomain acak unik untuk setiap tes (seperti k3f9x2ab.leakv4.myipdns.com) agar peramban Anda menyelesaikannya. Nama host ini hanya muncul sekali dalam sejarah dan tidak akan pernah ada dalam cache mana pun, jadi rantai resolusi rekursif Anda harus meminta server otoritatif kami sampai ke sumbernya; kami mencatat siapa yang sebenarnya membuat kueri, lalu mengembalikan alamat tersebut ke peramban Anda. Oleh karena itu, kolom "Keluar DNS" menampilkan alamat jaringan keluar sebenarnya dari resolver rekursif Anda, bukan IP hulu yang Anda masukkan dalam pengaturan sistem Anda: jika Anda mengatur 8.8.8.8, mesin yang meminta kami adalah node keluar tertentu dalam kluster tersebut, yang mungkin berada di negara lain; resolver publik besar mengandalkan anycast dan pengelompokan, jadi mengamati beberapa alamat keluar yang berbeda dalam satu tes adalah hal yang sepenuhnya normal. Kriteria sebenarnya bukanlah apakah alamat cocok, melainkan: jika titik keluar ini berada di dalam jaringan ISP broadband Anda sendiri sementara titik keluar IP Anda berakhir di proksi—itu menandakan kueri DNS gagal mengikuti terowongan.

⚠ Metodologi ini hanya dapat mengamati siapa yang meminta server otoritatif kami sendiri; kami tidak dapat dan tidak melihat domain lain yang Anda selesaikan. Ada juga titik buta yang diketahui: jika proksi Anda juga mencegat kueri DNS, apa yang kami amati adalah resolver penyedia proksi—mengonfirmasi tidak ada kebocoran ke ISP lokal Anda, namun log kueri DNS Anda tetap terlihat oleh penyedia proksi Anda; itu adalah pertimbangan terpisah di luar apa yang dideteksi alat ini.

Melalui WebRTC, probe tunggal dikirimkan ke beberapa server STUN untuk mengumpulkan kandidat srflx yang dikembalikan—yaitu, IP dan port publik yang sebenarnya diamati oleh server jarak jauh setelah terjemahan NAT. Hanya ada satu kriteria yang menentukan: kandidat dikelompokkan berdasarkan IP publik yang diterjemahkan; jika dua atau lebih port yang berbeda muncul di bawah IP yang sama, ini diklasifikasikan sebagai NAT Simetris (Symmetric NAT) (menetapkan port terpetakan baru untuk setiap tujuan yang berbeda); jika tidak, ini diklasifikasikan sebagai NAT Kerucut (Cone NAT) (secara konsisten memetakan port internal yang sama ke port eksternal yang sama). Mengelompokkan kandidat sebelum membandingkan port sengaja diperkenalkan: dalam lingkungan proksi split-tunnel, server STUN yang berbeda dapat merutekan melalui titik keluar yang berbeda, secara alami menyebabkan port berbeda; namun, perbedaan ini berasal dari perbedaan jalur daripada perilaku NAT, dan menghilangkan pengelompokan akan salah mendiagnosis semua pengaturan tersebut sebagai Simetris. Menampilkan "Tidak Diketahui" memiliki dua penyebab: pertama, gagal menerima kandidat srflx apa pun dalam batas waktu 4 detik (WebRTC dinonaktifkan di peramban, diblokir oleh ekstensi, atau UDP keluar difilter); kedua, hanya menerima satu kandidat yang IP publiknya tidak cocok dengan IP masuk yang digunakan untuk mengakses situs ini, sehingga mustahil untuk membedakan deduplikasi kandidat peramban dari pemisahan perutean lalu lintas, jadi kami sengaja menampilkan tidak diketahui.

⚠ Klarifikasi jujur: kami hanya membedakan antara Cone dan Symmetric NAT, dan tidak mengklasifikasikan lebih lanjut menjadi Full Cone, Restricted Cone, atau Port-Restricted Cone. Model empat tingkat RFC 3489 memerlukan pengendalian kombinasi port sumber dan target tujuan secara aktif di seluruh probe berulang, dan WebRTC di peramban tidak menyediakan kontrol tingkat rendah seperti itu; ketika alat berbasis web melaporkan salah satu dari empat kategori, mereka biasanya hanya melabeli ulang kedua hasil ini.

Pemeriksaan pada halaman utama terdiri dari beberapa kelompok permintaan: menghubungkan ke beberapa subdomain situs ini untuk mengumpulkan karakteristik tumpukan protokol di seluruh IPv4, IPv6, dan berbagai versi HTTP; menanyakan beberapa layanan pencarian IP pihak ketiga serta WebRTC untuk melihat apakah berbagai tujuan mengamati jalan keluar yang sama; menyelesaikan subdomain acak untuk melihat siapa yang menyelesaikan DNS Anda; memeriksa node kami di wilayah lain untuk memverifikasi silang dari beberapa lokasi; serta mengukur latensi ke beberapa situs web populer.

⚠ Konsekuensinya adalah menghubungkan ke cukup banyak domain saat memuat, yang terkadang dicegat oleh pemblokir iklan atau ekstensi privasi yang ketat. Item yang terpengaruh akan menampilkan titik abu-abu dan tetap dalam status tidak diketahui, dan kami tidak akan melengkapinya menggunakan hasil lain.