HTTP Status Code Reference

Tính năng nổi bật

• 60+ HTTP status codes đầy đủ theo chuẩn RFC 9110 (HTTP Semantics 2022)
• Mô tả bằng tiếng Việt dễ hiểu cho developer Việt Nam – không cần dịch từ MDN
• Phân loại 5 nhóm với màu sắc trực quan: 1xx, 2xx, 3xx, 4xx, 5xx
• Ví dụ thực tế và nguyên nhân phổ biến cho mỗi status code
• Gợi ý cách xử lý cho từng mã (đặc biệt 4xx và 5xx)
• Tìm kiếm fuzzy: theo mã số, tên, mô tả hoặc keyword tiếng Việt
• Copy mã ("404") hoặc full header ("HTTP/1.1 404 Not Found") với 1 click
• Phân biệt các mã dễ nhầm: 301 vs 302 vs 307 vs 308, 401 vs 403, 502 vs 504
• Bao gồm cả mã hiếm gặp như 418 (I'm a teapot), 451 (Unavailable For Legal Reasons)
• Cập nhật theo RFC mới nhất – RFC 9110, RFC 6585, RFC 8470
• Mobile responsive – tra cứu nhanh khi đang debug trên đường
• Hoàn toàn miễn phí, không cần đăng ký, không có quảng cáo chèn

Vì sao mỗi web developer Việt Nam cần thành thạo HTTP Status Codes?

HTTP (HyperText Transfer Protocol) là ngôn ngữ giao tiếp nền tảng của toàn bộ Web – mỗi request từ browser/app đến server đều kèm response với một status code 3 chữ số mô tả kết quả. Theo khảo sát Stack Overflow Developer Survey 2024, hiểu đúng HTTP status codes là kỹ năng được hỏi nhiều thứ 3 trong phỏng vấn web developer (sau JavaScript fundamentals và SQL). Tuy nhiên, theo State of Web Development 2024, chỉ 42% dev junior Việt Nam phân biệt được 301 vs 302 redirect, chỉ 38% biết khác biệt giữa 401 và 403 – những kiến thức cốt lõi ảnh hưởng trực tiếp đến SEO và bảo mật. Hiểu sâu HTTP status codes giúp bạn: (1) Debug API/website nhanh hơn 3–5 lần – nhìn status code biết ngay vấn đề ở client (4xx) hay server (5xx), không phải đoán mò; (2) Viết error handling chuẩn – phân biệt 401 (redirect login) vs 403 (show forbidden page) vs 404 (show 404 page); (3) Tối ưu SEO – 301 (permanent) giữ link juice 90–99% trong khi 302 (temporary) chỉ ~80%, dùng sai có thể mất top ranking; (4) Monitor production – spike 502/504 báo hiệu upstream service down, 503 báo hiệu server overload, 429 báo hiệu bị rate limit – cần action khác nhau; (5) Communicate hiệu quả với team – dùng đúng thuật ngữ giúp BA/PM/QA hiểu nhanh. Công cụ HTTP Status Reference của Tấn Phát Digital tổng hợp toàn bộ kiến thức này trong 1 trang duy nhất, dễ tra cứu, kèm ví dụ thực tế từ stack Việt Nam (nginx, Cloudflare, Vercel, AWS).

Lợi ích khi sử dụng

• •Tra cứu trong <5 giây – nhanh hơn search Google rồi đọc MDN tiếng Anh
• •Hiểu rõ nguyên nhân từng mã – không chỉ "nhớ ý nghĩa" mà biết cách xử lý
• •Phân biệt chính xác các mã hay nhầm: 301/302/307/308, 401/403, 502/504
• •Tăng tốc debug API – nhìn status code biết ngay nguyên nhân (client hay server)
• •Cải thiện SEO – dùng đúng 301 vs 302 cho redirect, giữ link juice tối đa
• •Viết error handling chuẩn enterprise – matrix xử lý theo từng nhóm status
• •Hiểu rate limiting (429) – quan trọng khi tích hợp API bên ngoài
• •Hiểu CDN/Cloudflare error – 520/521/522/525 đặc thù Cloudflare
• •Resource tham khảo cho QA tester khi viết test case API
• •Cập nhật theo RFC 9110 mới nhất – không bị outdated như nhiều trang khác

Hướng dẫn 6 bước tra cứu HTTP Status Code hiệu quả

1. 1Bước 1: Mở công cụ HTTP Status Reference trên trình duyệt – không cần đăng ký, có thể bookmark để tra cứu nhanh
2. 2Bước 2: Nếu đã biết mã (vd 404), gõ vào ô tìm kiếm – kết quả hiện ngay lập tức cùng tên đầy đủ "404 Not Found"
3. 3Bước 3: Nếu chỉ nhớ tên (vd "unauthorized", "forbidden", "timeout"), gõ tên tiếng Anh hoặc tiếng Việt – công cụ fuzzy search theo tên và mô tả
4. 4Bước 4: Để xem theo nhóm, click tab 1xx/2xx/3xx/4xx/5xx – hiển thị tất cả mã trong nhóm với màu sắc phân biệt
5. 5Bước 5: Click vào card mã để xem chi tiết: mô tả tiếng Việt, ví dụ thực tế, nguyên nhân phổ biến, cách xử lý cho frontend/backend
6. 6Bước 6: Click nút "Copy" để sao chép mã (vd "404") hoặc cụm header (vd "HTTP/1.1 404 Not Found") – paste vào code, Postman, Swagger documentation

Phân loại 5 nhóm HTTP Status Codes theo RFC 9110

HTTP Status Codes được chia thành 5 nhóm theo chữ số đầu tiên: (1) 1xx Informational (100-199): Provisional response, server đã nhận request và tiếp tục xử lý. Hiếm gặp trong ứng dụng web thông thường. Ví dụ: 100 Continue, 101 Switching Protocols (dùng cho WebSocket upgrade), 102 Processing, 103 Early Hints (Cloudflare/Vercel dùng để hint browser preload resource). (2) 2xx Success (200-299): Request thành công, server xử lý xong và trả response. Ví dụ: 200 OK (phổ biến nhất), 201 Created (sau POST tạo resource), 202 Accepted (async processing), 204 No Content (thành công nhưng không có body, dùng cho DELETE), 206 Partial Content (range request, dùng cho video streaming). (3) 3xx Redirection (300-399): Cần thêm action từ client, thường là redirect. Ví dụ: 301 Moved Permanently (URL đổi vĩnh viễn, giữ 90-99% SEO juice), 302 Found (temporary redirect), 303 See Other (sau POST chuyển sang GET), 304 Not Modified (cache hit, không gửi body), 307 Temporary Redirect (giữ HTTP method), 308 Permanent Redirect (giữ HTTP method). (4) 4xx Client Error (400-499): Lỗi từ phía client – sai URL, thiếu auth, sai format. Ví dụ: 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 405 Method Not Allowed, 408 Request Timeout, 409 Conflict, 410 Gone, 422 Unprocessable Entity (Spring Boot, Rails dùng nhiều), 429 Too Many Requests (rate limit). (5) 5xx Server Error (500-599): Lỗi từ phía server – crash, overload, upstream fail. Ví dụ: 500 Internal Server Error, 501 Not Implemented, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout, 507 Insufficient Storage. Quy tắc nhớ nhanh: 4xx = lỗi của BẠN (client/request sai), 5xx = lỗi của SERVER.

10 HTTP Status Codes phổ biến nhất và cách xử lý trong production

1) 200 OK – phổ biến nhất, request thành công, response có body. Không cần xử lý gì đặc biệt. 2) 201 Created – sau POST tạo resource thành công, response thường có Location header trỏ đến resource mới. Frontend: redirect đến trang detail. 3) 301 Moved Permanently – URL đã đổi vĩnh viễn. SEO impact: search engine update sitemap, ~99% link juice chuyển sang URL mới. Dùng khi đổi domain, restructure URL. 4) 302 Found – URL tạm thời chuyển hướng, search engine GIỮ URL cũ. Dùng cho A/B testing, geo-redirect. KHÔNG dùng cho permanent redirect (mất SEO). 5) 304 Not Modified – cache hit, browser dùng version cache, không tải lại. Yêu cầu ETag/Last-Modified header. 6) 400 Bad Request – request format sai (vd JSON malformed, missing required field). Frontend: hiển thị validation error. 7) 401 Unauthorized – chưa authenticated (chưa login hoặc token hết hạn). Frontend: redirect đến trang login. 8) 403 Forbidden – đã login nhưng không có quyền truy cập resource. Frontend: hiển thị "Bạn không có quyền truy cập". 9) 404 Not Found – URL không tồn tại. Frontend: hiển thị trang 404 custom, gợi ý URL liên quan. 10) 500 Internal Server Error – lỗi chung của server, thường do bug code. Backend: log đầy đủ stack trace, alert team. Frontend: hiển thị "Đã có lỗi xảy ra, vui lòng thử lại", không hiển thị raw error cho user.

