429 too many requests: cách khắc phục cho web scraping và AI API

Hãy tưởng tượng một scraper thu thập các trang sản phẩm công khai thông qua proxy CyberYozh App, sau đó gửi văn bản đã trích xuất đến một AI API để phân tích. Giữa chừng công việc, nó dừng lại với thông báo "429 too many requests." Phản ứng hấp tấp là thử lại, nhưng trước tiên bạn cần tìm ra nơi yêu cầu đã thất bại.

Website, dịch vụ trung gian hay AI API đã trả về lỗi? Mỗi bên có thể áp dụng các giới hạn khác nhau, vì vậy thay đổi sai cài đặt có thể khiến vấn đề vẫn chưa được giải quyết.

Trong quá trình thu thập, hãy kiểm tra tốc độ yêu cầu, kết nối đồng thời và liệu giới hạn có áp dụng cho IP hay session. CyberYozh App cho phép bạn kiểm soát việc thay đổi IP proxy và hành vi session ở giai đoạn này. Trong quá trình xử lý AI, thay vào đó hãy kiểm tra hạn mức yêu cầu và token của nhà cung cấp. Hướng dẫn này sẽ đi qua cả hai giai đoạn để bạn có thể xác định hạn chế, áp dụng cách khắc phục đúng và tránh lặp lại công việc đã thành công.

TL;DR

• 429 too many requests có nghĩa là một dịch vụ đang áp dụng giới hạn tốc độ hoặc sử dụng. Nó không tự động có nghĩa là proxy của bạn bị lỗi hoặc bị cấm vĩnh viễn.

• Tìm nguồn gốc trước: website đích, dịch vụ trung gian hay AI API. Kiểm tra response body và header.

• Làm chậm lại và thử lại cẩn thận. Tuân thủ Retry-After, điều phối các worker, giảm concurrency và sử dụng backoff với jitter cùng số lần thử tối đa.

• Lưu công việc đã hoàn thành. Thử lại bước thu thập hoặc phân tích thất bại mà không khởi động lại toàn bộ quy trình.

• Kiểm tra giới hạn yêu cầu AI, hạn mức token và quota riêng biệt. Thay đổi IP không làm tăng hạn mức tài khoản.

• Khớp cơ sở hạ tầng proxy với yêu cầu thu thập. CyberYozh App cung cấp geotargeting, sticky session lên đến 24 giờ và lưu lượng không giới hạn.

429 too many requests có nghĩa là gì?

Lỗi 429 too many requests có nghĩa là một dịch vụ đang giới hạn các yêu cầu tiếp theo vì bạn đã đạt đến một trong các ngưỡng sử dụng của nó. Thông thường, điều này liên quan đến việc gửi quá nhiều yêu cầu trong một khoảng thời gian cụ thể. Chỉ riêng phản hồi không cho bạn biết giới hạn nào đã đạt đến hoặc hạn chế sẽ kéo dài bao lâu.

Để hiểu "429 too many requests" có nghĩa là gì đối với quy trình của bạn, hãy kiểm tra cách dịch vụ đếm hoạt động. Như tài liệu 429 của MDN giải thích, giới hạn có thể áp dụng trên một máy chủ, cho một tài nguyên cụ thể hoặc theo địa chỉ IP, người dùng đã xác thực hoặc ứng dụng. Do đó, nhiều worker có thể chia sẻ một hạn mức ngay cả khi mỗi worker gửi tương đối ít yêu cầu.

Lỗi 429 tự nó không thiết lập lệnh cấm vĩnh viễn hoặc chứng minh rằng proxy của bạn bị lỗi. Kết nối có thể đang hoạt động trong khi đích từ chối các yêu cầu bổ sung. Thay đổi IP sẽ không đặt lại giới hạn gắn với cùng một tài khoản đã xác thực.

Kiểm tra nội dung phản hồi và các header để biết chi tiết về giới hạn, bao gồm bất kỳ chỉ dẫn Retry-After nào, trước khi chọn hành động tiếp theo.

Tìm hiểu dịch vụ nào đang trả về lỗi

Quay lại ví dụ về trang sản phẩm: việc thu thập có thất bại trước khi văn bản đến AI API hay quá trình phân tích dừng lại sau khi các trang đã được lưu?

Trong trình duyệt, mở công cụ dành cho nhà phát triển, chọn bảng Network và kiểm tra yêu cầu có trạng thái 429. Trong Postman, xem lại trạng thái phản hồi, headers và nội dung. Trong nhật ký ứng dụng, khớp lỗi với dấu thời gian và bước quy trình làm việc của nó.

Ghi lại hostname, nội dung phản hồi, các header liên quan, dấu thời gian và ID yêu cầu khi có sẵn. Xóa mật khẩu, API keys, giá trị ủy quyền và session cookies trước khi chia sẻ hồ sơ chẩn đoán.

