Lỗi 429 khi phân tích: 6 lý do ngoài proxy

Bạn thay đổi proxy, mua một nhóm địa chỉ IP mới, nhưng trình phân tích vẫn gặp lỗi 429 Too Many Requests? Đây là một tình huống điển hình: 70% trường hợp bị chặn không liên quan đến địa chỉ IP mà liên quan đến cách mà yêu cầu được thực hiện. Chúng ta sẽ phân tích sáu lý do thực tế khiến trang web tiếp tục chặn bạn ngay cả sau khi thay đổi proxy — và cách xử lý trong từng trường hợp.

Lỗi 429 có nghĩa là gì và tại sao proxy không phải là phương thuốc chữa bách bệnh

Mã HTTP 429 Too Many Requests về mặt hình thức có nghĩa là "đã vượt quá giới hạn yêu cầu". Nhưng trên thực tế, các trang web — đặc biệt là Wildberries, Ozon, Avito, Yandex.Market — sử dụng mã này như một tín hiệu phổ quát "chúng tôi cho rằng bạn là bot". Nguyên nhân có thể là do tần suất yêu cầu, nhưng cũng có thể là do tiêu đề, dấu vân tay của trình duyệt, thiếu phiên cookie hoặc các giới hạn không gắn với IP mà gắn với tài khoản của bạn.

Chính vì vậy, việc thay đổi proxy thường không giúp ích: nếu hệ thống chặn không phải IP mà là mẫu yêu cầu (dấu vân tay, tiêu đề, tốc độ nhấp chuột), thì từ địa chỉ IP mới, bạn sẽ nhận được lỗi 429 trong vài phút. Chúng ta sẽ phân tích từng lý do một cách chi tiết và chỉ ra cách kiểm tra và khắc phục mà không cần mua một nhóm proxy mới.

Quan trọng: proxy vẫn là công cụ cần thiết — nhưng chỉ như một phần của hệ thống, chứ không phải là giải pháp duy nhất. IP dân cư và di động giảm khả năng bị đưa vào danh sách đen do uy tín IP, nhưng không cứu được bạn khỏi việc bị chặn do hành vi hoặc tiêu đề.

Lý do 1: Tần suất yêu cầu quá cao

Đây là lý do rõ ràng nhất, nhưng cũng là lý do thường bị chẩn đoán sai. Nhiều người nghĩ: "vì tôi thay đổi proxy cho mỗi yêu cầu — tần suất không quan trọng". Điều này là sai. Các hệ thống chống bot hiện đại (ví dụ, Wildberries và Ozon sử dụng các giải pháp cấp độ Cloudflare hoặc WAF riêng) không chỉ phân tích tần suất từ một IP mà còn phân tích tổng tải trên một endpoint API hoặc trang sản phẩm trong một khoảng thời gian từ tất cả các nguồn kết hợp với các tín hiệu hành vi.

Nếu trình phân tích của bạn thực hiện 50-100 yêu cầu mỗi giây đến cùng một phần của danh mục, hệ thống sẽ thấy sự gia tăng lưu lượng bất thường bất kể bạn sử dụng bao nhiêu IP khác nhau. Giải pháp không phải là thay đổi proxy, mà là áp dụng độ trễ nhân tạo (throttling) giữa các yêu cầu: 1-3 giây độ trễ ngẫu nhiên thay vì khoảng thời gian cố định, cộng với việc tăng gấp đôi thời gian chờ khi nhận được lỗi 429 (tăng thời gian chờ gấp đôi sau mỗi lần bị chặn).

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

Nếu bạn sử dụng trình phân tích có sẵn mà không có mã (ví dụ, dịch vụ giám sát giá trên đám mây), hãy kiểm tra cài đặt khoảng thời gian giữa các yêu cầu — hầu hết các công cụ như vậy đều có thanh trượt "tốc độ quét". Giảm tốc độ xuống 30-40% thường loại bỏ hoàn toàn lỗi 429, ngay cả khi không thay đổi proxy.

