Jejak TCP/IP Proksi: Cara Memastikan OS Anda Tidak Teridentifikasi oleh Antibot

Anda telah mengatur browser anti-detect di Windows dan Chrome, memilih IP bersih, menyelaraskan zona waktu dan bahasa, tetapi situs tetap meminta captcha atau memblokir akun. Penyebab umum terletak di bawah browser, pada tingkat TCP/IP. Server melihat paket pertama dari koneksi (SYN), dan dari bidangnya terlihat sistem operasi mana yang mengirimkan paket ini. Jika ini adalah proxy Linux, tetapi User-Agent menyatakan Windows, sistem anti-bot menerima kontradiksi yang tidak bisa diperbaiki dengan header.

Topik ini tidak lagi menjadi hal yang eksotis. Pada 13 Oktober 2026, menurut Proxyway, penyedia Inggris Byteful telah mengaktifkan penggantian sidik jari TCP/IP untuk proxy pusat data dan ISP dalam versi beta terbuka: mereka dapat menyamar sebagai Windows, macOS, Linux, Android, dan iOS. Penjelasan dari Proxyway sederhana: sistem anti-bot semakin sering melihat sidik jari TCP/IP. Di bawah ini kita akan membahas bagaimana pemeriksaan ini dilakukan, bagaimana memeriksa proxy Anda dalam lima menit, dan apa yang harus dilakukan jika terjadi ketidakcocokan.

Apa itu sidik jari TCP/IP dan mengapa proxy mengubahnya

Setiap OS mengumpulkan paket SYN dengan caranya sendiri: TTL awalnya, ukuran jendela TCP, faktor skala jendela, MSS, dan yang paling penting, kumpulan dan urutan opsi TCP. Fingerprinting pasif (di sini klasiknya adalah utilitas p0f, varian modern disebut Zardaxt dan JA4T) membaca bidang ini dan menebak OS tanpa mengirimkan apa pun kepada klien sebagai balasan.

Poin kunci bagi mereka yang bekerja melalui proxy: situs melihat tumpukan TCP dari mesin yang membuka koneksi terakhir ke situs tersebut. Proxy biasa (HTTP CONNECT atau SOCKS5) menerima koneksi Anda dan membuka koneksi baru ke situs dengan namanya sendiri. Oleh karena itu, TTL dan opsi TCP dalam paket adalah milik proxy, bukan komputer Anda. Mengubah User-Agent, sidik jari TLS, atau header bisa dilakukan, tetapi SYN sudah dikumpulkan oleh kernel mesin yang Anda gunakan untuk terhubung.

Nilai tipikal berdasarkan OS

Referensi dari analisis Scrapfly dan dokumentasi pydoll (pada versi kernel dan jaringan tertentu, nilai dapat bervariasi):

• Windows 10/11: TTL awal 128, jendela 64240–65535, urutan opsi MSS, NOP, WSCALE, NOP, NOP, SACK (tanpa timestamp secara default).
• Linux: TTL 64, jendela 29200 pada kernel 3.x+ (pada beberapa kernel 5.x/6.x 64240), urutan MSS, SACK, TIMESTAMP, NOP, WSCALE.
• macOS dan iOS: TTL 64, jendela 65535, urutan MSS, NOP, WSCALE, NOP, NOP, TIMESTAMP, SACK, EOL.
• Android: TTL 64, urutan opsi mendekati Linux, yang logis karena menggunakan kernel Linux.

Dari sini, jebakan utama: hampir semua proxy pusat data berjalan di Linux. Profil "Windows + Chrome" di atas proxy semacam itu membawa dalam SYN tanda-tanda Linux, dan kontradiksi ini paling mencolok.

Seberapa akurat anti-bot menangkap ketidakcocokan

Angka-angka ada pada proyek terbuka Zardaxt: ini adalah versi ulang dari p0f dan satori.py, yang mencari tepatnya relay, yaitu proxy HTTP dan SOCKS, di mana browser menyamar sebagai mesin lain. Menurut README untuk build dari 21 September 2026 (basis dari 1.453 sidik jari dari sekitar 23 ribu sesi):

