429 too many requests: solusi untuk web scraping dan AI API

Bayangkan sebuah scraper mengumpulkan halaman produk publik melalui proxy CyberYozh App, kemudian mengirimkan teks yang diekstrak ke AI API untuk dianalisis. Di tengah pekerjaan, scraper berhenti dengan pesan "429 too many requests." Respons yang menggoda adalah mencoba lagi, tetapi pertama-tama Anda perlu mencari tahu di mana permintaan gagal.

Apakah website, layanan perantara, atau AI API yang mengembalikan error? Masing-masing dapat menerapkan batasan yang berbeda, jadi mengubah pengaturan yang salah dapat membuat masalah tetap tidak terselesaikan.

Selama pengumpulan, periksa pacing permintaan, koneksi konkuren, dan apakah batasan berlaku untuk IP atau sesi. CyberYozh App memungkinkan Anda mengontrol perubahan IP proxy dan perilaku sesi pada tahap ini. Selama pemrosesan AI, periksa allowance permintaan dan token dari penyedia. Panduan ini membahas kedua tahap sehingga Anda dapat mengidentifikasi pembatasan, menerapkan perbaikan yang tepat, dan menghindari pengulangan pekerjaan yang sudah berhasil.

TL;DR

• 429 too many requests berarti layanan menerapkan batasan rate atau penggunaan. Ini tidak secara otomatis berarti proxy Anda rusak atau diblokir secara permanen.

• Temukan sumbernya terlebih dahulu: website target, layanan perantara, atau AI API. Periksa response body dan header.

• Perlambat dan coba lagi dengan hati-hati. Hormati Retry-After, koordinasikan worker, kurangi konkurensi, dan gunakan backoff dengan jitter serta batas percobaan maksimum.

• Simpan pekerjaan yang sudah selesai. Coba lagi langkah pengumpulan atau analisis yang gagal tanpa memulai ulang seluruh workflow.

• Periksa batasan permintaan AI, allowance token, dan kuota secara terpisah. Mengubah IP tidak meningkatkan allowance akun.

• Sesuaikan infrastruktur proxy dengan kebutuhan pengumpulan. CyberYozh App menyediakan geotargeting, sticky session hingga 24 jam dan traffic unlimited.

Apa arti 429 too many requests?

Error 429 too many requests berarti layanan membatasi permintaan lebih lanjut karena Anda telah mencapai salah satu ambang penggunaannya. Biasanya, ini melibatkan pengiriman terlalu banyak permintaan dalam jendela waktu tertentu. Respons saja tidak memberi tahu Anda batasan mana yang tercapai atau berapa lama pembatasan akan berlangsung.

Untuk memahami apa arti "429 too many requests" bagi workflow Anda, periksa bagaimana layanan menghitung aktivitas. Seperti yang dijelaskan oleh dokumentasi 429 MDN, batasan dapat berlaku di seluruh server, untuk resource tertentu, atau menurut alamat IP, pengguna terautentikasi, atau aplikasi. Beberapa worker dapat berbagi allowance meskipun masing-masing mengirim permintaan yang relatif sedikit.

429 tidak, dengan sendirinya, menetapkan pemblokiran permanen atau membuktikan bahwa proxy Anda rusak. Koneksi mungkin berfungsi sementara tujuan menolak permintaan tambahan. Mengubah IP tidak akan mereset batasan yang terikat pada akun terautentikasi yang sama.

Periksa body dan header respons untuk detail tentang pembatasan, termasuk instruksi Retry-After jika ada, sebelum memilih tindakan selanjutnya.

Cari tahu layanan mana yang mengembalikan error

Kembali ke contoh halaman produk: apakah pengumpulan gagal sebelum teks mencapai AI API, atau apakah analisis berhenti setelah halaman disimpan?

Di browser, buka developer tools, pilih panel Network, dan periksa permintaan dengan status 429. Di Postman, tinjau status respons, header, dan body. Dalam log aplikasi, cocokkan kegagalan dengan timestamp dan langkah workflow-nya.

Catat hostname, body respons, header yang relevan, timestamp, dan request ID jika tersedia. Hapus password, API key, nilai otorisasi, dan session cookie sebelum membagikan catatan diagnostik.

Cara memperbaiki error 429 too many requests

Setelah Anda mengidentifikasi layanan yang mengembalikan 429, biarkan detail respons memandu perbaikan. Kerjakan langkah-langkah ini sebelum memulai ulang pekerjaan penuh.