Cách khắc phục lỗi 429 too many requests

Khi bạn xác định được dịch vụ trả về 429, hãy để chi tiết phản hồi hướng dẫn cách khắc phục. Thực hiện các bước này trước khi khởi động lại toàn bộ công việc.

1. Tạm dừng các lần thử lại
   Tạm dừng công việc bị ảnh hưởng, sau đó kiểm tra các worker chạy nền, tác vụ đã lên lịch và các lần chạy trùng lặp. Nếu chúng dùng chung hạn mức, hãy phối hợp tạm dừng chúng; việc dừng một script có thể không làm thay đổi phần lớn lưu lượng.

2. Tuân thủ header Retry-After
   Retry-After: 60 có nghĩa là chờ ít nhất 60 giây. Ngày HTTP chỉ định thời điểm thử lại. Tài liệu Retry-After của MDN giải thích cả hai định dạng. Khi header không có, hãy tham khảo giới hạn được ghi trong tài liệu của dịch vụ và sử dụng độ trễ thử lại tăng dần thay vì giả định một khoảng thời gian chờ chung.

3. Giảm tần suất request và concurrency
   Tần suất có nghĩa là các request được gửi theo thời gian; concurrency có nghĩa là các request chạy đồng thời. Kiểm soát cả hai. Các worker dùng chung hạn mức cần nhịp độ phối hợp, chẳng hạn như hàng đợi chung với rate limiter, vì độ trễ riêng lẻ không kiểm soát được lưu lượng kết hợp của chúng.

4. Sử dụng exponential backoff với jitter
   Tăng độ trễ sau các lần thất bại lặp lại và thêm jitter, một biến thể ngẫu nhiên nhỏ giúp các worker tránh thử lại cùng lúc. Đặt số lần thử tối đa và kiểm tra hành vi thử lại hiện có của client hoặc SDK trước khi thêm vòng lặp khác. Không bao giờ rút ngắn thời gian chờ mà server yêu cầu.

5. Loại bỏ các request không cần thiết
   Loại bỏ trùng lặp các URL trong hàng đợi, cache các response thành công khi được phép và giảm polling khi dữ liệu mới không cần thiết. Lưu các trang đã hoàn thành để một request thất bại không khởi động lại toàn bộ công việc thu thập.

Ví dụ Python GET này xử lý cả hai định dạng header, quay về backoff cho các giá trị thiếu hoặc sai định dạng và dừng sau năm lần thử không thành công:

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))

Khắc phục lỗi 429 lặp lại trong web scraping

Lỗi 429 lặp lại đòi hỏi phải xem xét lại lịch trình tổng thể của công việc thu thập. Đếm các request trên mọi worker nhắm đến cùng một website, đặc biệt khi chúng dùng chung địa chỉ IP, tài khoản hoặc thông tin xác thực API. Phối hợp các worker dùng chung giới hạn thông qua rate limiter chung và áp dụng cooldown trên toàn nhóm bị ảnh hưởng khi xảy ra throttling.

Tự động hóa trình duyệt có thể tạo ra nhiều lưu lượng hơn script của bạn gợi ý. Mở một trang sản phẩm có thể kích hoạt các request cho hình ảnh, script, đề xuất và cập nhật nền. Kiểm tra panel Network của trình duyệt để xem những gì thực sự đến đích. Chỉ bỏ qua các tài nguyên không cần thiết khi làm như vậy vẫn giữ nguyên hành vi trang và dữ liệu bạn cần.

Loại bỏ trùng lặp các URL trong hàng đợi trong khi vẫn giữ lại các khác biệt có chủ ý, chẳng hạn như cửa hàng khu vực hoặc biến thể sản phẩm. Lưu các response thành công và ghi lại những mục nào đã hoàn thành. Trong ví dụ trang sản phẩm mở đầu, nếu thu thập dừng lại giữa chừng catalog, hãy tiếp tục từ mục thất bại sau khi chờ đợi theo yêu cầu. Các trang đã thu thập nên vẫn có sẵn để xử lý AI mà không cần tải xuống lại.

Duy trì tính liên tục của session khi các request liên quan phụ thuộc vào cùng cookie, tài khoản hoặc địa chỉ IP. Dựa vào yêu cầu kết nối của tác vụ và giới hạn đã xác định để xoay proxy; chỉ riêng lỗi 429 không phải là lý do để thay đổi địa chỉ. Lên lịch thu thập dựa trên hạn mức được ghi trong tài liệu của đích và giảm polling khi thông tin sản phẩm không cần cập nhật thường xuyên.

Khắc phục lỗi 429 trong AI API và quy trình agent

