429 Too Many Requests — Ai đang giới hạn bạn?

Ai đang giới hạn?

Xác định nguồn trước khi thay đổi bất cứ thứ gì. Bản thân response thường đã cho biết, nếu bạn nhìn vào header thay vì chỉ nhìn trang hiển thị.

Retry-After: header nói cho bạn biết phải làm gì

Một 429 được viết đúng chuẩn sẽ kèm header Retry-After, và đó là thông tin hữu ích nhất trong toàn bộ response.

Nó có hai dạng: số giây cần chờ, hoặc một mốc thời gian HTTP để chờ tới. Dù dạng nào thì đó cũng là máy chủ nói thẳng khi nào nó sẽ nhận yêu cầu trở lại — tốt hơn nhiều so với tự đoán.

Nếu bạn đang viết client, hãy đọc và tuân theo nó. Thử lại ngay lập tức sau khi nhận 429 chính là hành vi khiến địa chỉ IP bị chặn hẳn thay vì chỉ bị làm chậm, vì nhìn từ phía máy chủ nó không khác gì một cuộc tấn công.

Nếu bạn là bên phát ra 429, hãy gửi kèm nó. Không có Retry-After, client viết tốt buộc phải đoán, còn client viết dở sẽ dội vào bạn liên tục.

Nguyên nhân thường gặp, phổ biến nhất trước

• Code gọi API trong vòng lặp mà không điều tiết nhịp độ. Duyệt vài nghìn bản ghi rồi gọi API cho từng bản ghi sẽ chạm giới hạn của hầu hết mọi API chỉ trong vài giây.
• Không cache các lệnh gọi lặp lại. Lấy cùng một tỷ giá hay cùng dữ liệu sản phẩm ở mỗi lượt tải trang nghĩa là nhân số yêu cầu với lượng truy cập.
• Hệ thống chống bot cảnh báo nhầm với lưu lượng hợp lệ. Cloudflare và các công cụ tương tự đôi khi xếp công cụ giám sát, trình đọc feed hay một crawler chăm chỉ nhưng trung thực vào nhóm lạm dụng.
• Dùng chung địa chỉ IP. Trên shared hosting hoặc sau NAT của công ty, bạn thừa hưởng cả danh tiếng lẫn số lượng yêu cầu của mọi người dùng chung địa chỉ đó.
• wp-cron hoặc kiểu polling tương tự trên site đông khách. WordPress kích hoạt cron theo lượt xem trang; site lưu lượng cao có thể tạo ra hàng trăm yêu cầu nội bộ mỗi phút.
• Vòng lặp thử lại không có backoff. 429 đầu tiên kích hoạt một lần thử lại, lần đó lại nhận 429, lại kích hoạt thử lại — biến một giới hạn ngắn hạn thành một lệnh chặn kéo dài.
• Endpoint đăng nhập hoặc form bị dò mật khẩu. Ở đây 429 đang làm đúng việc của nó và cách xử lý đúng là để yên.

Nếu code của bạn bị giới hạn: hãy lùi lại đúng cách

Khi bạn ở phía client, hành vi đúng đã có chuẩn mực rõ ràng và đáng để viết cho tử tế một lần.

Dùng exponential backoff kèm jitter. Chờ 1 giây, rồi 2, rồi 4, rồi 8 — và cộng thêm một lượng ngẫu nhiên nhỏ mỗi lần. Phần ngẫu nhiên rất quan trọng: không có nó, mọi client cùng thất bại một lúc sẽ cùng thử lại một lúc, tạo thành một đợt sóng đồng bộ khiến tất cả tiếp tục bị giới hạn.

Tuân theo Retry-After khi có. Nó thắng giá trị bạn tự tính, vì máy chủ biết rõ hơn thuật toán của bạn.

Giới hạn số lần thử lại. Vòng lặp thử lại vô hạn biến giới hạn tạm thời thành lệnh chặn vĩnh viễn, đồng thời che giấu vấn đề thật khỏi tầm mắt bạn.

Cache thật mạnh tay. Yêu cầu rẻ nhất là yêu cầu không bao giờ được gửi. Dữ liệu thay đổi theo giờ không cần lấy lại ở mỗi lượt xem trang, và một lớp cache ngắn thường xóa sạch vấn đề rate limit.

Gộp lô nếu API hỗ trợ. Một yêu cầu lấy một trăm bản ghi tốt hơn một trăm yêu cầu lấy từng bản ghi, vì hầu hết API đếm số yêu cầu chứ không đếm số bản ghi.

Nếu khách truy cập của bạn nhận 429

• Xác định là máy chủ hay CDN. Trang lỗi cho biết: trang có thương hiệu kèm ray ID là CDN, trang trơn là máy chủ.
• Xem lại mẫu yêu cầu thật trong access log trước khi nới lỏng bất cứ điều gì. Nếu lưu lượng đó thực sự bất thường, giới hạn đang hoạt động đúng và nên giữ nguyên.
• Tìm các cảnh báo nhầm với bot tốt. Googlebot, công cụ giám sát uptime và trình đọc feed hợp lệ có thể vướng vào quy tắc quá gắt — và giới hạn Googlebot sẽ khiến bạn mất thứ hạng.
• Kiểm tra xem chính website của bạn có tạo ra tải đó không. Plugin polling endpoint nội bộ, hay cron cấu hình sai, có thể ăn hết hạn mức trước khi khách thật kịp tới.
• Bật cache trang trước khi nâng giới hạn. Trang đã cache thậm chí không chạm tới bộ đếm, tức là xử lý nguyên nhân chứ không phải triệu chứng.
• Đặt giới hạn theo từng endpoint thay vì đặt chung. Endpoint đăng nhập và API xứng đáng bị siết chặt; trang nội dung tĩnh thường không cần giới hạn gì cả.

Vì sao nâng giới hạn thường là bước sai đầu tiên

Bản năng khi thấy 429 là đi nâng ngưỡng. Đôi khi điều đó đúng, nhưng thường xuyên hơn nó biến một vấn đề thành một vấn đề tệ hơn.

Rate limit tồn tại để bảo vệ năng lực hữu hạn. Nâng ngưỡng mà không tăng năng lực nghĩa là những yêu cầu đó giờ sẽ chạm tới ứng dụng, ăn worker và bộ nhớ, và bạn đổi một mã 429 gọn gàng lấy một website chậm hoặc một mã 503 — trải nghiệm tệ hơn với chi phí cao hơn.

Trình tự tốt hơn là: cache trước, để phần lớn yêu cầu không bao giờ chạm bộ đếm; sửa những thứ tạo ra tải không cần thiết; rồi nếu nhu cầu thật vẫn vượt giới hạn, hãy nâng nó lên kèm theo năng lực đủ để phục vụ.

Ngoại lệ là giới hạn vốn được đặt quá thấp so với lưu lượng bình thường ngay từ đầu. Nếu access log cho thấy khách bình thường duyệt web bình thường mà vẫn chạm giới hạn, đó là lỗi cấu hình và nâng ngưỡng chính là cách sửa đúng.