418 Tôi là ấm trà

Tóm tắt — 418 I'm a teapot là mã trạng thái hài hước được yêu thích nhất trên web. Mã xuất phát từ RFC 2324, một RFC Cá tháng Tư về bình pha cà phê, và chưa bao giờ có ngữ nghĩa ứng dụng HTTP thông thường; nhưng theo RFC 9110 và sổ đăng ký IANA, mã được dành riêng chứ không phải chưa được gán. Hướng dẫn Google năm 2023 coi mã này như mọi 4xx khác trừ 429: URL không được lập chỉ mục. Hãy thử trên site này: /coffee trả 418 thật; bạn có thể kiểm tra trong thẻ Network.

418 bắt nguồn từ đâu

Ngày 1 tháng 4 năm 1998, IETF công bố RFC 2324: Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) — giao thức được đặc tả đầy đủ nhưng hoàn toàn châm biếm để điều khiển bình pha cà phê qua web. Các đóng góp gồm phương thức BREW, header Accept-Additions (sữa, siro, whisky) và một mã trạng thái bất hủ:

418 I’m a teapot — “Any attempt to brew coffee with a teapot should result in the error code ‘418 I’m a teapot’. The resulting entity body MAY be short and stout.” (bản dịch) «Mọi nỗ lực pha cà phê bằng ấm trà phải dẫn đến mã lỗi ‘418 I’m a teapot’. Nội dung thực thể trả về CÓ THỂ thấp và tròn.»

Toàn bộ trò đùa chỉ vậy: bạn yêu cầu một ấm trà pha cà phê. Nó không làm được vì nó là ấm trà.

Mười sáu năm sau, RFC 7168 trở lại ý tưởng này cho thiết bị pha trà — một RFC Thông tin khác vào ngày Cá tháng Tư, lần này phân biệt thiết bị tạm hết cà phê với thiết bị vốn là ấm trà vĩnh viễn. Không RFC nào trao cho 418 ngữ nghĩa ứng dụng HTTP thông thường; cả hai mô tả HTCPCP, một giao thức châm biếm, không phải HTTP lõi.

Vì sao mã này chưa bao giờ trở thành HTTP thật

418 chưa bao giờ được gán ngữ nghĩa HTTP thông thường, nhưng cũng không phải “chưa được gán”. RFC 9110, đặc tả Ngữ nghĩa HTTP hiện hành, chính thức dành riêng mã này vì nó thường được triển khai như trò đùa; Sổ đăng ký mã trạng thái HTTP của IANA liệt kê 418 là (Unused) và tham chiếu RFC 9110, nghĩa là không sẵn sàng để tái sử dụng thông thường. Bằng chứng cho nhận định này RFC 9110 reserves status code 418, citing how often it has been deployed as a joke, and leaves open the possibility of assigning it a different meaning in the future if circumstances require it. Phạm vi: Current HTTP Semantics reservation; RFC 9110 does not make 418 a normal production status, but does not permanently foreclose future reassignment. Độ tin cậy: cao · Đã xác minh: 2026-07-16 IETF: RFC 9110 §15.5.19 — 418 (Unused) Năm 2017, nhóm công tác HTTP của IETF đề xuất dọn mã để có thể gán lại cho mục đích hữu ích. Internet đáp lại bằng chiến dịch “Save 418”, nên trạng thái dành riêng được giữ; RFC 9110 vẫn để ngỏ khả năng gán lại nếu hoàn cảnh tương lai thật sự yêu cầu. Bằng chứng cho nhận định này The IANA HTTP Status Code Registry lists 418 as "(Unused)" and references RFC 9110; it is not an unassigned number available for ordinary reuse. Phạm vi: IANA's current registry entry for status code 418. Độ tin cậy: cao · Đã xác minh: 2026-07-16 IANA: HTTP Status Code Registry — 418