301 vs 302 vs 307 vs 308 – Phân biệt các redirect codes và tác động SEO

301 Moved Permanently: redirect vĩnh viễn, có thể đổi HTTP method (POST → GET), cache mạnh trên browser/CDN, SEO juice ~90-99% chuyển sang URL mới. DÙNG KHI: đổi domain (example.com → newexample.com), đổi URL structure (/blog/post-1 → /blog/2024/post-1), HTTP → HTTPS migration. 302 Found (HTTP/1.1) / 302 Moved Temporarily (HTTP/1.0): redirect tạm thời, search engine giữ URL cũ làm canonical. KHÔNG cache mạnh. SEO juice ~70-80% (Google chính thức nói 302 cũng pass juice nhưng không bằng 301). DÙNG KHI: A/B testing, geo-redirect, maintenance mode, login redirect. KHÔNG DÙNG cho permanent moves (sẽ mất SEO). 307 Temporary Redirect: như 302 nhưng BẢO TOÀN HTTP method (POST vẫn là POST sau redirect, không bị xuống GET). Quan trọng cho REST API. 308 Permanent Redirect: như 301 nhưng BẢO TOÀN HTTP method. Mới hơn (RFC 7538), dùng khi muốn redirect API permanently. Tóm lại: web thông thường dùng 301 (permanent) hoặc 302 (temp). API/REST dùng 308 (permanent) hoặc 307 (temp). 80% case web là 301 hoặc 302.

