418 的来历
418 I'm a teapot 出自 1998 年的愚人节 RFC 2324：它定义了一个超文本咖啡壶控制协议（HTCPCP），规定用茶壶煮咖啡时要回 418。后续 RFC 7168 还扩展了这套玩笑规范。它从未进入正式 HTTP 语义，IANA 注册表把它标注为 Unused，但大量框架与站点仍然把它实现成彩蛋，所以抓包时真会遇到这个码。
基本信息
| 名称 | 418 I'm a teapot |
|---|---|
| 出处 | RFC 2324 §2.3.2，扩展见 RFC 7168 |
| 注册状态 | IANA HTTP 状态码注册表标注为 Unused |
| 实现情况 | Node.js、Go 等框架可返回，Google 等站点保留彩蛋端点 |
| 分类 | 属于 4xx 客户端错误段的玩笑码 |
典型使用场景
- 接口文档里的彩蛋：某些开放平台拿它测试客户端能否处理未知 4xx
- 识别爬虫与自动化流量：部分站点对可疑请求回 418 而非 403，减少被针对性绕过
- 前端演示未知状态码兜底逻辑，验证错误映射是否健壮
- 抓包分析时确认这是实现自定义行为，不必按标准语义解读
相邻的玩笑与特殊码
| 状态码 | 含义 | 是否标准 |
|---|---|---|
| 418 | 我是个茶壶 | 否，未分配 |
| 450 | 被微软封锁（历史遗留） | 否 |
| 451 | 因法律原因不可用 | 是，RFC 7725 |
| 599 | 部分代理用作网络连接超时 | 否，非标准 |
观察与实现
观察与实现
curl -si https://www.google.com/teapot | head -3
# HTTP/1.1 418 I'm a teapot
curl -si https://example.com/healthz | head -1 # 确认业务接口没有误用玩笑码
# Node.js: res.status(418).send('teapot')别在严肃业务里用 418 表达真实错误：监控平台与客户端 SDK 的状态码映射表通常不认识它，会被归入「未知 4xx」，告警与重试策略都会失准。
按标准，客户端收到无法识别的状态码时应把它当作同类别处理（4xx 归客户端错误）；实现良好的库会保留原始数字，便于排查。
链路排查时要在日志里保留原始状态码与响应体：彩蛋码经网关或 SDK 包装后往往只剩一个 4xx 分类，真正的码值被吞掉，定位成本反而升高。