Giới hạn tần suất API sàn tiền mã hóa: lỗi 429 nghĩa là gì và cách không vượt

HTTP 429 nghĩa là bạn đã gửi quá nhiều yêu cầu trong một khoảng thời gian, và máy chủ yêu cầu bạn chậm lại. Đó không phải sự cố. Mỗi sàn đếm khác nhau: Binance dùng trọng số cho từng endpoint và chặn IP tiếp tục sau 429, Bybit chặn IP vượt 600 yêu cầu trong năm giây, và OKX đặt giới hạn theo endpoint và trả mã lỗi 50011. Muốn không vượt, hãy đọc header phản hồi, lùi đúng cách và dùng WebSocket khi có thể.

429 thực sự nghĩa là gì

HTTP 429 Too Many Requests là mã trạng thái chuẩn, được định nghĩa đúng cho tình huống này. Tài liệu MDN mô tả nó là client đã gửi quá nhiều yêu cầu trong một khoảng thời gian, và lưu ý header Retry-After có thể cho biết phải đợi bao lâu. Giới hạn có thể áp cho cả máy chủ hoặc một tài nguyên, thường dựa trên IP, nhưng cũng có thể gắn với ứng dụng hoặc người dùng.

Đó là thông điệp hữu ích chứ không phải thất bại. Nó cho biết dịch vụ đang chạy, bạn đã được nhận diện và cần làm gì tiếp. Khi đo tỷ lệ khả dụng trên trang này, chúng tôi giữ nhóm riêng cho giới hạn tần suất, để không báo sàn sập chỉ vì một yêu cầu bị hạn chế.

Binance đếm thế nào: trọng số yêu cầu và chặn IP

Tài liệu API hợp đồng tương lai của Binance mô tả hệ thống trọng số. Mỗi route có trọng số, và endpoint nặng hơn hoặc xử lý nhiều mã tốn hơn. Giới hạn của bạn là tổng trọng số mỗi khoảng, không phải số yêu cầu đơn giản. Giới hạn hiện tại nằm trong mảng rateLimits của /fapi/v1/exchangeInfo.

Các điểm chính trong tài liệu:

• Mỗi phản hồi có X-MBX-USED-WEIGHT-(intervalNum)(intervalLetter), cho biết trọng số đã dùng của IP.
• 429 được trả khi vượt một trong các giới hạn.
• Vượt liên tục, hoặc không lùi sau 429, dẫn đến chặn IP tự động với trạng thái 418.
• Thời gian chặn tăng với người tái phạm, từ 2 phút đến 3 ngày.
• Giới hạn IP dựa trên địa chỉ IP chứ không phải khóa API, nên nhiều chương trình trên một máy dùng chung ngân sách.
• Giới hạn tần suất lệnh được theo dõi riêng, và phản hồi lệnh có header đếm riêng.

Bybit đếm thế nào: theo IP và theo người dùng

Tài liệu v5 của Bybit mô tả hai lớp. Ở lớp IP, mặc định bạn được 600 yêu cầu trong cửa sổ năm giây mỗi IP, cho lưu lượng đến các tên máy chủ API chính. Vượt quá sẽ nhận lỗi 403, access too frequent, và tài liệu nói phải dừng mọi phiên HTTP và đợi ít nhất 10 phút, sau đó lệnh chặn tự gỡ. Lưu ý đây là 403 chứ không phải 429, điều khiến nhiều người bất ngờ.

Ở lớp API, giới hạn áp cho từng người dùng trong cửa sổ trượt, và vượt sẽ trả retCode 10006 với Too many visits! trong JSON. Header phản hồi báo vị trí của bạn:

• X-Bapi-Limit-Status cho biết số yêu cầu còn lại của endpoint hiện tại.
• X-Bapi-Limit cho biết giới hạn hiện tại của endpoint đó.
• X-Bapi-Limit-Reset-Timestamp cho biết khi nào giới hạn đặt lại nếu bạn đã vượt.

Bybit cũng khuyên không chạy ứng dụng sát mép các giới hạn này, vì hoạt động mạng bất thường có thể gây vi phạm ngoài ý muốn. Kết nối WebSocket có giới hạn riêng.

