Kesalahan 429 saat Mengambil Data Wildberries dan Ozon: 6 Penyebab yang Tidak Teratasi dengan Mengganti Proxy

Anda mengganti proxy, membeli kumpulan alamat IP baru, tetapi parser tetap gagal dengan kesalahan 429 Too Many Requests? Ini adalah situasi klasik: 70% kasus pemblokiran tidak terkait dengan alamat IP, tetapi dengan bagaimana permintaan itu sendiri terlihat. Kami membahas enam penyebab nyata mengapa situs terus memblokir Anda bahkan setelah mengganti proxy — dan apa yang harus dilakukan di setiap kasus.

Apa arti kesalahan 429 dan mengapa proxy bukanlah solusi ajaib

Kode HTTP 429 Too Many Requests secara formal berarti "batas permintaan terlampaui". Namun dalam praktiknya, situs — terutama Wildberries, Ozon, Avito, Yandex.Market — menggunakan kode ini sebagai sinyal universal "kami menganggap Anda bot". Penyebabnya bisa jadi frekuensi permintaan, tetapi dengan kemungkinan yang sama — di header, jejak browser, tidak adanya sesi cookie, atau batasan yang tidak terkait dengan IP, tetapi dengan akun Anda.

Itulah sebabnya mengganti proxy sering kali tidak membantu: jika sistem memblokir bukan berdasarkan IP, tetapi pola permintaan (fingerprint, header, kecepatan klik), maka dari alamat IP baru Anda akan mendapatkan 429 yang sama dalam beberapa menit. Mari kita bahas setiap penyebab secara rinci dan tunjukkan cara memeriksa dan mengatasinya tanpa membeli kumpulan proxy baru.

Penting: proxy tetap menjadi alat yang diperlukan — tetapi hanya sebagai bagian dari sistem, bukan sebagai satu-satunya solusi. IP residensial dan seluler mengurangi kemungkinan masuk dalam daftar hitam berdasarkan reputasi IP, tetapi tidak menyelamatkan dari pemblokiran berdasarkan perilaku atau header.

Penyebab 1: Frekuensi permintaan terlalu tinggi

Ini adalah penyebab yang paling jelas, tetapi juga yang paling sering salah didiagnosis. Banyak yang berpikir: "karena saya mengganti proxy untuk setiap permintaan — frekuensi tidak penting". Ini salah. Sistem anti-bot modern (misalnya, Wildberries dan Ozon menggunakan solusi tingkat Cloudflare atau WAF mereka sendiri) menganalisis tidak hanya frekuensi dari satu IP, tetapi juga beban total pada endpoint API tertentu atau halaman produk dalam satuan waktu dari semua sumber, bersamaan dengan sinyal perilaku.

Jika parser Anda melakukan 50-100 permintaan per detik ke bagian katalog yang sama, sistem melihat lonjakan lalu lintas yang tidak normal terlepas dari berapa banyak IP berbeda yang Anda gunakan. Solusinya bukan mengganti proxy, tetapi menerapkan penundaan buatan (throttling) antara permintaan: 1-3 detik penundaan acak alih-alih interval tetap, ditambah exponential backoff saat menerima 429 (meningkatkan jeda dua kali lipat setelah setiap pemblokiran).

import time, random

def safe_request(session, url):
    for attempt in range(5):
        response = session.get(url)
        if response.status_code == 429:
            wait = (2 ** attempt) + random.uniform(0, 1)
            time.sleep(wait)
            continue
        return response
    return None

Jika Anda menggunakan parser siap pakai tanpa kode (misalnya, layanan pemantauan harga berbasis cloud), periksa pengaturan interval antara permintaan — sebagian besar alat semacam itu memiliki slider "kecepatan pemindaian". Mengurangi kecepatan sebesar 30-40% sering kali menghilangkan 429 sepenuhnya, bahkan tanpa mengubah proxy.

Penyebab 2: Header yang salah atau hilang

Banyak parser mengirimkan permintaan dengan set header minimal atau menggunakan User-Agent dari pustaka default (misalnya, "python-requests/2.28.1"). Header semacam itu segera mengungkapkan bot — browser nyata mengirimkan puluhan header: Accept, Accept-Language, Accept-Encoding, Sec-Fetch-*, Referer, dan lainnya dalam urutan yang sangat spesifik.

