Lỗi HTTP 429 Too Many Requests: Nguyên nhân và Cách khắc phục

Lỗi HTTP 429 là gì?

Lỗi HTTP 429 là mã trạng thái lỗi phía client có nghĩa là Too Many Requests (Quá nhiều yêu cầu). Máy chủ thông báo rằng bạn đã gửi quá nhiều yêu cầu trong một khoảng thời gian nhất định, và tạm thời từ chối xử lý thêm cho đến khi bạn giảm tốc độ.

Lỗi này được định nghĩa trong RFC 6585 và là một phần của cơ chế giới hạn tốc độ (rate limiting) trong HTTP. Đây là một trong những lỗi phổ biến nhất mà lập trình viên gặp phải khi làm việc với API, nhưng người dùng thông thường cũng có thể thấy lỗi này khi duyệt web.

Mã trạng thái 429 khác với các lỗi 4xx khác. Lỗi 403 có nghĩa là bạn không được phép truy cập. Lỗi 401 có nghĩa là bạn chưa xác thực. Còn lỗi 429 có nghĩa là thông tin xác thực của bạn hoàn toàn hợp lệ — bạn chỉ đang gửi yêu cầu quá nhanh mà thôi.

Khi máy chủ trả về phản hồi 429, nó có thể kèm theo header Retry-After cho bạn biết chính xác cần đợi bao lâu trước khi gửi yêu cầu tiếp theo.

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

Lỗi 429 hiển thị khác nhau tùy vào trình duyệt, ứng dụng hoặc API client bạn đang sử dụng. Dưới đây là những dạng phổ biến nhất:

Khác với lỗi 500 là sự cố phía máy chủ, lỗi 429 là lỗi phía client — máy chủ vẫn hoạt động bình thường, nhưng đang tự bảo vệ trước lượng yêu cầu quá lớn.

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à máy chủ sử dụng để kiểm soát số lượng yêu cầu mà một client có thể gửi trong một khoảng thời gian nhất định. Khi vượt quá giới hạn, máy chủ sẽ trả về mã HTTP 429.

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

• Fixed Window (Cửa sổ cố định) — Máy chủ cho phép N yêu cầu trong mỗi khung thời gian (ví dụ: 100 yêu cầu mỗi phút). Bộ đếm được đặt lại theo chu kỳ cố định.

• Sliding Window (Cửa sổ trượt) — Tương tự fixed window, nhưng khung thời gian trượt theo mỗi yêu cầu. Điều này ngăn chặn các đợt bùng nổ tại ranh giới khung thời gian.

• Token Bucket (Xô token) — Máy chủ cấp phát token được nạp lại với tốc độ ổn định. Mỗi yêu cầu tiêu tốn một token. Khi hết token, yêu cầu sẽ bị từ chối.

• Leaky Bucket (Xô rò rỉ) — Yêu cầu được xử lý với tốc độ không đổi bất kể số lượng đến cùng lúc. Các yêu cầu dư thừa sẽ được xếp hàng hoặc bị loại bỏ.

Hầu hết các API truyền đạt giới hạn tốc độ thông qua header trong phản hồi. Các header phổ biến bao gồm X-RateLimit-Limit (số yêu cầu tối đa cho phép), X-RateLimit-Remaining (số yêu cầu còn lại trong khung thời gian hiện tại) và X-RateLimit-Reset (thời điểm khung thời gian được đặt lại).

Hiểu được thuật toán mà dịch vụ sử dụng sẽ giúp bạn thiết kế client nằm trong giới hạn cho phép và tránh gặp lỗi 429.

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

Lỗi 429 có thể được kích hoạt bởi nhiều tình huống khác nhau. Dưới đây là những nguyên nhân phổ biến nhất, được phân loại theo đối tượng thường gặp phả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 đang duyệt web, hãy thử các cách khắc phục dưới đây. Bắt đầu từ giải pháp đơn giản nhất rồi tiến dần đến các bước phức tạp hơn.

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

