Quick Reference HTTP 状态码速查指南：1xx 到 5xx 完整清单与 curl、nginx 实战用法-创锋一号

Quick Reference HTTP 状态码速查指南：1xx 到 5xx 完整清单与 curl、nginx 实战用法

【免费下载链接】reference面向开发者的技术速查清单（Cheat Sheets）集合，整理常见技术、工具与开发流程，帮助快速查阅关键信息，提高开发效率。项目地址: https://gitcode.com/GitHub_Trending/referen/reference

本文基于 HTTP 状态码备忘清单系统整理 1xx 到 5xx 全部常用 HTTP 状态码的含义与适用场景，并结合本仓库中 curl 备忘清单与 NGINX 备忘清单的实用配置，讲解如何用命令和反向代理直接验证、构造各类状态码，帮助你在接口调试、日志排障和 API 设计中快速定位问题、正确选型。

状态码五大分类总览

HTTP 状态码是服务器对客户端请求的应答信号，按首位数字分为五个类别。这一分类体系直接决定了你在排障时的第一反应方向：

1xx: 信息—— 代表已收到请求并且该过程正在继续；
2xx: 成功—— 代表该操作已成功接收、理解和接受；
3xx: 重定向—— 代表必须采取进一步行动才能完成请求；
4xx: 客户端错误—— 代表请求包含不正确的语法或无法完成；
5xx: 服务器错误—— 代表服务器未能满足明显有效的请求。

记住这个"责任归属"逻辑：4xx 的问题在客户端（改请求、带凭证、修参数），5xx 的问题在服务器端（查进程、查上游、查资源）。以下各节逐个展开每个状态码的标准语义。

1xx 信息类：过程仍在继续

| 状态码 | 名称 | 含义 | | :- | :- | :- |100| Continue | 服务器只收到了请求的一部分，但只要没有被拒绝，客户端就应该继续请求 | |101| Switching Protocols | 服务器切换协议，典型场景是 WebSocket 握手成功后从 HTTP 切换到 WebSocket 协议 | |102| Processing | 用于通知客户端服务器已接受完整请求但尚未完成的临时响应（源自 WebDAV 扩展，RFC 2518） |

1xx 响应通常是"中间报文"，浏览器与多数 HTTP 客户端不会将其暴露给业务层。最典型的实战场景是Expect: 100-continue头：客户端上传大文件前先发送请求头，收到100 Continue后再发送请求体，避免"头都不可用、白传了请求体"的浪费。

2xx 成功类：操作已被接受

| 状态码 | 名称 | 含义 | | :- | :- | :- |200| OK | 请求成功，响应体中携带请求的资源（GET/PUT/DELETE 的标准成功应答） | |201| Created | 请求成功，并创建了新的资源，响应头通常附带Location指向新资源 | |202| Accepted | 请求成功，但处理尚未完成（已被排队异步处理），客户端需另行轮询结果 | |203| Non-Authoritative Information | 请求成功，但负载经过了第三方服务器（如缓存代理）的修改，而非原始负载 | |204| No Content | 响应给出了状态码和标头，但响应中没有实体主体，常用于"操作成功、无内容可返回"的 POST/PUT/DELETE | |205| Reset Content | 请求成功，但浏览器应重置文档视图，比如清空表单内容、重置 canvas 状态或者刷新用户界面 | |206| Partial Content | 请求成功，服务器正在返回请求所指定部分的数据。用于响应标头中指定了数据区间的请求。服务器必须使用Content-Range标头指定响应中包含的数据区间 |

两个值得展开的实战点：

201与200的区分。REST 风格下，POST创建资源应返回201 Created并携带Location头；若你习惯用POST做幂等更新（如"注册或覆盖"），则返回200或204更贴切。
206是断点续传的地基。客户端请求Range: bytes=300-599，服务器返回206并在Content-Range: bytes 300-599/1000中声明区间。视频拖动进度条、curl --continue-at -续传下载，底层都依赖这一对状态码与标头。

3xx 重定向类：还需要一步动作

| 状态码 | 名称 | 含义 | | :- | :- | :- |300| Multiple Choices | 一个链接列表。用户可以选择一个链接并转到该位置（最多五个地址） | |301| Moved Permanently | 请求的页面已永久移至新的 URL，客户端应更新书签，后续请求直接走新地址 | |302| Found | 请求的页面已临时移动到新的 URL | |303| See Other | 请求的页面可以在不同的 URL 下找到，客户端应用 GET 访问该地址获取结果（常用于 POST 后跳转） | |304| Not Modified | 这是对If-Modified-Since或If-None-Match标头的响应代码，其中 URL 自指定日期以来未修改，客户端应使用本地缓存 | |305| Use Proxy | 请求的 URL 必须通过Location标头中提到的代理访问 | |306| Unused | 此代码在以前的版本中使用过，它不再使用，但代码被保留 | |307| Temporary Redirect | 请求的页面已临时移动到新的 URL，且要求重定向后保持原请求方法与请求体（区别于302可能被改写为 GET） |