401 vs 403 – Khác biệt quan trọng cho bảo mật và UX

Đây là cặp mã bị nhầm nhiều nhất theo khảo sát developer 2024. 401 Unauthorized (đúng ra phải là "Unauthenticated" – tên gây nhầm lẫn): client CHƯA xác thực. Server không biết bạn là ai. Lý do: chưa login, token JWT hết hạn, session expire, sai password. Header response phải có WWW-Authenticate hint phương thức auth. Cách xử lý frontend: chuyển hướng đến trang login, lưu intended URL để redirect sau khi login. 403 Forbidden: client ĐÃ xác thực, server biết bạn là ai, nhưng bạn không có permission truy cập resource cụ thể này. Lý do: không có role/scope, IP bị block, account bị suspend, resource thuộc tenant khác. Cách xử lý: hiển thị thông báo "Bạn không có quyền truy cập" rõ ràng, không redirect login (vì đã login rồi), gợi ý liên hệ admin nếu cần. Nguyên tắc bảo mật: KHÔNG dùng 403 để "hint" resource có tồn tại nhưng bạn không có quyền – một số trường hợp cần dùng 404 thay 403 để giấu sự tồn tại của resource (vd: private repo trên GitHub trả 404 thay vì 403 để không leak thông tin).

502 vs 503 vs 504 – Phân biệt các lỗi server và cách debug

502 Bad Gateway: server đóng vai trò proxy/gateway nhận INVALID response từ upstream server. Ví dụ: Nginx proxy đến Node.js app, app crash hoặc trả response không hợp lệ → Nginx trả 502. CÁCH DEBUG: kiểm tra log upstream app, restart service, kiểm tra config proxy. Phổ biến trên stack Nginx + Node/PHP-FPM, Cloudflare khi origin server crash. 503 Service Unavailable: server không thể xử lý request lúc này. Lý do: maintenance mode, server overload, autoscaling chưa kịp. Header Retry-After hint client khi nào retry. CÁCH DEBUG: kiểm tra CPU/RAM server, scale up, kiểm tra rate limit config. 504 Gateway Timeout: server proxy/gateway KHÔNG nhận được response từ upstream trong thời gian quy định. Ví dụ: Nginx config timeout 60s, Node app process request quá 60s. CÁCH DEBUG: tăng timeout config, tối ưu query database/API call upstream, cache response, dùng async/queue cho long-running task. Tóm lại: 502 = upstream RESPONSE SAI, 503 = server NHẬN không nổi (busy/down), 504 = upstream KHÔNG TRẢ LỜI (slow).

