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: bytes300-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 客户端错误类问题在请求侧| 状态码 | 名称 | 含义 | | :- | :- | :- |400| Bad Request | 服务器不理解该请求语法错误、畸形参数、请求体过大无法解析等 | |401| Unauthorized | 请求的页面需要用户名和密码响应通常携带WWW-Authenticate头 | |402| Payment Required | 该状态码被创建时最初用于表明请求的内容只有付费之后才能获取目前不存在标准的使用约定 | |403| Forbidden | 禁止了对于此页面的请求——身份已识别但权限不足与401的区别401 是你是谁403 是你没资格 | |404| Not Found | 服务器找不到请求的页面 | |405| Method Not Allowed | 请求中指定的方法不被允许响应头Allow会列出可用方法 | |406| Not Acceptable | 服务器只能生成客户端不接受的响应Accept协商失败 | |407| Proxy Authentication Required | 您必须先通过代理服务器进行身份验证然后才能提供此请求 | |408| Request Timeout | 请求花费的时间比服务器准备等待的时间长 | |409| Conflict | 由于冲突请求无法完成如并发写入同一版本资源 | |410| Gone | 请求的页面不再可用且永久消失与 404 的区别是明确告知不用再试了可安全移除缓存 | |411| Length Required |Content-Length未定义没有它服务器将不会接受请求 | |412| Precondition Failed | 请求中给出的前提条件被服务器评估为 falseIf-Match、If-Unmodified-Since等前置头校验失败 | |413| Payload Too Large | 服务器不会接受请求因为请求实体太大如上传文件超过client_max_body_size | |414| URI Too Long | 服务器不会接受请求因为 URL 太长。当您将发布请求转换为具有长查询信息的获取请求时发生 | |415| Unsupported Media Type | 服务器不会接受请求因为不支持媒体类型 | |416| Range Not Satisfiable | 请求的字节范围不可用且超出范围与206配对使用 | |417| Expectation Failed | 此服务器无法满足在Expect请求标头字段中给出的期望 | |426| Upgrade Required | 服务器拒绝使用当前协议执行请求但在客户端升级到不同协议后可能愿意这样做 | |451| Unavailable For Legal Reasons | 此状态代码表示服务器拒绝访问资源作为法律要求的结果 |原文档未逐条列出但实践中高频出现的还有418 Im a teapotRFC 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 7235WebDAV 扩展 102 来自 RFC 2518451 来自 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行为。【免费下载链接】reference面向开发者的技术速查清单Cheat Sheets集合整理常见技术、工具与开发流程帮助快速查阅关键信息提高开发效率。项目地址: https://gitcode.com/GitHub_Trending/referen/reference创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 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: bytes300-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 客户端错误类问题在请求侧| 状态码 | 名称 | 含义 | | :- | :- | :- |400| Bad Request | 服务器不理解该请求语法错误、畸形参数、请求体过大无法解析等 | |401| Unauthorized | 请求的页面需要用户名和密码响应通常携带WWW-Authenticate头 | |402| Payment Required | 该状态码被创建时最初用于表明请求的内容只有付费之后才能获取目前不存在标准的使用约定 | |403| Forbidden | 禁止了对于此页面的请求——身份已识别但权限不足与401的区别401 是你是谁403 是你没资格 | |404| Not Found | 服务器找不到请求的页面 | |405| Method Not Allowed | 请求中指定的方法不被允许响应头Allow会列出可用方法 | |406| Not Acceptable | 服务器只能生成客户端不接受的响应Accept协商失败 | |407| Proxy Authentication Required | 您必须先通过代理服务器进行身份验证然后才能提供此请求 | |408| Request Timeout | 请求花费的时间比服务器准备等待的时间长 | |409| Conflict | 由于冲突请求无法完成如并发写入同一版本资源 | |410| Gone | 请求的页面不再可用且永久消失与 404 的区别是明确告知不用再试了可安全移除缓存 | |411| Length Required |Content-Length未定义没有它服务器将不会接受请求 | |412| Precondition Failed | 请求中给出的前提条件被服务器评估为 falseIf-Match、If-Unmodified-Since等前置头校验失败 | |413| Payload Too Large | 服务器不会接受请求因为请求实体太大如上传文件超过client_max_body_size | |414| URI Too Long | 服务器不会接受请求因为 URL 太长。当您将发布请求转换为具有长查询信息的获取请求时发生 | |415| Unsupported Media Type | 服务器不会接受请求因为不支持媒体类型 | |416| Range Not Satisfiable | 请求的字节范围不可用且超出范围与206配对使用 | |417| Expectation Failed | 此服务器无法满足在Expect请求标头字段中给出的期望 | |426| Upgrade Required | 服务器拒绝使用当前协议执行请求但在客户端升级到不同协议后可能愿意这样做 | |451| Unavailable For Legal Reasons | 此状态代码表示服务器拒绝访问资源作为法律要求的结果 |原文档未逐条列出但实践中高频出现的还有418 Im a teapotRFC 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 7235WebDAV 扩展 102 来自 RFC 2518451 来自 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行为。【免费下载链接】reference面向开发者的技术速查清单Cheat Sheets集合整理常见技术、工具与开发流程帮助快速查阅关键信息提高开发效率。项目地址: https://gitcode.com/GitHub_Trending/referen/reference创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考