Trạng thái dành riêng không ngăn người triển khai: net/http của Go và module http của Python đều cung cấp hằng số 418 có tên (StatusTeapot, HTTPStatus.IM_A_TEAPOT), còn framework và nền tảng khác làm theo như một easter egg — trong đó có google.com/teapot của Google. Bằng chứng cho nhận định này Go's net/http and Python's http module both expose a named 418 status constant, showing implementation recognition without requiring servers to emit 418. Phạm vi: Named constants in two mainstream standard libraries; not evidence of a default response. Độ tin cậy: cao · Đã xác minh: 2026-07-16 Go: net/http status constants (StatusTeapot) Python docs: http.HTTPStatus.IM_A_TEAPOT Hằng số có tên không có nghĩa framework mặc định phát 418; nó chỉ nghĩa mã được nhận biết, không phải mang ngữ nghĩa HTTP đã được gán.

418 có ý nghĩa gì với SEO

Không có gì đặc biệt — và đó là điều cần biết. Google không diễn giải trò đùa; một bài Search Central tháng 2 năm 2023 có tên cụ thể nói mọi phản hồi 4xx trừ 429 được xử lý giống nhau trong Search: URL từng được lập chỉ mục sẽ dần bị loại và nội dung trang không được dùng. Bằng chứng cho nhận định này Google's Search Central blog states that all 4xx responses except 429 receive the same treatment for Search: content isn't used and previously indexed URLs are removed over time. Phạm vi: Google Search's dated, named statement on 4xx handling (not 418-specific). Độ tin cậy: cao · Đã xác minh: 2026-07-16 Google Search Central Blog (Feb 2023): Don't use 403s or 404s for rate limiting Đây là phát biểu chung về 4xx, không phải rule riêng cho ấm trà; trang trạng thái crawler chung hiện hành của Google nói rõ bảng không bao phủ trạng thái hiếm như 418. Bằng chứng cho nhận định này Google's current generic crawler-status-code page states that exotic statuses such as 418 are not covered by its table. Phạm vi: Scope note limiting Google's generic HTTP-status guidance to common codes. Độ tin cậy: cao · Đã xác minh: 2026-07-16 Google: How HTTP status codes affect Google's crawlers Trong thực tế lập chỉ mục, 418 hoạt động như 4xx khác ngoài 429; không có rule xếp hạng, lịch deindex hay bảo đảm phục hồi riêng cho ấm trà ngoài phát biểu chung đó.

Điểm trò đùa hết vui là một số cấu hình WAF và bảo vệ bot dùng 418 làm phản hồi “yêu cầu bị chặn”, vì mã nổi bật và dễ tìm trong log. Nếu rule như vậy kích hoạt nhầm với Googlebot, trang thật bắt đầu trả 418 và sẽ bị xử lý hệt như trang không tồn tại.

Nếu thấy 418 trong log máy chủ hoặc báo cáo crawl trên URL quan trọng, riêng mã trạng thái không cho biết tầng nào tạo ra nó. Mã ứng dụng, mặc định framework, rule WAF/bảo vệ bot, CDN hay máy chủ gốc đều có thể phát mã, và phản hồi có thể đi qua nhiều tầng trước khi đến client. Kiểm tra cấu hình, header phản hồi và log đường dẫn yêu cầu ở từng tầng để tìm nguồn thật, rồi sửa như mọi 4xx ngoài ý muốn trên URL cần được lập chỉ mục.

Dùng chuỗi chẩn đoán tối thiểu sau:

Ghi lại trạng thái thô và header phản hồi của URL bị ảnh hưởng.
So sánh log ứng dụng, WAF, CDN và origin cho cùng đường dẫn cùng thời điểm yêu cầu.
Sửa tầng đang phát 418, rồi lặp lại yêu cầu thô và kiểm tra crawler.

Mã 418 trên site này

Đúng tinh thần RFC, /coffee trên site này trả 418 thật, thấp và tròn, trực tiếp từ edge. Trang này tồn tại để easter egg đó có lời giải thích canonical và để cụm mã trạng thái HTTP bao phủ mã duy nhất thật sự khiến mọi người mỉm cười.

TL;DR — Hãy xem phản hồi 418 ngoài ý muốn như một lỗi 4xx thông thường khác 429 do một lớp bất thường phát ra. Lưu phản hồi thô, xác định ứng dụng, WAF, CDN hay origin đã gửi nó, rồi kiểm tra đúng đường đi của crawler cho đến khi các URL quan trọng trở về trạng thái dự kiến.

