Máy chủ đã nhận header của yêu cầu và client có thể tiếp tục gửi phần body.
Khi nào dùng: Được gửi khi phản hồi một yêu cầu có Expect: 100-continue, để client kiểm tra trước rằng file tải lên lớn sẽ được chấp nhận rồi mới gửi.
Giải thích mọi mã phản hồi HTTP chuẩn bằng ngôn ngữ dễ hiểu, kèm cách dùng và ảnh hưởng đến SEO. Tìm kiếm, lọc hoặc mở thẳng liên kết tới một mã.
Yêu cầu đã được nhận và quá trình đang tiếp tục. Trình duyệt tự động xử lý các mã này.
Máy chủ đã nhận header của yêu cầu và client có thể tiếp tục gửi phần body.
Khi nào dùng: Được gửi khi phản hồi một yêu cầu có Expect: 100-continue, để client kiểm tra trước rằng file tải lên lớn sẽ được chấp nhận rồi mới gửi.
Máy chủ đồng ý chuyển sang giao thức được nêu trong header Upgrade của client.
Khi nào dùng: Dùng khi nâng cấp kết nối HTTP/1.1 lên WebSocket (Upgrade: websocket).
WebDAV: máy chủ đã nhận yêu cầu nhưng chưa xử lý xong.
Khi nào dùng: Ngăn client bị timeout trong các thao tác WebDAV kéo dài. Ngày nay hiếm khi được dùng.
Cho phép máy chủ gửi header Link (preload / preconnect) trước khi phản hồi cuối cùng sẵn sàng.
Khi nào dùng: Gửi trong lúc backend vẫn đang tạo trang, để trình duyệt bắt đầu tải sớm CSS, font hoặc script quan trọng.
Yêu cầu đã được nhận, hiểu và chấp nhận.
Yêu cầu thành công. Body chứa tài nguyên được yêu cầu hoặc kết quả của hành động.
Khi nào dùng: Phản hồi thành công mặc định cho GET, và cho POST/PUT khi bạn trả về body.
Ảnh hưởng SEO: Đây là trạng thái duy nhất cho phép trang được lập chỉ mục cùng nội dung. Hãy đảm bảo các trang “không tìm thấy” không trả về 200 (một “soft 404”).
Yêu cầu thành công và một tài nguyên mới đã được tạo.
Khi nào dùng: Trả về sau POST (hoặc PUT) tạo mới dữ liệu; kèm header Location trỏ tới tài nguyên mới.
Yêu cầu đã được chấp nhận để xử lý, nhưng việc xử lý chưa hoàn tất.
Khi nào dùng: Tác vụ bất đồng bộ: đưa việc vào hàng đợi và trả về một URL để client kiểm tra kết quả.
Phản hồi đã bị proxy trung gian chỉnh sửa và khác với phản hồi 200 của máy chủ gốc.
Khi nào dùng: Do các proxy thay đổi nội dung đặt ra; máy chủ gốc thường không nên gửi mã này.
Yêu cầu thành công và cố ý không có body trong phản hồi.
Khi nào dùng: Yêu cầu DELETE, endpoint tự động lưu và phản hồi preflight của CORS khi không cần trả về dữ liệu.
Yêu cầu thành công và client nên làm mới giao diện tài liệu (ví dụ xóa trắng một form).
Khi nào dùng: Hiếm khi dùng; yêu cầu trình duyệt reset form đã gửi yêu cầu.
Máy chủ chỉ gửi phần byte được yêu cầu qua header Range.
Khi nào dùng: Phát video trực tuyến, tải xuống có thể tiếp tục và các trình quản lý tải xuống.
WebDAV: body là một tài liệu XML chứa mã trạng thái riêng cho nhiều yêu cầu con.
Khi nào dùng: Các thao tác WebDAV hàng loạt, trong đó từng mục có thể thành công hoặc thất bại riêng.
WebDAV: các thành viên của một binding đã được liệt kê trước đó trong cùng phản hồi 207.
Khi nào dùng: Tránh liệt kê lặp lại cùng một tài nguyên trong phản hồi Multi-Status.
Máy chủ đã thực hiện GET với các thao tác xử lý instance (mã hóa delta).
Khi nào dùng: Mã hóa delta HTTP (RFC 3229); trong thực tế gần như không bao giờ gặp.
Cần thực hiện thêm bước — thường là đi theo header Location tới một URL khác.
Tài nguyên có nhiều dạng biểu diễn và client (hoặc người dùng) nên chọn một dạng.
Khi nào dùng: Hiếm khi dùng; việc thương lượng nội dung thường được thực hiện tự động.
Ảnh hưởng SEO: Google có thể chọn bất kỳ phương án nào; nên dùng một 301 duy nhất trỏ về phiên bản chuẩn.
Tài nguyên có URL vĩnh viễn mới, được nêu trong header Location.
Khi nào dùng: Chuyển tên miền, HTTP → HTTPS, đổi slug, gộp các trang trùng lặp.
Ảnh hưởng SEO: Cách chuẩn để chuyển trang: công cụ tìm kiếm chuyển tín hiệu xếp hạng và lập chỉ mục URL mới. Trình duyệt có thể đổi POST thành GET với 301 — hãy dùng 308 nếu cần giữ phương thức.
Tài nguyên tạm thời nằm ở một URL khác.
Khi nào dùng: Chuyển hướng ngắn hạn như trang bảo trì, A/B test hoặc luồng đăng nhập.
Ảnh hưởng SEO: Google coi đây là tạm thời và thường vẫn giữ URL gốc trong chỉ mục. Nếu việc chuyển là vĩnh viễn, hãy dùng 301.
Client nên lấy kết quả từ một URL khác bằng GET.
Khi nào dùng: Mẫu “Post/Redirect/Get”: sau khi gửi form bằng POST, chuyển hướng tới trang xác nhận.
Ảnh hưởng SEO: Được xử lý như chuyển hướng tạm thời.
Bản sao trong cache vẫn còn hiệu lực; không gửi body.
Khi nào dùng: Phản hồi cho yêu cầu có điều kiện (If-None-Match / If-Modified-Since) khi tài nguyên chưa thay đổi.
Ảnh hưởng SEO: Tốt cho hiệu quả crawl: Googlebot dùng lại bản cache, tiết kiệm crawl budget.
Đã lỗi thời. Ban đầu yêu cầu client truy cập tài nguyên qua một proxy.
Khi nào dùng: Không nên dùng — trình duyệt bỏ qua vì lý do bảo mật.
Giống 302, nhưng client phải lặp lại yêu cầu với cùng phương thức và body.
Khi nào dùng: Chuyển hướng tạm thời cho yêu cầu POST/PUT; trình duyệt cũng hiển thị “307 Internal Redirect” khi nâng cấp HSTS.
Ảnh hưởng SEO: Tạm thời — URL gốc thường vẫn được giữ trong chỉ mục.
Giống 301, nhưng client phải giữ nguyên phương thức và body.
Khi nào dùng: Chuyển vĩnh viễn endpoint API hoặc đích của form mà POST phải giữ là POST.
Ảnh hưởng SEO: Google xử lý 308 giống 301 và chuyển tín hiệu sang URL mới.
Yêu cầu chứa lỗi hoặc không thể thực hiện: client nên sửa lại trước khi thử lần nữa.
Máy chủ không thể xử lý yêu cầu vì sai định dạng (cú pháp sai, JSON không hợp lệ, cookie quá lớn…).
Khi nào dùng: Lỗi kiểm tra dữ liệu mà bạn không thể diễn đạt chính xác hơn; hãy kèm thông báo lỗi trong body.
Ảnh hưởng SEO: Các trang trả về 4xx sẽ bị loại khỏi chỉ mục.
Cần xác thực nhưng thiếu hoặc không hợp lệ. Dù tên gọi là “Unauthorized”, mã này thực chất nghĩa là “chưa xác thực”.
Khi nào dùng: Thiếu hoặc hết hạn token / thông tin đăng nhập. Phải kèm header WWW-Authenticate.
Ảnh hưởng SEO: Bot không thể đăng nhập, nên các trang sau 401 không được lập chỉ mục — đúng như mong muốn với khu vực riêng tư.
Được dành cho tương lai; một số API dùng khi cần thanh toán hoặc nâng hạn mức.
Khi nào dùng: Lỗi thanh toán không chuẩn (ví dụ gói đăng ký đã hết hạn).
Máy chủ đã hiểu yêu cầu nhưng từ chối cấp quyền. Đăng nhập lại cũng không giúp được gì.
Khi nào dùng: Người dùng đã đăng nhập nhưng thiếu quyền, hoặc truy cập bị chặn theo IP, WAF hoặc quyền file.
Ảnh hưởng SEO: Không được lập chỉ mục. Hãy kiểm tra xem tường lửa hoặc công cụ chống bot có nhầm trả về 403 cho Googlebot hay không.
Máy chủ không tìm thấy tài nguyên được yêu cầu.
Khi nào dùng: URL chưa từng tồn tại hoặc đã bị xóa mà không có thay thế. Hãy hiển thị trang 404 tùy chỉnh, hữu ích cho người dùng.
Ảnh hưởng SEO: Bình thường và vô hại với các trang thực sự không còn tồn tại; Google sẽ loại bỏ dần. Hãy chuyển hướng (301) các URL có backlink hoặc có nội dung thay thế rõ ràng.
Phương thức HTTP không được hỗ trợ cho URL này (ví dụ POST tới một trang chỉ đọc).
Khi nào dùng: Trả về kèm header Allow liệt kê các phương thức được hỗ trợ.
Máy chủ không thể tạo phản hồi khớp với các header Accept của yêu cầu.
Khi nào dùng: Thương lượng nội dung nghiêm ngặt; nhiều API đơn giản trả về định dạng mặc định.
Giống 401, nhưng client phải xác thực với proxy.
Khi nào dùng: Được gửi bởi proxy doanh nghiệp hoặc proxy chuyển tiếp, kèm header Proxy-Authenticate.
Máy chủ đã hết thời gian chờ client gửi xong yêu cầu.
Khi nào dùng: Kết nối nhàn rỗi hoặc rất chậm; client có thể thử lại.
Yêu cầu xung đột với trạng thái hiện tại của tài nguyên.
Khi nào dùng: Xung đột khi chỉnh sửa, khóa duy nhất bị trùng, hoặc sai phiên bản trong khóa lạc quan (optimistic locking).
Tài nguyên đã bị xóa vĩnh viễn và sẽ không quay lại.
Khi nào dùng: Nội dung đã được xóa có chủ đích, tin đăng hoặc chiến dịch đã hết hạn.
Ảnh hưởng SEO: Google xử lý 410 giống 404 nhưng có thể loại URL nhanh hơn một chút.
Máy chủ yêu cầu header Content-Length.
Khi nào dùng: Tải lên không có độ dài khi máy chủ không chấp nhận chunked encoding.
Một điều kiện trong header yêu cầu (If-Match, If-Unmodified-Since) có kết quả sai.
Khi nào dùng: Kiểm soát đồng thời lạc quan: từ chối cập nhật vì tài nguyên đã thay đổi kể từ lần client đọc gần nhất.
Body của yêu cầu lớn hơn giới hạn máy chủ cho phép (trước đây là “Payload Too Large”).
Khi nào dùng: Tệp tải lên vượt quá giới hạn — ví dụ client_max_body_size của nginx.
URL dài hơn mức máy chủ có thể xử lý.
Khi nào dùng: Thường là lỗi: query string quá dài hoặc vòng lặp chuyển hướng liên tục thêm tham số.
Định dạng của body (Content-Type) không được hỗ trợ.
Khi nào dùng: API yêu cầu application/json nhưng lại nhận dữ liệu form hoặc XML.
Header Range yêu cầu các byte nằm ngoài phạm vi file.
Khi nào dùng: Tiếp tục tải xuống từ vị trí vượt quá cuối file đã bị thu nhỏ.
Máy chủ không đáp ứng được yêu cầu trong header Expect.
Khi nào dùng: Từ chối các lượt tải lên có Expect: 100-continue.
Một trò đùa Cá tháng Tư từ RFC 2324 (Hyper Text Coffee Pot Control Protocol): máy chủ từ chối pha cà phê vì nó là một ấm trà.
Khi nào dùng: Chỉ để làm彩蛋 (easter egg). Một số dịch vụ trả về mã này để từ chối yêu cầu tự động hoặc không mong muốn, nhưng nó không mang ý nghĩa chuẩn nào.
Yêu cầu đã đến một máy chủ không thể tạo phản hồi cho host này.
Khi nào dùng: Tái sử dụng kết nối HTTP/2 giữa các hostname có chứng chỉ hoặc cấu hình không khớp.
Cú pháp hợp lệ, nhưng nội dung không qua được kiểm tra về ngữ nghĩa.
Khi nào dùng: Lỗi xác thực form hoặc API (thiếu trường bắt buộc, email không hợp lệ). Phổ biến trong API của Rails và Laravel.
WebDAV: tài nguyên đang bị khóa.
Khi nào dùng: Tệp đang được người khác mượn hoặc khóa.
WebDAV: yêu cầu thất bại vì một yêu cầu trước đó mà nó phụ thuộc vào đã thất bại.
Khi nào dùng: Thao tác hàng loạt mà một lỗi sẽ hủy các bước còn lại.
Máy chủ không xử lý yêu cầu có thể bị phát lại (TLS 1.3 early data / 0-RTT).
Khi nào dùng: Bảo vệ các yêu cầu không idempotent gửi trong early data của TLS khỏi tấn công replay.
Client phải chuyển sang giao thức khác, được nêu trong header Upgrade.
Khi nào dùng: Buộc client chuyển sang phiên bản giao thức mới hơn.
Máy chủ yêu cầu yêu cầu phải có điều kiện (ví dụ có If-Match).
Khi nào dùng: Ngăn “mất cập nhật” bằng cách từ chối các yêu cầu PUT/PATCH không có điều kiện.
Client đã gửi quá nhiều yêu cầu trong một khoảng thời gian (giới hạn tần suất).
Khi nào dùng: Giới hạn tần suất API và bảo vệ chống tấn công dò mật khẩu. Hãy kèm header Retry-After.
Ảnh hưởng SEO: Googlebot giảm tốc độ crawl khi gặp 429 (và 503). 429 kéo dài có thể khiến URL bị loại bỏ.
Một header (thường là Cookie) hoặc tổng các header quá lớn.
Khi nào dùng: Thường do cookie tích tụ lâu ngày; xóa cookie của trang sẽ khắc phục cho người dùng.
Tài nguyên bị chặn vì lý do pháp lý — kiểm duyệt, lệnh của tòa án hoặc quy định của từng khu vực. Con số này ám chỉ cuốn Fahrenheit 451 của Ray Bradbury.
Khi nào dùng: Nội dung bị gỡ do yêu cầu gỡ bỏ hoặc bị giới hạn địa lý theo luật.
Ảnh hưởng SEO: Được xử lý như các mã 4xx khác: không được lập chỉ mục.
Máy chủ không thể thực hiện một yêu cầu có vẻ hợp lệ.
Lỗi chung: máy chủ gặp một tình huống không lường trước.
Khi nào dùng: Ngoại lệ chưa được xử lý, script bị crash, quy tắc .htaccess lỗi. Hãy kiểm tra log máy chủ.
Ảnh hưởng SEO: Sự cố ngắn hạn vẫn được chấp nhận; nếu lỗi 5xx kéo dài nhiều ngày, Google sẽ giảm crawl và cuối cùng loại URL.
Máy chủ không hỗ trợ chức năng cần thiết (thường là một phương thức không xác định).
Khi nào dùng: Phương thức mà máy chủ hoàn toàn không nhận ra, khác với 405 dành cho phương thức đã biết nhưng không được phép.
Gateway hoặc proxy nhận được phản hồi không hợp lệ từ máy chủ phía trên.
Khi nào dùng: App server của bạn (PHP-FPM, Node, Gunicorn) bị crash hoặc trả về dữ liệu lỗi phía sau nginx, load balancer hoặc CDN.
Ảnh hưởng SEO: Giống các lỗi 5xx khác: lỗi tạm thời thì ổn, lỗi kéo dài sẽ ảnh hưởng đến crawl và lập chỉ mục.
Máy chủ tạm thời không thể xử lý yêu cầu — quá tải hoặc đang bảo trì.
Khi nào dùng: Bảo trì theo kế hoạch hoặc quá tải. Thêm Retry-After để cho biết khi nào nên quay lại.
Ảnh hưởng SEO: Mã đúng cho thời gian ngừng hoạt động có kế hoạch: Google giữ trang trong chỉ mục và thử lại sau. Đừng trả về mã này quá một hai ngày.
Gateway hoặc proxy không nhận được phản hồi từ máy chủ phía trên kịp thời.
Khi nào dùng: Truy vấn cơ sở dữ liệu chậm hoặc API phía trên vượt quá thời gian chờ của proxy.
Ảnh hưởng SEO: Timeout kéo dài làm giảm tốc độ crawl và có thể dẫn đến việc bị gỡ khỏi chỉ mục.
Máy chủ không hỗ trợ phiên bản HTTP được dùng trong yêu cầu.
Khi nào dùng: Các phiên bản giao thức quá cũ hoặc quá mới mà máy chủ không xử lý được.
Lỗi cấu hình máy chủ: biến thể được chọn cũng được cấu hình để thương lượng, tạo ra một vòng lặp.
Khi nào dùng: Lỗi cấu hình thương lượng nội dung.
WebDAV: máy chủ không thể lưu biểu diễn cần thiết để hoàn tất yêu cầu.
Khi nào dùng: Đĩa hoặc hạn mức của người dùng đã đầy.
WebDAV: máy chủ phát hiện vòng lặp vô hạn khi xử lý yêu cầu.
Khi nào dùng: Một số hosting (ví dụ cPanel/CloudLinux) cũng trả về mã này khi tài khoản chạm giới hạn tài nguyên.
Yêu cầu cần thêm các phần mở rộng (RFC 2774, nay đã lỗi thời).
Khi nào dùng: Hầu như không còn được dùng.
Client phải xác thực để truy cập mạng.
Khi nào dùng: Trang đăng nhập Wi-Fi (captive portal) ở khách sạn, sân bay hoặc quán cà phê.
Không thuộc đặc tả HTTP, nhưng thường gặp trong log máy chủ và trang báo lỗi.
nginx đóng kết nối mà không gửi bất kỳ phản hồi nào.
Khi nào dùng: Được cấu hình trong nginx để âm thầm loại bỏ các yêu cầu độc hại hoặc không mong muốn.
nginx ghi log khi client đóng kết nối trước khi máy chủ kịp phản hồi.
Khi nào dùng: Bạn sẽ thấy mã này trong log khi người dùng rời trang hoặc timeout của client ngắn hơn thời gian phản hồi của bạn.
Cloudflare nhận được phản hồi rỗng, không rõ hoặc bất thường từ máy chủ gốc.
Khi nào dùng: Máy chủ gốc bị crash, header quá lớn hoặc kết nối bị reset. Hãy kiểm tra log lỗi của máy chủ gốc.
Ảnh hưởng SEO: Được xử lý như lỗi 5xx.
Máy chủ gốc từ chối kết nối của Cloudflare.
Khi nào dùng: Web server đã dừng hoặc tường lửa chặn dải IP của Cloudflare.
Ảnh hưởng SEO: Được xử lý như lỗi 5xx.
Cloudflare không thể hoàn tất kết nối TCP tới máy chủ gốc.
Khi nào dùng: Máy chủ gốc quá tải, bản ghi DNS sai hoặc tường lửa làm rơi gói tin.
Ảnh hưởng SEO: Được xử lý như lỗi 5xx.
Cloudflare đã kết nối được tới máy chủ gốc, nhưng máy chủ không phản hồi trong 100 giây.
Khi nào dùng: Các yêu cầu chạy lâu; hãy chuyển chúng sang tác vụ nền.
Ảnh hưởng SEO: Được xử lý như lỗi 5xx.
Quá trình bắt tay TLS giữa Cloudflare và máy chủ gốc thất bại.
Khi nào dùng: Máy chủ gốc không có chứng chỉ hợp lệ, hoặc không hỗ trợ SNI/phiên bản TLS mà Cloudflare dùng.
Ảnh hưởng SEO: Được xử lý như lỗi 5xx.
Cloudflare (ở chế độ Full Strict) không thể xác thực chứng chỉ của máy chủ gốc.
Khi nào dùng: Chứng chỉ máy chủ gốc hết hạn hoặc tự ký — hãy cài một chứng chỉ hợp lệ hoặc chứng chỉ Cloudflare Origin CA.
Ảnh hưởng SEO: Được xử lý như lỗi 5xx.
Dữ liệu của bạn không bao giờ rời khỏi máy tính. Mọi xử lý diễn ra 100% cục bộ trong trình duyệt của bạn.
404) hoặc một từ khóa (redirect, timeout, rate limit) vào ô tìm kiếm./http-status-codes#429) dùng cho tài liệu hoặc khi review code.Mã trạng thái HTTP là số ba chữ số mà máy chủ gửi ở đầu mỗi phản hồi để cho biết yêu cầu đã diễn ra thế nào. Trình duyệt, client API và bot của công cụ tìm kiếm đều đọc mã này trước tiên. Chữ số đầu tiên xác định nhóm: 1xx thông tin, 2xx thành công, 3xx chuyển hướng, 4xx lỗi phía client và 5xx lỗi phía máy chủ. Định nghĩa hiện hành nằm trong RFC 9110 (HTTP Semantics, 2022), cùng một vài phần mở rộng như 429 (RFC 6585) và 451 (RFC 7725).
| Mã | Ý nghĩa | Nguyên nhân thường gặp |
|---|---|---|
| 200 | OK | Mọi thứ hoạt động bình thường |
| 301 / 308 | Chuyển hướng vĩnh viễn | Trang hoặc tên miền đã được chuyển |
| 302 / 307 | Chuyển hướng tạm thời | Luồng đăng nhập, bảo trì, A/B test |
| 304 | Not Modified | Cache của trình duyệt vẫn còn hiệu lực |
| 401 / 403 | Chưa xác thực / bị từ chối | Thiếu token, không đủ quyền, WAF chặn |
| 404 | Not Found | URL sai hoặc trang đã bị xóa |
| 429 | Too Many Requests | Vượt giới hạn tần suất (rate limit) |
| 500 | Internal Server Error | Lỗi hoặc crash trong ứng dụng |
| 502 / 504 | Bad gateway / timeout | Backend phía sau proxy hoặc CDN bị lỗi hoặc phản hồi quá chậm |
| 503 | Service Unavailable | Đang bảo trì hoặc quá tải |
Công cụ tìm kiếm chỉ lập chỉ mục những trang trả về 200. Chuyển hướng vĩnh viễn (301, 308) chuyển tín hiệu xếp hạng sang URL mới, còn chuyển hướng tạm thời (302, 307) giữ URL cũ trong chỉ mục. 404 và 410 sẽ loại trang khỏi chỉ mục theo thời gian — điều hoàn toàn bình thường với nội dung đã không còn, nhưng các URL đã bị xóa mà vẫn có backlink thì nên chuyển hướng. Soft 404 — trang báo lỗi nhưng vẫn trả về 200 — làm lãng phí crawl budget và bị Google Search Console đánh dấu. Khi website tạm ngừng hoạt động, hãy trả về 503 kèm header Retry-After: Google sẽ giữ các trang trong chỉ mục và quay lại sau. Ngược lại, lỗi 5xx kéo dài hoặc phản hồi 429 liên tục khiến Googlebot crawl ít hơn và cuối cùng loại bỏ URL.
Location sau khi tạo tài nguyên, và 204 khi không có gì để trả về.Retry-After cho giới hạn tần suất.Kiểm tra mã trạng thái mà một URL thực tế đang trả về bằng HTTP Header Checker, theo dõi chuỗi chuyển hướng bằng Redirect Checker, hoặc tự gửi yêu cầu bằng API Tester.
Cũng được tìm dưới tên: mã phản hồi http, danh sách mã http, http status code là gì, lỗi 404, redirect 301, lỗi 500, 503 service unavailable, 429 too many requests.
Retry-After. Mã này cho bot biết sự cố chỉ tạm thời, nên thứ hạng của bạn không bị ảnh hưởng bởi các đợt bảo trì ngắn.Gợi ý cải tiến cho Mã trạng thái HTTP hoặc yêu cầu công cụ mới — gửi thẳng đến hộp thư của chúng tôi.
Ứng dụng web đã cài sẽ mở trong cửa sổ riêng; các công cụ chạy trên trình duyệt vẫn hoạt động khi không có kết nối internet. Cách cài đặt ứng dụng hoạt động
Tìm trong tất cả 570+ công cụ miễn phí — gõ sai cũng không sao — hoặc cho chúng tôi biết nên làm công cụ nào tiếp theo.