Lý do 2: Tiêu đề không đúng hoặc thiếu

Nhiều trình phân tích gửi yêu cầu với bộ tiêu đề tối thiểu hoặc sử dụng User-Agent của thư viện theo mặc định (ví dụ, "python-requests/2.28.1"). Tiêu đề như vậy ngay lập tức cho thấy đây là bot — trình duyệt thực tế gửi hàng chục tiêu đề: Accept, Accept-Language, Accept-Encoding, Sec-Fetch-*, Referer và các tiêu đề khác theo một thứ tự nhất định.

Wildberries và Ozon so sánh bộ tiêu đề với "dấu vân tay" mong đợi của trình duyệt thực tế như Chrome hoặc Safari. Nếu số lượng tiêu đề quá ít, không đúng thứ tự hoặc User-Agent không khớp với các tham số khác (ví dụ, khai báo Chrome trên Windows, nhưng dấu vân tay TLS giống như Python) — yêu cầu sẽ bị chặn với mã 429 bất kể IP.

Tiêu đề	Lỗi điển hình	Giải pháp
User-Agent	Phiên bản lỗi thời hoặc chuỗi rõ ràng từ thư viện	UA hiện tại của Chrome/Safari thực tế, quay vòng từ nhóm
Accept-Language	Thiếu hoặc không khớp với định vị địa lý của IP	ru-RU cho các chợ trực tuyến của Nga
Referer	Trống, trong khi chuyển tiếp thực tế luôn có Referer	Chỉ định trang trước đó trong danh mục
Sec-Fetch-*	Hoàn toàn không có (không phải khách hàng trình duyệt)	Sao chép bộ tiêu đề đầy đủ từ DevTools của trình duyệt thực tế

Cách đơn giản nhất là sao chép bộ tiêu đề đầy đủ từ tab Network trong DevTools của trình duyệt thực tế, mở trang cần thiết bằng tay, và sử dụng chính bộ tiêu đề này trong trình phân tích — với thứ tự tiêu đề nếu thư viện cho phép (ví dụ, curl_cffi hoặc httpx với thứ tự rõ ràng).

Lý do 3: Thiếu quay vòng phiên và cookie

Lỗi mà thường bị bỏ qua: trình phân tích thay đổi IP cho mỗi yêu cầu, nhưng sử dụng cùng một phiên cookie hoặc hoàn toàn không lưu cookie. Người dùng thực tế nhận được một bộ cookie (token phiên, ID thiết bị, nhãn bảo vệ chống bot như Cloudflare __cf_bm hoặc tương tự ở Ozon/WB) trong lần truy cập đầu tiên và sử dụng chúng trong tất cả các yêu cầu tiếp theo trong phiên.

Nếu bạn gửi yêu cầu mà không có cookie, nhận được từ trang "đã được làm nóng", hệ thống chống bot sẽ thấy phiên "không" — và điều này ngay lập tức gây nghi ngờ, đặc biệt khi truy cập trực tiếp vào các endpoint API, bỏ qua trang chính. Giải pháp là mô phỏng kịch bản hoàn chỉnh: trước tiên tải trang chính hoặc trang danh mục, nhận cookie, chờ 1-2 giây, và chỉ sau đó truy cập vào API cần thiết hoặc thẻ sản phẩm, giữ cookie trong cùng một phiên trong suốt chuỗi yêu cầu.

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

# Làm nóng phiên
session.get("https://www.wildberries.ru/catalog/0/search.aspx")
time.sleep(1.5)

# Yêu cầu chính đã có cookie
response = session.get(target_url)

Nếu bạn sử dụng trình duyệt chống phát hiện như Dolphin Anty hoặc AdsPower để giám sát thẻ sản phẩm bằng tay hoặc qua tự động hóa tích hợp, hãy đảm bảo rằng hồ sơ lưu cookie giữa các phiên và không khởi động lại mỗi lần từ "trang trắng" — điều này cũng kích hoạt sự nghi ngờ của hệ thống.

