Lỗi HTTP 429 (Too Many Requests) là gì? Cách khắc phục

Lỗi HTTP 429 là gì?

HTTP 429 Too Many Requests nghĩa là máy chủ đang giới hạn tốc độ của bạn: bạn, địa chỉ IP của bạn hoặc ứng dụng của bạn đã gửi nhiều yêu cầu hơn mức máy chủ cho phép trong một khoảng thời gian. Lỗi này chỉ là tạm thời. Máy chủ vẫn hoạt động, chỉ là nó chọn không trả lời bạn trong lúc này.

Mã này được thêm vào trong RFC 6585 (2012) đúng cho trường hợp này, và phản hồi có thể kèm header Retry-After cho biết cần chờ bao lâu. Bạn có thể gặp lỗi này khi lướt các website đông người truy cập, gọi API, tải hàng loạt, hoặc khi dùng VPN có địa chỉ IP được nhiều người dùng chung.

Nó khác với các mã lân cận: 401 nghĩa là bạn chưa đăng nhập, 403 nghĩa là bạn không được phép, còn 429 nghĩa là bạn được phép, chỉ là đang gửi quá nhanh.

Lỗi 429 hiển thị như thế nào?

Thông báo phụ thuộc vào nơi trả lời yêu cầu. Đây là những dạng mọi người hay tìm nhất:

Khác với lỗi 500 nghĩa là có thứ gì đó hỏng trên máy chủ, theo cách phân loại của HTTP thì 429 là lỗi phía client: máy chủ đang tự bảo vệ trước quá nhiều yêu cầu.

Cơ chế giới hạn tốc độ (rate limiting) hoạt động như thế nào?

Giới hạn tốc độ (rate limiting) là kỹ thuật máy chủ dùng để kiểm soát số yêu cầu một client được gửi trong một khoảng thời gian. Khi vượt giới hạn, máy chủ thường trả về 429 (một số trả về 403 hoặc 503).

Có vài thuật toán giới hạn tốc độ phổ biến:

• Fixed Window — Máy chủ cho phép N yêu cầu trong mỗi cửa sổ thời gian (ví dụ 100 yêu cầu mỗi phút). Bộ đếm được đặt lại theo các mốc cố định.
• Sliding Window — Giống fixed window nhưng cửa sổ thời gian trượt theo từng yêu cầu. Cách này ngăn các đợt tăng đột biến ở ranh giới cửa sổ.
• Token Bucket — Máy chủ cấp các token được nạp lại với tốc độ đều. Mỗi yêu cầu tiêu tốn một token. Hết token thì yêu cầu bị từ chối.
• Leaky Bucket — Yêu cầu được xử lý ở tốc độ không đổi bất kể đợt yêu cầu lớn đến đâu. Yêu cầu dư sẽ xếp hàng hoặc bị loại bỏ.

Nhiều API công bố giới hạn trong header phản hồi. Ví dụ của GitHub là x-ratelimit-limit (số yêu cầu được phép mỗi giờ), x-ratelimit-remaining, x-ratelimit-used và x-ratelimit-reset (thời điểm cửa sổ được đặt lại, tính bằng giây Unix). Một bản nháp của IETF đề xuất các header chuẩn RateLimit và RateLimit-Policy cho cùng mục đích.

Biết dịch vụ dùng thuật toán và cửa sổ thời gian nào sẽ giúp bạn thiết kế client để luôn nằm trong giới hạn.

Nguyên nhân phổ biến gây ra lỗi HTTP 429

Nguyên nhân phụ thuộc vào việc ai là người gặp lỗi:

Cách sửa lỗi 429 (dành cho người dùng)

Nếu bạn gặp lỗi 429 khi lướt web, đây là các cách sửa bạn có thể thử. Hãy bắt đầu từ cách đơn giản nhất rồi lần lượt đi xuống.

1. Đợi rồi thử lại

Cách đơn giản nhất là chờ. Lỗi 429 chỉ là tạm thời: máy chủ đang yêu cầu bạn chậm lại, chứ không cấm bạn.

