Tra Cứu Mã HTTP Status
Tra cứu mã HTTP status đầy đủ. Tìm 60+ mã (100–511) với định nghĩa, link RFC, cờ cacheable và có thể thử lại. Bao gồm 200, 301, 404, 429, 500.
Mã HTTP Status — Tham Chiếu Đầy Đủ Từ 100 đến 511
Mỗi phản hồi HTTP từ server bao gồm mã ba chữ số cho client biết điều gì đã xảy ra. Mã được nhóm thành năm danh mục: 1xx (thông tin), 2xx (thành công), 3xx (chuyển hướng), 4xx (lỗi client), và 5xx (lỗi server). Tham chiếu này liệt kê tất cả 60+ mã đã đăng ký với tên, mô tả, tình huống sử dụng phổ biến, và link tới RFC định nghĩa. Mỗi card còn mang huy hiệu kỹ thuật — Cacheable (theo tập cacheable theo phỏng đoán của RFC 9111), Thử lại được (an toàn để tự động thử lại với backoff), Giữ method và Truyền SEO — để kỹ sư trực ban viết tầng thử lại, cache hay redirect biết ngay một mã có an toàn để thử lại hoặc cache không. Lọc theo danh mục hoặc theo Cacheable/Thử lại được, tìm theo số hoặc từ khóa với luồng curl/Postman/observability trong đầu, và xem hướng dẫn về Retry-After, X-RateLimit và RFC 7807 Problem Details trong phần câu hỏi thường gặp.
Mã trạng thái HTTP là gì và được tổ chức ra sao?
Mã trạng thái HTTP là số ba chữ số được máy chủ trả về để đáp lại yêu cầu của client, được định nghĩa chủ yếu trong RFC 9110 (HTTP Semantics, 2022) thay thế RFC 7231. Chúng được nhóm thành năm lớp theo chữ số đầu: 1xx thông tin (đã nhận yêu cầu, đang tiếp tục), 2xx thành công (yêu cầu được nhận, hiểu và chấp nhận thành công), 3xx chuyển hướng (cần hành động thêm để hoàn thành yêu cầu), 4xx lỗi client (yêu cầu chứa cú pháp sai hoặc không thể đáp ứng), và 5xx lỗi máy chủ (máy chủ thất bại khi đáp ứng một yêu cầu hợp lệ). Sổ đăng ký đầy đủ do IANA duy trì, hiện gồm khoảng 70 mã. Client nên đối xử với mã chưa biết như mã x00 chung của lớp đó — vậy mã mới 499 nên được đối xử như 400 bởi client không nhận ra nó.
Khác biệt giữa 401 Unauthorized và 403 Forbidden là gì?
Hai mã này thường bị nhầm lẫn. 401 Unauthorized nghĩa là "bạn chưa xác thực — hãy cung cấp thông tin đăng nhập." Phản hồi phải bao gồm header WWW-Authenticate cho client biết dùng cơ chế auth nào (Basic, Bearer, Digest). Cùng yêu cầu đó với thông tin đăng nhập hợp lệ sẽ thành công. 403 Forbidden nghĩa là "tôi biết bạn là ai, và bạn không được phép." Xác thực lại sẽ không giúp; thông tin đăng nhập được nhận diện nhưng thiếu quyền cho tài nguyên này. Tên 401 có lịch sử gây nhầm lẫn — "unauthorized" thực sự phải là "unauthenticated." Trong thực tế, nhiều API trả về 401 sai cho lỗi quyền. RFC 9110 nêu rõ 403 nên dùng khi máy chủ hiểu yêu cầu nhưng từ chối ủy quyền. Mã liên quan tinh tế là 407 Proxy Authentication Required, giống 401 nhưng cho máy chủ proxy trong chuỗi.
Khi nào dùng chuyển hướng 301 vs 302 vs 307 vs 308?
Cả bốn đều chuyển hướng, nhưng khác nhau ở hai chiều: vĩnh viễn vs tạm thời, và liệu phương thức yêu cầu có thể thay đổi hay không. 301 Moved Permanently và 308 Permanent Redirect đều báo hiệu tài nguyên đã chuyển vĩnh viễn — công cụ tìm kiếm chuyển giao link equity. 302 Found và 307 Temporary Redirect báo hiệu chuyển tạm thời. Khác biệt bảo toàn phương thức là then chốt: 301 và 302 lịch sử cho phép client đổi POST thành GET khi chuyển hướng (do mơ hồ tuân thủ RFC), trong khi 307 và 308 nghiêm ngặt yêu cầu cùng phương thức và body. Cho di chuyển SEO, dùng 301. Cho endpoint POST chuyển, dùng 308 để giữ body. Cho cân bằng tải hoặc thử nghiệm A/B, dùng 302 hoặc 307. Bing và Google đã nêu rõ 308 được đối xử tương đương 301 cho mục đích xếp hạng.
429 Too Many Requests nghĩa là gì và xử lý thế nào?
429 (RFC 6585) nghĩa là client đã gửi quá nhiều yêu cầu trong một khoảng thời gian và đang bị giới hạn tốc độ. Phản hồi nên bao gồm header Retry-After — hoặc số nguyên giây-delta ("Retry-After: 60") hoặc HTTP-date — cho client biết khi nào thử lại. Client lịch sự nên triển khai lùi lại theo cấp số nhân với jitter: đừng thử lại đúng thời điểm Retry-After (mọi client sẽ đập một lúc), thay vào đó thử lại giữa Retry-After và Retry-After + jitter ngẫu nhiên. Header bổ sung thường thấy nhưng không trong RFC: X-RateLimit-Limit (trần), X-RateLimit-Remaining (lệnh gọi còn lại trong cửa sổ hiện tại), X-RateLimit-Reset (dấu thời gian Unix khi cửa sổ reset). Bản dự thảo IETF draft-ietf-httpapi-ratelimit-headers đề xuất header chuẩn hóa RateLimit và RateLimit-Policy. Nhiều API cũng trả về 503 với Retry-After cho cùng mục đích; tín hiệu then chốt là Retry-After.
418 I'm a teapot là gì và có thật không?
418 I'm a teapot là Easter egg nổi tiếng nhất trong HTTP. Bắt nguồn từ RFC 2324 (Hyper Text Coffee Pot Control Protocol), một trò đùa Cá tháng Tư công bố ngày 1 tháng 4 năm 1998. Ý nghĩa dự định là ấm trà, khi được yêu cầu pha cà phê, phải trả lời với trạng thái này. Nó không phải phần của đặc tả HTTP thực tế (RFC 9110 không bao gồm), và IANA không đăng ký. Tuy nhiên, nhiều framework web và thư viện (Node.js, Go, Python, Rust) đi kèm hằng số cho HTTP 418 vì lập trình viên thực sự dùng nó cho endpoint kỳ quặc hoặc ẩn. robots.txt của Google trong nhiều năm trả về 418 cho một số user agent. Để dành 418 cho trò đùa và honeypot — không bao giờ dùng cho ngữ nghĩa lỗi thật, vì client rõ ràng không bắt buộc xử lý nó.