补充一点：RFC 7538 定义了308 Permanent Redirect，语义与307相同但表示永久搬迁，重定向后同样保持方法与请求体不变。它未在原文档清单中列出，但在现代服务器（含 NGINX）中已是常见能力。

301 与 302 的选型要点：301会被浏览器和爬虫持久缓存，适合域名迁移、www 归一化这类"一次改、永远对"的场景；302/307不缓存，适合维护页、A/B 分流这类随时可能撤销的跳转。

用 NGINX 配置重定向状态码

本仓库的 NGINX 备忘清单给出了直接可抄的return写法，其中return 301即为上文"301 永久重定向"：

server { listen 80; server_name demo.com; # 将 http 永久重定向到 https，对应 301 Moved Permanently return 301 https://demo.com$request_uri; }

server { listen 80; server_name yourdomain.com; # 临时重定向，对应 302 Found return 302 http://otherdomain.com; }

该清单还整理了rewrite指令的两个重定向修饰符，与上表直接对应：

| 修饰符 | 说明 | | :- | :- |permanent| 永久性重定向，日志中的状态码为301| |redirect| 临时重定向，日志中的状态码为302|

例如把整个旧子路径 301 到新站：

location /old-site/ { rewrite ^/old-site/(.*) http://example.org/new-site/$1 permanent; }

这意味着你在 nginx 的 access log 里看到的$status列，取值正是上表中的这些数字——排障时"哪个页面在跳 301"可以直接从日志里 grep 出来。

4xx 客户端错误类：问题在请求侧

原文档未逐条列出但实践中高频出现的还有：418 I'm a teapot（RFC 828 愚人节彩蛋）、422 Unprocessable Entity（语义校验失败，REST 表单/JSON 校验常用）、429 Too Many Requests（限流）。后两者在下一节的 API 对照表中出现。

5xx 服务器错误类：问题在服务侧

| 状态码 | 名称 | 含义 | | :- | :- | :- |500| Internal Server Error | 请求未完成，服务器遇到了意外情况（未捕获异常的兜底应答） | |501| Not Implemented | 请求未完成，服务器不支持所需的功能 | |502| Bad Gateway | 请求未完成，服务器收到来自上游服务器的无效响应（网关/反向代理连不上或上游报错） | |503| Service Unavailable | 请求未完成，服务器暂时超载或停机，可配合Retry-After头告知重试时机 | |504| Gateway Timeout | 网关已超时——上游在限定时间内没有给出响应 | |505| HTTP Version Not Supported | 服务器不支持请求所用的 HTTP 协议版本 |

在网关拓扑下，这三个码有明确分工：502是上游返回了"坏东西"（连接被拒、响应格式非法），504是上游"太慢"（等到超时），503是主动"拒绝服务"（限流、维护窗口）。本仓库 NGINX 备忘清单中就展示了在 NGINX 层直接return 503做维护降级返回的写法，以及配置proxy_next_upstream重试上游时502/504的产生与收敛逻辑。

RESTful API 推荐状态码对照

原文档专门整理了一份 RESTful API 语境下的状态码选用表。做接口设计时按这张表对齐语义，客户端（前端、第三方集成、Agent 解析）才能仅凭状态码做正确的分支处理：

| 状态码 | RESTful API 建议语义 | | :- | :- | |200| 返回成功，GET、DELETE 请求成功 | |204| 无内容，POST 请求成功（操作完成且无响应体） | |301| 永久重定向 | |302/307| 临时重定向 | |304| 未修改，自上次请求以来（命中缓存） | |331| 用户名正确，需要密码 | |332| 需要登录帐户 | |400| 错误请求，缺少 API 请求的必需属性 | |401| 未授权，无效凭据进行身份验证失败 | |403| 禁地，该请求不被允许 | |404| 未找到，无法访问资源 | |405| 方法不允许，不支持该请求方法 | |409| 冲突，冲突资源已存在 | |412| 该请求被拒绝（前置条件不成立） | |422| 无法处理，无法处理该实体（参数格式对但语义不合法） | |429| 请求过多，用户超出了应用速率限制 | |500| 服务器错误，在处理请求时，服务器出现问题 | |530| 未登录 |

需要说明的是：331、332、530并非 IETF 定义的 HTTP 标准状态码，它们实际出自 FTP 协议的应答码体系（下文"FTP 永久性否定应答"一节有完整对照），原文档将其一并列出，是因为很多内网网关与老式 API 系统直接沿用了这套数字作为自定义约定。如果你的服务在文档里出现这三个码，应以该服务的私有约定为准，不要按 HTTP 标准语义理解。

422与400的边界也值得强调：400表示"请求根本读不懂"（字段缺失、JSON 解析失败），422表示"读懂了但不合规"（如注册邮箱已被占用、日期早于出生日期）。

FTP 协议的应答码：永久性否定应答

原文档末尾的"5xx 永久性否定"一节，其内容是FTP 协议（而非 HTTP）的应答码清单——HTTP 与 FTP 的应答码在数字上高度重叠但语义体系独立。这些代码表示永久性否定的完成答复：该命令不成功，错误是永久性的，如果客户端重试命令，将再次出现同样的错误（与之相对的是 4xx 类临时错误，重试可能成功）。

| 应答码 | 含义 | | :- | :- | |500| 语法错误，命令无法识别。这可能包括诸如命令行太长之类的错误 | |501| 在参数中有语法错误 | |502| 未执行命令 | |503| 错误的命令序列（如未登录就发 STOR） | |504| 未执行该参数的命令（参数不被支持或不被理解） | |530| 未登录 | |532| 存储文件需要帐户 | |550| 未执行请求的操作，文件不可用（例如：未找到文件、没有访问权限） | |551| 请求的操作异常终止：未知的页面类型 | |552| 请求的文件操作异常终止：超出存储分配（对于当前目录或数据集） | |553| 未执行请求的操作，不允许的文件名 |

当你通过 curl 备忘清单中的 FTP 用法（如curl -T file ftp://server/）或 FTP 备忘清单中的交互式命令调试文件传输时，-v详细输出里回显的正是这套数字。例如530出现即提示检查账号密码，550出现即提示检查路径与权限。

实战：用 curl 验证与捕获状态码

理解状态码的最后一公里是"亲眼看到它"。本仓库 curl 备忘清单中有几条与状态码直接相关的命令，可直接复制使用：

只看响应头，快速确认状态码与重定向链：

# --head: 仅获取标头，首行即状态码（如 HTTP/2 301） curl -I https://example.com # --include: 在输出中同时包含 HTTP 标头 curl -i https://example.com

配合-L跟随重定向：当服务器返回301/302/307时，加-L让 curl 自动"点击"Location指向的地址，直到拿到最终响应。调试跳转链时可加-v观察每一跳的状态码变化。

脚本化探测：只输出状态码（健康检查、上线探活最常用的一招）：

# -o /dev/null 丢弃响应体，-I 只发 HEAD，-w 以模板输出状态码，最终只打印一个三位数 curl -o /dev/null --silent -I -w "%{http_code}" https://example.com/my.remote.tarball.gz

输出形如200/403/404，可直接用于 shell 条件判断：

code=$(curl -o /dev/null --silent -I -w "%{http_code}" https://example.com/health) [ "$code" = "200" ] && echo OK || echo "异常: $code"

断点续传与 206 的验证：

# --continue-at 发送 Range 请求，支持续传的服务器将返回 206 而非 200 curl --remote-name --continue-at - "https://example.com/linux-distro.iso"

配合curl -v观察请求/响应头中的Range、Content-Range字段，即可确认对端是否真正实现了部分响应。

速查入口与延伸阅读

本清单的原始文档位于 docs/http-status-code.md，采用 IETF RFC 作为各状态码语义的权威出处（2xx/3xx/4xx/5xx 主体定义来自 RFC 7231，范围请求与条件请求来自 RFC 7232/7233，认证来自 RFC 7235，WebDAV 扩展 102 来自 RFC 2518，451 来自 RFC 7725）。仓库中与本主题直接相关的配套文档：

curl 备忘清单：请求头/响应头查看、重定向跟随、状态码模板输出；
NGINX 备忘清单：return 301/302/503、rewrite ... permanent/redirect的重定向配置；
FTP 备忘清单：FTP 应答码出现时的交互式调试手段；
MIME types 备忘清单：与415 Unsupported Media Type、406 Not Acceptable排查配套的媒体类型速查；
常见端口对照：排查502/504上游不可达时的端口核对参考。

掌握这份清单后，你应该能够：看 access log 里的$status值立即判断问题归属（4xx 改客户端 / 5xx 查服务端）；设计 REST 接口时为每种失败模式选择语义准确的状态码；以及在 NGINX、curl 层面快速构造和验证重定向、缓存（304）与部分响应（206）行为。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析