Thời gian chờ phụ thuộc vào giới hạn của website: có nơi đặt lại trong vòng một phút, có nơi theo giờ hoặc theo ngày. Nếu trang hoặc API gửi header Retry-After, đó chính là thời gian chờ chính xác. Sau đó hãy tải trang đúng một lần.

Đừng liên tục tải lại: mỗi lần tải lại là một yêu cầu nữa và vẫn bị tính vào cùng giới hạn đó.

2. Xóa cookie của website đó

Cách này hiếm khi có tác dụng, nhưng một số website đếm yêu cầu theo cookie phiên. Hãy xóa cookie của riêng website đó để có phiên mới mà không bị đăng xuất khỏi mọi trang khác:

• Chrome / Edge: mở chrome://settings/content/all (Edge: edge://settings/content/all), tìm website rồi xóa dữ liệu của nó
• Firefox: bấm biểu tượng ổ khóa trên thanh địa chỉ → "Clear cookies and site data…"
• Safari: Safari → Cài đặt → Quyền riêng tư → Quản lý dữ liệu trang web → chọn website → Xóa

Sau khi xóa, hãy đóng và mở lại trình duyệt trước khi truy cập lại website.

3. Ngắt kết nối VPN hoặc proxy

Nếu bạn đang dùng VPN hoặc proxy, bạn có thể đang chung địa chỉ IP với hàng trăm người dùng khác. Khi tổng số yêu cầu của họ vượt giới hạn của máy chủ, tất cả mọi người trên IP đó đều bị giới hạn tốc độ.

Hãy thử ngắt VPN và truy cập website bằng kết nối internet thông thường. Nếu lỗi 429 biến mất thì IP của VPN chính là nguyên nhân.

Nếu bạn cần dùng VPN, hãy chuyển sang một vị trí máy chủ khác: địa chỉ của nó có thể được ít người dùng chung hơn.

4. Tắt tiện ích mở rộng trình duyệt

Một số tiện ích mở rộng gửi yêu cầu ngầm đến các website bạn truy cập: công cụ theo dõi giá, công cụ SEO và tiện ích tự động tải lại có thể cộng dồn đến mức chạm giới hạn. (Trình chặn quảng cáo thường làm ngược lại và giảm số yêu cầu.)

Để kiểm tra, hãy mở website trong cửa sổ ẩn danh/riêng tư, nơi hầu hết tiện ích đã tắt. Chế độ ẩn danh cũng bắt đầu mà không có cookie, nên nếu lỗi 429 biến mất thì có liên quan đến một tiện ích hoặc giới hạn theo phiên.

Hãy tắt từng tiện ích một để tìm ra tiện ích gây lỗi. Trong Chrome, vào chrome://extensions/ và tắt từng cái.

5. Kiểm tra xem IP của bạn có đang dùng chung không

Nhiều người có thể dùng chung một địa chỉ IP công cộng: mạng văn phòng hoặc trường học, mạng của nhà mạng di động (CGNAT) hoặc máy chủ VPN. Yêu cầu của họ bị tính vào cùng giới hạn với bạn.

Nếu bạn đang ở trong mạng như vậy, hãy thử tải website từ mạng nhà riêng hoặc dữ liệu di động của bạn để biết địa chỉ dùng chung có phải nguyên nhân không. Nếu giới hạn nằm ở chính địa chỉ của bạn, hãy chờ nó được đặt lại thay vì đổi mạng để né giới hạn. Bạn có thể xem IP công cộng hiện tại bằng IP Của Tôi Là Gì.

Cách sửa lỗi 429 (dành cho lập trình viên)

Nếu code của bạn nhận lỗi 429, nghĩa là nó gửi yêu cầu nhanh hơn mức API cho phép. Hãy xử lý theo thứ tự: đọc Retry-After, lùi lại với jitter, rồi giảm số yêu cầu bạn gửi.

1. Triển khai exponential backoff