Lý do 4: Hành vi giống như bot

Ngay cả với các tiêu đề và cookie hoàn hảo, trình phân tích có thể tự lộ diện bằng các mẫu hành vi: thứ tự truy cập sản phẩm nghiêm ngặt (theo ID tăng dần), khoảng thời gian giữa các yêu cầu giống hệt nhau đến từng mili giây, thiếu các yêu cầu "rác" đến các tài nguyên tĩnh (hình ảnh, CSS, JS), mà trình duyệt thông thường tải tự động.

Các hệ thống bảo vệ tiên tiến của Wildberries và Ozon không chỉ phân tích các yêu cầu HTTP mà còn xem xét liệu JavaScript trên trang có được thực thi hay không (thông qua phát hiện headless), chuột có di chuyển hay không, có cuộn trang hay không. Nếu bạn thực hiện các yêu cầu HTTP sạch mà không có việc render JS, và trang web mong đợi việc thực thi kịch bản để nhận token (ví dụ, thử thách chống bot bằng JavaScript), yêu cầu mà không thực hiện kịch bản này sẽ tự động nhận được lỗi 429 hoặc 403.

Giải pháp phụ thuộc vào quy mô: đối với các khối lượng nhỏ, việc sử dụng trình duyệt headless (Playwright, Puppeteer) với mô phỏng chuyển động chuột và độ trễ ngẫu nhiên là phù hợp. Đối với việc phân tích công nghiệp — ngẫu nhiên hóa thứ tự duyệt sản phẩm, thêm "nhiễu" dưới dạng yêu cầu đến các tài nguyên phụ, biến đổi khoảng thời gian theo phân phối chuẩn, chứ không phải theo bước cố định.

Lý do 5: Dấu vân tay TLS/JA3 và HTTP/2

Đây là lý do kỹ thuật "khó nhận thấy" nhất, mà 90% người làm phân tích không biết. Mỗi khách hàng TLS (thư viện requests, curl, urllib) để lại dấu vân tay độc nhất khi thiết lập kết nối HTTPS — bộ mã hóa được hỗ trợ, phiên bản giao thức, mở rộng TLS. Dấu vân tay này được gọi là dấu vân tay JA3/JA4.

Các hệ thống chống bot cấp độ Cloudflare, Akamai và các giải pháp riêng của các chợ lớn so sánh dấu vân tay JA3 với cơ sở dữ liệu của các bot và thư viện đã biết. Python requests tiêu chuẩn hoặc mô-đun https của Node.js có dấu vân tay dễ phát hiện, hoàn toàn khác với dấu vân tay của Chrome thực tế. Ngay cả với các tiêu đề và cookie hoàn hảo, yêu cầu bị chặn ngay tại giai đoạn TLS-handshake, trước khi máy chủ thấy các tiêu đề HTTP.

Thêm vào đó, nhiều chợ yêu cầu HTTP/2 với các tham số nhất định (thứ tự khung SETTINGS, ưu tiên luồng) — các thư viện dựa trên HTTP/1.1 tự động bị phát hiện trên nền tảng này. Giải pháp là sử dụng các thư viện mô phỏng dấu vân tay của trình duyệt thực: curl_cffi (mô phỏng dấu vân tay TLS của Chrome), tls-client, hoặc các trình duyệt headless hoàn chỉnh dựa trên Chromium, cung cấp "dấu vân tay thực" theo định nghĩa.

pip install curl_cffi

Ví dụ: curl_cffi.requests.get(url, impersonate="chrome120") — thư viện tự động thay thế dấu vân tay TLS, giống như Chrome 120 thực tế.

Lý do 6: Giới hạn ở cấp tài khoản hoặc API key

