← Kembali ke blog

SOCKS5 vs SOCKS5h: Memperbaiki Kebocoran Permintaan DNS di Python, curl, dan Selenium

Kami membahas mengapa saat bekerja melalui SOCKS5, permintaan DNS langsung berasal dari IP Anda, perbedaan antara SOCKS5h, dan cara menutup celah ini di Python, curl, Selenium, dan browser anti-detect.

📅30 Oktober 2026

Anda telah mengatur proxy SOCKS5, lalu lintas tampaknya berjalan melalui itu, IP di browser ditampilkan dengan benar — tetapi situs tetap dapat melihat wilayah nyata Anda atau penyedia mulai mencurigai sesuatu. Penyebabnya hampir selalu sama: permintaan DNS langsung dari komputer Anda, melewati proxy. Dalam artikel ini, kita akan membahas mengapa ini terjadi, perbedaan antara SOCKS5 dan SOCKS5h, dan bagaimana menutup kebocoran ini dalam kode dan alat yang sudah ada.

Apa itu SOCKS5 dan apa bedanya dengan SOCKS5h

SOCKS5 adalah protokol proxy yang bekerja pada level koneksi TCP/UDP dan tidak menganalisis konten paket, berbeda dengan proxy HTTP(S). Ini membuatnya serbaguna: melalui SOCKS5, hampir semua lalu lintas dapat diproksikan — browser, Telegram, klien torrent, skrip di Python. Namun, implementasi klasik SOCKS5 memiliki satu fitur penting: resolusi nama domain (DNS) secara default dilakukan di sisi klien, yaitu di komputer Anda, bukan di sisi server proxy.

SOCKS5h adalah protokol yang sama, tetapi dengan modifikasi "h" (hostname), yang memberi tahu aplikasi klien untuk tidak meresolusi domain sendiri, tetapi mengirimkannya apa adanya ke server proxy, dan proxy akan melakukan permintaan DNS atas namanya. Perbedaannya hanya satu huruf, tetapi konsekuensinya untuk anonimitas dan stabilitas kerja — sangat signifikan.

Penting untuk dipahami: SOCKS5h bukanlah protokol terpisah, tetapi kesepakatan di tingkat pustaka atau aplikasi tertentu tentang bagaimana membentuk permintaan ke proxy. Server proxy itu sendiri berfungsi sama dalam kedua kasus, perbedaannya hanya pada siapa yang memulai resolusi DNS — klien atau server.

Mengapa permintaan DNS melewati proxy

Ketika Anda mengakses alamat seperti https://example.com, sebelum membangun koneksi, aplikasi harus mengetahui alamat IP dari domain tersebut. Proses ini disebut resolusi DNS. Saat bekerja melalui SOCKS5 biasa, banyak pustaka dan pengaturan sistem melakukan resolusi melalui server DNS sistem — yang ditentukan dalam pengaturan jaringan penyedia Anda atau router.

Akibatnya, muncul situasi paradoks: lalu lintas HTTP/TCP itu sendiri berjalan melalui proxy dan tampak seolah permintaan datang dari IP server proxy, sementara permintaan DNS "IP apa yang dimiliki example.com?" langsung dari IP nyata Anda ke server DNS penyedia. Inilah yang disebut kebocoran DNS (DNS leak). Situs atau layanan yang menganalisis aktivitas jaringan pada tingkat yang lebih dalam (dan metode deteksi semacam itu secara aktif digunakan oleh sistem anti-fraud Facebook, Google, TikTok) dapat melihat ketidaksesuaian antara IP koneksi dan sumber permintaan DNS.

Penyebabnya adalah bahwa protokol SOCKS5 awalnya dikembangkan sebagai tingkat transportasi untuk koneksi IP yang sudah ada, bukan untuk resolusi nama. Para pengembang pustaka dan utilitas harus secara terpisah mengimplementasikan fungsi pengiriman permintaan DNS melalui terowongan — dari sinilah SOCKS5h muncul sebagai petunjuk eksplisit "resolusi domain sendiri, bukan saya".

Apa bahaya kebocoran DNS dalam praktik

Bagi pengembang parser atau skrip otomatisasi, kebocoran DNS bukanlah teori abstrak, tetapi penyebab konkret pemblokiran dan larangan akun. Mari kita bahas beberapa skenario.

Parsing marketplace dan situs. Jika Anda mem-parsing Wildberries, Ozon, atau sumber lain melalui proxy dari wilayah yang diinginkan, tetapi permintaan DNS berjalan melalui penyedia, sistem anti-bot dapat mendeteksi ketidaksesuaian geolokasi dan meningkatkan tingkat kecurigaan sesi — hingga captcha atau pemblokiran sementara IP proxy.

Multi-akunting dan arbitrase lalu lintas. Saat bekerja dengan Facebook Ads, TikTok Ads, atau Google Ads melalui beberapa akun, sistem anti-fraud menganalisis puluhan parameter, termasuk jejak DNS. Jika permintaan DNS dari beberapa akun "berbeda" tiba-tiba berjalan melalui server DNS penyedia yang sama, ini adalah sinyal untuk menggabungkan akun menjadi satu kluster — dan sebagai akibatnya, rantai larangan (chain-ban).