Exponential backoff là chiến lược thử lại tiêu chuẩn: thay vì thử lại ngay sau lỗi 429, hãy tăng gấp đôi thời gian chờ mỗi lần (1 giây, 2, 4, 8…) và thêm jitter, tức một khoảng trễ ngẫu nhiên, để nhiều client không cùng thử lại một lúc.

Phiên bản này dùng Retry-After khi máy chủ gửi giá trị hợp lệ ở một trong hai định dạng, nếu không thì quay về backoff có jitter, và bỏ cuộc sau vài lần thử. (Khi trình duyệt gọi API của website khác, chỉ đọc được Retry-After nếu API công khai nó bằng Access-Control-Expose-Headers.)

async function fetchWithBackoff(url, options = {}, maxRetries = 5) {
  for (let attempt = 0; attempt <= maxRetries; attempt++) {
    const response = await fetch(url, options);
    if (response.status !== 429 || attempt === maxRetries) return response;

    // Retry-After is either a number of seconds or an HTTP date
    const header = response.headers.get('Retry-After');
    let delay = NaN;
    if (header) {
      const seconds = Number(header);
      delay = Number.isNaN(seconds) ? Date.parse(header) - Date.now() : seconds * 1000;
    }
    if (!Number.isFinite(delay)) delay = 2 ** attempt * 1000 + Math.random() * 1000; // backoff + jitter
    await new Promise((resolve) => setTimeout(resolve, Math.max(delay, 0)));
  }
}

2. Tuân thủ header Retry-After

Khi máy chủ gửi Retry-After kèm 429, nó cho biết chính xác cần chờ bao lâu. RFC 9110 cho phép hai dạng: số giây hoặc ngày giờ HTTP.

Retry-After: 60 nghĩa là chờ 60 giây. Retry-After: Wed, 21 Oct 2026 07:28:00 GMT nghĩa là chờ đến thời điểm đó. Hãy kiểm tra nó trước logic backoff của bạn: máy chủ biết rõ hơn code của bạn.

Trong Python, hãy xử lý cả hai dạng và dừng sau vài lần thử thay vì đệ quy mãi:

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

import requests


def get_with_retry(url, max_retries=5):
    for attempt in range(max_retries + 1):
        response = requests.get(url)
        if response.status_code != 429 or attempt == max_retries:
            return response
        retry_after = response.headers.get("Retry-After", "")
        try:
            if retry_after.isdigit():
                wait = int(retry_after)
            else:  # an HTTP date
                wait = (parsedate_to_datetime(retry_after) - datetime.now(timezone.utc)).total_seconds()
        except (TypeError, ValueError):  # missing or unparseable: back off with jitter
            wait = 2 ** attempt + random.random()
        time.sleep(max(wait, 0))

3. Cache phản hồi API

Nếu ứng dụng của bạn gọi cùng một API nhiều lần, hãy cache phản hồi thay vì gọi API mỗi lần. Cách này giảm mạnh số yêu cầu.

Hãy dùng cache trong bộ nhớ (như Redis hoặc một Map đơn giản) cho dữ liệu được truy cập thường xuyên. Đặt TTL (thời gian sống) hợp lý tùy theo tần suất dữ liệu thay đổi.

Ví dụ, nếu bạn đang kiểm tra bản ghi DNS của một tên miền, kết quả nhiều khả năng sẽ không đổi trong 5 phút tới, hãy cache chúng.

const cache = new Map();
const CACHE_TTL = 5 * 60 * 1000; // 5 minutes

async function cachedFetch(url) {
  const cached = cache.get(url);
  if (cached && Date.now() - cached.time < CACHE_TTL) return cached.data;

  const response = await fetch(url);
  if (!response.ok) throw new Error(`HTTP ${response.status}`); // never cache errors (a 429 included)
  const data = await response.json();
  cache.set(url, { data, time: Date.now() });
  return data;
}

4. Sử dụng webhook thay vì polling

Nếu bạn liên tục polling một API để kiểm tra thay đổi (ví dụ: kiểm tra trạng thái đơn hàng mỗi 10 giây), hãy chuyển sang webhook nếu dịch vụ hỗ trợ.