Nếu bạn làm việc thông qua API chính thức hoặc bán chính thức của chợ (ví dụ, API của người bán Wildberries hoặc Ozon Seller API), lỗi 429 có thể không gắn với IP mà gắn với tài khoản người bán hoặc API token. Trong trường hợp này, việc thay đổi proxy hoàn toàn vô nghĩa — giới hạn được lưu trữ trên máy chủ gắn với ID tài khoản của bạn, và bất kỳ IP nào từ tài khoản đó cũng sẽ nhận được giới hạn giống nhau.

Tình huống này thường gặp ở những người bán cùng lúc giám sát giá của đối thủ qua tài khoản cá nhân và gọi API để xuất dữ liệu tồn kho — cả hai luồng yêu cầu được cộng dồn vào giới hạn tổng của tài khoản. Giải pháp là phân chia tải theo thời gian, sử dụng các hạn ngạch API chính thức một cách tiết kiệm hơn (cache dữ liệu không thay đổi mỗi phút), và để giám sát giá của đối thủ, sử dụng một luồng yêu cầu không được xác thực riêng biệt, không gắn với tài khoản người bán.

Kiểm tra điều này rất đơn giản: nếu lỗi 429 vẫn tiếp diễn ngay cả khi truy cập từ một IP mới sạch và không có bất kỳ cookie nào từ các phiên trước, nhưng bạn đã đăng nhập vào tài khoản cá nhân trong tab bên cạnh — rất có thể, giới hạn là do tài khoản.

Cách chẩn đoán lý do thực sự

Trước khi thay đổi hạ tầng, hãy thực hiện chẩn đoán theo thuật toán sau. Đầu tiên, mở trang bằng tay trong trình duyệt thông thường và đảm bảo rằng lỗi 429 không xảy ra khi hành vi thực tế — điều này xác nhận rằng vấn đề nằm ở phía trình phân tích, không phải là chặn toàn cầu của khu vực.

Sau đó, so sánh tiêu đề của trình phân tích của bạn với tiêu đề của trình duyệt thực qua DevTools (tab Network → Copy as cURL). Nếu sự khác biệt là tối thiểu, hãy kiểm tra dấu vân tay TLS qua các dịch vụ như tls.peet.ws — gửi yêu cầu bằng thư viện của bạn và so sánh hash JA3 với trình duyệt mẫu. Nếu yêu cầu bị lỗi ở giai đoạn TLS-handshake (kết nối bị ngắt trước khi nhận được phản hồi HTTP) — nguyên nhân là do dấu vân tay, không phải do tần suất hoặc tiêu đề.

Tiếp theo, kiểm tra xem giới hạn có gắn với IP hay tài khoản: thực hiện yêu cầu từ một IP mới sạch mà không có xác thực. Nếu lỗi 429 biến mất — vấn đề nằm ở uy tín của IP trước đó hoặc tần suất từ địa chỉ đó. Nếu lỗi 429 vẫn còn — hãy tìm nguyên nhân trong tiêu đề, TLS hoặc hành vi, không phải trong proxy.

Danh sách kiểm tra khắc phục lỗi 429 mà không cần thay đổi proxy

Thêm độ trễ ngẫu nhiên từ 1-4 giây giữa các yêu cầu thay vì khoảng thời gian cố định.
Sao chép bộ tiêu đề đầy đủ của trình duyệt thực, bao gồm Sec-Fetch-* và Accept-Language.
Lưu và truyền cookie trong cùng một phiên, bắt đầu từ việc làm nóng trang chính.
Kiểm tra dấu vân tay TLS của thư viện của bạn — sử dụng curl_cffi hoặc trình duyệt headless thay vì khách hàng HTTP sạch.
Ngẫu nhiên hóa thứ tự duyệt các trang và thêm các yêu cầu "nhiễu" đến các tài nguyên tĩnh.
Phân chia tải của tài khoản API và giám sát giá ẩn danh thành các luồng khác nhau.
Áp dụng backoff theo cấp số nhân khi nhận được lỗi 429, thay vì lặp lại yêu cầu ngay lập tức.
Chỉ sau khi kiểm tra tất cả các điểm trên — hãy thay đổi proxy hoặc mở rộng nhóm IP.