Automatisasi di Selenium/Playwright. Skrip yang meniru tindakan pengguna di browser, terutama rentan: browser itu sendiri dapat meresolusi DNS melalui pengaturan sistem OS, mengabaikan proxy yang hanya ditentukan untuk lalu lintas HTTP. Akibatnya, semua sidik jari jaringan lainnya menunjukkan lokasi nyata.

Untuk sebagian besar tugas ini, sangat penting untuk menggunakan proxy residensial dengan resolusi DNS yang diatur dengan benar di sisi server — ini secara signifikan mengurangi risiko deteksi berdasarkan tanda jaringan.

Bagaimana cara memeriksa apakah ada kebocoran DNS

Sebelum memperbaiki masalah, sebaiknya pastikan bahwa masalah tersebut benar-benar ada. Berikut beberapa cara cepat untuk memeriksa.

  1. Buka situs dnsleaktest.com atau ipleak.net melalui koneksi proxy Anda dan jalankan tes lanjutan (Extended test).
  2. Bandingkan daftar server DNS dalam hasil dengan siapa penyedia internet Anda sebenarnya. Jika Anda melihat penyedia alih-alih pusat data proxy — kebocoran terkonfirmasi.
  3. Untuk command line, gunakan kombinasi tcpdump atau Wireshark, menyaring lalu lintas berdasarkan port 53 (DNS) — jika paket pergi langsung ke server penyedia, bukan melalui terowongan proxy, masalah ada di pihak Anda.
  4. Di Python, Anda dapat dengan cepat memeriksa resolusi secara manual melalui socket.getaddrinfo() sebelum dan setelah mengaktifkan proxy — jika IP cocok dengan hasil tanpa proxy, resolusi dilakukan secara lokal.

Perbaikan di Python (requests, PySocks, urllib3)

Kesalahan paling umum dalam skrip Python adalah penggunaan pustaka requests bersama dengan PySocks tanpa menyebutkan skema socks5h secara eksplisit. Perbedaannya hanya satu karakter, tetapi karakter tersebut menentukan siapa yang meresolusi domain.

import requests

# BURUK: DNS diresolusi secara lokal, melewati proxy
proxies_leak = {
    "http": "socks5://user:pass@proxy_host:1080",
    "https": "socks5://user:pass@proxy_host:1080",
}

# BAIK: DNS diresolusi di sisi server proxy
proxies_safe = {
    "http": "socks5h://user:pass@proxy_host:1080",
    "https": "socks5h://user:pass@proxy_host:1080",
}

response = requests.get("https://example.com", proxies=proxies_safe, timeout=10)
print(response.status_code)
print(response.text[:200])

Untuk berfungsi dengan benar, skema socks5h melalui requests perlu menginstal ketergantungan:

pip install "requests[socks]" PySocks

Jika Anda menggunakan urllib3 tingkat rendah secara langsung, contohnya akan terlihat seperti ini:

from urllib3.contrib.socks import SOCKSProxyManager

proxy = SOCKSProxyManager(
    "socks5h://user:pass@proxy_host:1080",
    num_pools=10
)

response = proxy.request("GET", "https://example.com")
print(response.status)

Untuk skrip asinkron di aiohttp, gunakan pustaka aiohttp-socks, di mana skema ditentukan dengan cara yang sama:

import aiohttp
from aiohttp_socks import ProxyConnector

connector = ProxyConnector.from_url("socks5h://user:pass@proxy_host:1080")

async def fetch():
    async with aiohttp.ClientSession(connector=connector) as session:
        async with session.get("https://example.com") as resp:
            print(await resp.text())

Perbaikan di curl

Di curl juga ada dua bendera berbeda untuk proxy SOCKS5, dan kebingungan antara keduanya adalah penyebab klasik kebocoran DNS dalam skrip bash.

# BURUK: resolusi di mesin lokal
curl --socks5 proxy_host:1080 https://example.com

# BAIK: resolusi di sisi server proxy
curl --socks5-hostname proxy_host:1080 https://example.com

# Dengan otorisasi
curl --socks5-hostname user:pass@proxy_host:1080 https://example.com

Bendera --socks5-hostname adalah analog langsung dari socks5h di alat lain. Ini memberi tahu curl: "jangan sentuh DNS, cukup kirim domain ke server proxy apa adanya".

Perbaikan di Selenium dan Playwright

Dengan otomatisasi browser, situasinya lebih rumit: Chrome atau Firefox secara default dapat meresolusi DNS melalui pengaturan sistem, mengabaikan proxy yang hanya ditentukan pada tingkat permintaan jaringan. Untuk Selenium dengan Chrome, Anda perlu secara eksplisit mengaktifkan resolusi melalui proxy dengan menggunakan bendera peluncuran browser.

from selenium import webdriver
from selenium.webdriver.chrome.options import Options