• model dengan ambang 0,8 menangkap 94,4% koneksi melalui proxy dan hanya salah menandai 0,1% koneksi langsung;
• jika browser menyatakan Windows, proxy tertangkap dalam 96% kasus, jika Mac, maka dalam 99%;
• tempat lemah adalah Android dan Linux: mereka berbagi satu kelas, sehingga relay semacam itu tertangkap dalam 74% kasus;
• VPN terowongan hampir tidak terlihat oleh model (6,1%): melalui terowongan dengan situs, tumpukan perangkat Anda sendiri yang terlihat.

Yang paling jelas ditunjukkan oleh OS adalah urutan opsi TCP: dalam analisis faktor proyek ini, bidang ini menebak OS dalam 99,1% kasus. Bendera DF hampir tidak berguna (0,362). Ini adalah alat terbuka dari satu peneliti, detail dari anti-bot komersial tidak dipublikasikan, tetapi prinsipnya sama: membandingkan OS dari SYN dengan OS dari User-Agent.

Bagaimana memeriksa proxy Anda: langkah demi langkah

1. Ambil "standar" tanpa proxy. Buka di browser biasa browserleaks.com/tcp. Catat TTL, MSS, urutan opsi, tebakan p0f, dan penilaian Zardaxt berdasarkan OS. Ini adalah tumpukan nyata Anda.
2. Periksa proxy dari konsol. Lakukan permintaan melalui proxy ke pengklasifikasi terbuka:
   curl -x http://LOGIN:PASS@HOST:PORT "https://tcpip.incolumitas.com/classify?by_ip=1"
   Dalam balasan, akan ada bidang avg_score_os_class dengan skor untuk Linux, Windows, Mac OS, dan iOS. Pemenangnya di sini adalah OS dari node keluar proxy, bukan komputer Anda.
3. Ulangi di profil anti-detect. Buka browserleaks.com/tcp atau proxydetect.live/tcpip.html sudah dalam profil dengan proxy. Sekarang bandingkan dua hal: OS dari TCP/IP dan OS dari User-Agent profil.
4. Lihat pada MSS. Jalur Ethernet bersih memberikan MSS 1460. Nilai seperti 1380 (WireGuard), 1360 (IPsec) atau 1240 menunjukkan terowongan dalam perjalanan. Ini sendiri bukan larangan, jaringan seluler juga sering memberikan MSS yang lebih kecil, tetapi dalam kombinasi dengan tanda-tanda lain menambah kecurigaan.
5. Lakukan 5–10 pengukuran pada rotasi. Pada proxy residensial dan seluler, setiap IP baru bisa menjadi perangkat lain dengan OS yang berbeda. Satu pengukuran tidak memberikan informasi yang cukup, lihat distribusinya.
6. Susun dalam tabel: tipe proxy → OS berdasarkan TCP → OS profil → kecocokan ya/tidak. Ini adalah jawaban tentang profil mana yang harus dijalankan pada proxy mana.

Satu TTL sebagai bukti tidak cukup: nilai yang terlihat berkurang di setiap router, dan situs hanya menilai yang awal (64 atau 128) berdasarkan pangkat terdekat. Kombinasi bidang, terutama urutan opsi, yang menentukan.

Apa yang harus dilakukan jika terjadi ketidakcocokan

1. Sesuaikan profil dengan proxy, bukan sebaliknya

Cara termurah: pilih OS profil sehingga sesuai dengan apa yang ditunjukkan oleh node keluar. Jika proxy memberikan Linux, lebih jujur untuk menjalankan profil Linux daripada membuktikan kepada situs bahwa Anda menggunakan Windows. Untuk tugas di mana OS profil tidak penting (pengambilan halaman publik, pemantauan harga), ini sepenuhnya menyelesaikan masalah.

2. Pilih tipe proxy sesuai dengan OS yang dibutuhkan

