HTTP Status Code Explorer
Search common HTTP status codes, compare lookalike failures such as 401 vs 403 vs 422, and keep a sharper debugging checklist next to the raw response you are investigating.
401 Unauthorized
4xxAuthentication is missing, expired, or invalid for this request.
The token is absent, malformed, expired, signed for the wrong audience, or dropped by a proxy.
- Confirm the Authorization header is actually reaching the server.
- Check token expiry, issuer, audience, and environment-specific secrets.
常见问题
401 和 403 之间有什么区别？
`401 Unauthorized` 响应通常意味着身份验证材料本身缺失、过期、格式错误或不可接受。`403 Forbidden` 响应通常意味着调用者已通过身份验证，但缺乏该操作所需的权限、范围 (Scope)、方案或所有权。
在 API 调试中应该如何看待 400 与 422？
将 `400 Bad Request` 视为服务器根本无法正确解析或解释请求结构的信号。将 `422 Unprocessable Entity` 视为结构有效足以解析，但负载在解析后未能通过验证或业务规则的信号。
如何区分 429 问题和 503 问题？
`429 Too Many Requests` 响应首先引导您检查频率限制、配额和重试行为。`503 Service Unavailable` 响应引导您检查临时服务不稳定、依赖压力、维护窗口或更广泛的平台饱和。
当我看到失败的 API 请求中有 HTTP 状态码时，首先应该检查什么？
首先区分客户端故障系列（如 `4xx`）和服务器端故障系列（如 `5xx`），因为这会立即改变调查路径。然后通过询问您处理的是语法、认证、权限、验证、限流还是不稳定的上游服务来缩小问题范围。
工作流程
HTTP 状态码查询 是什么？
HTTP 状态码查询工具可帮助您将原始的 API 失败转化为更有用的调试序列。与其将状态码视为静态参考表，不如对比常见的易混淆项（如 `401` 与 `403`、`400` 与 `422` 或 `429` 与 `503`），同时将下一步检查重点放在手边。
这在事件响应和日常 API 调试中尤其有用，因为一个代码错误往往会让团队走错排查方向。状态码查询工具通过为每个代码匹配真实的生产场景和简短的检查清单，减少了这种偏离。
如何使用 HTTP 状态码查询
按代码、标题或症状（如 `timeout`、`forbidden` 或 `validation`）进行搜索，然后使用 `2xx`、`3xx`、`4xx` 和 `5xx` 过滤器缩小列表。选择一个状态码以查看其含义、真实的生产场景、接下来的检查步骤以及通常与之混淆的临近代码。
当您想与同事分享结果时，使用“复制总结”来获取精简的解释和检查清单，适用于工单、Slack 讨论或交接记录。
示例
示例：
一个 API 登录调用在测试环境返回 401，但在生产环境返回 403。
如何使用该工具：
1. 打开 401 并验证是否缺少请求头、令牌过期、颁发者 (Issuer) 或受众 (Audience) 问题。
2. 对比 403 并检查令牌是否有效但角色 (Role) 或范围 (Scope) 不足。
3. 复制总结，以便团队在这是身份验证 (Authentication) 问题还是权限批准 (Authorization) 问题上达成一致。应用场景
1. 在盲目更改身份验证逻辑之前，对比 `401`、`403` 和 `404`。
2. 区分格式错误请求 (`400`) 与验证失败 (`422`)。
3. 区分频率限制事件 (`429`) 与临时服务降级 (`503`)。
4. 在 API 故障排查期间快速构建事件笔记。
常见问题
这与普通的 HTTP 状态码图表有什么不同？
图表只提供定义，但很少能告诉您工程师在生产环境中实际上会混淆什么。此工具增加了真实的场景、实用的检查步骤以及通常会触发错误调试方向的临近代码。
此工具是否会检查实时响应体？
不会。它专注于状态码解释和排错引导，而不是负载解析。当响应体本身也可能格式错误时，请将其与 JSON 验证器等工具配合使用。
它对后端团队和前端团队都有用吗？
是的。前端团队可以使用它快速推断网络故障，而后端团队可以将其作为支持工单、事件笔记和 API 评审对话的快速检查清单。