OKX đếm thế nào: theo endpoint và theo công cụ

Tài liệu API của OKX nói yêu cầu bị từ chối trả mã lỗi 50011, giới hạn khác nhau theo từng endpoint và ghi trong chi tiết của endpoint đó. Giới hạn REST công khai không xác thực dựa trên IP, giới hạn đăng nhập và đăng ký WebSocket dựa trên kết nối. Với API giao dịch, đặt, sửa và hủy lệnh có giới hạn độc lập, thường định nghĩa theo công cụ và dùng chung giữa REST và WebSocket.

Bài học từ ba sàn: đừng giả định quy tắc của sàn này cho sàn khác. Mã trạng thái, đơn vị đếm và hình phạt có thể khác, và đều thay đổi theo thời gian, nên hãy quay lại tài liệu hiện hành.

Vì sao bạn chạm giới hạn ngoài ý muốn

Đa số vấn đề giới hạn không đến từ một vòng lặp bận. Chúng đến từ nguyên nhân kém rõ ràng hơn.

• IP dùng chung. Nhiều bot, cổng NAT đám mây hoặc VPN chung đều tính vào một địa chỉ. Hàng xóm có thể tiêu ngân sách của bạn.
• Endpoint nặng. Lấy mọi giá hoặc sổ lệnh sâu có thể tốn gấp nhiều lần yêu cầu một mã. Mười yêu cầu như vậy có thể bằng hàng trăm lệnh gọi đơn giản.
• Bão thử lại. Lỗi ngắn khiến mọi worker thử lại cùng lúc. Đợt đó đẩy bạn vào 429, kích hoạt thêm thử lại.
• Vòng khởi động lại. Chương trình tải lại trạng thái khi khởi động, rồi crash và khởi động liên tục, có thể tiêu hết ngân sách chỉ để khởi động.
• Hỏi liên tục thứ luồng có thể cung cấp. Hỏi giá mỗi giây trên 50 mã là 3.000 yêu cầu một phút, trong khi WebSocket giao cùng dữ liệu với chi phí thấp hơn nhiều.

Cách lùi đúng

Khi nhận phản hồi giới hạn, hành vi đúng rất đơn giản và đáng làm một lần, ở một chỗ.

• Ngừng gửi đến sàn đó trong thời gian yêu cầu. Nếu có header Retry-After hoặc dấu thời gian đặt lại, hãy theo. Nếu không, đợi, bắt đầu khoảng một giây.
• Dùng lùi theo cấp số nhân kèm ngẫu nhiên. Nhân đôi thời gian đợi sau mỗi lỗi liên tiếp, có trần, và thêm ngẫu nhiên để các worker không cùng thử lại.
• Dùng chung bộ giới hạn giữa các worker. Một token bucket cho mỗi IP và sàn, dùng chung cho mọi tiến trình trên địa chỉ đó, hiệu quả hơn nhiều so với mỗi worker tự đoán.
• Theo dõi mức dùng liên tục. Đọc header trọng số trên mỗi phản hồi và chậm lại khi gần giới hạn thay vì đợi bị báo.
• Coi 418 và chặn IP là tín hiệu dừng. Dừng và báo người vận hành. Tiếp tục sẽ kéo dài lệnh chặn.

Cách dùng ít yêu cầu hơn

Yêu cầu rẻ nhất là yêu cầu bạn không gửi.

• Dùng WebSocket cho dữ liệu thị trường và cập nhật tài khoản. Một luồng thay cho hỏi liên tục, và cập nhật còn đến sớm hơn.
• Lưu đệm dữ liệu ít đổi. Đặc tả hợp đồng và biểu phí ít thay đổi. Lấy thỉnh thoảng thay vì mỗi lần chạy.
• Dùng endpoint gộp cẩn thận. Chúng tiết kiệm nhiều yêu cầu, nhưng hãy xem trọng số vì mỗi lệnh gọi tốn hơn.
• Chỉ yêu cầu độ sâu cần thiết. Yêu cầu sổ lệnh sâu tốn hơn, và nhiều việc chỉ cần vài mức đầu.
• Tránh hỏi trạng thái lệnh trong vòng lặp. Luồng dữ liệu người dùng báo khi lệnh khớp.