Khác biệt giữa 500, 502, 503 và 504 là gì?
Cả bốn đều là lỗi phía máy chủ nhưng chỉ các kiểu thất bại khác nhau. 500 Internal Server Error là bắt tất cả chung khi một ngoại lệ không mong đợi xảy ra trong code ứng dụng — NullPointerException, từ chối promise không xử lý, truy vấn DB nổ tung. 502 Bad Gateway nghĩa là máy chủ thượng nguồn trả phản hồi không hợp lệ cho gateway/proxy (như NGINX nói chuyện với backend hư). 503 Service Unavailable nghĩa là máy chủ tạm thời quá tải hoặc bảo trì và cố ý từ chối yêu cầu; nên bao gồm Retry-After. 504 Gateway Timeout nghĩa là gateway/proxy chờ máy chủ thượng nguồn và hết thời gian trước khi nhận phản hồi. Phân biệt quan trọng với ops: 500 nghĩa "sửa code," 502 nghĩa "kiểm tra dịch vụ backend," 503 nghĩa "mở rộng," và 504 nghĩa "kiểm tra timeout mạng/thượng nguồn." Cloudflare thêm mã không chuẩn 520-527 cho thất bại biên chi tiết hơn.
422 Unprocessable Entity nghĩa là gì so với 400 Bad Request?
400 Bad Request nghĩa là cú pháp sai: JSON dị dạng, thiếu header bắt buộc, định dạng query string không hợp lệ — máy chủ thậm chí không thể parse cái bạn gửi. 422 Unprocessable Entity (gốc từ WebDAV RFC 4918, được REST API phổ biến hóa) nghĩa là cú pháp đúng nhưng ngữ nghĩa sai: JSON parse sạch sẽ, nhưng "email" không phải địa chỉ email hợp lệ, hoặc "age" là -5, hoặc "endDate" trước "startDate". RFC 9110 tái khẳng định 422 cho khán giả HTTP rộng hơn. Hầu hết REST API hiện đại (Stripe, GitHub, Rails) dùng 422 cho lỗi xác thực, cho phép client phân biệt "code của tôi tạo JSON không hợp lệ" với "code của tôi tạo JSON hợp lệ với giá trị không hợp lệ." Ghép 422 với body JSON liệt kê lỗi cấp trường (RFC 7807 Problem Details là định dạng chuẩn). 409 Conflict là mã liên quan cho xung đột trạng thái như tạo tài nguyên trùng.
Các mã trạng thái ít biết nào tôi nên biết?
Ngoài các mã phổ biến, một số mã ngách giải quyết vấn đề thực. 100 Continue được dùng với Expect: 100-continue để tránh gửi body lớn nếu máy chủ sẽ từ chối. 103 Early Hints (RFC 8297) cho phép máy chủ gửi header Link trước phản hồi cuối, cho phép trình duyệt tải trước. 226 IM Used dành cho mã hóa delta (hiếm). 308 Permanent Redirect là 301 bảo toàn phương thức. 410 Gone báo hiệu tài nguyên đã được cố ý loại bỏ và khó có khả năng quay lại — mạnh hơn 404 và tốt cho gỡ chỉ mục SEO. 451 Unavailable For Legal Reasons (RFC 7725, đặt theo Fahrenheit 451) dùng cho gỡ nội dung theo lệnh tòa. 425 Too Early ngăn tấn công phát lại trong TLS 1.3 0-RTT. 428 Precondition Required buộc client dùng If-Match cho yêu cầu có điều kiện. 511 Network Authentication Required là cái cổng giam giữ nên trả về. Biết những mã này cho phép bạn truyền tải ý định chính xác.
Những mã HTTP nào được cache mặc định?
RFC 9111 (HTTP Caching) định nghĩa một tập phản hồi cụ thể có thể cache theo phỏng đoán mặc định — nghĩa là cache chia sẻ có thể lưu chúng kể cả khi không có header Cache-Control hay Expires rõ ràng. Tập đó gồm: 200 OK, 203 Non-Authoritative Information, 204 No Content, 206 Partial Content, 300 Multiple Choices, 301 Moved Permanently, 308 Permanent Redirect, 404 Not Found, 405 Method Not Allowed, 410 Gone, 414 URI Too Long và 451 Unavailable For Legal Reasons. Công cụ đánh dấu mỗi mã này bằng huy hiệu Cacheable, và bộ lọc Chỉ cacheable thu hẹp lưới về đúng danh sách này. Ba lưu ý: (1) đây là mặc định — bất kỳ phản hồi nào cũng có thể được làm cacheable hay không bằng directive Cache-Control rõ ràng; (2) phản hồi có no-store, private hoặc header Vary: * không bao giờ được lưu; và (3) lỗi như 404 và 410 chỉ được cache ngắn bằng độ tươi phỏng đoán (thường là một phần thời gian kể từ Last-Modified). Khi nghi ngờ, hãy đặt Cache-Control rõ ràng thay vì dựa vào tập phỏng đoán.
Những mã 4xx và 5xx nào an toàn để tự động thử lại?
An toàn thử lại phụ thuộc vào việc yêu cầu có idempotent không và lỗi có nhất thời không. Các mã đáng tự động thử lại — luôn với backoff theo cấp số nhân và jitter, và tôn trọng mọi header Retry-After — là: 408 Request Timeout, 425 Too Early, 429 Too Many Requests, 500 Internal Server Error (chỉ cho method idempotent như GET/PUT/DELETE), 502 Bad Gateway, 503 Service Unavailable và 504 Gateway Timeout. Công cụ gắn cờ chúng bằng huy hiệu Thử lại được và bộ lọc Chỉ thử lại được tách riêng chúng. Đừng bao giờ thử lại mù quáng 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict hay 422 Unprocessable Content — bản thân yêu cầu đã sai và thử lại y hệt sẽ chỉ thất bại lại. Với 500 trên POST không idempotent, thử lại có nguy cơ tạo bản trùng; hãy dùng khóa idempotency (như Stripe và hầu hết API thanh toán) để thử lại an toàn. Với 429 và 503, ưu tiên Retry-After do server cấp hơn bộ đếm của bạn, và thêm jitter để một đội client không thử lại đồng loạt (hiệu ứng bầy đàn) đúng lúc cửa sổ reset.
Tính Năng Chính
- Mọi mã HTTP status đã đăng ký IANA (60+) bao phủ 100 đến 511
- Mô tả chi tiết cho 25 mã phổ biến nhất (200, 301, 304, 401, 403, 404, 429, 500, 503, v.v.)
- Tìm theo số mã hoặc từ khóa qua tên và mô tả
- Lọc theo danh mục: 1xx Thông tin, 2xx Thành công, 3xx Chuyển hướng, 4xx Lỗi Client, 5xx Lỗi Server
- Chỉ báo danh mục mã màu cho nhận diện trực quan tức thì
- Link trực tiếp tới RFC định nghĩa cho mỗi mã (RFC 9110, RFC 6585, v.v.)
- Nút truy cập nhanh cho bốn mã được tìm nhiều nhất (200, 301, 404, 500)
- Sao chép bất kỳ mã status nào vào clipboard với một cú nhấp cho báo cáo bug và tài liệu
- Ví dụ tình huống sử dụng giải thích khi nào mỗi mã phù hợp
- Bao phủ bổ sung hiện đại: 103 Early Hints, 308 Permanent Redirect, 425 Too Early, 451 Legal
- Bao gồm 418 I'm a teapot của RFC 2324 cho đầy đủ
- JavaScript thuần — không thư viện ngoài
- Hoạt động offline sau lần tải đầu
- Bố cục lưới responsive cho di động và desktop
- 100% phía client — không yêu cầu nào được tra cứu