Scraper của bạn có thể thu thập mọi trang sản phẩm thành công, sau đó gặp lỗi 429 khi gửi kết quả để phân tích. Hoàn thành một lô thu thập có thể kích hoạt một loạt lệnh gọi model, mỗi lệnh tiêu thụ một phần hạn mức request hoặc token của nhà cung cấp AI.

Kiểm tra hạn mức nào bạn đã đạt đến. Tài liệu rate-limit của Claude phân biệt request mỗi phút, input token mỗi phút và output token mỗi phút. Token là đơn vị mà model sử dụng để xử lý văn bản. Do đó, một vài input lớn có thể đạt đến giới hạn token ngay cả khi số lượng request trông khiêm tốn. Kiểm tra các giới hạn áp dụng cho tài khoản và model của bạn.

Đưa các công việc phân tích vào hàng đợi và phát hành chúng với tốc độ được kiểm soát. Nếu nhiều agent dùng chung hạn mức tổ chức hoặc dự án, hãy phối hợp việc sử dụng kết hợp của chúng. Giảm input không cần thiết và yêu cầu output ngắn gọn cũng có thể giảm mức tiêu thụ token, trong khi nhịp độ ngăn các lô scraping đã hoàn thành làm quá tải giai đoạn xử lý.

Một mục nhật ký như last status: 429 too many requests ghi lại trạng thái HTTP cuối cùng; chẩn đoán vẫn phụ thuộc vào response cơ bản. Kiểm tra loại lỗi, thông báo, request ID và limit header của nhà cung cấp, sau đó so sánh chúng với thông tin sử dụng và thanh toán. Giới hạn tốc độ tạm thời và hạn mức đã cạn kiệt yêu cầu các hành động khác nhau. Ví dụ, Claude ghi lại response monthly tier spend-cap tiếp tục thất bại cho đến khi quyền truy cập được khôi phục.

Giữ các trang đã thu thập được lưu độc lập với công việc phân tích. Khi một request AI thất bại, chỉ thử lại bước xử lý đó sau khi giải quyết hạn chế. Kiểm tra hành vi thử lại hiện có của SDK để quy trình bên ngoài không liên tục khởi động lại các lệnh gọi mà client đã đang thử lại.

Nếu response xung đột với mức sử dụng quan sát được, hãy kiểm tra trang service-status của nhà cung cấp và điều tra các khối lượng công việc khác dùng chung hạn mức. Giữ lại timestamp và request ID để hỗ trợ. Thay đổi proxy IP của scraper sẽ không tăng giới hạn request hoặc token của tài khoản AI.

CyberYozh App phù hợp với quy trình scraping như thế nào

Khi chẩn đoán xác định nhu cầu truy cập khu vực, tính liên tục của session hoặc kiểm soát tốt hơn các kết nối thu thập, CyberYozh App cung cấp một số tùy chọn cơ sở hạ tầng. Kết hợp kết nối với tác vụ, bao gồm cả thời gian các request liên quan cần giữ cùng một IP.

• Proxy di động: Lưu lượng không giới hạn trên các gói LTE/4G/5G thực giúp chi phí băng thông có thể dự đoán được cho việc thu thập liên tục. Gói chuyên dụng dành riêng kênh di động cho khối lượng công việc của bạn, trong khi gói chia sẻ sử dụng kênh cùng với các khách hàng khác. Kết nối chuyên dụng cung cấp khả năng thay đổi IP thủ công và qua API, cho phép bạn lên lịch thay đổi theo ranh giới tác vụ. 

• Proxy residential luân phiên: Sử dụng nhắm mục tiêu khu vực để thu thập danh sách hoặc giá phụ thuộc vào vị trí. Chọn luân phiên cho các tác vụ thu thập độc lập hoặc phiên cố định lên đến 24 giờ khi các yêu cầu liên quan cần tính nhất quán IP tạm thời. Lưu lượng được tính phí theo mức sử dụng, với lưu lượng chưa sử dụng được chuyển sang chu kỳ thanh toán tiếp theo.

• Proxy ISP tĩnh: Địa chỉ cố định trong suốt thời gian thuê phù hợp với các phiên thu thập định kỳ yêu cầu cùng một IP. Điều này cung cấp tính liên tục qua các lần chạy riêng biệt mà không phụ thuộc vào phiên cố định tạm thời.

• Proxy datacenter chuyên dụng: Những proxy này cung cấp kết nối datacenter cố định cho các khối lượng công việc mà mục tiêu chấp nhận loại mạng đó. Chúng có thể phù hợp với các công việc thu thập thường xuyên không yêu cầu kết nối residential hoặc di động.

CyberYozh App hỗ trợ kết nối proxy trong Scrapy, Postman, Playwright, Puppeteervà Selenium. Quyền truy cập API đầy đủ cho phép các script quản lý các thao tác proxy được hỗ trợ cùng với mã thu thập hiện có của bạn.