Wildberries dan Ozon mencocokkan set header dengan "fingerprint" yang diharapkan dari browser nyata seperti Chrome atau Safari. Jika header terlalu sedikit, tidak dalam urutan yang benar, atau User-Agent tidak sesuai dengan parameter lainnya (misalnya, dinyatakan Chrome di Windows, tetapi jejak TLS mirip dengan Python) — permintaan diblokir dengan 429 terlepas dari IP.

Header	Kesalahan umum	Solusi
User-Agent	Versi usang atau jelas merupakan string pustaka	UA terkini dari Chrome/Safari nyata, rotasi dari kumpulan
Accept-Language	Hilang atau tidak sesuai dengan geolokasi IP	ru-RU untuk marketplace Rusia
Referer	Kosong, meskipun transisi nyata selalu dengan Referer	Sebutkan halaman katalog sebelumnya
Sec-Fetch-*	Sepenuhnya hilang (bukan klien browser)	Salin set lengkap dari DevTools browser nyata

Cara termudah adalah menyalin set lengkap header dari tab Jaringan di DevTools browser nyata, membuka halaman yang diperlukan secara manual, dan menggunakan set ini di parser — dengan memperhatikan urutan header, jika pustaka memungkinkan (misalnya, curl_cffi atau httpx dengan urutan yang jelas).

Penyebab 3: Tidak adanya rotasi sesi dan cookies

Kesalahan yang sering terlewat: parser mengganti IP untuk setiap permintaan, tetapi menggunakan sesi cookie yang sama atau tidak menyimpan cookies sama sekali. Pengguna nyata mendapatkan set cookie (token sesi, ID perangkat, label perlindungan antibot seperti Cloudflare __cf_bm atau yang serupa di Ozon/WB) pada kunjungan pertama dan menggunakannya di semua permintaan berikutnya dalam sesi.

Jika Anda mengirim permintaan tanpa cookies yang diperoleh di halaman "hangat", sistem anti-bot melihat sesi "nol" — dan ini segera mencurigakan, terutama saat mengakses endpoint API secara langsung, melewati halaman utama. Solusinya adalah meniru skenario lengkap: pertama-tama memuat halaman utama atau halaman kategori, mendapatkan cookies, menunggu 1-2 detik, dan hanya kemudian mengakses API yang diperlukan atau kartu produk, menyimpan cookies dalam sesi yang sama sepanjang rantai permintaan.

import requests

session = requests.Session()
session.headers.update({
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)...",
    "Accept-Language": "ru-RU,ru;q=0.9"
})

# Memanaskan sesi
session.get("https://www.wildberries.ru/catalog/0/search.aspx")
time.sleep(1.5)

# Permintaan utama sudah dengan cookies
response = session.get(target_url)

Jika Anda menggunakan browser anti-deteksi seperti Dolphin Anty atau AdsPower untuk memantau kartu produk secara manual atau melalui otomatisasi terintegrasi, pastikan profil menyimpan cookies antar sesi dan tidak dimulai setiap kali "dari awal" — ini juga memicu kecurigaan sistem.

Penyebab 4: Perilaku yang mirip bot

Bahkan dengan header dan cookies yang sempurna, parser dapat mengungkapkan dirinya melalui pola perilaku: urutan akses produk yang sangat linier (berdasarkan ID yang meningkat), interval yang sama antara permintaan hingga milidetik, tidak adanya permintaan "sampah" pada statis (gambar, CSS, JS), yang biasanya dimuat otomatis oleh browser biasa.

Sistem perlindungan canggih Wildberries dan Ozon menganalisis tidak hanya permintaan HTTP, tetapi juga apakah JavaScript telah dijalankan di halaman (melalui deteksi headless), apakah "mouse" bergerak, apakah ada scroll. Jika Anda melakukan permintaan HTTP bersih tanpa rendering JS, dan situs mengharapkan eksekusi skrip untuk mendapatkan token (misalnya, tantangan javascript-antibot), permintaan tanpa eksekusi skrip ini otomatis mendapatkan 429 atau 403.

Solusinya tergantung pada skala: untuk volume kecil, penggunaan browser headless (Playwright, Puppeteer) dengan simulasi gerakan mouse dan penundaan acak cocok. Untuk parsing industri — randomisasi urutan penelusuran produk, penambahan "noise" dalam bentuk permintaan ke sumber daya sekunder, variasi interval waktu berdasarkan distribusi normal, bukan langkah tetap.