Cách đơn giản nhất là chờ đợi. Lỗi 429 chỉ là tạm thời — máy chủ yêu cầu bạn giảm tốc độ, không phải chặn bạn vĩnh viễn.

Hãy đợi từ 30 giây đến vài phút rồi thử lại. Hầu hết giới hạn tốc độ sẽ được đặt lại trong vòng 1–5 phút. Nếu trang vẫn hiện lỗi 429, hãy đợi lâu hơn — một số dịch vụ áp dụng giới hạn theo giờ hoặc theo ngày.

Tuyệt đối không tải lại trang liên tục. Mỗi lần tải lại sẽ gửi thêm một yêu cầu và có thể kéo dài thời gian bị giới hạn.

2. Xóa cache và cookie trình duyệt

Đôi khi dữ liệu cache hoặc cookie có thể kích hoạt giới hạn tốc độ. Xóa chúng có thể giúp giải quyết vấn đề:

• Chrome: Nhấn Ctrl+Shift+Delete (Windows) hoặc Cmd+Shift+Delete (Mac) → chọn "Cookie" và "Hình ảnh đã lưu trong bộ nhớ đệm" → nhấn "Xóa dữ liệu"

• Firefox: Nhấn Ctrl+Shift+Delete → chọn "Bộ nhớ đệm" và "Cookie" → nhấn "Xóa ngay"

• Edge: Nhấn Ctrl+Shift+Delete → chọn "Cookie" và "Dữ liệu đã lưu trong bộ nhớ đệm" → nhấn "Xóa ngay"

• Safari: Vào Safari → Cài đặt → Quyền riêng tư → Quản lý dữ liệu website → Xóa tất cả

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

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

Nếu bạn đang sử dụng VPN hoặc proxy, bạn có thể đang chia sẻ đị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 quá 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 kết nối VPN và truy cập trang web 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 sử dụng VPN, hãy thử chuyển sang vị trí máy chủ khác để lấy địa chỉ IP mới.

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

Một số tiện ích mở rộng trình duyệt gửi yêu cầu nền mà bạn không biết. Các công cụ chặn quảng cáo, so sánh giá, tiện ích SEO và plugin tự động tải lại đều có thể tạo thêm yêu cầu kích hoạt giới hạn tốc độ.

Để kiểm tra, hãy mở trang web trong cửa sổ ẩn danh/riêng tư (chế độ này mặc định tắt hầu hết tiện ích mở rộng). Nếu lỗi 429 biến mất, một trong các tiện ích mở rộng của bạn chính là thủ phạm.

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 tiện ích.

5. Thử kết nối mạng khác

Nếu không có cách nào hiệu quả, máy chủ có thể đang giới hạn cụ thể địa chỉ IP của bạn. Hãy thử:

Chuyển từ Wi-Fi sang dữ liệu di động (điều này sẽ cấp cho bạn IP khác). Thử truy cập trang web từ một mạng hoàn toàn khác. Nếu bạn đang dùng mạng công ty hoặc trường học, hãy thử từ nhà — các mạng lớn thường chia sẻ chung một IP công cộng.

Bạn có thể kiểm tra địa chỉ IP hiện tại bằng công cụ IP của tôi là gì để xác nhận IP đã thay đổi.

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

Nếu bạn đang xây dựng ứng dụng gọi API, lỗi 429 có nghĩa là code của bạn đang gửi yêu cầu quá nhanh. Dưới đây là cách xử lý đúng cách.

1. Triển khai Exponential Backoff

Exponential backoff là chiến lược thử lại tiêu chuẩn trong ngành. Thay vì thử lại ngay lập tức khi gặp 429, bạn tăng dần thời gian chờ giữa các lần thử:

Lần thử đầu: đợi 1 giây. Lần thử thứ hai: đợi 2 giây. Lần thử thứ ba: đợi 4 giây. Lần thử thứ tư: đợi 8 giây. Và cứ tiếp tục như vậy.

