网络状态码_列举所有状态码_100至500

2025-08-23 10:15:47

通过阮一峰博客看到了相关http码的详细解释，现在分别归类一下。

197

Informational 1xx

100 Continue【服务器给客户端的“绿灯”】

用途：客户端（比如浏览器）在发送较大数据（比如文件上传）前，先问服务器：“我要发数据了，你准备好了吗？”

服务器回应：

如果服务器说 100 Continue，表示：“可以发，我等着！”
如果服务器拒绝（比如文件太大），客户端就不用白费流量发送了。

节省资源：避免客户端直接发送大量数据后，才发现服务器不接收，浪费时间和带宽。

举个栗子：

你上传一个1GB的视频 → 浏览器先问服务器：“能传吗？”
服务器检查空间足够 → 回复 100 Continue → 浏览器开始上传。
如果服务器空间不足 → 回复错误（如 413 Payload Too Large）→ 上传直接取消。

101 Switching Protocols【服务器在说：“好的，我们换个新协议聊天吧！”】

用途：当客户端（比如浏览器）和服务器需要升级通信协议时使用。

常见场景：从 HTTP 协议 切换到 WebSocket（比如网页聊天室、实时游戏）。

交互过程：

客户端请求升级协议（比如：Upgrade: websocket）。
服务器同意 → 返回 101 Switching Protocols，之后双方就用新协议通信。

关键点：协议切换后，原来的HTTP连接会变成另一种协议（比如WebSocket），继续传输数据。

举个栗子：

网页聊天室：
浏览器用HTTP连到服务器，请求升级到WebSocket。
服务器返回 101 → 双方开始通过WebSocket实时收发消息。
HTTP/2 升级：从旧的HTTP/1.1切换到更快的HTTP/2。

102 Processing【服务器的“进度条提醒”，意思是：“我没卡死，活还在干，请稍候！” 】

用途：服务器告诉客户端：“你的请求我收到了，但处理起来比较耗时，别急着超时，我还在努力！”

适用于长时间运行的操作（比如大文件处理、复杂计算）。

为什么需要它？

如果没有这个状态码，客户端可能以为“卡住了”，直接断开连接或重试，导致重复提交。

和 100 Continue 的区别：

100 是问：“能发数据吗？” → 服务器说：“可以发。”
102 是：“数据已收到，正在处理，请耐心等结果。”

举个栗子：

上传大文件并转码：
你传了一个视频到云盘，服务器返回 102，表示：“正在转码，别关页面！”
批量删除操作：
删除1万条数据时，服务器返回 102，避免客户端以为请求丢失。

103 Early Hints【服务器的“抢跑指令”，意思是：“正式内容还没好，但这些资源你可以先准备着！” 】

用途：服务器在正式响应（比如HTML页面）准备好之前，先提前告诉浏览器可以预先加载哪些资源（比如CSS、JS、图片）。

类似“剧透”关键信息，让浏览器聪明地提前准备。

为什么需要它？

传统流程：浏览器必须等完整HTML下载完，才发现需要加载CSS/JS，浪费时间。
用 103 后：服务器在生成HTML的同时，先发个“预告”：“待会儿要用这些文件，你先去下载吧！”

效果：网页加载更快，用户体验更流畅（尤其对慢速网络或复杂网站）。

举个栗子：

访问一个网站：
浏览器请求首页。
服务器先返回 103，提示：“你先去加载 styles.css 和 logo.png 吧！”
浏览器并行下载这些资源，同时等服务器生成完整的HTML。
电商网站：提前提示加载商品图片，减少用户等待时间。

Successful 2xx

200 OK【互联网的“绿灯”，意思是：“搞定！你要的东西在这儿！”】

用途：服务器告诉客户端（比如浏览器）：“你的请求我成功处理了，这是你要的东西！”

适用于几乎所有成功的请求（比如加载网页、下载文件、提交表单成功）。

常见场景：

打开网页 → 返回 200 + HTML内容。
下载图片 → 返回 200 + 图片数据。
提交登录表单 → 返回 200 + “欢迎页面”。

为什么它重要？

它是HTTP最“理想”的状态码，表示一切按预期运行。

举个栗子：

浏览知乎首页：
浏览器请求 zhihu.com → 服务器返回 200 + 网页内容。
微信发送消息：
你发“你好”给朋友 → 服务器返回 200（表示消息发送成功）。

201 Created【服务器的“确认函”，意思是：“你要的东西我做好了，这是它的身份证（地址）！” 】

用途：服务器告诉客户端：“你让我创建的新资源（比如文件、用户账号、订单）已经成功搞定了！”

和 200 OK 的区别：200 是通用成功，而 201 专门用于新建资源成功。

常见场景：

注册新用户 → 返回 201 + 用户ID。
上传新文件到网盘 → 返回 201 + 文件链接。
提交订单 → 返回 201 + 订单编号。

通常会附带新资源的地址：

服务器会在响应头中加一个 Location 字段，告诉客户端：“这是你刚创建的东西的访问路径”。

举个栗子：

发微博：
你发了一条新微博 → 服务器返回 201 + 微博ID（比如 /posts/123）。
GitHub新建仓库：
你创建了一个叫 my-project 的仓库 → 返回 201 + 仓库地址 github.com/yourname/my-project。

202 Accepted【服务器的"收件回执"，意思是："活我接了，但结果要等等，你可以先忙别的去" 】

用途：服务器告诉客户端："你的请求我收到了，也接受了，但还没处理完，结果要等等"

和 200/201 的关键区别：202 表示"已接收但未完成"

典型使用场景：

需要排队处理的任务（比如视频转码）
需要人工审核的内容（比如用户投稿）
需要调用外部系统的操作（比如支付结算）

后续跟进方式：

响应中通常会包含一个状态查询接口（比如 /task-status/123）
也可能通过回调通知（webhook）告知最终结果

举个栗子：

视频网站上传：
你传了个4K视频 → 服务器返回 202："视频已接收，正在转码，可通过/task/456查询进度"
银行转账：
你发起大额转账 → 银行返回 202："交易已受理，需要人工审核，2小时内短信通知结果"

203 Non-Authoritative Information【服务器的"免责声明"："这消息绝对保真，但不保证是最新版本哦！"】

用途：代理服务器告诉客户端："这个响应不是我生成的，是原始服务器的，但可能不是最新鲜的"

