Situasi klasik: skrip untuk memantau harga di Wildberries atau Ozon berfungsi dengan baik di laptop rumah, tetapi setelah dipindahkan ke VPS mulai mendapatkan 403, captcha, atau pemblokiran instan berdasarkan IP. Pengembang mengubah header, menambahkan jeda — tetapi hasilnya tidak berubah. Masalahnya hampir tidak pernah terletak pada kode parser itu sendiri, tetapi pada lingkungan dari mana ia membuat permintaan. Kami membahas 7 alasan konkret dan apa yang perlu diubah agar parser berfungsi secara stabil di server.
Mengapa semuanya berfungsi secara lokal, tetapi di server — diblokir
Ketika Anda menjalankan parser dari komputer rumah, situs melihat permintaan dari alamat IP rumah biasa dari penyedia Anda, dari wilayah yang familiar, dengan lingkungan browser yang nyata, jika Anda menggunakan Selenium atau Playwright dengan profil yang sebenarnya. Begitu skrip yang sama dipindahkan ke VPS di Jerman, Belanda, atau AS, gambaran berubah sepenuhnya: IP milik data center, fingerprint TLS mungkin berbeda karena versi pustaka yang berbeda, zona waktu server tidak cocok dengan geolokasi IP, dan frekuensi permintaan meningkat tajam, karena server beroperasi 24/7 tanpa jeda.
Sistem anti-bot Wildberries, Ozon, Avito, dan sebagian besar marketplace besar tidak lagi hanya melihat User-Agent. Mereka menganalisis kombinasi puluhan sinyal: jenis IP, kecepatan dan regularitas permintaan, perilaku di halaman, kesesuaian header dan parameter TLS, keberadaan cookies, dan riwayat sesi. Mesin lokal secara acak melewati pemeriksaan di sebagian besar poin, server — hampir semuanya gagal. Di bawah ini adalah analisis mendetail dari setiap alasan.
Alasan 1: IP data center daripada IP rumah
Ini adalah alasan nomor 1 dalam 80% kasus. Alamat IP VPS dan server cloud (AWS, DigitalOcean, Hetzner, hosting VDS biasa) berada dalam basis data data center — ASN penyedia ini diketahui secara publik dan digunakan oleh sistem anti-bot untuk penyaringan lalu lintas instan. Marketplace menggunakan daftar semacam itu sebagai prioritas, karena 95% pengambilan data otomatis berasal dari IP server.
Solusinya adalah menggunakan IP yang secara visual tidak berbeda dari pengguna internet biasa. Untuk pengambilan data Wildberries, Ozon, dan Avito, proxy residensial adalah yang paling cocok: ini adalah alamat IP nyata dari penyedia rumah, yang diberikan kepada pelanggan biasa. Sistem anti-bot melihat permintaan semacam itu sebagai lalu lintas dari pengguna nyata, bukan dari server di data center, yang menghilangkan sebagian besar pemblokiran secara langsung.
Alasan 2: Tidak ada rotasi IP dan batas frekuensi permintaan
Di mesin lokal, Anda melakukan 20–50 permintaan secara manual selama pengujian, dan situs tidak menyadarinya. Di server, skrip dijalankan melalui cron setiap 5 menit dan memproses ribuan kartu produk berturut-turut dari satu IP. Pola semacam itu adalah sinyal langsung untuk sistem anti-bot: orang nyata tidak dapat membuka 3000 halaman katalog dalam satu jam tanpa jeda sama sekali.
Anda perlu menerapkan rotasi IP pada kumpulan proxy dan membatasi jumlah permintaan ke satu alamat dalam satu waktu. Aturan praktis: tidak lebih dari 30–60 permintaan dari satu IP per menit untuk kartu produk, dengan penggantian alamat otomatis setelah setiap batch permintaan. Contoh pengaturan rotasi dalam Python melalui kumpulan proxy:
import requests
proxies_pool = [
"http://user:[email protected]:9000",
"http://user:[email protected]:9001",
"http://user:[email protected]:9002",
]
def get_page(url, session_id):
proxy = proxies_pool[session_id % len(proxies_pool)]
resp = requests.get(
url,
proxies={"http": proxy, "https": proxy},
headers={"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"},
timeout=10
)
return resp.textSaat mengumpulkan volume besar kartu produk dalam sehari, lebih nyaman menggunakan proxy dengan rotasi IP otomatis berdasarkan permintaan atau berdasarkan timer — ini menghilangkan kebutuhan untuk menjaga daftar alamat secara manual.
Alasan 3: Header dan User-Agent tidak mirip dengan browser
Banyak parser menggunakan requests atau aiohttp mengirimkan permintaan dengan set header minimal atau dengan User-Agent standar pustaka, yang segera menunjukkan skrip (misalnya python-requests/2.31.0). Di mesin lokal melalui browser, set header lengkap: Accept, Accept-Language, Accept-Encoding, Sec-Ch-Ua, Referer, dan lainnya — kombinasi ini terlihat alami.
Anda perlu menyalin set lengkap header dari browser nyata, termasuk urutan pengirimannya — beberapa sistem anti-bot bahkan memeriksa ini. Selain itu, penting untuk merotasi User-Agent secara bersamaan dengan versi fingerprint TLS (lihat poin berikut), jika tidak, ketidaksesuaian antara header browser dan klien TLS yang sebenarnya akan menjadi sinyal baru dari bot.
Alasan 4: TLS/JA3 fingerprint menunjukkan skrip
Ini adalah alasan yang kurang dikenal, tetapi sangat umum untuk pemblokiran di server. Pustaka requests, urllib, aiohttp menggunakan implementasi TLS handshake mereka sendiri, yang berbeda dari implementasi di Chrome atau Firefox. Sistem anti-bot menghitung JA3/JA4 fingerprint dari koneksi TLS — dan itu di skrip python sama sekali tidak mirip dengan fingerprint dari browser nyata, bahkan jika header disalin dengan sempurna.
Solusinya adalah menggunakan pustaka yang meniru fingerprint TLS dari browser (misalnya curl_cffi, tls-client di Python, atau browser headless penuh berbasis Chromium melalui Playwright/Puppeteer). Opsi kedua — bekerja tidak melalui klien HTTP bersih, tetapi melalui mesin browser yang dikelola dalam kombinasi dengan alat anti-deteksi, di mana TLS dan header dibentuk oleh inti browser yang nyata, bukan oleh emulasi pustaka.
Alasan 5: Zona waktu, lokal, dan DNS server
Jika skrip meniru browser melalui Selenium atau Playwright, sistem anti-bot dapat memeriksa zona waktu sistem, bahasa antarmuka, DNS resolver, dan bahkan kebocoran WebRTC dari IP server yang sebenarnya. VPS di data center Frankfurt dengan zona waktu sistem UTC dan penyedia DNS dari host, sambil menggunakan proxy dengan IP dari Moskow, menciptakan ketidaksesuaian geodata yang jelas — ini adalah salah satu sinyal paling dapat diandalkan untuk deteksi.
Semua parameter lingkungan — zona waktu, bahasa browser, DNS, geolokasi melalui WebRTC — harus sesuai dengan wilayah alamat IP yang digunakan untuk permintaan. Untuk menyelesaikan tugas ini, browser anti-deteksi telah dibuat: Dolphin Anty, AdsPower, Multilogin, Octo Browser, dan GoLogin memungkinkan Anda untuk mengatur "profil browser" terpisah untuk setiap proxy, di mana zona waktu, lokal, resolusi layar, dan WebRTC secara otomatis disesuaikan dengan geolokasi IP.
Alasan 6: Pola permintaan terlalu "robotik"
Manusia menggulir katalog dengan jeda yang berbeda, mengklik produk secara acak, kadang-kadang kembali, menggulir halaman secara tidak merata. Skrip server biasanya membuat permintaan melalui interval yang sama (misalnya tepat setiap 2 detik) dan hanya mengakses URL yang diperlukan tanpa "kebisingan" di sekitarnya — tanpa memuat gambar, skrip, tanpa mengunjungi halaman utama sebelum kartu produk.
Apa yang perlu diubah: tambahkan jeda acak (bukan 2 detik tetap, tetapi acak dari 1.5 hingga 6 detik), sesekali mengunjungi halaman perantara (kategori → kartu, bukan permintaan langsung ke API), meniru scroll dan gerakan mouse saat bekerja melalui browser headless. Ini meningkatkan waktu pengumpulan data, tetapi secara drastis mengurangi jumlah pemblokiran.
Alasan 7: Sesi dan cookies tidak disimpan antara permintaan
Seringkali parser di server membuat sesi requests baru untuk setiap permintaan — tanpa cookies, tanpa token otorisasi yang disimpan, tanpa riwayat kunjungan. Marketplace seperti Wildberries dan Ozon mengeluarkan cookies sementara dan token pada kunjungan pertama, dan permintaan selanjutnya tanpa mereka terlihat mencurigakan, seolah-olah setiap permintaan dilakukan oleh pengunjung anonim baru.
Skema yang benar: satu sesi (requests.Session() atau konteks browser) — untuk satu IP dari kumpulan proxy, dengan menyimpan cookies sepanjang serangkaian permintaan ke IP ini. Saat mengganti proxy, Anda perlu memulai sesi baru dengan cookies bersih, meniru pengguna baru, bukan melanjutkan menggunakan cookies lama dengan IP baru — ini juga menciptakan ketidaksesuaian dan memicu pemblokiran.
Checklist: apa yang perlu diubah secara berurutan
Jika parser terus-menerus diblokir di server, tetapi berfungsi secara lokal, periksa perubahan dalam urutan ini — sehingga Anda dapat lebih cepat menemukan penyebabnya:
| Langkah | Apa yang perlu diperiksa | Apa yang perlu diubah |
|---|---|---|
| 1 | Jenis IP server | Berpindah ke proxy residensial daripada IP langsung dari hosting |
| 2 | Frekuensi permintaan | Terapkan rotasi IP dan batas permintaan ke alamat |
| 3 | Header permintaan | Salin set lengkap header dari browser nyata |
| 4 | Fingerprint TLS | Gunakan curl_cffi / browser headless daripada requests bersih |
| 5 | Zona waktu dan lokal | Atur profil di Dolphin Anty / AdsPower untuk wilayah IP |
| 6 | Pola perilaku | Acak jeda, tambahkan halaman perantara |
| 7 | Sesi dan cookies | Mengaitkan satu sesi ke satu IP untuk seluruh siklus permintaan |
Untuk pengambilan data katalog Wildberries dan Ozon yang sering, di mana kecepatan menjelajahi ribuan halaman sangat penting, sering kali menggabungkan dua jenis proxy: proxy data center untuk permintaan teknis kasar (memeriksa ketersediaan, kode status) dan residensial — untuk pengumpulan data akhir dari kartu produk, di mana penyamaran sebagai pengguna nyata sangat penting. Untuk aplikasi mobile marketplace dan Avito, terkadang lebih efektif menggunakan proxy mobile, karena mereka lebih jarang masuk dalam daftar pemblokiran otomatis berdasarkan ASN.
Kesimpulan
Pemblokiran parser di server saat versi lokal berfungsi hampir selalu terkait dengan lingkungan: jenis IP, fingerprint TLS, header, zona waktu, pola permintaan, dan pengelolaan sesi. Dengan memeriksa setiap dari 7 alasan secara berurutan — dari yang paling umum (IP data center) hingga yang paling tidak terlihat (ketidaksesuaian zona waktu dan wilayah IP) — Anda dapat memulihkan operasi stabil parser tanpa mengubah logika bisnis utama pengumpulan data.
Jika Anda mengumpulkan harga dan stok di Wildberries, Ozon, atau Avito dalam volume besar, mulailah dengan mengganti IP: coba proxy residensial daripada alamat VPS standar — dalam banyak kasus ini menghilangkan hingga 70% pemblokiran bahkan sebelum Anda mulai mengatur header dan fingerprint TLS.