Dưới đây là đoạn code mẫu bằng JavaScript:

async function fetchWithBackoff(url, options = {}, maxRetries = 5) {
  for (let attempt = 0; attempt < maxRetries; attempt++) {
    const response = await fetch(url, options);
    
    if (response.status !== 429) return response;
    
    // Check Retry-After header first
    const retryAfter = response.headers.get('Retry-After');
    const delay = retryAfter
      ? parseInt(retryAfter) * 1000
      : Math.pow(2, attempt) * 1000; // Exponential backoff
    
    console.log(`Rate limited. Retrying in ${delay / 1000}s...`);
    await new Promise(resolve => setTimeout(resolve, delay));
  }
  throw new Error('Max retries exceeded');
}

Hãy thêm jitter (biến động ngẫu nhiên) vào thời gian chờ để tránh nhiều client cùng thử lại vào đúng cùng một thời điểm. Thay thế công thức tính delay bằng Math.pow(2, attempt) * 1000 + Math.random() * 1000.

2. Tuân thủ header Retry-After

Khi máy chủ trả về phản hồi 429, nó thường kèm theo header Retry-After cho bạn biết chính xác cần đợi bao lâu. Header này có thể chứa số giây hoặc một ngày giờ HTTP cụ thể:

Retry-After: 60 nghĩa là đợi 60 giây. Retry-After: Thu, 06 Mar 2026 12:00:00 GMT nghĩa là đợi đến thời điểm đó.

Luôn kiểm tra header này trước khi áp dụng logic backoff riêng của bạn. Máy chủ biết rõ hơn code của bạn về thời gian cần đợi.

import requests
import time

def make_request(url):
    response = requests.get(url)
    
    if response.status_code == 429:
        retry_after = response.headers.get('Retry-After', '5')
        wait_time = int(retry_after)
        print(f"Rate limited. Waiting {wait_time} seconds...")
        time.sleep(wait_time)
        return make_request(url)  # Retry after waiting
    
    return response

3. Cache phản hồi API

Nếu ứng dụng của bạn thực hiện cùng một lệnh gọi API nhiều lần, hãy lưu phản hồi vào bộ nhớ đệm thay vì gọi API mỗi lần. Điều này giảm đáng kể số lượng yêu cầu.

Sử dụng bộ nhớ đệm trong RAM (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ý dựa trên tần suất thay đổi của dữ liệu.

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ả thường không thay đổi trong 5 phút tiếp theo — hãy cache lại.

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);
  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 đang polling (truy vấn liên tục) 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ủ sẽ chủ động đẩy cập nhật đến ứng dụng của bạn khi có thay đổi — không cần polling liên tục. Điều này có thể giảm số lượng lệnh gọi API từ hàng ngàn xuống chỉ còn vài cuộc mỗi giờ.

Hầu hết các API hiện đại (Stripe, GitHub, Twilio, Shopify) đều hỗ trợ webhook. Hãy kiểm tra 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ực sự cần nhiều lệnh gọi API 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 yêu cầu nâng giới hạn, hãy giải thích mục đích sử dụng và cung cấp ước tính về số lượng yêu cầu dự kiến. Các dịch vụ như Google APIs, Twitter API và GitHub API đều có quy trình để yêu cầu nâng cấp giới hạn.

Một số API còn cung cấp endpoint hàng loạt (bulk endpoint) cho phép bạn lấy nhiều tài nguyên trong một yêu cầu duy nhất, 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 hợp lệ gặp lỗi 429, giới hạn tốc độ của bạn có thể quá nghiêm ngặt. Hãy xem xét và điều chỉnh lại.

Trong Nginx, module giới hạn tốc độ (ngx_http_limit_req_module) kiểm soát tần suất yêu cầu:

# 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/ {
        # Allow bursts of 20, no delay for first 10
        limit_req zone=api burst=20 nodelay;
        limit_req_status 429;
    }
}