1. Hentikan upaya berulang
   Jeda pekerjaan yang terpengaruh, lalu periksa background worker, tugas terjadwal, dan eksekusi duplikat. Jika mereka berbagi allowance yang sama, koordinasikan jeda mereka juga; menghentikan satu skrip mungkin tidak mengubah sebagian besar traffic.

2. Patuhi header Retry-After
   Retry-After: 60 berarti tunggu setidaknya 60 detik. Tanggal HTTP menentukan kapan harus mencoba lagi. Dokumentasi Retry-After MDN menjelaskan kedua format. Ketika header tidak ada, konsultasikan batas yang didokumentasikan layanan dan gunakan penundaan retry yang meningkat daripada mengasumsikan periode tunggu universal.

3. Kurangi frekuensi request dan konkurensi
   Frekuensi berarti request yang dikirim dari waktu ke waktu; konkurensi berarti request yang berjalan secara bersamaan. Kontrol keduanya. Worker yang berbagi allowance memerlukan pacing terkoordinasi, seperti antrian bersama dengan rate limiter, karena penundaan individual tidak mengontrol traffic gabungan mereka.

4. Gunakan exponential backoff dengan jitter
   Tingkatkan penundaan setelah kegagalan berulang dan tambahkan jitter, variasi acak kecil yang membantu worker menghindari retry bersamaan. Tetapkan jumlah upaya maksimum dan periksa perilaku retry yang ada pada client atau SDK sebelum menambahkan loop lain. Jangan pernah mempersingkat waktu tunggu yang diminta server.

5. Hapus request yang tidak perlu
   Deduplikasi URL yang diantrekan, cache respons yang berhasil jika diizinkan, dan kurangi polling ketika data segar tidak diperlukan. Simpan halaman yang telah selesai sehingga satu request yang gagal tidak memulai ulang seluruh pekerjaan pengumpulan.

Contoh Python GET ini menangani kedua format header, mundur ke backoff untuk nilai yang hilang atau salah format, dan berhenti setelah lima upaya yang tidak berhasil:

import random
import time
from datetime import timezone
from email.utils import parsedate_to_datetime

import requests


def get_with_backoff(url):
    for attempt in range(5):
        response = requests.get(url, timeout=30)
        if response.status_code != 429:
            response.raise_for_status()
            return response
        if attempt == 4:
            response.raise_for_status()

        value = response.headers.get("Retry-After", "").strip()
        delay = 2 ** attempt
        try:
            if value.isascii() and value.isdigit():
                delay = max(delay, int(value))
            elif value:
                retry_at = parsedate_to_datetime(value)
                if retry_at.tzinfo is None:
                    retry_at = retry_at.replace(tzinfo=timezone.utc)
                delay = max(delay, retry_at.timestamp() - time.time())
        except (ValueError, TypeError, OverflowError):
            pass  # Invalid header: keep the backoff delay.

        response.close()
        time.sleep(delay + random.uniform(0, 1))

Perbaiki error 429 berulang dalam web scraping

Error 429 berulang memerlukan peninjauan jadwal keseluruhan pekerjaan pengumpulan. Hitung request di semua worker yang menargetkan website yang sama, terutama ketika mereka berbagi alamat IP, akun, atau kredensial API. Koordinasikan worker yang berbagi batas melalui rate limiter umum, dan terapkan cooldown di seluruh grup yang terpengaruh ketika throttling terjadi.

Otomasi browser dapat menghasilkan lebih banyak traffic daripada yang disarankan skrip Anda. Membuka satu halaman produk dapat memicu request untuk gambar, skrip, rekomendasi, dan pembaruan latar belakang. Periksa panel Network browser untuk melihat apa yang sebenarnya mencapai target. Lewati resource yang tidak perlu hanya ketika melakukannya mempertahankan perilaku halaman dan data yang Anda butuhkan.

Deduplikasi URL yang diantrekan sambil mempertahankan perbedaan yang disengaja, seperti storefront regional atau varian produk. Simpan respons yang berhasil dan catat item mana yang telah selesai. Dalam contoh halaman produk pembuka, jika pengumpulan berhenti di tengah katalog, lanjutkan dari item yang gagal setelah waktu tunggu yang diperlukan. Halaman yang sudah dikumpulkan harus tetap tersedia untuk pemrosesan AI tanpa diunduh lagi.

Pertahankan kontinuitas sesi ketika request terkait bergantung pada cookie, akun, atau alamat IP yang sama. Dasarkan rotasi proxy pada persyaratan koneksi tugas dan batas yang teridentifikasi; 429 saja bukan alasan untuk mengubah alamat. Jadwalkan pengumpulan sesuai allowance yang didokumentasikan target, dan kurangi polling ketika informasi produk tidak memerlukan pembaruan yang sering.

