可检索的 HTTP 状态码速查表，包含标准原因短语与定义它的 RFC 章节，支持按 1xx 至 5xx 分类过滤。
这个响应码到底代表什么？ 输入数字（如 429）或单词（如 gateway）过滤表格，也可以只看某一类。每行给出状态码、在链路上实际传输的原因短语，以及定义它的规范章节。
没有匹配的状态码。
每个 HTTP 响应都以三位数字开头，而客户端必须理解的只有第一位。RFC 9110 写得很明确：收到无法识别的 499 时，客户端应当完全按 400 处理。类别决定语义，后两位只是细化。正是这条规则让协议可以持续扩展——2005 年写的代理今天仍能正确转发 451，哪怕它根本不知道什么是法律审查。
五个类别按"接下来谁负责"划分得很干净：1xx 是临时响应，真正的结果还在后面；2xx 表示成功，客户端可以收工；3xx 交回一个重定向，客户端应换个地址重试；4xx 归咎于请求本身，原样重发只会再次失败；5xx 归咎于服务端，同样的请求重试有可能成功。所以重试逻辑应该按类别而不是具体码来写：重试 503 合理，重试 403 是 bug。
301 与 308、302 与 307 的区别不是风格问题。旧的一组允许客户端在跟随重定向时把 POST 改写成 GET，浏览器历史上确实这么做。新的一组禁止改写，方法和请求体都会被保留。如果用 301 迁移一个表单端点，部分客户端会静默地把提交变成 GET 并丢掉负载。非幂等的请求请用 308 或 307。
401 和 403 同样常被混用。401 表示请求未通过认证，响应必须带上 WWW-Authenticate 挑战头，告诉客户端该怎样带凭据重试；403 表示服务端已经知道你是谁，但仍然拒绝。不带挑战头的 401 属于违反规范，而用户只是忘了登录却返回 403，会让排查变得困难得多。
4xx 里还有一组很有用的划分：400 与 422。400 表示请求根本无法解析，语法就是坏的；422 表示语法解析正常，但内容没通过校验。区分这两者能把一个含糊的失败变成可行动的提示。
状态码旁边的文字（如 Not Found、I'm a teapot）叫原因短语。HTTP/1.1 会在状态行里传输它，但 HTTP/2 和 HTTP/3 已彻底移除，所以现代连接上往往只有数字而没有短语。客户端代码绝不应该依据这个字符串分支判断——它存在的意义仅仅是让人在看日志或原始抓包时不用查表。
有些状态码的约束也比看上去更严格：204 和 304 不得携带消息体，中间件擅自添加就会产生非法响应；HEAD 响应无论什么码都不带消息体。这些成帧规则很重要，因为不该有消息体的地方出现消息体会破坏连接复用的同步，表现出来是跨请求的诡异串数据，而不是一个明确的报错。