Diễn giải tín hiệu trước khi thay đổi

Mã trạng thái phân loại phản hồi chứ không chỉ ra hệ thống đã chọn mã đó. Hướng dẫn Google được trích dẫn xử lý 418 như các lỗi 4xx khác 429: nội dung không được dùng để lập chỉ mục và URL đã có trong chỉ mục có thể bị loại bỏ theo thời gian; không có quy trình phục hồi riêng cho teapot.

Bắt đầu với một URL và lưu thời gian, đường dẫn, trạng thái, header và body. Kiểm tra kết quả có phụ thuộc user-agent, IP, xác thực, tần suất hay vị trí hay không.

Cô lập lớp phát phản hồi

Đi từ phản hồi công khai vào bên trong:

Tái hiện bằng request thô và ghi lại header cùng body.
Đối chiếu đường dẫn và thời gian trong log CDN, WAF, origin, framework và ứng dụng.
So sánh trình duyệt với crawler; nội dung trang lỗi không chứng minh nguồn phát.
Chỉ sửa rule hoặc mã đã được chứng minh; hằng số có tên không có nghĩa framework mặc định gửi 418.

Xác minh phục hồi

Kiểm tra lại URL theo đúng đường đã lỗi. Kết quả phải là trạng thái tài nguyên thực sự cần, thường là 200 cho trang đang hoạt động và có thể lập chỉ mục. Lấy mẫu cả các URL lân cận chịu cùng rule.

Theo dõi 418 mới trên URL có thể lập chỉ mục. /coffee phải tiếp tục là đối chứng 418 có chủ ý; trang production không được kế thừa hành vi này.

Công cụ tìm 418 ngoài ý muốn

Công cụ kiểm tra mã trạng thái HTTP hàng loạt: quét nhóm URL để tìm phản hồi 418 và phân biệt easter egg chủ ý với trang thật bị WAF hoặc rule bảo vệ bot chặn.
Công cụ kiểm tra header HTTP: xem header CDN và bảo mật để tìm manh mối về tầng tạo phản hồi.
Bảng Network trong DevTools trình duyệt: xác minh trạng thái thô của yêu cầu thay vì dựa vào chữ trên trang lỗi hiển thị.
curl: chạy curl -i https://example.com/path để ghi trạng thái, header và nội dung phản hồi mà không cần phiên trình duyệt đã đăng nhập.
Sự kiện bảo mật CDN/WAF: nếu 418 xuất hiện trên trang cần được lập chỉ mục, đối chiếu thời điểm và URL yêu cầu với rule đã kích hoạt trước khi thay đổi rule.

418 I'm a teapot bắt nguồn từ RFC 2324 (HTCPCP), RFC Cá tháng Tư năm 1998; mã nói một ấm trà đã bị yêu cầu pha cà phê. RFC 7168 trở lại ý tưởng này năm 2014 cho thiết bị pha trà.
Mã không phải “chưa được gán”: RFC 9110 chính thức dành riêng 418 và sổ đăng ký IANA liệt kê là (Unused); đây là trạng thái internet đã đấu tranh để giữ, không phải mã chưa ai nhận. Nỗ lực thu hồi mã năm 2017 bị bỏ sau chiến dịch “Save 418”.
Go và Python đều cung cấp hằng số 418 có tên; framework và nền tảng khác triển khai như easter egg, trong đó Google có google.com/teapot; nhưng hằng số không có nghĩa framework mặc định phát 418.
Tác động SEO: bài Google Search Central tháng 2 năm 2023 có tên cụ thể coi mọi 4xx ngoài 429 giống nhau trong Search — URL trả 418 không được lập chỉ mục, giống 404; trang trạng thái crawler chung hiện hành không bao phủ mã hiếm như 418.
Rủi ro thực tế: 418 ngoài ý muốn có thể đến từ ứng dụng, mặc định framework, rule WAF/bảo vệ bot, CDN hoặc origin; kiểm tra header và log từng tầng để tìm nguồn trước khi sửa như mọi 4xx khác.
Site này trả 418 thật tại /coffee.