Perbaiki error 429 di API AI dan workflow agent

Scraper Anda mungkin mengumpulkan setiap halaman produk dengan sukses, lalu mengalami 429 ketika mengirim hasil untuk analisis. Menyelesaikan batch pengumpulan dapat memicu ledakan panggilan model, masing-masing mengonsumsi bagian dari allowance request atau token penyedia AI.

Periksa allowance mana yang Anda capai. Dokumentasi rate-limit Claude membedakan request per menit, token input per menit, dan token output per menit. Token adalah unit yang digunakan model untuk memproses teks. Beberapa input besar oleh karena itu dapat mencapai batas token bahkan ketika jumlah request terlihat sederhana. Periksa batas yang berlaku untuk akun dan model Anda.

Antrekan pekerjaan analisis dan lepaskan dengan kecepatan terkontrol. Jika beberapa agent berbagi allowance organisasi atau proyek, koordinasikan penggunaan gabungan mereka. Mengurangi input yang tidak perlu dan meminta output yang ringkas juga dapat mengurangi konsumsi token, sementara pacing mencegah batch scraping yang selesai membanjiri tahap pemrosesan.

Entri log seperti last status: 429 too many requests mencatat status HTTP akhir; diagnosis masih bergantung pada respons yang mendasarinya. Periksa tipe error penyedia, pesan, ID request, dan header batas, lalu bandingkan dengan informasi penggunaan dan penagihan. Rate limit sementara dan allowance yang habis memerlukan tindakan berbeda. Claude, misalnya, mendokumentasikan respons spend-cap tier bulanan yang terus gagal hingga akses dilanjutkan.

Simpan halaman yang dikumpulkan secara independen dari pekerjaan analisis. Ketika request AI gagal, retry hanya langkah pemrosesan itu setelah mengatasi pembatasan. Periksa perilaku retry yang ada pada SDK sehingga workflow luar tidak berulang kali memulai ulang panggilan yang sudah di-retry oleh client.

Jika respons bertentangan dengan penggunaan yang diamati, periksa halaman status layanan penyedia dan selidiki beban kerja lain yang berbagi allowance. Simpan timestamp dan ID request untuk dukungan. Mengubah IP proxy scraper tidak akan meningkatkan batas request atau token akun AI.

Di mana CyberYozh App cocok dalam workflow scraping

Setelah diagnosis mengidentifikasi kebutuhan untuk akses regional, kontinuitas sesi, atau kontrol yang lebih baik atas koneksi pengumpulan, CyberYozh App menyediakan beberapa opsi infrastruktur. Sesuaikan koneksi dengan tugas, termasuk berapa lama request terkait perlu mempertahankan IP yang sama.

• Proksi mobile: Traffic unlimited pada paket LTE/4G/5G asli membuat biaya bandwidth dapat diprediksi untuk pengumpulan data berkelanjutan. Paket dedicated menyediakan channel mobile khusus untuk beban kerja Anda, sementara paket shared menggunakan channel bersama pelanggan lain. Koneksi dedicated menawarkan perubahan IP manual dan berbasis API, memungkinkan Anda menjadwalkan perubahan sesuai batasan tugas. 

• Proksi residential rotating: Gunakan penargetan regional untuk mengumpulkan listing atau harga yang bergantung pada lokasi. Pilih rotasi untuk tugas pengumpulan independen atau sticky session hingga 24 jam ketika permintaan terkait memerlukan konsistensi IP sementara. Traffic ditagih berdasarkan penggunaan, dengan traffic yang tidak terpakai akan diperpanjang ke periode penagihan berikutnya.

• Proksi ISP statis: Alamat tetap selama periode sewa cocok untuk sesi pengumpulan berulang yang memerlukan IP yang sama. Ini memberikan kontinuitas di berbagai sesi terpisah tanpa bergantung pada sticky session sementara.

• Proksi datacenter dedicated: Ini menyediakan koneksi datacenter tetap untuk beban kerja di mana target menerima jenis jaringan tersebut. Cocok untuk pekerjaan pengumpulan rutin yang tidak memerlukan koneksi residential atau mobile.

CyberYozh App mendukung koneksi proksi di Scrapy, Postman, Playwright, Puppeteer, dan Selenium. Akses API penuh memungkinkan skrip mengelola operasi proksi yang didukung bersama kode pengumpulan Anda yang sudah ada.