就像"二手信息"，虽然来自权威来源，但可能不是第一手

出现场景：

使用了缓存代理服务器（CDN）
响应头信息被代理修改过
原始服务器的完整验证不可用

与200 OK的区别：

200：这是新鲜出炉的数据！
203：这是从别处转发的数据，可能有点"回锅"

举个栗子：

新闻网站：
你访问的页面来自CDN缓存（203）
页脚显示"数据最后更新于10分钟前"
API调用：
请求经过网关转发
响应头显示部分字段被网关修改过

204 No Content【服务器的"默契点头"："事情办妥了，不用我多说，你懂的~" 】

用途：服务器成功处理了请求，但不需要返回任何内容

就像点头确认，不需要多余的解释

典型使用场景：

表单提交只需成功反馈（如"保存成功"弹窗）
删除操作成功
自动化的后台操作

特殊优势：

节省网络流量（没有多余的响应体）
让前端可以自由处理成功逻辑

举个栗子：

点赞功能：

点击"喜欢"按钮 → 服务器返回 204
前端直接切换爱心图标即可，不需要服务器返回新数据

清空购物车：

点击"全部删除" → 204 表示成功
页面直接清空列表，不需要刷新

205 Reset Content【服务器的"黑板擦"："操作成功啦，现在把页面擦干净，可以重新开始了！"】

用途：服务器告诉客户端（通常是浏览器）："请求已成功处理，现在请清空当前表单/显示内容，方便用户重新输入"

和 204 的关键区别：204 只是"完成"，205 还要求"重置"

设计初衷：

专门为网页表单设计的状态码
避免用户重复提交相同内容

实际效果：

浏览器收到后会清空当前表单的所有输入框
但不会刷新页面（和页面刷新不同）

举个栗子：

问卷调查提交后：
提交成功 → 返回 205
网页自动清空所有选择题选项，方便下一位用户填写
在线测试系统：
交卷成功后 → 返回 205
自动清空答题卡，准备下一场考试

206 Partial Content【服务器的"分餐服务"："你要的第2-5分钟的视频片段在这，其他部分需要再问我拿！"】

用途：服务器成功返回了客户端请求的部分内容（就像视频"断点续传"）

必须配合 Range 请求头使用
响应会包含 Content-Range 说明这是哪一部分

为什么需要它：

大文件可以分块下载（比如暂停/继续）
网络不好时不用重头开始
支持快速跳转到视频的某个时间点

特殊优势：

节省带宽（不用下载完整文件）
提升大文件传输可靠性

举个栗子：

在线视频网站：
拖动进度条到中间 → 浏览器请求"从10MB开始的内容"
服务器返回 206 + 视频的10-20MB片段
下载管理器：
下载到50%暂停 → 下次从50%继续请求
服务器返回剩余部分

207 Multi-Status【服务器的清单，每个都有状态码】

用途：当客户端一次请求多个操作时，服务器返回每个操作的独立状态

就像一个包裹里装着多个子请求的结果报告
常见于 WebDAV 协议（网络文件管理）

数据格式：

响应体是一个 XML/JSON 列表
每个子项都有独立的状态码（比如 200/404/403 等）

典型场景：

批量删除云盘文件（有的成功有的失败）
同时获取多个资源的状态
日历系统处理多个会议邀请

举个栗子：

网盘批量操作：

同时删除10个文件 → 返回 207
响应体显示：

[
  { "file1.txt": 204 }, // 成功
  { "file2.jpg": 404 }, // 不存在
  { "file3.pdf": 403 }  // 无权限
]

智能家居控制：

同时开关5个设备 → 返回每个设备的执行状态

208 Already Reported【服务器的"去重标记"："这些内容上次给过了，这次跳过，只看新的！" 】

用途：在批量查询时，避免重复返回之前已经报告过的结果

通常配合 207 Multi-Status 使用
相当于数据去重标记
常用于 WebDAV

工作流程：

第一次请求：返回完整结果（含A/B/C项）
第二次请求：只返回新项D/E，对A/B/C项用208占位

核心价值：

节省网络传输量
避免客户端处理重复数据

举个栗子：

同步网盘文件列表：

首次获取：返回全部50个文件状态
增量同步：只返回新增/变化的5个文件，其余45个用208表示"这些没变过"

日历系统同步：

已经同步过的旧事件标记为208
只传输新增事件

226 IM Used【服务器的"智能省流模式"："你要的数据我用了优化版，不是原始完整版！"】

用途：服务器对实例操作（Instance Manipulation）的确认

表示返回的内容是经过特定处理的版本（如差分/压缩/缓存版本）
常见于 Delta Encoding（差分编码）场景
这个状态码就像HTTP协议里的"黑科技"，能极大提升传输效率，但需要客户端和服务器共同支持

核心特点：

响应头会包含 IM（Instance Manipulation）字段
客户端必须明确支持这种处理方式

优势：

大幅减少数据传输量
特别适合频繁更新的资源

举个栗子：

在线文档协作：

你编辑了文档的第5行
服务器返回 226 + 只含第5行变化的差分数据
而不是返回整个文档

APP增量更新：

更新时只下载变化的部分（226）
而不是整个安装包

Redirection 3xx

300 Multiple Choices 【服务器的"选项菜单"："亲，你要的东东有N个版本，选一个呗~" 】

用途：服务器提供多个可选资源版本，需要客户端/用户选择其中一个

常见于内容协商（Content Negotiation）场景
实际开发中这个状态码很少见，通常服务器会直接返回最优版本（用200）或重定向（用301/302）

典型情况：

同一个资源有不同语言版本（英文/中文/日文）
同一文件有不同格式（PDF/Word/TXT）
同一视频有不同分辨率（720p/1080p）

响应特点：

会返回 Location 或 Alternates 头列出选项
可能需要人工选择，或浏览器自动选最优版本

举个栗子：

国际网站访问：

访问 example.com → 返回 300
提供 example.com/en（英文）和 example.com/cn（中文）选项

文档下载：

请求报告文件 → 返回 300
可选 PDF/Excel/CSV 三种格式

301 Moved Permanently 【互联网的"搬家通知单"："老地址已废弃，请收藏新地址，以后都来这儿找我！" 】

用途：告诉浏览器或搜索引擎：这个网址已永久迁移到新地址

旧地址作废，所有流量应该转向新地址

核心特点：