Khi nào cần proxy và nên chọn loại nào

Sau khi khắc phục tất cả sáu lý do, proxy vẫn là một phần quan trọng của hạ tầng — nhưng giờ đây như một phương tiện mở rộng, chứ không phải là cách duy nhất để chống lại các lệnh cấm. Nếu nhiệm vụ của bạn là giám sát đồng thời hàng nghìn thẻ sản phẩm trên Wildberries và Ozon từ nhiều "người dùng ảo", bạn cần một nhóm IP có uy tín tốt, để không tích lũy lịch sử bị chặn trên một địa chỉ.

Đối với việc giám sát giá và danh mục của các chợ trực tuyến, proxy dân cư là lựa chọn tốt nhất — chúng sử dụng các IP thực từ các nhà cung cấp dịch vụ internet, vì vậy các hệ thống chống bot coi các yêu cầu như lưu lượng của người mua thông thường, không phải từ trung tâm dữ liệu. Điều này rất quan trọng, vì Wildberries và Ozon đã từ lâu đưa các dải IP của trung tâm dữ liệu vào danh sách đen.

Nếu nhiệm vụ liên quan đến việc kiểm tra phiên bản di động của trang web, làm việc qua ứng dụng của chợ hoặc thử nghiệm quảng cáo trên TikTok Ads và Facebook Ads với độ chính xác địa lý đến từng thành phố, proxy di động là lựa chọn phù hợp — chúng có mức độ tin cậy cao nhất trong hầu hết các hệ thống bảo vệ, vì IP thuộc về các nhà điều hành mạng di động thực sự.

Đối với các nhiệm vụ ít nhạy cảm hơn — chẳng hạn như phân tích các danh mục mở mà không cần xác thực ở quy mô nhỏ — bạn có thể sử dụng proxy trung tâm dữ liệu: chúng rẻ hơn và nhanh hơn nhiều, nhưng yêu cầu cấu hình tiêu đề và dấu vân tay TLS cẩn thận hơn, vì bản thân chúng mang lại rủi ro cao hơn về việc bị nghi ngờ.

Loại proxy	Khi nào giải quyết lỗi 429	Khi nào không giúp được
Dân cư	IP đã có trong danh sách đen do uy tín	Bị chặn do dấu vân tay TLS hoặc tiêu đề
Di động	Cần độ tin cậy tối đa của IP cho các kịch bản nhạy cảm	Giới hạn gắn với tài khoản, không phải IP
Trung tâm dữ liệu	Phân tích đơn giản các trang mở mà không cần xác thực	Các hệ thống chống bot nghiêm ngặt với kiểm tra uy tín dải IP

Kết luận

Lỗi 429 khi phân tích hiếm khi được giải quyết bằng một nút "thay đổi proxy". Trong hầu hết các trường hợp, vấn đề nằm ở tần suất yêu cầu, tiêu đề không đầy đủ, thiếu phiên cookie, dấu vân tay TLS có thể phát hiện, các mẫu hành vi hoặc các giới hạn gắn với tài khoản, không phải địa chỉ IP. Hãy thực hiện chẩn đoán theo từng điểm trong sáu điểm của bài viết này trước khi tiêu tốn ngân sách vào việc mở rộng nhóm proxy.

Khi phần kỹ thuật được thiết lập đúng — các tiêu đề khớp với trình duyệt thực, dấu vân tay TLS không phát hiện thư viện, và các yêu cầu mô phỏng hành vi tự nhiên của người dùng — proxy trở thành công cụ thực sự hiệu quả để mở rộng. Đối với việc giám sát giá trên Wildberries và Ozon ở quy mô công nghiệp, chúng tôi khuyên bạn nên bắt đầu với proxy dân cư: chúng cung cấp sự cân bằng tốt nhất giữa chi phí và mức độ tin cậy của các hệ thống chống bot.