Với webhook, máy chủ tự đẩy cập nhật tới ứng dụng của bạn khi có thay đổi — không cần polling liên tục. Cách này có thể giảm số lệnh gọi API từ hàng nghìn mỗi giờ xuống chỉ còn vài lệnh.

Hầu hết API hiện đại (Stripe, GitHub, Twilio, Shopify) đều hỗ trợ webhook. Hãy xem tài liệu API để biết cách cấu hình webhook.

5. Yêu cầu nâng giới hạn tốc độ

Nếu bạn thật sự cần gọi API nhiều hơn, hãy liên hệ nhà cung cấp dịch vụ. Nhiều API cung cấp giới hạn cao hơn cho gói trả phí hoặc ứng dụng đã được xác minh.

Khi xin giới hạn cao hơn, hãy nêu rõ trường hợp sử dụng và ước tính lượng yêu cầu dự kiến. Nhiều API, trong đó có API của Google, có biểu mẫu hoặc gói trả phí cho giới hạn cao hơn.

Một số API còn có endpoint hàng loạt cho phép lấy nhiều tài nguyên trong một yêu cầu, giúp giảm tổng số lần gọi.

Cách sửa lỗi 429 (dành cho quản trị website)

Nếu người truy cập hoặc người dùng API của bạn gặp lỗi 429, vấn đề nằm ở cấu hình máy chủ của bạn. Dưới đây là cách chẩn đoán và khắc phục.

1. Điều chỉnh giới hạn tốc độ

Nếu người dùng thật gặp lỗi 429, hãy tìm xem lớp nào trả lời trước: CDN hoặc WAF, máy chủ web hay ứng dụng của bạn. Sau đó điều chỉnh giới hạn của lớp đó.

Trong nginx, limit_req đảm nhiệm việc này. Lưu ý rằng mặc định nó trả về 503: hãy thêm limit_req_status 429; để client biết cần chậm lại thay vì nghĩ máy chủ đã sập:

# Define rate limit zone: 10 requests per second per IP
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

server {
    location /api/ {
        # Up to 20 extra requests pass at once (nodelay); more than that get 429
        limit_req zone=api burst=20 nodelay;
        limit_req_status 429;
    }
}

Tham số burst cho phép các đợt tăng đột biến ngắn đi qua mà không bị 429; nếu thiếu nó, một lần tải trang bình thường có nhiều yêu cầu cũng có thể chạm giới hạn.

Apache không có bộ giới hạn tốc độ yêu cầu tích hợp sẵn: mod_ratelimit giới hạn băng thông chứ không giới hạn số yêu cầu, còn mod_evasive của bên thứ ba trả về 403. Hãy dùng reverse proxy, WAF hoặc ứng dụng của bạn để trả 429. Trong Node.js, express-rate-limit mặc định trả về 429.

2. Cho phép IP tin cậy (whitelist)

Nếu một số client nhất định (dịch vụ giám sát, cổng thanh toán, microservice nội bộ) bị giới hạn tốc độ, hãy đưa địa chỉ IP của chúng vào danh sách cho phép.

Trong nginx, geo và map gán khóa rỗng cho các địa chỉ tin cậy, và nginx không đếm các yêu cầu có khóa rỗng. Đoạn này thay cho dòng limit_req_zone ở ví dụ trước:

geo $rate_limit {
    default        1;
    192.168.0.0/16 0;  # Internal network
    10.0.0.0/8     0;  # Internal network
    203.0.113.50   0;  # Payment processor
}

map $rate_limit $limit_key {
    0 "";
    1 $binary_remote_addr;
}

limit_req_zone $limit_key zone=api:10m rate=10r/s;

Đừng vô tình giới hạn tốc độ của các trình thu thập dữ liệu của công cụ tìm kiếm: Google coi 429 là lỗi máy chủ và giảm tốc độ thu thập (Google Search Central). Hãy xác minh yêu cầu thật của Googlebot và Bingbot bằng tra cứu Reverse DNS, sau đó xác nhận bằng tra cứu xuôi tên miền nhận được, hoặc miễn giới hạn cho các dải IP mà các trình thu thập công bố.