自动跳转（浏览器会直接访问新地址）
搜索引擎会更新索引（把旧网址的权重转移到新网址）

响应必备：

Location 字段标明新地址（比如 Location: https://新地址.com）

和302（临时跳转）的区别：

301（永久）搜索引擎会更新记录
302（临时）搜索引擎保留旧地址

举个栗子：

网站更换域名：

访问 old.com → 返回 301 + Location: new.com
浏览器自动跳转到 new.com

HTTP升级HTTPS：

访问 http://example.com → 301 跳转到 https://example.com

302 Found 【服务器的"临时指路牌"："亲，今天走这边，明天记得走原路哦~"】

用途：服务器告诉浏览器："你要找的东西临时放在另一个地址，先去那里拿"

关键在"临时"二字，原网址后续还会继续使用
保留原地址，不传递SEO权重
现代开发更推荐用 303（See Other） 或 307（Temporary Redirect） 替代

核心特点：

浏览器会自动跳转到新地址（用户可能察觉不到）
搜索引擎不会更新收录链接（知道这是临时安排）

响应必备：

Location 字段标明临时地址（如 Location: /temp-page）

举个栗子：

网站维护：

访问首页 → 302 跳转到维护公告页

登录跳转：

访问 /admin → 临时跳转到 /login（登录后仍返回/admin）

A/B测试：

临时将部分用户跳转到新版本页面

303 See Other 【服务器的"安全跳转指令"："表单已提交，现在请用GET方法去新页面查看结果，这样刷新也不怕！】

用途：服务器明确要求客户端用GET方法去另一个地址查看结果

专门用于POST提交后的重定向
避免用户重复提交表单（刷新页面不会重复POST请求）
强制转为GET方法，专为POST提交设计

核心特点：

强制把后续请求转为GET方法（无论原请求是什么方法）
响应必须包含 Location 字段（指向新地址）

设计初衷：

解决浏览器刷新重复提交表单的问题
实现PRG模式（Post-Redirect-Get）

举个栗子：

表单提交成功：

提交订单 → 服务器处理 → 303 跳转到 /order-success
即使用户刷新页面，也只是刷新成功页，不会重复下单

支付完成跳转：

支付请求完成后 → 303 跳转到账单详情页

304 Not Modified 【服务器的"省流量神器"："你要的东西还是老样子，用你手机里存的版本就行啦！" 】

用途：服务器告诉浏览器："你要的资源没变化，直接用本地缓存吧！"

专为缓存优化设计的状态码
不返回实际数据，省流量

触发条件：

浏览器携带 If-Modified-Since（上次修改时间）或 If-None-Match（文件指纹）
服务器比对后发现资源未更新

核心优势：

减少不必要的数据传输
提升网页加载速度

注意：

虽然状态码是3xx开头，但不是重定向
响应体必须为空（因为没传数据）

举个栗子：

刷新新闻网站：

浏览器问："首页内容有变吗？这是昨天的版本指纹 xyz123"
服务器："没变（304），继续用你缓存的版本吧"

加载网页图片：

已缓存的LOGO图片第二次加载时直接返回 304

305 Use Proxy 【服务器的"硬性通道要求"："想访问我？必须从指定代理走，否则免谈！"】

用途：服务器明确要求客户端必须通过指定的代理服务器访问资源

像一道"强制关卡"，所有请求必须经过代理
响应中会包含代理服务器的地址（Location 字段）
主流浏览器已不再支持305状态码，因为强制代理可能被恶意利用

设计初衷：

企业内网安全管控
内容过滤或审计

核心特点：

代理地址通常以 http:// 或 https:// 开头
浏览器需要重新发送完整请求到代理

现状：

这个状态码已被废弃（因安全风险）
现代网络改用以下方案替代：
自动代理配置（PAC文件）
透明代理（用户无感知）
HTTP 407（代理要求认证）

举个栗子：

公司网络限制：

访问外网 → 返回 305 + 代理地址 proxy.company.com:8080
所有流量必须经过这个代理

学校上网认证：

连校园网后首次访问任何网站 → 跳转到认证代理

306 Switch Proxy （已废弃）

原始用途：

要求客户端切换到另一个代理服务器
类似305的升级版，用于代理服务器之间的切换

现状：

该状态码在HTTP/1.1规范中被正式删除
现代HTTP协议中完全不再使用

为什么被废弃：

存在安全隐患（可能被恶意代理利用）
被更安全的方案替代（如自动代理配置PAC）

307 Temporary Redirect 【服务器的"无损临时搬迁"："临时换地方办事，但你的所有材料都要原封不动带过去！" 】

用途：服务器告诉浏览器："资源临时搬到新地址，但必须用原来的方式访问"

关键特点：保持原始请求方法（POST仍用POST跳转，GET仍用GET）
和302的核心区别：不会把POST偷偷改成GET

典型场景：

网站临时维护（但表单提交不能丢失）
A/B测试需要保持请求方法
负载均衡临时转移请求

响应必备：

Location 字段标明临时地址

举个栗子：

支付系统维护：

提交支付请求 → 307 跳转到备用服务器
保证支付数据不会因为跳转而丢失

API临时迁移：

POST /v1/orders → 307 临时指向 /temp/v1/orders

308 Permanent Redirect 【服务器的"完美搬家通知"】

用途：服务器声明："资源已永久搬家，且要求所有访问必须保持原始请求方式"

是 301 + 307 的结合体：既永久，又保持请求方法
响应必须包含 Location 指向新地址

核心特点：

永久性：搜索引擎会更新索引（和301相同）
严格性：POST请求跳转后仍是POST（解决301的方法丢失问题）

适用场景：

API接口永久迁移
网站改版时重要表单提交路径变更
HTTP→HTTPS的强制升级

举个栗子：

银行系统升级：

旧转账接口 POST /transfer → 308 永久跳转到 POST /api/v2/transfer
保证所有转账请求完整传递到新接口

全站HTTPS化：

访问 http://example.com/login → 308 跳转到 https://example.com/login

Client Error 4xx

400 Bad Request 【服务器的"纠错提示"】

用途：服务器表示："我看不懂你的请求，就像读到了一封错别字连篇的信"

客户端（浏览器/APP）的请求存在语法错误或缺失关键信息
服务器无法理解，因此无法处理

常见触发原因：

请求头格式错误（比如漏了Content-Type）
JSON/XML数据格式错误（缺引号、少括号）
上传文件超过大小限制
必填参数未提交