Penyebab 5: Jejak TLS/JA3 dan HTTP/2

Ini adalah penyebab teknis yang paling "tidak terlihat", yang tidak diketahui 90% orang yang melakukan parsing tanpa pelatihan teknis yang mendalam. Setiap klien TLS (pustaka requests, curl, urllib) meninggalkan jejak unik saat membangun koneksi HTTPS — set cipher yang didukung, versi protokol, ekstensi TLS. Jejak ini disebut jejak JA3/JA4.

Sistem anti-bot tingkat Cloudflare, Akamai, dan solusi internal dari marketplace besar mencocokkan jejak JA3 dengan basis data bot dan pustaka yang dikenal. Python requests standar atau modul https Node.js memiliki jejak yang mudah terdeteksi, yang sepenuhnya berbeda dari jejak Chrome yang nyata. Bahkan dengan header dan cookies yang sempurna, permintaan diblokir pada tingkat TLS-handshake, sebelum server melihat header HTTP.

Selain itu, banyak marketplace memerlukan HTTP/2 dengan parameter tertentu (urutan frame SETTINGS, prioritas aliran) — pustaka berbasis HTTP/1.1 secara otomatis terdeteksi di latar belakang ini. Solusinya adalah menggunakan pustaka yang meniru jejak browser nyata: curl_cffi (meniru jejak TLS Chrome), tls-client, atau browser headless lengkap berbasis Chromium, yang memberikan jejak "nyata" berdasarkan definisi.

Penyebab 6: Batasan pada tingkat akun atau kunci API

Jika Anda bekerja melalui API resmi atau semi-resmi dari marketplace (misalnya, API penjual Wildberries atau Ozon Seller API), 429 mungkin terkait bukan dengan IP, tetapi dengan akun penjual itu sendiri atau token API. Dalam hal ini, mengganti proxy sama sekali tidak berguna — batasan disimpan di sisi server terkait dengan identifikasi akun Anda, dan IP mana pun dari akun tersebut akan mendapatkan batasan yang sama.

Situasi ini umum bagi penjual yang secara bersamaan memantau harga pesaing melalui akun pribadi dan menarik API untuk mengunduh sisa — kedua aliran permintaan dijumlahkan dalam batasan umum akun. Solusinya adalah menyebarkan beban berdasarkan waktu, menggunakan kuota API resmi dengan lebih hemat (meng-cache data yang tidak berubah setiap menit), dan untuk pemantauan harga pesaing yang bersih, menggunakan aliran permintaan terpisah yang tidak terikat pada akun penjual.

Memeriksa ini sangat mudah: jika 429 terus berlanjut bahkan saat mengakses dari IP baru yang bersih dan tanpa satu pun cookie dari sesi sebelumnya, tetapi Anda sudah login di akun pribadi di tab sebelah — kemungkinan besar, batasan tersebut adalah batasan akun.

Cara mendiagnosis penyebab sebenarnya

Sebelum mengganti infrastruktur, lakukan diagnosis berdasarkan algoritma berikut. Pertama, buka halaman secara manual di browser biasa dan pastikan bahwa 429 tidak muncul saat perilaku nyata — ini akan mengonfirmasi bahwa masalah ada di sisi parser, bukan pemblokiran global di wilayah tersebut.

Kemudian bandingkan header parser Anda dengan header browser nyata melalui DevTools (tab Jaringan → Salin sebagai cURL). Jika perbedaannya minimal, periksa jejak TLS melalui layanan seperti tls.peet.ws — kirim permintaan menggunakan pustaka Anda dan bandingkan hash JA3 dengan browser referensi. Jika permintaan gagal pada tahap TLS-handshake (koneksi terputus sebelum menerima respons HTTP) — penyebabnya ada di fingerprint, bukan di frekuensi atau header.

Selanjutnya, periksa apakah batasan terkait dengan IP atau akun: lakukan permintaan dari IP baru yang bersih tanpa otorisasi. Jika 429 menghilang — masalahnya ada di reputasi IP sebelumnya atau di frekuensi dari alamat tersebut. Jika 429 tetap ada — cari penyebabnya di header, TLS, atau perilaku, bukan di proxy.