Nếu chỉ cần funding rate hoặc số liệu độ tin cậy, có thể bạn không cần hỏi sàn. Chúng tôi công bố dữ liệu dưới dạng tệp JSON miễn phí, cập nhật theo lịch, dù không nên dùng cho quyết định giao dịch cần dữ liệu trực tiếp.

429 lúc khẩn cấp

Lúc tệ nhất để chạm giới hạn là khi đang cố hủy lệnh trong thị trường giảm. Vòng lặp của bạn đang dồn API, ngân sách hết, và giờ lệnh hủy bị từ chối. Hãy lên kế hoạch: giữ lưu lượng liên quan lệnh trong ngân sách dành riêng, tách khỏi việc hỏi dữ liệu thị trường. Giữ dữ liệu công khai trên luồng để không dùng ngân sách REST. Tài liệu Binance ghi rằng khi nút máy chủ đang bảo vệ cấp hệ thống và hạn chế yêu cầu, lệnh đóng vị thế, reduce-only và hủy được miễn, cho thấy dùng các loại lệnh này để giảm rủi ro là thói quen khôn ngoan. Hướng dẫn phải làm gì trong sự cố đề cập chuẩn bị liên quan.

Giới hạn hay sự cố?

Hai thứ có thể giống nhau trên bảng theo dõi, vì đều tạo lỗi. Hãy tách theo mã.

• 429, 418 hoặc mã giới hạn riêng của sàn: lưu lượng của bạn có lẽ là nguyên nhân.
• 403: có thể là tường lửa web, chặn khu vực hoặc giới hạn IP của Bybit. Xem hướng dẫn 403 và 451.
• 5xx hoặc hết thời gian: có lẽ phía sàn hoặc trên đường đi. Xem sàn có sập không.

Hãy ghi mã, endpoint và header phản hồi cho mọi lỗi. Không có chúng, bạn chỉ đoán.

Câu hỏi thường gặp về giới hạn tần suất

Dùng nhiều khóa API có tránh được giới hạn không?

Không với giới hạn theo IP, như trọng số IP của Binance. Nhiều khóa từ cùng địa chỉ dùng chung ngân sách. Giới hạn lệnh có thể theo tài khoản, nên hãy xem từng loại được đếm thế nào. Rải lưu lượng qua nhiều địa chỉ chỉ để né giới hạn có thể vi phạm điều khoản sàn, và chúng tôi không khuyên làm.

Lệnh chặn kéo dài bao lâu?

Tùy sàn. Tài liệu Binance nêu lệnh chặn tăng từ 2 phút đến 3 ngày với người tái phạm. Bybit nói đợi ít nhất 10 phút sau 403, access too frequent. Tiếp tục gửi trong lúc bị chặn có thể kéo dài nó.

Có thể xin giới hạn cao hơn không?

Một số sàn có giới hạn cao hơn cho nhà tạo lập, bậc VIP hoặc theo đơn. Hãy xem tài liệu. Bước đầu tốt hơn thường là giảm lưu lượng không cần thiết, vì nó cũng làm hệ thống vững hơn.

Giữ dưới giới hạn

1. Đọc quy tắc giới hạn của đúng API bạn dùng.
2. Ghi header trọng số và chậm lại trước khi chạm giới hạn.
3. Dùng chung một bộ giới hạn cho mọi worker trên một IP.
4. Khi có phản hồi giới hạn, lùi kèm ngẫu nhiên và tuân theo Retry-After.
5. Dừng và cảnh báo khi gặp 418 hoặc lệnh chặn.
6. Chuyển dữ liệu thị trường sang WebSocket.
7. Dành ngân sách cho lệnh hủy.

Đọc thêm: Vì sao API sàn trả về 403 hoặc 451 · Cách sửa lỗi Binance -1021 · Cách kiểm tra sàn có bị sập không

Nguồn

Binance · Giới hạn · Bybit · Quy tắc giới hạn · OKX · Tài liệu API · MDN · 429 · Về Tickmark