• Proxy pusat data hampir selalu menunjukkan server Linux dari ASN cloud. Ini normal untuk pengambilan data dari klien Linux (Python, Go, curl di server): tumpukan dan User-Agent skrip Anda selaras. Untuk profil "pengguna Windows", ini adalah titik lemah. Ambil proxy pusat data di tempat yang penting untuk kecepatan dan harga per gigabyte, bukan legenda "manusia hidup".
• Proxy residensial keluar melalui perangkat rumah nyata dan gateway, sehingga situs melihat tumpukan dari node pengguna yang sebenarnya. OS pada IP tertentu tidak dijamin sebelumnya, tetapi ini adalah tumpukan perangkat hidup, bukan server cloud. Untuk multi-akun dan anti-bot yang kompleks, proxy residensial memberikan gambaran yang paling alami, jika memeriksa distribusi OS pada rotasi.
• Proxy seluler menunjukkan jalur yang mirip dengan Android atau iOS. Untuk profil seluler (media sosial, aplikasi, versi seluler situs), ini adalah kecocokan yang sempurna di semua lapisan. Untuk informasi lebih lanjut tentang cara membedakan IP seluler yang asli dari yang palsu, baca panduan kami tentang memeriksa proxy seluler. Untuk tugas semacam itu, proxy 4G/5G seluler sangat cocok.

3. Jangan bingungkan lapisan TCP dengan lapisan TLS

Alat seperti curl-impersonate atau curl_cffi memalsukan handshake TLS dan HTTP/2 di bawah Chrome, tetapi tidak menyentuh tumpukan TCP: SYN masih dikumpulkan oleh kernel mesin dari mana koneksi berasal. Sidik jari TLS yang baik di atas TCP yang kontradiktif tidak menyelamatkan, kedua lapisan diperlukan. Cara menyelaraskan bagian TLS telah dibahas dalam artikel tentang menghindari JA4 melalui curl_cffi.

4. Penggantian OS di sisi proxy dan terowongan

Penyedia mulai menjual penggantian sidik jari TCP/IP di server mereka, contoh Byteful di atas, tetapi ini masih jarang dan dalam versi beta. Ada juga jalan sebaliknya: VPN terowongan model Zardaxt hampir tidak tertangkap sebagai relay, karena situs melihat tumpukan Anda sendiri. Kekurangan juga diketahui: MSS yang berkurang menunjukkan terowongan, dan IP dari VPN sering terdaftar dalam basis data sebagai hosting.

Kesalahan umum

• Memeriksa hanya dengan pemeriksa IP. Layanan reputasi IP melihat alamat dan ASN, bukan SYN. IP bersih dengan tumpukan Linux di bawah profil Windows lolos dari pemeriksa dan gagal di anti-bot.
• Membuat kesimpulan berdasarkan satu pengukuran pada rotasi. Pada kumpulan residensial, IP berikutnya bisa menjadi OS yang berbeda.
• Memperbaiki dengan header. Tidak ada header yang dapat menulis ulang SYN setelah kernel mengirimkannya.
• Mengabaikan profil Android di proxy Linux. Untuk model terbuka, ini adalah zona ketidakpastian (74% penangkapan), tetapi anti-bot komersial dapat menambahkan sinyal lain, seperti waktu dan ASN seluler. Profil seluler terlihat lebih alami pada IP seluler.

Kesimpulan

Sidik jari TCP/IP adalah lapisan yang tidak dapat diperbaiki dari browser: itu ditentukan oleh mesin yang membuka koneksi ke situs. Pemeriksaan memakan waktu lima menit: browserleaks.com/tcp tanpa proxy dan dengan proxy, ditambah curl ke pengklasifikasi terbuka. Selanjutnya, aturan sederhana: OS profil harus cocok dengan OS dari node keluar. Pusat data cocok untuk skrip Linux, proxy residensial untuk profil desktop "hidup", dan proxy seluler untuk skenario seluler. Pilih tipe proxy yang sesuai dengan profil Anda, lakukan 5–10 pengukuran pada rotasi, dan anti-bot akan kehilangan salah satu petunjuk yang paling andal.