原因短语是什么
HTTP/1.1 状态行由三部分组成：版本、三位状态码、原因短语（Reason-Phrase），例如 200 OK 中的 OK。短语只是给人看的可读文本，规范明确客户端不得依赖它做判断；HTTP/2 起状态行被取消，只有 :status 这个伪头部携带数字。理解这一点，就不会再试图靠改短语去「让程序识别错误」。
基本信息
| 组成 | HTTP/1.1 200 OK —— OK 即原因短语 |
|---|---|
| 规范 | RFC 9110 §15（短语由实现自由填写，客户端不得依赖） |
| HTTP/2 及以上 | 只有 :status 数字，没有原因短语与状态行 |
| 常见非标准码 | Nginx 私有 444、495、496、497、499 |
Nginx 私有状态码
| 状态码 | 含义 | 典型场景 |
|---|---|---|
| 444 | 直接关闭连接不回响应 | 拦截恶意扫描、隐藏服务 |
| 495 | 客户端证书错误 | 双向认证失败 |
| 496 | 需要客户端证书 | 未提供证书 |
| 497 | HTTP 请求发到了 HTTPS 端口 | 协议用错端口 |
| 499 | 客户端提前关闭连接 | 上游超时或用户取消，只出现在访问日志 |
观察与自定义
观察与自定义
curl -si https://example.com/ | head -1 # 看完整状态行与短语
curl -si https://example.com/ | head -1 | cat -A # 确认短语后的 CRLF
# 修改短语需第三方模块（more_headers 等），不建议依赖
# 应用侧要可读错误就把说明放进响应体 JSON，而不是改短语典型使用场景
- 读日志时区分「框架自造的状态码」与标准码，避免把 499 当成标准响应处理
- 排查反向代理异常：495 到 497 基本可以确定是 TLS 或证书配置问题
- 对接老客户端时确认其是否真的解析了短语，多数库只认数字
- 设计 API 错误约定时把说明放进响应体，而不是自定义短语
499 是 Nginx 自己记账用的：它表示客户端在服务器给出响应前就断开，通常意味着上游太慢或用户取消，抓包时看不到这个码被真正发给客户端。
HTTP/2 与 HTTP/3 中没有状态行，抓包工具展示的「状态短语」是工具按数字表反查补上的，看到的文本并不来自服务端。