Tham số burst rất quan trọng — nó cho phép các đợt tăng lưu lượng ngắn hạn mà không kích hoạt lỗi 429. Nếu không có nó, ngay cả lưu lượng duyệt web bình thường cũng có thể chạm giới hạn.

Trong Apache, sử dụng mod_ratelimit hoặc mod_evasive. Trong Node.js, sử dụng các package như express-rate-limit.

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 thêm địa chỉ IP của chúng vào danh sách cho phép.

Trong Nginx, bạn có thể sử dụng map để bỏ qua giới hạn tốc độ cho các IP tin cậy:

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 thời hãy cho phép bot công cụ tìm kiếm (Googlebot, Bingbot) nếu chúng đang bị giới hạn — chặn chúng sẽ ảnh hưởng xấu đến SEO. Bạn có thể xác minh danh tính bot bằng tra cứu DNS ngược.

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

Nếu bạn sử dụng Cloudflare, AWS WAF, Sucuri hoặc dịch vụ bảo mật tương tự, quy tắc giới hạn tốc độ của chúng có thể là nguồn gây ra lỗi 429 — không phải máy chủ gốc của bạn.

Trong Cloudflare, hãy kiểm tra Security → WAF → Rate Limiting Rules. Bạn có thể xem quy tắc nào đang kích hoạt và điều chỉnh ngưỡng. Chế độ "I'm Under Attack" của Cloudflare đặc biệt nghiêm ngặt.

Trong AWS WAF, kiểm tra các quy tắc web ACL cho rate-based rules. Ngưỡng tối thiểu là 100 yêu cầu mỗi 5 phút — hãy đảm bảo con số này phù hợp với mức lưu lượng truy cập của bạn.

Xem lại phân tích CDN để phân biệt giữa lưu lượng hợp lệ và lưu lượng bot trước khi điều chỉnh giới hạn.

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

Đôi khi lỗi 429 xuất hiện vì máy chủ không thể xử lý tải, và giới hạn tốc độ tự kích hoạt như một cơ chế bảo vệ. Cải thiện hiệu suất máy chủ cho phép bạn nâng giới hạn một cách an toàn.

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

Sử dụng công cụ HTTP Headers của chúng tôi để kiểm tra xem header cache của bạn đã được cấu hình đú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 lẫn với các mã trạng thái HTTP khác. Dưới đây là bảng so sánh chi tiết:

Điểm khác biệt quan trọng: 429 là tạm thời và có chủ đích. Máy chủ hoạt động bình thường — nó chủ động từ chối yêu cầu của bạn để tự bảo vệ. Các lỗi 5xx khác cho thấy có điều gì đó thực sự bị hỏng.

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

Phòng bệnh hơn chữa bệnh. Dưới đây là các phương pháp tốt nhất để tránh gặp lỗi 429 ngay từ đầu:

• Đọc tài liệu API — Nắm rõ giới hạn tốc độ trước khi viết code. Hầu hết dịch vụ công bố giới hạn rõ ràng trong tài liệu.

• Giám sát mức sử dụng — Theo dõi header X-RateLimit-Remaining để biết bạn còn bao xa so với giới hạn.

• Gom nhóm yêu cầu — Sử dụng endpoint hàng loạt khi có sẵn thay vì gọi từng lệnh riêng lẻ.

• Phân bổ yêu cầu đều — Rải đều các lệnh gọi API theo thời gian thay vì gửi dồn dập.

• Sử dụng API key — Yêu cầu đã xác thực thường được cấp giới hạn tốc độ cao hơn so với yêu cầu ẩn danh.

• Triển khai circuit breaker — Nếu liên tục gặp lỗi 429, ngừng hoàn toàn việc gửi yêu cầu trong một khoảng thời gian hạ nhiệt.

• Kiểm tra với trình mô phỏng — Giả lập phản hồi 429 trong môi trường development để đảm bảo xử lý lỗi hoạt động đú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 hóa mẫu yêu cầu.