Cloudflare-specific status codes và cách xử lý khi dùng Cloudflare CDN

Nếu website của bạn dùng Cloudflare (hơn 30% website Việt Nam dùng), có một số status codes đặc thù: 520 Web Server Returned an Unknown Error – Cloudflare nhận response từ origin server nhưng không thể parse (response quá lớn, header bất thường, connection reset). Fix: tăng origin server response time, check log origin. 521 Web Server Is Down – Cloudflare không kết nối được đến origin. Fix: check origin server status, firewall rule Cloudflare IPs. 522 Connection Timed Out – TCP handshake timeout giữa Cloudflare và origin. Fix: tăng timeout, check network latency. 523 Origin Is Unreachable – DNS resolution fail. Fix: check DNS A record. 524 A Timeout Occurred – Cloudflare đợi response >100s. Fix: tối ưu backend, hoặc dùng Cloudflare Workers/Argo. 525 SSL Handshake Failed – SSL certificate origin hết hạn hoặc misconfig. Fix: renew SSL certificate, check Full/Strict mode. 526 Invalid SSL Certificate – SSL certificate không hợp lệ. Fix: dùng Cloudflare Origin Certificate hoặc valid cert. Khi gặp 5xx Cloudflare, luôn check trạng thái origin server trước khi đổ lỗi cho Cloudflare.

Rate Limiting (429) và API Best Practices khi tích hợp service bên ngoài

429 Too Many Requests xuất hiện khi client gửi quá nhiều request trong khoảng thời gian – server áp dụng rate limiting để bảo vệ. Phổ biến với public API (Twitter, GitHub, OpenAI, Stripe). Response header thường có: Retry-After (giây nên đợi), X-RateLimit-Limit (tổng request/window), X-RateLimit-Remaining (còn lại), X-RateLimit-Reset (timestamp reset). BEST PRACTICES khi tích hợp API: (1) Đọc header X-RateLimit-* để biết limit; (2) Implement exponential backoff – đợi 1s, 2s, 4s, 8s khi gặp 429; (3) Cache response để giảm số request; (4) Queue + batch request thay vì gọi tuần tự; (5) Dùng webhook thay polling khi có thể; (6) Khi build API riêng, đặt rate limit hợp lý (vd: 100 req/min/IP), dùng Redis để track. Stack điển hình: Node.js + express-rate-limit, Nginx limit_req, Cloudflare Rate Limiting Rules. Vi phạm rate limit liên tục có thể bị block IP tạm thời hoặc vĩnh viễn.

Khi nào nên dùng HTTP Status Codes – Tra Cứu Mã Trạng Thái HTTP Đầy Đủ Bằng Tiếng Việt (RFC 9110)?

HTTP Status Codes – Tra Cứu Mã Trạng Thái HTTP Đầy Đủ Bằng Tiếng Việt (RFC 9110) phù hợp khi bạn cần xử lý nhanh một tác vụ cụ thể mà không muốn cài thêm phần mềm, tạo tài khoản mới hoặc mở một bộ công cụ quá nặng. Công cụ đặc biệt hữu ích cho các tình huống cần kiểm tra nhanh, chuẩn hóa dữ liệu, tạo đầu ra có thể copy ngay, rà soát lỗi trước khi đưa vào workflow chính hoặc hỗ trợ công việc lặp lại hằng ngày. Với người làm SEO, marketing, thiết kế, lập trình, vận hành hoặc admin văn phòng, việc có một tool chạy ngay trên trình duyệt giúp giảm thời gian chuyển ngữ cảnh và giữ toàn bộ quy trình gọn hơn.

Câu hỏi thường gặp (FAQ)

Từ khóa liên quan

• http status codes tiếng việt
• mã trạng thái http
• http response codes reference
• status code 404
• status code 500
• 301 vs 302 redirect
• 401 vs 403
• 502 bad gateway
• 503 service unavailable
• 504 gateway timeout
• 429 rate limit
• 422 unprocessable entity
• cloudflare error codes
• rfc 9110
• http semantics
• rest api status codes
• api error handling
• http status code seo