3. Kiểm tra cấu hình WAF và CDN

Nếu bạn dùng Cloudflare, AWS WAF, Sucuri hoặc dịch vụ bảo mật khác, quy tắc giới hạn tốc độ của chúng có thể trả lời trước khi máy chủ của bạn nhìn thấy yêu cầu.

Cloudflare hiển thị cho người truy cập "Error 1015: You are being rate limited" khi một quy tắc giới hạn tốc độ được kích hoạt. Hãy tìm quy tắc đó trong các quy tắc bảo mật của bảng điều khiển, xem các sự kiện của nó, rồi nâng ngưỡng hoặc thu hẹp phạm vi.

Quy tắc dựa trên tốc độ của AWS WAF đếm số yêu cầu theo IP (hoặc khóa khác) trong cửa sổ 1, 2, 5 hoặc 10 phút, với giới hạn tối thiểu là 10. Yêu cầu bị chặn mặc định nhận 403; hãy đặt phản hồi tùy chỉnh là 429 để client biết cần lùi lại.

Hãy xem phân tích của CDN để phân biệt người truy cập thật với bot trước khi thay đổi bất cứ điều gì.

4. Tối ưu hóa hiệu suất máy chủ

Một số dịch vụ giới hạn tốc độ chặt hơn khi đang chịu tải, như một van an toàn. Cải thiện hiệu năng máy chủ giúp bạn nâng giới hạn một cách an toàn.

Các tối ưu chính gồm: bật cache phản hồi để giảm tải backend, dùng CDN cho tài nguyên tĩnh, thêm cache truy vấn cơ sở dữ liệu bằng Redis hoặc Memcached, dùng connection pooling cho kết nối cơ sở dữ liệu, và mở rộng theo chiều ngang bằng load balancing nếu lưu lượng đòi hỏi.

Hãy dùng công cụ Kiểm tra HTTP Header của chúng tôi để kiểm tra các header cache đã được đặt đúng chưa.

So sánh lỗi 429 với các lỗi HTTP khác

Lỗi 429 dễ bị nhầm với các mã trạng thái HTTP khác. Đây là điểm khác nhau:

Điểm khác biệt chính: 429 là có chủ đích và tạm thời: máy chủ chọn từ chối bạn trong lúc này. Hầu hết mã 5xx nghĩa là có thứ gì đó hỏng trên máy chủ, dù 503 cũng có thể là bảo trì theo kế hoạch hoặc, trong nginx, là giới hạn tốc độ.

Cách phòng tránh lỗi 429

Phòng bệnh hơn chữa bệnh. Đây là các thực hành tốt nhất để tránh lỗi 429 ngay từ đầu:

• Đọc tài liệu API — Biết giới hạn tốc độ trước khi viết code. Hầu hết dịch vụ công bố rõ giới hạn của mình.
• Theo dõi mức sử dụng — Theo dõi header X-RateLimit-Remaining để biết bạn còn cách giới hạn bao xa.
• Gộp yêu cầu — Dùng endpoint hàng loạt khi có thay vì gọi từng yêu cầu riêng lẻ.
• Phân bổ yêu cầu — Rải đều các lần gọi API theo thời gian thay vì gửi dồn thành đợt.
• Dùng API key — Yêu cầu đã xác thực thường có giới hạn cao hơn yêu cầu ẩn danh.
• Triển khai circuit breaker — Nếu liên tục nhận 429, hãy dừng hẳn việc gửi yêu cầu trong một khoảng nghỉ.
• Kiểm thử bằng trình mô phỏng giới hạn tốc độ — Mô phỏng phản hồi 429 khi phát triển để đảm bảo phần xử lý lỗi hoạt động.
• Ghi log phản hồi 429 — Theo dõi thời điểm và vị trí xảy ra giới hạn tốc độ để tối ưu cách gửi yêu cầu.