由 Deme 在网络世界里冲浪，你可能经常遇到页面打不开或者加载出错的情况。这背后，HTTP状态码起着关键作用，它就像网络世界的“诊断书”，告诉我们请求的处理结果。今天，咱们就来深入聊聊常用的HTTP状态码。
一、HTTP状态码分类速览
HTTP状态码总共分为五大类，每一类都有特定的含义。
| 分类 | 含义 | 范围 |
|---|---|---|
| 1xx消息 | 请求已被接受，需继续处理 | 100 – 199 |
| 2xx成功 | 请求已成功被服务器接收、理解并接受 | 200 – 299 |
| 3xx重定向 | 需要客户端采取进一步操作完成请求 | 300 – 399 |
| 4xx客户端错误 | 客户端可能发生错误，妨碍服务器处理 | 400 – 499 |
| 5xx服务器错误 | 服务器无法完成明显有效的请求 | 500 – 599 |
二、1xx消息类状态码
这类状态码代表请求已被接受，还得接着处理，不过是临时响应，只含状态行和部分可选响应头，最后以空行结束。因为HTTP/1.0协议没定义1xx状态码，所以老版本客户端可能收不到这类响应。
| 状态码 | 含义 | 示例场景 |
|---|---|---|
| 100 Continue | 服务器收到请求头，客户端若要发请求主体（像POST请求）就继续发，或者请求已完成就忽略此响应。服务器处理完请求后得给客户端发最终响应。客户端要先发Expect: 100 – continue头，收到100 Continue状态码后再发正文。417期望失败状态码表示请求不该继续 | 比如在一个大文件上传的POST请求中，客户端先发送请求头，服务器确认收到请求头没问题，返回100 Continue，客户端再继续上传文件主体 |
| 101 Switching Protocols | 服务器懂了客户端请求，通过Upgrade消息头通知客户端换协议来完成请求。发完响应最后的空行后，服务器就切换到Upgrade头里定义的协议。只有新协议更有优势时才这么干，像从旧HTTP版本切换到HTTP/2，或者切换到WebSocket协议来传输实时同步资源 | 当客户端和服务器协商将HTTP协议升级到WebSocket协议进行实时通信时，服务器可能返回101状态码 |
| 102 Processing (WebDAV; RFC 2518) | WebDAV请求可能包含好多文件操作子请求，处理起来耗时久。这个代码表示服务器收到并正在处理请求，但没响应可给，防止客户端因等待超时以为请求丢失 | 在进行复杂的WebDAV文件操作，如批量移动、复制大量文件时，服务器可能返回102状态码告知客户端请求正在处理 |
三、2xx成功类状态码
这一类说明请求成功被服务器接收、理解并接受啦。
| 状态码 | 含义 | 示例场景 |
|---|---|---|
| 200 OK | 请求成功，响应头或数据体会随响应返回。具体响应依请求方法而定，GET请求返回对应资源实体，POST请求返回操作结果实体 | 我们日常正常访问网页，服务器返回200 OK，网页内容正常显示 |
| 201 Created | 请求实现了，还按需求创建了新资源，新资源URI随Location头信息返回。要是资源不能马上创建，就该返回202 Accepted | 当我们在网站上创建一个新的博客文章，服务器创建成功后返回201 Created，同时在Location头中给出新文章的链接 |
| 202 Accepted | 服务器接受请求了，但还没处理。最终处理不处理不一定，处理时也可能被禁止 | 在提交一个复杂任务请求，如大数据分析任务，服务器先返回202 Accepted表示收到请求，后续再慢慢处理 |
| 203 Non – Authoritative Information (自HTTP / 1.1起) | 服务器是转换代理服务器（像网络加速器），起源响应是200 OK，但返回的是修改后的版本 | 比如网络加速器对原始资源进行了优化处理，返回给客户端时状态码为203 |
| 204 No Content | 服务器成功处理请求，没返回内容 | 比如执行一个删除操作，操作成功但无需返回额外信息，服务器返回204 |
| 205 Reset Content | 和204类似，服务器成功处理请求无内容返回，但这个响应要求请求者重置文档视图 | 在一些表单提交后，服务器返回205，提示客户端重置表单页面显示 |
| 206 Partial Content (RFC 7233) | 服务器成功处理部分GET请求。像FlashGet、迅雷这类下载工具，用这个响应实现断点续传或分段下载大文档 | 下载一个大文件时，如果之前下载中断，再次下载时服务器返回206，从上次中断处继续下载 |
| 207 Multi – Status (WebDAV; RFC 4918) | 后面消息体是XML消息，可能按之前子请求数量，包含一系列独立响应代码 | 在进行WebDAV多操作请求时，如同时对多个文件进行不同操作，服务器用207返回每个操作的结果 |
| 208 Already Reported (WebDAV; RFC 5842) | DAV绑定的成员在之前（多状态）响应部分已列举，不再重复包含 | 在一个WebDAV资源列表请求中，部分资源之前已报告过，再次请求时相关资源用208状态码表示已报告 |
| 226 IM Used (RFC 3229) | 服务器满足对资源的请求，代表对实体请求的一个或多个实体操作结果 | 在对资源进行特定处理后，用226表示操作结果 |
四、3xx重定向类状态码
这类意味着客户端得再做点操作才能完成请求，常用来重定向，后续请求地址在响应的Location域指明。
| 状态码 | 含义 | 示例场景 |
|---|---|---|
| 300 Multiple Choices | 请求资源有多个回馈选项，每个有自己地址和商议信息，用户或浏览器可自行选一个重定向地址。除非是HEAD请求，响应应包含资源特性及地址列表实体。若服务器有首选回馈，Location中指明，响应可缓存 | 一个网站有多个语言版本，访问时服务器返回300，客户端可根据自身设置选择语言版本对应的链接 |
| 301 Moved Permanently | 请求资源永久移到新位置，以后引用该资源都得用响应返回的URI。客户端若能编辑链接，应自动修改请求地址。响应可缓存，新URI在Location域返回，响应实体含指向新URI超链接及简短说明。不是GET或HEAD请求时，浏览器不会自动重定向，得用户确认，因为请求条件可能变。注意：HTTP/1.0协议的浏览器，POST请求收到301响应，重定向请求会变成GET方式 | 一个网站域名更换，旧域名的所有页面永久重定向到新域名，服务器返回301 |
| 302 Found | 要求客户端临时重定向（原描述短语为”Moved Temporarily”）。客户端后续请求仍发往原有地址，仅在Cache – Control或Expires指定时可缓存。新临时URI在Location域返回，响应实体含指向新URI超链接及简短说明。不是GET或HEAD请求，浏览器不会自动重定向，需用户确认。注意：很多浏览器把302响应当303响应，用GET方式访问Location中的URI，无视原请求方法 | 一个活动页面临时调整到另一个地址，活动结束后还会回到原地址，服务器返回302 |
| 303 See Other | 当前请求响应在另一个URI可找到，POST（或PUT / DELETE）请求收到响应时，客户端应假定服务器已收到数据，用单独GET消息重定向。新URI不是原始资源替代引用，303响应禁止缓存，第二个请求（重定向）可能被缓存。新URI在Location域返回，响应实体含指向新URI超链接及简短说明。注意：很多HTTP/1.1版以前浏览器不理解303状态，这种情况302状态码可替代 | 在一个电商网站，用户提交订单后，服务器返回303，引导用户到订单详情页面 |
| 304 Not Modified | 资源未修改，因为请求头指定的版本If – Modified – Since或If – None – Match。客户端有之前下载副本，无需重新传输资源 | 用户刷新一个没更新的网页，服务器返回304，浏览器直接显示本地缓存页面 |
| 305 Use Proxy | 请求资源得通过指定代理访问，Location域给出代理URI信息，接收者得再发个单独请求通过代理访问资源。只有原始服务器能创建305响应，很多HTTP客户端（如Mozilla和Internet Explorer）处理这个状态码响应有问题，主要出于安全考虑 | 公司内部网络设置了代理服务器，员工访问外部资源时，服务器返回305，告知员工通过指定代理访问 |
| 306 Switch Proxy | 在最新版规范中不再使用，最初指“后续请求应使用指定的代理” | 无 |
| 307 Temporary Redirect | 请求应与另一个URI重复，但后续请求仍用原始URI。和302相反，重新发原始请求时，不允许更改请求方法，比如POST请求就该用另一个POST请求重复 | 在一些特定业务场景，如特定数据提交流程临时调整，服务器返回307，引导客户端按要求重定向请求 |
| 308 Permanent Redirect (RFC 7538) | 请求和以后所有请求都该用另一个URI重复。307和308类似302和301行为，但不允许HTTP方法更改，比如表单提交到永久重定向资源可能顺利进行 | 网站的某个重要页面永久迁移到新地址，服务器返回308 |
五、4xx客户端错误类状态码
这类说明客户端可能出问题，妨碍服务器处理请求。除非是HEAD请求，服务器得返回解释错误状况的实体，说明是临时还是永久问题。这些状态码适用于任何请求方法，浏览器应向用户显示错误响应中的实体内容。
| 状态码 | 含义 | 示例场景 |
|---|---|---|
| 400 Bad Request | 因客户端明显错误（如请求语法格式错、大小太大、请求消息无效或欺骗性路由请求），服务器不能或不愿处理请求 | 用户在表单中输入不符合格式要求的数据，提交时服务器返回400 |
| 401 Unauthorized（RFC 7235） | 类似403 Forbidden，语义是“未认证”，即用户没凭据。表示当前请求需用户验证，响应必须含WWW – Authenticate信息头询问用户信息。客户端可重发含恰当Authorization头信息的请求。若当前请求已含Authorization证书，401响应表示服务器拒绝了这些证书。若401响应和前一个相同身份验证询问，且浏览器至少尝试一次验证，应向用户展示响应实体信息，可能含诊断信息。注意：有些网站禁止IP地址时，状态码显示401，表示该IP被拒绝访问 | 用户访问需要登录的页面，但没登录，服务器返回401 |
| 402 Payment Required | 为将来可能需求预留，最初可能用于数字现金或在线支付方案，但很少服务商使用，通常不被用。Google Developers API特定开发人员超每日请求限制时会用 | 无常见实际场景 |
| 403 Forbidden | 服务器理解请求，但拒绝执行。和401不同，身份验证没用，请求也不该重复提交。不是HEAD请求时，服务器若想说明拒绝原因，应在实体内描述，也可返回404 | 用户尝试访问受限制的文件或目录，没有权限，服务器返回403 |
| 404 Not Found | 请求失败，希望得到的资源在服务器没找到，但允许用户后续请求。无法告知用户是暂时还是永久情况。若服务器知道是永久不可用，因内部配置问题，应使用410状态码。404广泛用于服务器不想揭示拒绝原因或没其他合适响应的情况 | 用户访问一个不存在的网页，服务器返回404 |
| 405 Method Not Allowed | 请求行指定的请求方法不能用于请求相应资源。响应必须返回Allow头信息，列出当前资源能接受的请求方法列表。比如表单GET请求需POST呈现数据，或只读资源上的PUT请求。因为PUT、DELETE方法会对服务器资源写操作，多数网页服务器默认不支持或不允许，此类请求返回405 | 在一个只允许GET请求获取数据的接口，用户使用POST请求，服务器返回405 |
| 406 Not Acceptable | 请求资源的内容特性不满足请求头条件，无法生成响应实体，请求不可接受。除非是HEAD请求，响应应返回包含让用户或浏览器选择最合适实体特性及地址列表的实体。实体格式由Content – Type头定义媒体类型决定，浏览器可自行选择，但规范没定义自动选择标准 | 用户请求一个特定格式的文件，如JSON格式，但服务器只有XML格式，服务器返回406 |
| 407 Proxy Authentication Required（RFC 2617） | 和401响应类似，不过客户端得在代理服务器上身份验证。代理服务器必须返回Proxy – Authenticate进行身份询问，客户端用Proxy – Authorization信息头验证 | 在企业网络环境中，通过代理服务器访问外部资源，若代理服务器需要认证，用户未认证时服务器返回407 |
| 408 Request Timeout | 请求超时。按HTTP规范，客户端在服务器预备等待时间内没完成请求发送，客户端可随时重发请求，无需更改 | 用户在页面加载时，网络延迟太久，服务器返回408 |
| 409 Conflict | 因请求冲突无法处理，如多个同步更新间的编辑冲突 | 多人同时编辑一个文档，提交时发生冲突，服务器返回409 |
| 410 Gone | 表示请求资源不再可用，且永久不可用。资源被有意删除且应清除时用这个。收到410状态码后，用户应停止请求资源。但多数服务端直接用404状态码 | 一个网站删除了某个旧页面，且不希望用户再访问，服务器返回410 |
| 411 Length Required | 服务器拒绝没定义Content – Length头的请求。客户端添加有效Content – Length头，标明请求消息体长度后可重发请求 | 在上传文件时，若请求未包含文件大小信息（Content – Length头），服务器返回411 |
| 412 Precondition Failed（RFC 7232） | 服务器验证请求头字段先决条件时，不满足一个或多个。允许客户端在获取资源时，在请求元信息（请求头字段数据）设先决条件，避免请求方法应用到不希望的资源上 | 客户端希望获取某个文件，前提是文件在某时间后被修改过，若不满足条件，服务器返回412 |
| 413 Request Entity Too Large（RFC 7231） | 前称”Request Entity Too Large”，服务器拒绝处理当前请求，因为请求提交的实体数据大小超服务器处理范围。服务器可关闭连接。若是临时情况，服务器应返回Retry – After响应头，告知客户端多久后可重试 | 用户上传一个超大文件，超过服务器设定的上传大小限制，服务器返回413 |
| 414 Request – URI Too Long（RFC 7231） | 前称”Request – URI Too Long”，请求的URI长度超服务器能解释的长度，服务器拒绝对该请求服务。通常是GET请求查询字符串数据太多，应转成POST请求。少见情况包括：本该POST的表单提交成GET，导致查询字符串过长；重定向URI“黑洞”，重定向时旧URI作为新URI一部分，多次重定向后URI超长；客户端利用服务器安全漏洞攻击，服务器用固定长度缓冲读取或操作请求URI，GET参数超数值可能缓冲区溢出，无漏洞服务器应返回414 | 用户构造一个超长的URL访问网站，服务器返回414 |
| 415 Unsupported Media Type | 请求提交的互联网媒体类型，对于当前请求方法和所请求资源，不是服务器支持的格式，请求被拒绝 | 用户上传图片时，格式为不支持的svg，服务器要求jpg格式，服务器返回415 |
| 416 Requested Range Not Satisfiable（RFC 7233） | 前称”Requested Range Not Satisfiable”。客户端要求文件一部分（Byte serving），但服务器不能提供该部分，比如客户端要求文件超出尾端的部分 | 在进行文件分段下载时，客户端请求的文件段不存在，服务器返回416 |
| 417 Expectation Failed | 请求头Expect中指定的预期内容无法被服务器满足，或服务器是代理服务器，有证据证明下一个节点无法满足Expect内容 | 客户端发送请求时，设置了特定的期望条件，如期望服务器返回特定格式数据，服务器无法满足，返回417 |
| 418 I’m a teapot（RFC 2324） | 1998年作为IETF传统愚人节笑话，在RFC 2324超文本咖啡壶控制协议中定义，真实HTTP服务器无需定义。控制茶壶的HTCPCP收到BREW或POST指令煮咖啡时应回传此错误。在某些网站（如Google.com）与项目（如Node.js、ASP.NET和Go语言）中用作彩蛋 | 无实际业务场景 |
| 420 Enhance Your Caim | Twitter Search与Trends API在客户端被限速时返回 | 在Twitter上频繁搜索，达到限制次数，服务器返回420 |
| 421 Misdirected Request （RFC 7540） | 请求针对无法产生响应的服务器（如因连接重用） | 无常见实际场景 |
| 422 Unprocessable Entity（WebDAV；RFC 4918 ） | 请求格式正确，但含语义错误，无法响应 | 在WebDAV操作中，请求参数格式对，但参数值不符合业务逻辑，服务器返回422 |
| 423 Locked（WebDAV；RFC 4918） | 当前资源被锁定 | 在多人协作编辑WebDAV资源时，资源被锁定，其他用户操作时服务器返回423 |
| 424 Failed Dependency（WebDAV；RFC 4 |