Checklist mengatasi 429 tanpa mengganti proxy

1. Tambahkan penundaan acak 1-4 detik antara permintaan alih-alih interval tetap.
2. Salin set lengkap header dari browser nyata, termasuk Sec-Fetch-* dan Accept-Language.
3. Simpan dan kirim cookies dalam satu sesi, mulai dari memanaskan halaman utama.
4. Periksa jejak TLS pustaka Anda — gunakan curl_cffi atau browser headless alih-alih klien HTTP bersih.
5. Randomisasikan urutan penelusuran halaman dan tambahkan permintaan "noise" ke sumber daya statis.
6. Pisahkan beban akun API dan pemantauan harga anonim ke aliran yang berbeda.
7. Implementasikan exponential backoff saat menerima 429, bukan pengulangan permintaan instan.
8. Hanya setelah memeriksa semua poin di atas — ganti proxy atau perluas kumpulan IP.

Kapan proxy tetap diperlukan dan yang mana yang harus dipilih

Setelah mengatasi semua enam penyebab, proxy tetap menjadi elemen penting dari infrastruktur — tetapi sekarang sebagai alat untuk penskalaan, bukan satu-satunya cara untuk melawan pemblokiran. Jika tugas Anda adalah memantau ribuan kartu Wildberries dan Ozon secara paralel dari berbagai "pengguna virtual", Anda memerlukan kumpulan IP dengan reputasi baik agar tidak mengumpulkan riwayat pemblokiran di satu alamat.

Untuk pemantauan harga dan katalog marketplace secara massal, proxy residensial adalah yang paling cocok — mereka menggunakan IP nyata dari penyedia rumah, sehingga sistem anti-bot menganggap permintaan sebagai lalu lintas pembeli biasa, bukan dari pusat data. Ini sangat penting, karena Wildberries dan Ozon telah lama menyimpan daftar hitam untuk rentang IP pusat data.

Jika tugas terkait dengan memeriksa versi seluler situs, bekerja melalui aplikasi marketplace, atau menguji iklan di TikTok Ads dan Facebook Ads dengan akurasi geografis hingga kota, proxy seluler relevan — mereka memiliki tingkat kepercayaan tertinggi di sebagian besar sistem perlindungan, karena IP dimiliki oleh operator seluler nyata.

Untuk tugas yang kurang sensitif — misalnya, parsing katalog terbuka tanpa otorisasi dalam volume kecil — Anda dapat menggunakan proxy pusat data: mereka jauh lebih murah dan lebih cepat, tetapi memerlukan pengaturan header dan jejak TLS yang lebih cermat, karena mereka sendiri membawa risiko lebih tinggi untuk dicurigai.

Jenis proxy	Kapan menyelesaikan 429	Kapan tidak membantu
Residen	IP sudah dalam daftar hitam karena reputasi	Pemblokiran berdasarkan jejak TLS atau header
Seluler	Diperlukan kepercayaan maksimum IP untuk skenario sensitif	Batasan terkait dengan akun, bukan dengan IP
Pusat data	Parsing sederhana halaman terbuka tanpa otorisasi	Sistem anti-bot yang ketat dengan pemeriksaan reputasi rentang

Kesimpulan

Kesalahan 429 saat parsing jarang diselesaikan dengan satu tombol "ganti proxy". Dalam banyak kasus, masalah terletak pada frekuensi permintaan, header yang tidak lengkap, tidak adanya sesi cookie, jejak TLS yang terdeteksi, pola perilaku, atau batasan yang terkait dengan akun, bukan dengan alamat IP. Lakukan diagnosis pada setiap enam poin dari artikel ini sebelum menghabiskan anggaran untuk memperluas kumpulan proxy.

Ketika bagian teknis diatur dengan benar — header sesuai dengan browser nyata, jejak TLS tidak mengungkapkan pustaka, dan permintaan meniru perilaku alami pengguna — proxy menjadi alat yang benar-benar efektif untuk penskalaan. Untuk pemantauan harga di Wildberries dan Ozon dalam volume industri, kami merekomendasikan untuk memulai dengan proxy residensial: mereka memberikan keseimbangan terbaik antara biaya dan tingkat kepercayaan sistem anti-bot.