Jika Anda terlibat dalam parsing marketplace, pemantauan harga pesaing, atau otomatisasi kerja dengan media sosial, Anda pasti pernah menghadapi kesalahan 429 Terlalu Banyak Permintaan. Situs web memblokir permintaan Anda, menganggapnya mencurigakan, dan semua otomatisasi terhenti. Dalam artikel ini, kita akan membahas mengapa masalah ini muncul dan bagaimana cara menyelesaikannya melalui pengaturan proxy yang benar, rotasi IP, dan distribusi beban yang tepat.
Kami akan menunjukkan solusi konkret untuk berbagai tugas: parsing Wildberries dan Ozon, pemantauan pesaing, bekerja dengan API media sosial, pengumpulan data massal. Semua rekomendasi didasarkan pada pengalaman praktis dan bekerja dalam proyek nyata.
Apa itu kesalahan 429 Terlalu Banyak Permintaan dan mengapa itu terjadi
Kesalahan 429 Terlalu Banyak Permintaan adalah kode respons HTTP yang dikembalikan server ketika Anda melebihi jumlah permintaan yang diizinkan dalam periode waktu tertentu. Ini adalah mekanisme perlindungan situs web dari kelebihan beban dan pengumpulan data otomatis.
Situasi umum ketika kesalahan 429 muncul:
- Parsing marketplace β Anda mengumpulkan harga dari Wildberries, Ozon, atau Avito, melakukan ratusan permintaan per menit. Situs melihat aktivitas anomali dari satu IP dan memblokirnya.
- Pemantauan pesaing β pengumpulan data otomatis tentang produk, harga, ketersediaan. Dengan pemeriksaan yang sering, batasan akan terpicu.
- Bekerja dengan API β banyak API memiliki batasan ketat: misalnya, Instagram API mengizinkan 200 permintaan per jam, Twitter β 300 permintaan dalam 15 menit.
- Pendaftaran massal atau tindakan β membuat akun, mengirim pesan, menyukai. Platform dengan cepat mendeteksi otomatisasi dan memblokir IP.
Penting untuk dipahami: kesalahan 429 bukan hanya batasan teknis. Ini adalah sinyal bahwa situs telah mengenali aktivitas Anda sebagai mencurigakan. Jika terus menyerang dari IP yang sama, Anda bisa mendapatkan larangan permanen.
Penting: Beberapa situs menggantikan 429 dengan 403 Forbidden atau hanya menampilkan CAPTCHA. Intinya sama β Anda telah melebihi batas dan diblokir.
Bagaimana situs web menentukan aktivitas mencurigakan
Untuk menghindari pemblokiran secara efektif, Anda perlu memahami bagaimana situs web menghitung Anda. Sistem perlindungan modern menganalisis banyak parameter:
1. Alamat IP dan frekuensi permintaan
Parameter yang paling jelas. Jika dari satu IP datang 100 permintaan per menit, sementara pengguna biasa melakukan 5-10 β ini adalah otomatisasi yang jelas. Situs web menetapkan batas:
- Wildberries: sekitar 60 permintaan per menit dari satu IP
- Ozon: sekitar 30-40 permintaan per menit
- Avito: batasan ketat, terutama untuk permintaan pencarian
- Instagram API: 200 permintaan per jam per aplikasi
2. User-Agent dan header browser
Jika Anda mengirim permintaan melalui skrip tanpa User-Agent yang benar, situs segera memahami bahwa ini bukan browser nyata. Header juga dianalisis: Accept, Accept-Language, Referer. Ketidakhadiran header ini atau nilai yang tidak biasa β bendera merah.
3. Pola perilaku
Pengguna nyata tidak melakukan permintaan dengan frekuensi sempurna setiap 2 detik. Mereka menggulir, mengklik, dan membuat jeda. Jika parser Anda bekerja seperti metronom β itu mencurigakan.
4. Jenis alamat IP
Banyak platform memiliki daftar hitam IP dari pusat data. Jika Anda menggunakan proxy murah dari AWS atau Google Cloud, kemungkinan pemblokiran lebih tinggi. IP residensial dari penyedia nyata menimbulkan lebih sedikit kecurigaan.
Rotasi proxy: cara utama untuk menghindari batasan
Solusi utama untuk masalah 429 adalah rotasi alamat IP. Alih-alih melakukan semua permintaan dari satu IP, Anda mendistribusikan beban antara banyak alamat. Setiap IP melakukan sejumlah kecil permintaan dan tidak melebihi batas.
Jenis rotasi proxy
| Jenis rotasi | Cara kerja | Kapan digunakan |
|---|---|---|
| Rotasi per permintaan | Setiap permintaan datang dari IP baru. Penyedia proxy mengganti alamat secara otomatis. | Parsing massal, ketika perlu mengumpulkan banyak data dengan cepat |
| Rotasi berdasarkan timer | IP berubah setiap 5-30 menit. Anda menggunakan satu alamat untuk serangkaian permintaan. | Bekerja dengan situs yang memerlukan sesi (keranjang, otorisasi) |
| Kumpulan proxy statis | Anda memiliki daftar 100-1000 IP. Skrip memilih alamat acak untuk setiap permintaan. | Ketika Anda memerlukan kontrol penuh atas rotasi dan distribusi beban |
Contoh praktis: parsing Wildberries
Misalkan, Anda perlu mem-parsing harga dari 10.000 produk. Wildberries memblokir setelah 60 permintaan per menit dari satu IP. Bagaimana cara menyelesaikannya:
- Gunakan rotasi per permintaan β setiap permintaan datang dari IP baru. Anda memerlukan sekitar 167 IP yang berbeda (10.000 permintaan / 60 per menit = 167 menit dengan satu IP, tetapi dengan rotasi Anda melakukan ini dalam 10-15 menit).
- Atur jeda β bahkan dengan rotasi, tidak disarankan untuk melakukan 1.000 permintaan per detik. Optimal: 5-10 permintaan per detik dengan IP yang berbeda.
- Tambahkan randomisasi β jeda harus acak: dari 0,5 hingga 2 detik antara permintaan.
Untuk tugas-tugas seperti ini, proxy residensial dengan rotasi otomatis sangat cocok β mereka memiliki kumpulan dari jutaan IP dan mengganti alamat untuk setiap permintaan tanpa keterlibatan Anda.
Pengaturan jeda antar permintaan
Bahkan dengan rotasi proxy, Anda tidak boleh membombardir situs dengan permintaan pada kecepatan maksimum. Sistem perlindungan modern menganalisis beban total pada server dan dapat memblokir seluruh rentang IP jika melihat aktivitas yang mirip DDoS.
Aturan pengaturan jeda
Aturan dasar: tiru pengguna nyata
- Jeda minimum: 0,5-1 detik antara permintaan
- Disarankan: 1-3 detik dengan variasi acak
- Untuk situs yang kompleks (marketplace, media sosial): 2-5 detik
- Gunakan jeda eksponensial saat terjadi kesalahan
Jeda eksponensial (exponential backoff)
Jika Anda tetap mendapatkan kesalahan 429, jangan terus menyerang situs. Gunakan strategi jeda eksponensial:
- Percobaan pertama gagal β tunggu 1 detik
- Percobaan kedua gagal β tunggu 2 detik
- Percobaan ketiga gagal β tunggu 4 detik
- Percobaan keempat gagal β tunggu 8 detik
- Dan seterusnya, hingga maksimum (misalnya, 60 detik)
Strategi ini memberi waktu kepada server untuk "mendingin" dan mengurangi kemungkinan larangan permanen. Banyak API (Google, Twitter) merekomendasikan pendekatan ini dalam dokumentasi mereka.
Contoh pengaturan untuk berbagai tugas
| Tugas | Jeda antara permintaan | Komentar |
|---|---|---|
| Parsing Wildberries | 1-3 detik | Dengan rotasi proxy, dapat dipercepat hingga 0,5-1 detik |
| Parsing Ozon | 2-4 detik | Ozon lebih sensitif terhadap otomatisasi |
| Instagram API | 18 detik | Batas 200 permintaan/jam = 1 permintaan setiap 18 detik |
| Parsing Google Search | 5-10 detik | Google cepat memblokir, perlu jeda panjang |
| Pemantauan Avito | 3-6 detik | Perlindungan ketat, terutama untuk pencarian |
User-Agent dan header: meniru browser nyata
Rotasi proxy dan jeda menyelesaikan masalah frekuensi permintaan, tetapi itu tidak cukup. Situs web menganalisis bagaimana Anda mengirim permintaan. Jika header terlihat mencurigakan β pemblokiran tidak dapat dihindari.
Header wajib untuk meniru browser
Set minimum header yang harus ada dalam setiap permintaan:
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
Cache-Control: max-age=0Rotasi User-Agent
Jangan gunakan User-Agent yang sama untuk semua permintaan. Buat daftar 10-20 versi browser yang relevan dan ganti secara acak:
- Chrome (Windows, macOS, Linux)
- Firefox (berbagai versi)
- Safari (macOS, iOS)
- Edge (Windows)
Kesalahan umum: Menggunakan User-Agent yang usang (misalnya, Chrome 90 pada tahun 2024) atau User-Agent mobile untuk situs desktop. Ini segera mengungkapkan otomatisasi.
Referer dan Origin
Banyak situs memeriksa dari mana permintaan berasal. Jika Anda mem-parsing halaman produk, header Referer harus berisi tautan ke katalog atau pencarian. Jika mem-parsing API β harus ada Origin yang benar.
Contoh untuk parsing Wildberries:
Referer: https://www.wildberries.ru/catalog/0/search.aspx?search=Π½ΠΎΡΡΠ±ΡΠΊ
Origin: https://www.wildberries.ruProxy mana yang dipilih untuk menghindari 429
Pemilihan jenis proxy sangat penting. Proxy murah dari pusat data sering kali sudah ada dalam daftar hitam, dan Anda akan mendapatkan 429 bahkan dengan frekuensi permintaan yang rendah.
Perbandingan jenis proxy untuk menghindari batasan
| Jenis proxy | Keuntungan | Kekurangan | Untuk tugas apa |
|---|---|---|---|
| Pusat data | Kecepatan tinggi, harga rendah | Sering diblokir, mudah terdeteksi | Situs sederhana tanpa perlindungan |
| Residensial | IP nyata dari penyedia, sulit terdeteksi, kumpulan alamat besar | Lebih mahal, kadang lebih lambat | Marketplace, media sosial, situs kompleks |
| Mobile | IP dari operator seluler, kepercayaan maksimum | Mahal, kumpulan terbatas | Instagram, TikTok, Facebook Ads |
Rekomendasi pemilihan
Untuk parsing marketplace (Wildberries, Ozon, Avito): Gunakan proxy residensial dengan rotasi per permintaan. Kumpulan harus besar β minimal 10.000 IP. Ini menjamin bahwa setiap IP melakukan sedikit permintaan dan tidak terkena batasan.
Untuk bekerja dengan API media sosial: Proxy mobile adalah pilihan optimal. Instagram dan TikTok lebih mempercayai IP dari operator seluler dibandingkan dengan residensial. Satu IP mobile dapat melayani 5-10 akun tanpa masalah.
Untuk pemantauan harga pesaing: Proxy residensial dengan rotasi berdasarkan timer (setiap 10-15 menit). Ini memungkinkan melakukan serangkaian permintaan dari satu IP, menjaga sesi, tetapi tetap tidak melebihi batasan.
Untuk tugas sederhana (parsing berita, blog): Proxy pusat data dapat digunakan jika situs tidak memiliki perlindungan serius. Tetapi bersiaplah untuk pemblokiran berkala.
Kasus nyata: parsing marketplace dan API
Kasus 1: Pemantauan harga di Wildberries (10.000 produk setiap hari)
Tugas: Penjual marketplace melacak harga pesaing pada 10.000 posisi. Data perlu dikumpulkan 2 kali sehari.
Masalah: Dengan menggunakan satu IP, saya mendapatkan larangan setelah 50-60 permintaan. Parsing 10.000 produk memakan waktu beberapa jam dengan pemblokiran yang konstan.
Solusi:
- Terhubung ke proxy residensial dengan kumpulan 50.000 IP dan rotasi per permintaan
- Atur jeda acak dari 0,5 hingga 2 detik antara permintaan
- Tambahkan rotasi User-Agent (20 variasi Chrome dan Firefox)
- Atur header Referer dan Accept yang benar
Hasil: Parsing 10.000 produk memakan waktu 15-20 menit tanpa satu pun pemblokiran. Setiap IP melakukan maksimum 1-2 permintaan, yang tidak mungkin terdeteksi sebagai otomatisasi.
Kasus 2: Otomatisasi Instagram (50 akun klien)
Tugas: Agensi SMM mengelola 50 akun klien di Instagram. Perlu mempublikasikan konten, menjawab komentar, mengumpulkan statistik.
Masalah: Instagram API memiliki batas 200 permintaan per jam per aplikasi. Saat bekerja dengan 50 akun, batasan habis dalam 10 menit.
Solusi:
- Membuat 10 aplikasi Instagram API yang berbeda (5 akun per aplikasi)
- Setiap aplikasi menggunakan proxy mobile terpisah
- Atur jeda 18 detik antara permintaan (200 permintaan/jam = 1 permintaan setiap 18 detik)
- Tambahkan jeda eksponensial saat menerima 429
Hasil: Semua 50 akun berfungsi dengan stabil. Kesalahan 429 terjadi sangat jarang (1-2 kali seminggu) dan ditangani secara otomatis melalui percobaan ulang.
Kasus 3: Parsing Avito (iklan di seluruh Rusia)
Tugas: Agregator properti mengumpulkan iklan dari Avito di semua kota Rusia untuk basis datanya.
Masalah: Avito memiliki salah satu perlindungan paling ketat di antara situs Rusia. Pemblokiran mulai terjadi setelah 10-15 permintaan bahkan dari berbagai IP pusat data.
Solusi:
- Pindah ke proxy residensial dengan keterikatan geografis (IP dari kota yang sama dengan parsing)
- Menambah jeda hingga 3-5 detik antara permintaan
- Gunakan browser headless (Puppeteer) alih-alih permintaan HTTP sederhana
- Meniru tindakan pengguna: menggulir, mengklik, gerakan mouse
Hasil: Parsing lebih dari 50.000 iklan per hari berhasil. Pemblokiran berkurang 95%. 5% yang tersisa ditangani melalui percobaan ulang dengan IP baru.
Kasus 4: Pemantauan API pesaing (e-commerce)
Tugas: Toko online melacak ketersediaan produk dan harga dari 20 pesaing melalui API mereka.
Masalah: Sebagian besar API pesaing memiliki batas publik (100-500 permintaan per jam). Ketika melebihi, kembali 429.
Solusi:
- Membuat antrean permintaan dengan prioritas (produk paling penting diperiksa lebih sering)
- Melacak batasan melalui header respons (X-RateLimit-Remaining)
- Jeda otomatis saat mencapai 80% dari batasan
- Gunakan beberapa kunci API untuk setiap pesaing (di mana mungkin)
Hasil: Sistem secara otomatis mendistribusikan permintaan sehingga tidak pernah melebihi batasan. Data diperbarui dengan frekuensi maksimum yang mungkin tanpa pemblokiran.
Pelajaran umum dari semua kasus:
Kesalahan 429 diselesaikan secara komprehensif: rotasi proxy + jeda yang benar + meniru perilaku nyata. Tidak bisa hanya mengandalkan satu metode. Bahkan dengan satu juta IP, Anda akan diblokir jika melakukan 1.000 permintaan per detik dengan header mencurigakan.
Kesimpulan
Kesalahan 429 Terlalu Banyak Permintaan adalah mekanisme perlindungan situs web yang dapat dihindari dengan pendekatan yang benar. Prinsip utama untuk menyelesaikan masalah ini:
- Rotasi alamat IP β distribusikan beban antara banyak proxy, sehingga setiap alamat melakukan sedikit permintaan
- Jeda yang benar β tiru pengguna nyata dengan jeda acak dari 1 hingga 5 detik
- Header yang benar β gunakan User-Agent yang relevan dan kumpulan header browser yang lengkap
- Pemilihan jenis proxy β untuk situs yang kompleks (marketplace, media sosial) gunakan proxy residensial atau mobile
- Penanganan kesalahan β terapkan jeda eksponensial saat menerima 429, jangan menyerang situs kembali
Ingatlah: tujuan bukanlah untuk mengelabui perlindungan dengan cara apa pun, tetapi agar otomatisasi Anda terlihat sealamiah mungkin. Sistem perlindungan modern semakin cerdas, dan kekuatan kasar mulai tidak berfungsi.
Jika Anda berencana untuk bekerja dengan parsing marketplace, pemantauan pesaing, atau otomatisasi di media sosial, kami merekomendasikan untuk mencoba proxy residensial β mereka menyediakan kumpulan alamat IP yang besar, rotasi otomatis, dan risiko pemblokiran yang minimal. Untuk bekerja dengan Instagram, TikTok, dan platform mobile lainnya, proxy mobile dengan IP dari operator seluler nyata adalah pilihan terbaik.