options = Options()
options.add_argument("--proxy-server=socks5://proxy_host:1080")
# Bendera yang sangat penting: resolusi DNS melalui proxy
options.add_argument("--host-resolver-rules=MAP * ~NOTFOUND , EXCLUDE proxy_host")

driver = webdriver.Chrome(options=options)
driver.get("https://example.com")

Di Playwright, situasinya lebih sederhana: pustaka secara default meresolusi DNS melalui proxy jika ditentukan dalam konfigurasi konteks browser.

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch(
        proxy={"server": "socks5://proxy_host:1080"}
    )
    page = browser.new_page()
    page.goto("https://example.com")
    print(page.title())
    browser.close()

Namun, disarankan untuk selalu memeriksa perilaku nyata melalui dnsleaktest.com setelah pengaturan — perilaku dapat bervariasi antara versi Chromium.

Pengaturan di browser anti-detect

Jika Anda tidak menulis kode, tetapi bekerja melalui browser anti-detect seperti Dolphin Anty, AdsPower, Multilogin, atau GoLogin — kabar baiknya adalah bahwa sebagian besar dari mereka sudah secara otomatis meresolusi DNS melalui server proxy saat memilih protokol SOCKS5, tanpa perlu menyebutkan "h" secara manual. Ini adalah salah satu keuntungan utama mereka dibandingkan skrip yang ditulis sendiri.

Namun, sebaiknya periksa ini dalam praktik: buka profil di browser anti-detect, kunjungi dnsleaktest.com dan jalankan tes lanjutan langsung di dalam profil. Jika Anda melihat server DNS yang sesuai dengan wilayah proxy Anda, bukan penyedia nyata Anda — pengaturan benar. Jika tidak, hubungi dukungan browser anti-detect tertentu atau ganti jenis proxy ke HTTP(S), di mana masalah resolusi DNS tidak muncul dengan tajam, karena proxy HTTP selalu bekerja dengan URL lengkap.

Untuk farming akun di Instagram, TikTok, dan menjalankan kampanye iklan di Facebook Ads, proxy seluler menunjukkan hasil yang baik — berkat rotasi dinamis IP operator seluler, mereka lebih jarang dicurigai oleh sistem anti-fraud, bahkan jika ada sedikit kebocoran DNS di suatu tempat dalam rantai.

Tabel perbandingan protokol proxy

Protokol Siapa yang meresolusi DNS Risiko kebocoran Di mana menerapkan
SOCKS5 Klien (komputer Anda) Tinggi Hanya jika DNS tidak kritis (pengujian lokal)
SOCKS5h Server proxy Rendah Parsing, multi-akunting, otomatisasi
Proxy HTTP/HTTPS Server proxy (secara default) Rendah Lalu lintas web, browser, permintaan API

Jika tugas Anda adalah pengumpulan data berkecepatan tinggi tanpa terikat pada wilayah pengguna tertentu, pertimbangkan proxy pusat data — mereka lebih murah berdasarkan volume lalu lintas dan bekerja dengan baik dengan SOCKS5h untuk parsing, di mana kecepatan lebih penting daripada menyamarkan sebagai pengguna yang tinggal.

Daftar periksa sebelum memulai proyek

  • Gunakan skema socks5h://, bukan socks5:// di semua pustaka dan konfigurasi.
  • Untuk curl, gunakan bendera --socks5-hostname, bukan --socks5.
  • Di Selenium, tambahkan bendera --host-resolver-rules atau gunakan Playwright dengan resolusi proxy bawaan.
  • Periksa hasil di dnsleaktest.com atau ipleak.net setelah pengaturan, bukan sebelum.
  • Di browser anti-detect, uji jejak DNS di dalam profil itu sendiri, bukan hanya IP eksternal.
  • Untuk tugas dengan persyaratan anonimitas tinggi, pertimbangkan proxy residensial atau seluler daripada proxy pusat data.

Kesimpulan

Perbedaan antara SOCKS5 dan SOCKS5h adalah hanya satu huruf, tetapi itu menentukan siapa yang meresolusi permintaan DNS: komputer Anda atau server proxy. Kebocoran DNS adalah salah satu penyebab deteksi yang paling tidak terlihat, tetapi sering terjadi saat parsing, multi-akunting, dan otomatisasi kampanye iklan. Memeriksa melalui dnsleaktest.com dan secara eksplisit menyebutkan skema socks5h dalam kode, perintah curl, atau pengaturan otomatisasi browser menutup celah ini dalam beberapa menit.

Jika Anda baru memilih infrastruktur untuk tugas — untuk parsing dan bekerja dengan API, proxy pusat data lebih cocok, untuk multi-akunting dan media sosial — proxy residensial, dan untuk sidik jari jaringan yang paling alami saat bekerja dengan aplikasi seluler — proxy seluler. Dalam semua kasus ini, pengaturan resolusi DNS yang benar melalui SOCKS5h tetap merupakan langkah wajib sebelum meluncurkan proyek ke produksi.