举个栗子：

API调用错误：

请求体传了 {"name": "张三"（缺少闭合括号）→ 返回 400

网页表单提交：

注册时没填密码字段 → 返回 400 + "密码不能为空"

文件上传失败：

上传100MB文件但服务器限制50MB → 400 + "文件过大"

401 Unauthorized 【服务器的"身份检查站"】

用途：服务器表示："你需要先登录/提供有效凭证才能访问这个资源"

不是程序错误，而是权限控制的第一道关卡
通常会弹出登录框（浏览器）或要求API密钥
千万别在401响应中泄露敏感信息！比如别说"用户名存在但密码错误"

核心特点：

响应头会包含 WWW-Authenticate 字段，说明认证方式
（例如：Basic 基础认证 / Bearer Token认证）
与403的区别：
401："你还没证明你是谁"
403："我知道你是谁，但你不配访问"

常见认证方式：

用户名密码（Basic Auth）
JWT Token
OAuth 2.0

举个栗子：

网页未登录访问：

直接访问 /admin → 401 + 弹出浏览器登录框

API调用缺失Token：

请求 GET /api/user 未带Authorization头 → 401

Token过期：

使用过期的JWT访问API → 401 + "Token expired"

402 Payment Required 【互联网世界的"投币口"】

设计初衷：

为「在线支付」场景专门保留的状态码
理论上应该出现在需要付费才能访问的资源前

实际使用：

绝大多数网站和API并不使用它，而是用403或自定义逻辑
目前主要出现在两类场景：
某些付费API服务（如云计算平台）
实验性协议（如WebMoney支付系统）

响应特点：

通常会附带支付链接或二维码
可能包含 Payment Required 或 Upgrade Required 提示

举个栗子：

付费API调用：

请求「高级天气数据接口」→ 返回 402 + "请订阅高级套餐"

下载付费内容：

点击下载电子书 → 402 跳转到支付页面

403 Forbidden 【服务器的"权限防火墙"】

用途：服务器明确拒绝请求，即使客户端提供了身份认证

和401的区别：
401："你是谁？先证明身份"（未认证）
403："我知道你是谁，但你不配访问"（已认证但无权限）
和404的区别：
404："你要的东西不存在"
403："东西存在，但就不给你看"

常见触发原因：

用户权限等级不够（如普通用户访问管理员接口）
IP地址被拉黑
访问系统敏感目录（如 /etc/）
文件权限设置错误（chmod没配好）

特殊变体：

403.1：执行访问被禁止（如禁止运行脚本）
403.2：读取访问被禁止
403.14：目录列表被禁止（常见于关闭了目录浏览的网站）

举个栗子：

网站后台封锁：

普通用户访问 /admin → 403 + "您无权查看此页面"

API权限控制：

免费用户调用VIP接口 → 403 + "请升级会员"

云服务器配置：

直接访问 .env 配置文件 → 403（防止泄露数据库密码）

404 Not Found 【互联网的"寻人启事"】

用途：服务器明确告知："你要的东西在我这里不存在"

不是权限问题（不是403）
不是服务器错误（不是500）
纯粹是资源路径错误或内容已删除

常见触发原因：

网址拼写错误（如 prduct.html 少了个字母）
内容已被删除但链接还在
服务器没有配置默认首页（比如访问 /blog/ 但目录里没有 index.html）

特殊性质：

唯一拥有全球通用文化符号的状态码（"404页面"）
常被创意设计成趣味页面（如游戏公司做的小游戏404页）

举个栗子：

日常上网：

访问 example.com/old-page → 显示 404（页面已迁移）

API调用：

请求 GET /api/users/999 → 404（用户ID不存在）

资源失效：

点击过期的文件下载链接 → 404

405 Method Not Allowed 【服务器的"操作说明书"】

用途：服务器表示："我认识这个地址，但不接受你用的动作类型"

常见于：用GET请求提交数据，或用DELETE请求访问只读接口
必须返回 Allow 头，列出支持的请求方法（如 Allow: GET, POST）

常见冲突场景：

对只读接口发 POST/PUT/DELETE 请求
用 GET 请求提交表单数据（应该用POST）
访问需要特定方法的API（如必须用PATCH更新部分数据）

与其他错误的区别：

404：地址完全不存在
403：地址存在但没权限
405：地址存在，但动作不被支持

举个栗子：

错误调用API：

用 DELETE /api/articles 想删除所有文章 → 405 + Allow: GET, POST
（批量删除应该用 POST /api/articles/batch-delete）

网页表单提交：

用 GET /submit-form 提交密码 → 405（应该用POST）

只读资源：

尝试 PUT /about.html 修改公司介绍页 → 405（静态页面禁止修改）

406 Not Acceptable 【服务器的"定制需求拒绝函"】

用途：服务器表示："你要的数据格式/语言/版本我提供不了"

客户端通过 Accept 头提出了过于挑剔的要求
服务器无法满足，又不愿默认返回低质量内容

常见触发条件：

Accept：要求返回XML但服务器只支持JSON
Accept-Language：要求法语内容但只有英文版
Accept-Encoding：指定了不支持的压缩格式

必须返回的信息：

响应头会列出服务器实际支持的内容（如 Content-Type: application/json）
可能附带说明文档链接

举个栗子：

API格式冲突：

请求头：Accept: application/xml
但API只支持JSON → 406 + 返回支持的类型

多语言网站：

请求头：Accept-Language: fr-CA（加拿大法语）
网站只有英语 → 406

版本控制：

请求：Accept: application/vnd.api+json; version=2
服务器只支持v1 → 406

407 Proxy Authentication Required【代理服务器的"关卡检查"】

用途：代理服务器要求客户端先认证身份才能转发请求

和401类似，但认证对象是代理服务器（不是目标服务器）
常见于企业网络/学校网络

必备响应头：

Proxy-Authenticate：说明认证方式（如 Basic/Bearer）
Proxy-Authorization：客户端后续请求需携带此头

典型场景：

公司VPN需要二次认证
学校网络登录认证
爬虫遇到需要密码的代理

举个栗子：

企业网络上网：

访问百度 → 弹出公司代理认证窗口
输入域账号密码后才能上网

API调用经过网关：

GET /api/data HTTP/1.1
Host: example.com

408 Request Timeout 【服务器的"耐心耗尽警告"】

触发条件：

客户端（浏览器/APP）开始发送请求但未完整发送
服务器在等待超时后主动断开连接（如Nginx默认60秒）

常见原因：

网络延迟导致TCP包传输中断
客户端上传大文件时卡死
恶意软件发送不完整请求攻击服务器

与其他超时的区别：

504：服务器处理超时（后端程序太慢）
408：客户端发送请求太慢（请求头发送不全/请求体传一半断了）

举个栗子：

上传文件失败：

传500MB视频到网盘，传到90%时断网 → 服务器等太久返回 408

弱网环境访问：

手机信号差，请求头发送不完整 → 408

服务器防御机制：

黑客故意慢速发送请求 → 服务器用 408 打断攻击

409 Conflict 【服务器的"交通警察"】

用途：服务器检测到请求与当前资源状态冲突，拒绝执行

不是语法错误（不是400）
不是权限问题（不是403）
是业务逻辑层面的冲突

常见冲突类型：

文件版本冲突（如Git合并冲突）
数据库乐观锁冲突（版本号不匹配）
资源依赖关系冲突（如删除有子分类的父分类）

必须返回的信息：

响应体应解释冲突细节（如 {"error": "File version 123 is stale"}）
可能包含解决建议的URL

举个栗子：

购物车冲突：

你下单时商品库存突然变为0 → 409 + "库存不足"

协同编辑：

两人同时保存文档 → 409 + 显示差异对比

银行转账：

账户余额被其他操作变更 → 409 + "请刷新重试"

410 Gone 【服务器的"死亡证明书"】

用途：服务器明确声明某个资源曾经存在，但现已永久删除

和404的区别：
404："从未见过这个资源"（可能输错URL）
410："这资源以前有，现在故意删除了"
和301的区别：
301：资源永久搬家
410：资源永久消失
410是HTTP协议中少数自带"情感色彩"的状态码，传达一种决绝的态度

设计意图：

告诉客户端别再来找这个资源了（搜索引擎会移除索引）
避免客户端反复重试请求

典型场景：

下架的新闻/商品
注销的用户主页
被GDPR要求删除的数据

举个栗子：

社交媒体：

访问已注销用户的个人主页 → 410 + "该账号已注销"

电商平台：

请求已下架三年的商品页面 → 410（而404可能意味着商品ID错误）

API版本：

废弃的API接口返回 410 + 替代方案链接

411 Length Required 【服务器的"电子秤"】

用途：服务器要求客户端必须提供请求体的明确长度

通过 Content-Length 请求头声明（如 Content-Length: 1024）
常见于需要严格校验数据的场景

触发条件：

客户端发送POST/PUT请求但缺失 Content-Length 头
服务器明确配置需要长度验证（如文件上传接口）

安全意义：

防止"慢速攻击"（黑客故意不传完整数据拖垮服务器）
确保大数据传输的完整性

举个栗子：

文件上传API：

POST /upload HTTP/1.1
Host: example.com
（缺失 Content-Length 头）

严格的后端服务：

任何非GET请求都必须带长度声明 → 否则 411

412 Precondition Failed 【服务器的"条件检测器"】

用途：服务器检测到客户端设置的条件不满足，拒绝执行请求

不是语法错误（不是400）
不是权限问题（不是403）
是"if-else"条件判断失败

常见前置条件：

If-Match：要求资源版本号匹配（如ETag）
If-Unmodified-Since：要求资源在指定时间后未修改
If-None-Match：要求资源版本不同（用于缓存刷新）

设计初衷：

防止"丢失更新"问题（多人同时修改资源）
实现乐观锁机制

举个栗子：

在线文档协作：

你编辑文档前声明："只有版本号=123时才能保存"
但同事已先保存（版本变成124）→ 返回 412

支付系统：

转账请求要求："账户余额必须≥100元"
实际余额90元 → 412

413 Payload Too Large 【服务器的"体重秤"】

用途：服务器拒绝处理超过大小限制的请求数据

常见于文件上传、表单提交等场景
是服务器主动设置的安全防护

典型限制维度：

请求体总大小（如Nginx默认 client_max_body_size 1m）
单文件尺寸（如"头像不得超过2MB"）
数组元素数量（如"最多批量上传100个文件"）

与其他错误的区别：

400：数据格式错误
403：权限不足
413：数据体积超标

举个栗子：

网盘上传：

传500MB视频 → 服务器限制100MB → 413

表单提交：

提交含100张图片的表单 → 限制10张 → 413

API调用：

请求体JSON超过1MB → 413

414 URI Too Long 【服务器的"URL尺子"】

触发条件：

浏览器/APP发送的网址（URI）超过服务器限制
常见限制：
Nginx默认 large_client_header_buffers 4 8k（单个URI头最多8KB）
Apache默认约8000字符

典型问题场景：

过度冗长的GET参数（如?id=1&name=张三&age=20&...拼接100个字段）
前端错误生成的无限递归参数
恶意攻击者故意构造超长URL

安全意义：

防止缓冲区溢出攻击
避免服务器资源被超长URL耗尽

举个栗子：

错误的分页查询：

GET /api/data?page=1&size=10&sort=name&filter=type=news&search=2023年最新...（2000字符后截断）

返回 414

前端bug：

错误循环拼接参数生成如 ?param=1&param=1&param=1... 的无限长URL

爬虫攻击：

黑客发送10万字符的URL试探服务器漏洞

415 Unsupported Media Type 【服务器的"格式审查员"】

用途：服务器拒绝处理不支持的请求格式

客户端通过 Content-Type 头声明了服务器无法处理的格式
是严格的格式校验错误

常见冲突场景：

用 application/xml 调用只支持JSON的API
上传 .exe 文件到仅允许图片的接口
忘记设置 Content-Type 头（可能被默认当作错误类型）

必须返回的信息：

响应头应包含 Accept 字段，列出支持的格式（如 Accept: application/json）

举个栗子：

API调用错误：

返回 415 + Accept: application/json

图片上传限制：

上传 .mp4 到头像接口 → 415 + "仅支持JPEG/PNG"

416 Range Not Satisfiable 【服务器的"范围校正器"】

用途：服务器告知客户端请求的文件范围超出实际大小

发生在断点续传或分片下载时
客户端通过 Range 头指定了非法范围（如 bytes=500-1000，但文件只有300字节）

必备响应头：

Content-Range：显示文件实际大小（如 Content-Range: bytes */300）

常见触发原因：

文件被截断或缩小，但客户端不知道
客户端错误计算了范围
恶意攻击者故意发送非法范围请求

举个栗子：

视频加载失败：

请求："给我这个视频500MB-1GB的部分"
但视频总共只有400MB → 416

下载管理器错误：

网络中断后，错误计算了剩余下载范围

417 Expectation Failed 【服务器的"需求驳回函"】

用途：服务器无法满足客户端在 Expect 请求头中提出的特定要求

客户端预先声明："必须满足XX条件我才继续请求"
服务器检查后表示："做不到，请停止后续操作"

经典场景：

Expect: 100-continue（客户端问："能接收大文件吗？"）
→ 服务器返回 417 表示："别传了，我拒绝"
自定义扩展要求（如特殊加密算法支持）

与其他状态码的区别：

400：通用请求错误
412：前置条件不满足（针对资源状态）
417：明确拒绝客户端的Expect要求

举个栗子：

大文件上传被拒：

特殊需求不被支持：

418 I'm a teapot 【互联网的"幽默拒签条"】

起源：1998年愚人节的恶搞RFC文档（RFC 2324）

源自"超文本咖啡壶控制协议"（HTCPCP）的玩笑
官方用途：拒绝用茶壶煮咖啡的荒谬请求

实际意义：

专门用来优雅地拒绝明显不合理的请求
相当于程序的幽默版："你这请求太离谱了"

意外走红：

被Python、Node.js等框架实际实现
成为程序员群体中的文化符号

举个栗子：

API的彩蛋响应：

返回 418 + { "message": "我是茶壶，不能自毁" }

机器人防护：

对明显恶意的爬虫请求返回418（比403更幽默）

程序员节日彩蛋：

在愚人节把部分404页面替换成418

420 Enhance your calm【互联网的"电子佛珠"】

出身：

非官方状态码，源自Twitter早期API的限流响应
灵感来自电影《蠢蛋进化论》的经典台词

实际作用：

优雅版429（Too Many Requests）
用幽默方式提醒用户/开发者操作过于频繁

文化意义：

程序员对"暴力请求"的温柔反击
比冷冰冰的"请求被拒"更有人情味

举个栗子：

API限流：

HTTP/1.1 420 Enhance Your Calm
Retry-After: 30
{
  "message": "放松呼吸30秒再试",
  "tip": "试试冥想APP Headspace"
}

游戏防沉迷：

连续玩2小时后触发420 + 熊猫打坐动画

程序员彩蛋：

在代码注释里藏420梗（比如 // 这里本应该429，但我们更禅意）

421 Misdirected Request 【服务器的"导航纠错"】

用途：服务器告知客户端请求发错了地方

常见于HTTP/2和HTTP/3的多路复用场景
服务器无法用当前连接响应请求，必须重建连接

核心原因：

客户端在同一个TCP连接中发送了不属于该服务器的请求
服务器配置变更（如证书域名不匹配）
负载均衡器将请求导向了错误的服务器实例

必备响应头：

Connection: close（强制关闭当前错误连接）

举个栗子：

网站迁移后：

浏览器复用旧连接访问新域名 → 421 + "请用新连接访问"

微服务架构：

请求误发到未部署该API的容器 → 421

CDN边缘节点错误：

请求被路由到没有对应内容的CDN节点

422 Unprocessable Entity 【服务器的"逻辑审查员"】

用途：服务器表示："请求格式正确，但内容逻辑有问题"

介于400（语法错误）和409（业务冲突）之间
常见于WebDAV和REST API的校验错误

典型问题：

日期格式合法但超出范围（如"生日：3023年"）
数值越界（如"年龄：-10岁"）
依赖关系错误（如"所属部门ID不存在"）

必须返回的信息：

响应体应详细说明每个字段的错误（RFC 4918标准）

{
  "error": "验证失败",
  "details": {
    "birthday": "不能是未来日期",
    "department_id": "该部门不存在"
  }
}

举个栗子：

注册表单：

密码填"123" → 422 + "密码至少6位"

电商下单：

商品ID存在但库存不足 → 422（而404是ID不存在）

日历系统：

创建结束时间早于开始时间的会议 → 422

423 Locked 【服务器的"资源门禁"】

用途：服务器声明资源已被显式锁定，禁止并发修改

常见于WebDAV协议（网络文件管理）
防止多人同时修改导致数据冲突

锁定类型：

独占锁：只允许锁定者操作（如文档编辑）
共享锁：允许多个读取，禁止写入（如数据库读锁）

必备响应头：

Lock-Token：标识当前锁的ID
可能包含解锁时间（如 Timeout: Infinite）

举个栗子：

云文档协作：

用户A编辑PPT时 → 文件被锁定
用户B尝试保存 → 423 + "该文件正在被A编辑"

版本控制系统：

Git提交冲突时可能返回423

数据库运维：

执行备份时锁定表 → 其他写入请求返回423

424 Failed Dependency 【服务器的"多米诺骨牌警报"】

用途：服务器表示当前操作依赖的其他操作失败了

专为WebDAV协议设计（多步骤操作场景）
不是语法错误（不是400），而是流程中断

典型场景：

批量删除文件时，某个文件被锁定导致整体失败
事务处理中某一步骤失败（如付款成功但库存不足）
跨服务调用时依赖的API不可用

必须返回的信息：

响应体应说明具体失败的依赖项

<!-- WebDAV示例 -->
<error>
  <failed-dependency>/files/important.doc</failed-dependency>
  <reason>File is locked</reason>
</error>

举个栗子：

云盘批量操作：

删除10个文件 → 其中1个被锁定 → 424 + 列表显示失败项

电商下单流程：

扣款成功 → 库存系统故障 → 424 回滚整个订单

CI/CD流水线：

编译成功 → 测试阶段失败 → 中止部署并返回424

425 Too Early 【服务器的"安全守门员"】

用途：服务器拒绝处理可能引发重放攻击的过早请求

专为防御 "0-RTT"（零往返时间） 攻击设计
常见于HTTP/3和TLS 1.3的早期数据场景

核心机制：

客户端尝试用缓存密钥发送加密请求（节省时间）
服务器发现风险："上次会话的密钥可能已泄露" → 返回425
强制客户端走完整握手流程

安全意义：

防止黑客截获早期数据包伪造请求
保护敏感操作（如支付、登录）

举个栗子：

网购支付：

你快速点击支付按钮（尝试复用上次会话）
银行服务器返回 425："请重新输入短信验证码"

游戏登录：

客户端自动重连时发送早期数据 → 服务器要求完整握手

426 Upgrade Required【服务器的"技术淘汰通知"】

用途：服务器强制要求客户端升级协议版本

不是建议，而是必须升级才能继续访问
常见于淘汰旧协议的安全场景

核心机制：

通过 Upgrade 响应头指明所需协议（如 Upgrade: TLS/1.3）
客户端必须支持新协议才能重试请求

典型场景：

网站从HTTP强制升级到HTTPS
API废弃HTTP/1.1，要求使用HTTP/2
禁用老旧加密算法（如RC4）

举个栗子：

浏览器访问：

GET / HTTP/1.1
Host: example.com

APP接口调用：

使用已淘汰的API版本 → 426 + "请升级到v2.0"

428 Precondition Required 【服务器的"安全关卡"】

用途：服务器要求客户端必须携带校验条件才能处理请求

不是权限问题（不是401/403）
是强制性的流程控制机制

常见前置条件：

If-Match：要求资源版本匹配（防覆盖）
If-None-Match：要求资源已变更（防重复）
自定义条件（如必须携带交易令牌）

安全价值：

防止丢失更新（Lost Update）问题
确保幂等性操作安全

举个栗子：

在线文档保存：

直接提交修改 → 428 + "请携带文档当前ETag"

支付系统：

请求扣款 → 428 + "需提供短信验证码"

API设计：

要求所有写请求必须带 X-Idempotency-Key 头

429 Too Many Requests 【服务器的"流量警察"】

用途：服务器温柔地警告客户端请求频率超标了

不是错误，而是限流保护
防止恶意刷接口或意外流量风暴

核心机制：

通过 Retry-After 头告知冷却时间（如 Retry-After: 30）
可能配合令牌桶/漏桶等算法

常见触发场景：

爬虫抓取太快
用户反复刷新页面
API被暴力破解尝试

举个栗子：

登录失败限流：

连续输错5次密码 → 429 + "请1分钟后再试"

抢购活动：

每秒发起10次下单请求 → 429 + "当前排队人数过多"

免费API限制：

超过每分钟100次调用 → 429

430 Would Block 【网络的"智能交通系统"】

非官方实验性状态码

由HTTP扩展提案提出，尚未成为正式标准
目前主要用于QUIC协议（HTTP/3的底层协议）

核心作用：

预先警告客户端继续当前操作会导致阻塞
比429（限流）更前瞻性的流量控制

举个栗子：

视频流预判缓冲：

客户端带宽下降时，服务器预警："继续高清传输会卡顿" → 自动降为标清

游戏同步：

服务器预测玩家操作过快 → 返回430让客户端节流

物联网控制：

设备指令队列积压时，提前拒绝新请求

431 Request Header Fields Too Large 【服务器的"头信息体重秤】

触发条件：

请求头（Headers）总大小超过服务器限制
常见限制：
Nginx默认 large_client_header_buffers 4 8k（单个头最大8KB）
Apache默认约8000字节

典型问题：

Cookie太大（如存了MB级数据）
自定义头过多（如X-User-Info携带完整用户数据）
恶意攻击者故意构造超大请求头

安全意义：

防止缓冲区溢出攻击
避免服务器内存被垃圾头信息耗尽

举个栗子：

Cookie爆炸：

返回 431

过度追踪：

前端添加几十个X-Tracking-*头 → 触发限制

代理服务器错误：

多层代理不断添加Via头 → 最终超限

451 Unavailable For Legal Reasons 【互联网的"封条"】

用途：服务器依法拒绝提供某些内容

不是技术限制（不是404/403）
是明确的法定内容封锁

必须包含的信息：

响应头/页面上应注明法律依据（如 X-Censorship-Reason: DMCA）
可能附带申诉渠道（如版权投诉邮箱）

名字彩蛋：

致敬反乌托邦小说《华氏451》（书中焚烧禁书）
2015年正式成为RFC标准

举个栗子：

版权投诉：

访问盗版电影链接 → 451 + "应版权方要求移除"

地区封锁：

在欧盟访问某网站 → 451 + "因GDPR限制不可用"

政府审查：

某些国家访问维基百科 → 451 + "根据XX法规屏蔽"

Server Error 5xx

500 Internal Server Error 【服务器的"故障烟雾弹"】

用途：服务器承认"我炸了，但不知道具体哪炸了"

不是客户端的问题（不是4xx）
是服务器未处理的意外错误

经典翻车现场：

代码有bug（比如除以零）
数据库连接突然断开
配置文件写错了
内存泄漏把服务器撑爆

尴尬特点：

最让开发者头疼的状态码（因为缺乏具体信息）
用户看到的是"500"，但日志里可能藏着100种不同错误

举个栗子：

网站崩溃：

访问首页 → 突然白屏显示"500 Internal Server Error"

API抽风：

调用 /api/users → 返回 500（后端代码抛异常没捕获）

运维事故：

服务器磁盘满了 → 所有请求开始500

501 Not Implemented 【服务器的"诚实三连"】

用途：服务器坦白承认"这个功能我压根没做"

不是临时故障（不是503）
不是权限问题（不是403）
是永久性功能缺失

典型场景：

调用了未开发的API端点
使用了服务器不支持的HTTP方法（如对普通接口发PATCH请求）
请求了配置文件中禁用的功能模块

与500的区别：

500："我尝试做了但失败了"
501："这需求我根本不会做

举个栗子：

API版本过新：

请求 GET /api/v3/users → 501（服务器只实现到v2）

特殊操作：

发送 PURGE /cache 请求 → 501（未启用缓存清理功能）

超前功能：

调用"AI生成菜谱"接口 → 501（该功能尚在PPT阶段）

502 Bad Gateway 【互联网的"传话事故"】

角色定位：

由网关/代理服务器（如Nginx、Cloudflare）返回
表示："我（网关）是好的，但我后面的小弟（应用服务器）挂了"

经典故障链：

用户 → CDN → 负载均衡 → 应用服务器（崩在这里）
负载均衡器发现应用服务器无响应 → 向用户返回502

常见凶手：

应用进程崩溃（如PHP-FPM、Node.js服务停止）
数据库连不上导致服务不可用
防火墙错误拦截了内部通信

举个栗子：

网站访问：

浏览器 → Cloudflare（502）← 你的服务器（崩溃中）

微服务调用：

API网关 → 用户服务（超时无响应）→ 返回502

运维事故：

误删了Docker容器 → Nginx返回502

故障排查指南：

检查应用服务器进程是否存活（ps aux | grep node）
查看应用日志（如 tail -f /var/log/nginx/error.log）
测试内部网络（curl -v http://localhost:3000）
检查数据库连接（mysql -u root -p）
监控系统资源（htop看CPU/内存）

503 Service Unavailable 【服务器的"休假公告"】

核心特征：服务器主动声明"我现在不能服务，但还会回来"

不是崩溃（不是500）
不是网关问题（不是502）
是计划内的不可用状态

常见触发场景：

系统维护升级
流量暴增触发限流
依赖的第三方服务故障

友好设计：

通常伴随 Retry-After 头（如 Retry-After: 3600）
可能展示精心设计的维护页面

举个栗子：

网站维护：

访问淘宝 → 显示"系统升级中，预计23:00恢复"

API限流：

免费用户频繁调用 → 503 + "请1小时后重试"

云服务故障：

AWS某个区域宕机 → 所有托管服务返回503

504 Gateway Timeout 【互联网的"耐心终结者"】

角色定位：

由网关/代理服务器（如Nginx、API网关）返回
表示："我（网关）还在，但后面服务太久没理我"

典型超时场景：

应用服务器卡死（死循环/死锁）
数据库查询太久（没加索引的百万级表扫描）
微服务之间调用链超时（A等B，B等C...）

关键数字：

Nginx默认代理超时：60秒
AWS ALB默认：120秒

举个栗子：

网站访问：

浏览器 → CDN（504）← 你的服务器（SQL查询跑了3分钟）

支付接口：

调用银行网关超时 → 返回504

运维事故：

服务器CPU爆满 → 所有请求超时

505 HTTP Version Not Supported 【服务器的"协议门神"】

核心问题：服务器明确拒绝客户端使用的HTTP协议版本

不是兼容性降级（不会自动切到低版本）
是硬性阻断（"要么升级要么滚"）

常见冲突组合：

客户端用HTTP/2 → 古董服务器只支持HTTP/1.0
激进客户端用HTTP/3 → 中间代理不支持QUIC

安全考量：

防止老旧协议的安全漏洞被利用
强制淘汰不安全的加密方式

举个栗子：

企业内网设备：

新浏览器用HTTP/2访问老OA系统 → 505

API网关配置：

强制要求HTTP/2 → 旧版APP发HTTP/1.1请求被拒

黑客试探：

故意发送HTTP/9.9请求 → 服务器返回505

506 Variant Also Negotiates 【服务器的"选择困难症发作"】

用途：服务器发现内容协商陷入死循环

当资源的不同版本（变体）自己还需要进一步协商时触发
属于WebDAV协议的特殊错误

典型故障链：

客户端请求资源 → 服务器提供多个变体（如英文/中文版）
但某个变体（如中文版）自己又有子版本（简/繁体）
服务器懵逼："我该给你简体还是繁体？" → 返回506

本质问题：

多层嵌套的内容协商（像俄罗斯套娃）
服务器配置错误导致无限递归

举个栗子：

国际化网站故障：

请求 /doc → 可选英文/中文 → 选择中文 → 中文版又需要选简/繁体 → 506

版本控制API：

/api/v2 需要进一步选择 v2.1 或 v2.2 → 协商失败

507 Insufficient Storage 【服务器的"硬盘求救信号"】

用途：服务器明确表示"我的硬盘/内存不够存你的东西了"

专为WebDAV协议设计（网络文件管理）
不是临时故障（不是503），是物理容量极限

常见场景：

云盘上传文件时空间爆满
数据库磁盘写满导致写入失败
服务器日志占满存储空间

必备响应头：

X-Disk-Space-Available: 1024（剩余字节数）
可能包含清理建议（如删除路径 /old_backups/）

举个栗子：

网盘上传失败：

传50GB视频 → 507 + "剩余空间仅30GB"

邮件系统崩溃：

收件箱超过配额 → 新邮件被拒

运维事故：

监控日志未轮转 → 塞满硬盘 → 所有写操作507

508 Loop Detected 【服务器的"循环终结者"】

用途：服务器检测到请求处理陷入死循环

专为WebDAV协议设计（网络文件管理）
不是代码bug（不是500），是逻辑依赖成环

典型循环场景：

文件A的元数据指向文件B → 文件B又指回文件A
符号链接（快捷方式）循环引用
无限递归的API调用链

安全机制：

防止恶意构造的循环请求耗尽服务器资源
比超时错误（504）更主动的防御

举个栗子：

网站目录结构错误：

/photos/2023 链接到 /archive → /archive 又链接回 /photos → 508

微服务调用死循环：

服务A → 调用服务B → 服务B又回调服务A

运维配置事故：

DNS记录把 a.example.com CNAME到 b.example.com → 结果 b 又指向 a

510 Not Extended 【服务器的"功能解锁提示"】

用途：服务器要求客户端必须支持扩展功能才能继续

源自1999年RFC 2774的实验性协议
表示："基础功能不够用，得开高级权限"

核心条件：

请求需包含 MUST 扩展声明
服务器在响应中通过 Extension 头说明要求

现代应用：

企业级API的许可证控制
硬件设备的功能解锁

举个栗子：

企业软件API：

GET /api/advanced-analytics
→ 返回510 + "需购买高级许可证"

智能家居控制：

普通APP调烤箱高级模式 → 510
需安装厂商插件才能继续

511 Network Authentication Required 【网络的"门禁系统"】

用途：强制用户在使用网络前先认证

不是网站权限问题（不是401）
是网络接入层的拦截

必备要素：

必须重定向到认证页（如 Location: http://auth.wifi.com）
响应头包含 Network: WiFi 等网络类型标识

常见触发点：

酒店/机场的付费Wi-Fi
企业内网准入控制
学校宿舍的按时断网

举个栗子：

星巴克Wi-Fi：

连接后所有网页跳转登录页 → 底层返回 511

公司VPN：

未安装安全证书的设备访问内网 → 强制跳转安装页

家长控制：

儿童设备上网前需家长授权