HTTP常见状态码详细解析

HTTP状态码（英语：HTTP Status Code）是用以表示网页服务器 超文本传输协议响应状态的3位数字代码。

它由 RFC 2616 规范定义的，并得到 RFC 2518、RFC 2817、RFC 2295、RFC 2774 与 RFC 4918 等规范扩展。

HTTP状态码负责表示客户端HTTP请求的返回结果、标记服务端的处理是否正常、通知出现的错误等工作。

状态码的类别

http状态码的由三位数字和原因短语组成，数字的第一位数字表示响应的类别，后面两位无类别。以下有五种类别。另外只要遵循状态码类别的定义，即使改变RFC2616中定义的状态码，或者服务端自行创建状态码都可以。

1XX

• 类别：informational 信息性状态码
• 原因短语：接收的请求正在处理

2XX

• 类别：success 成功状态码
• 原因短语：请求正常处理完毕

3XX

• 类别：redirection 重定向状态码
• 原因短语：需要进行附加操作以完成请求

4XX

• 类别：client error 客户端错误状态码
• 原因短语：服务器无法处理请求

5XX

• 类别：server error 服务器错误状态码
• 原因短语：服务器处理请求出错

在RFC2616上的http状态码达到40多种，在加上WEBDAV和附加HTTP状态码（RFC6585）等扩展，就有60多种，但常用的有以下这些，接下来让我们分别来学习下。

（注：以下的使用场景只是举例，不包括所有使用场景）

1xx Informational 信息响应

1XX 是信息响应，表示接收的请求正在被处理。

100 Continue （继续）

• 响应结果：信息型状态响应码表示目前为止一切正常, 客户端应该继续请求, 如果已完成请求则忽略.
• 使用场景：为了让服务器检查请求的首部, 客户端必须在发送请求实体前, 在初始化请求中发送 Expect: 100-continue 首部并接收 100 Continue 响应状态码.

101 Switching Protocols （协议切换）

• 响应结果：表示服务器应客户端升级协议的请求（Upgrade请求头）正在进行协议切换。服务器会发送一个Upgrade响应头来表示其正在切换过去的协议。
• 使用场景： 
  在使用 WebSockets 时会用到协议切换。

  HTTP/1.1 101 Switching Protocols
  Upgrade: websocket 
  Connection: Upgrade
  

2xx Successful 成功响应

2XX 表示请求被正常处理了。

200 OK （成功）

• 响应结果：请求成功，表示客户端发来的请求在服务端被正常处理了。
• 不同的请求方法对请求成功的意义不同：
• • GET方法请求时，对应的请求资源实体会作为响应返回；
• • HEAD方法请求时，对应请求资源的实体首部不随报文主体作为响应返回，即响应中只返回首部，不返回实体的主体部分；
• • POST方法请求时，响应的消息体重包含请求的结果

201 Created （已创建）

• 响应结果：该请求已成功，并因此创建了一个新的资源。
• 使用场景：作为PUT请求的返回值。

202 Accepted（已接受）

• 响应结果：服务端收到请求，但未处理。
• 使用场景：这个状态码被设计用来将请求交由另外一个进程或者服务器来进行处理，或者是对请求进行批处理的情形。

203 Non-Authoritative Information（非权威信息）

• 响应结果：服务器已成功处理了请求，但返回的实体头部元信息不是在原始服务器上有效的确定集合，而是来自本地或者第三方的拷贝。当前的信息可能是原始版本的子集或者超集。
• 使用场景：通过代理访问原始服务器的时候，成功获取了原始服务器（状态码200）的返回内容，但是代理对内容作出了一些改动，代理会通过这个状态码告知用户，成功获取内容，但是这部分内容和原始服务器的返回内容可能不完全一致。

204 No Content (没有内容)

• 响应结果：服务器成功处理了客户端请求，但服务器无返回内容。204是HTTP中数据量最少的响应状态，204的响应中没有body，而且Content-Length=0。
• 使用场景：204状态在一些网站分析的代码中最常用到，只需要把客户端的一些信息提交给服务器而无需关心响应。

205 Reset Content (重置内容)

• 响应结果：服务器成功处理了请求，且没有返回任何内容。但是与204响应不同，返回此状态码的响应要求请求者重置文档视图。
• 使用场景：用来通知客户端重置文档视图，比如清空表单内容、重置 canvas 状态或者刷新用户界面。

206 Partial Content （部分内容）

• 响应结果：表示客户端进行了范围请求，而服务器成功执行了这部分GET请求。响应报文中包含由Content-Range指定范围的实体内容。
• 使用场景：类似于 FlashGet 或者迅雷这类的 HTTP 下载工具都是使用此类响应实现断点续传或者将一个大文档分解为多个下载段同时下载。该请求必须包含 Range 头信息来指示客户端希望得到的内容范围，并且可能包含 If-Range 来作为请求条件

3xx Redirection 重定向

3XX响应结果表明浏览器需要执行某些特殊的处理以正确的处理请求。

300 Multiple Choices （多项选择）

• 响应结果：是一个用来表示重定向的响应状态码，表示该请求拥有多种可能的响应。用户代理或者用户自身应该从中选择一个。
• 使用场景：由于没有如何进行选择的标准方法，这个状态码极少使用。

301 Moved Permanently（永久性重定向)

• 响应结果：表示请求的资源已被分配了新的URL，以后应使用现在所指的URL。也就是说如果已经吧资源对应的URL保存为书签了，这时应该按Location首部字段提示的URL重新保存。
• 使用场景：
• • 域名到期不想续费（或者发现了更适合网站的域名），想换个域名。
• • 在搜索引擎的搜索结果中出现了不带www的域名，而带www的域名却没有收录，这个时候可以用301重定向来告诉搜索引擎我们目标的域名是哪一个。
• • 空间服务器不稳定，换空间的时候。

302 Found（临时性重定向）

• 响应结果：该状态码表示请求的资源已被分配了新的URL，希望用户（本次）能使用新的URL访问。
• 使用场景：尽量使用301！

303 See Other（参见其他）

• 响应结果：表示由于请求对应的资源存在这另一个URL，应使用GET方法定向获取请求的资源。303与302不同之处在于，302是不会改变请求的方法，如果请求方法是POST的话，重定向的请求也应该是POST。而对于303，使用POST请求的话，重定向的请求应该是GET请求。
• 使用场景：未知。

304 Not Modified（未修改）

响应结果：该状态码表示客户端发送附带条件的请求（指采用GET方法的请求报文中包含）时，服务器端允许请求访问资源，但未满足条件的情况。304状态码返回时，不包含任何响应的主体。304虽然在3xx类别中，但是和重定向没关系。

• 使用场景：在 Web 页面中查看任务详情时，要求能够不刷新页面便自动的更新它的状态与日志等信息（任务的执行会花费一定的时间，同时后台在处理任务的过程中会同步它的状态与日志的更新）。因为任务的状态更新可接受短暂的延时，所以不必采用长连接的方式，客户端只需要定时往服务器发送获取数据的请求即可，但是任务的数据量较大，如果任务并未发生改变，就查询它全部的相关信息并返回到客户端对性能而言必然不是最优的选择，所以我们需要在它发生改变后才查询并返回数据，那么这里就可以引入 304 状态码来解决任务无变化时的返回结果。

305 Use Proxy （使用代理）

• 响应结果：被请求的资源必须通过指定的代理才能被访问。
• 使用场景：未知。

306 (Unused)

在最新版的规范中，306状态码已经不再被使用。

307 Temporary Redirect （临时重定向）

• 响应结果：该状态码与302有着相同的含义。尽管302标准禁止POST变换成GET，但实际使用时大家并不遵守。307会遵照浏览器标准，不会从POST变成GET。但是，对于处理响应时的行为，每种浏览器有可能出现不同的情况。
• 使用场景：同302

308 Permanent Redirect（永久重定向）

• 响应结果：是表示重定向的响应状态码，说明请求的资源已经被永久的移动到了由 Location 首部指定的 URL 上。浏览器会进行重定向，同时搜索引擎也会更新其链接（用 SEO 的行话来说，意思是链接汁被传递到了新的 URL）。在重定向过程中，请求方法和消息主体不会发生改变，然而在返回 301 状态码的情况下，请求方法有时候会被客户端错误地修改为 GET 方法。
• 使用场景：一些 Web 应用可能会将 308 Permanent Redirect 以一种非标准的方式使用以及用作其他用途。例如，Google Drive 会使用 308 Resume Incomplete 状态码来告知客户端文件上传终止且不完整。

4xx Client Error客户端响应

4XX的响应结果表明客户端是发生错误的原因所在。

400 Bad Request（坏请求）

• 响应结果：该状态码表示请求报文中存在语法错误。当错误发生时，需要修改请求的内容后再次发送请求。另外，浏览器会像200OK一样对待该状态码。
• 出现原因：语义有误，当前请求无法被服务器理解。除非进行修改，否则客户端不应该重复提交这个请求。请求参数有误。

401 Unauthorized（未授权）

-响应结果：表示发送的请求需要有通过HTTP认证的认证信息。另外若之前已进行过一次请求，则表示用户认证失败。返回含有401响应必须包含一个适用于被请求资源的WWW-Authenticate 首部用以质询用户信息。当浏览器初次接收到401响应，会弹出认证用的对话窗口。

• 出现原因：客户端错误，指的是由于缺乏目标资源要求的身份验证凭证，发送的请求未得到满足。

402 Payment Required（要求付款）

• 响应结果：此响应码保留以便将来使用，创造此响应码的最初目的是用于数字支付系统，然而现在并未使用。

403 Forbidden （禁止）

• 响应结果：对请求资源的访问服务器拒绝了。服务器端没有必要给出拒绝的详细理由，但如果想作说明的话，可以在实体的主题部分对原因进行描述，这样就能让用户看到了。
• 出现原因：未获得文件系统的访问授权，访问权限出现某些问题（从未授权的发送源IP地址试图访问）等列举情况都可能是发生403的原因。

404 Not Found（未找到）

• 响应结果：表明服务器上无法找到请求的资源。
• 使用场景：服务器找不到资源时，或者服务器拒绝请求又不想说明理由时。

405 Method Not Allowed（不允许使用的方法）

• 响应结果：请求行中指定的请求方法不能被用于请求相应的资源。该响应必须返回一个Allow 头信息用以表示出当前资源能够接受的请求方法的列表。
• 出现原因：鉴于 PUT，DELETE 方法会对服务器上的资源进行写操作，因而绝大部分的网页服务器都不支持或者在默认配置下不允许上述请求方法，对于此类请求均会返回405错误。

406 Not Acceptable（无法接受）

• 响应结果：表示客户端错误，指代服务器端无法提供与 Accept-Charset 以及 Accept-Language 消息头指定的值相匹配的响应
• 出现原因：在实际应用中，这个错误状态码极少使用：不是给用户返回一个晦涩难懂（且难以更正）的错误状态码，而是将相关的消息头忽略，同时给用户提供一个看得见摸得着的页面。这种做法基于这样一个假设：即便是不能达到用户十分满意，也强于返回错误状态码。

如果服务器返回了这个错误状态码，那么消息体中应该包含所能提供的资源表现形式的列表，允许用户手动进行选择。

407 Proxy Authentication Required(要求进行代理认证)

• 响应结果：代表客户端错误，指的是由于缺乏位于浏览器与可以访问所请求资源的服务器之间的代理服务器（proxy server ）要求的身份验证凭证，发送的请求尚未得到满足。
• 使用场景：这个状态码会与 Proxy-Authenticate 首部一起发送，其中包含有如何进行验证的信息。

//响应示例
HTTP/1.1 407 Proxy Authentication Required 
Date: Wed, 21 Oct 2015 07:28:00 GMT
Proxy-Authenticate: Basic realm="Access to internal site"

408 Request Timeout（请求超时）

• 响应结果：遇到408意味着你的请求发送到该网站花的时间比该网站的服务器准备等待的时间要长，即链接超时。408错误往往难以解决，通常涉及系统工作量或系统操作中的一次性变化。
• 出现原因：如果用户持续看到408错误，管理员首先要考虑到Web服务器的工作量，特别是在产生408错误的时间段，另外网络流量激增也可能导致用户无法访问网页从而出现该错误。

409 Conflict（冲突）

• 响应结果：表示请求与当前服务器端的状态相冲突。
• 出现原因：冲突最有可能发生在对 PUT 请求的响应中。例如，当上传文件的版本比服务器上已存在的要旧，从而导致版本冲突的时候，那么就有可能收到状态码为 409 的响应。

410 Gone（消失了）

• 响应结果：说明请求的内容在服务器上不存在了，同时是永久性的丢失。如果不清楚是否为永久或临时的丢失，应该使用404 。

411 Length Required（要求长度指示）

• 响应结果：属于客户端错误，表示由于缺少确定的Content-Length 首部字段，服务器拒绝客户端的请求。

412 Precondition Failed（先决条件失败）

• 响应结果:（先决条件失败）表示客户端错误，意味着对于目标资源的访问请求被拒绝。
• 出现场景：这通常发生于采用除 GET 和 HEAD 之外的方法进行条件请求时，由首部字段 If-Unmodified-Since 或 If-None-Match 规定的先决条件不成立的情况下。这时候，请求的操作——通常是上传或修改文件——无法执行，从而返回该错误状态码。

413 Payload Too Large（请求实体太大）

• 响应结果：表示请求主体的大小超过了服务器规定的限度，服务器可以选择关闭连接或者返回 Retry-After 首部字段。

414 URI Too Long（请求URI太长）

• 响应结果：表示客户端所请求的 URI 超过了服务器允许的范围。
• 出现原因：
• • 当客户端误将 POST 请求当作 GET 请求的时候，会带有一个常常的查询字符串(query)；
• • when the client has descended into a loop of redirection (for example, a redirected URI prefix that points to a suffix of itself)
• • 当客户端对服务器进行攻击，试图寻找潜在的漏洞的时候。

415 Unsupported Media Type（不支持的媒体类型）

• 响应结果：是一种HTTP协议的错误状态代码，表示服务器由于不支持其有效载荷的格式，从而拒绝接受客户端的请求。
• 出现原因：格式问题的出现有可能源于客户端在 Content-Type 或 Content-Encoding 首部中指定的格式，也可能源于直接对负载数据进行检测的结果。

416 Requested Range Not Satisfiable （所请求的范围未得到满足）

• 响应结果：服务器无法处理所请求的数据区间，最常见的情况是所请求的数据区间不在文件范围之内。一则 416 应答消息包含有一个 Content-Range 首部，提示无法满足的数据区间（用星号 * 表示），后面紧跟着一个“/”，再后面是当前资源的长度。例如：

遇到这一错误状态码的时候，浏览器一般有两种策略：一种是终止操作，例如，一项中断的下载操作被认为是不可恢复的；另外一种是再次请求整个文件。

417 Expectation Failed（无法满足期望）

• 响应结果：客户端错误，意味着服务器无法满足 Expect 请求消息头中的期望条件。

426 Upgrade Required（需要升级）

• 响应结果：是一种HTTP协议的错误状态代码，表示服务器拒绝处理客户端使用当前协议发送的请求，但是可以接受其使用升级后的协议发送的请求。

服务器会在响应中使用 Upgrade 首部来指定要求的协议。

//示例
HTTP/1.1 426 Upgrade Required 
Upgrade: HTTP/3.0 
Connection: Upgrade 
Content-Length: 53 
Content-Type: text/plain 

This service requires use of the HTTP/3.0 protocol

428 Precondition Required（先决条件要求）

• 响应结果：表示服务器端要求发送条件请求。
• 出现原因：一般的，这种情况意味着必要的条件首部——如 If-Match ——的缺失。.

当一个条件首部的值不能匹配服务器端的状态的时候，应答的状态码应该是 412 Precondition Failed，前置条件验证失败。

429 Too Many Requests（请求太多）

表示在一定的时间内用户发送了太多的请求，即超出了“频次限制”。

431 Request Header Fields Too Large

• 响应主体：表示在一定的时间内用户发送了太多的请求，即超出了“频次限制”。在响应中，可以提供一个 Retry-After 首部来提示用户需要等待多长时间之后再发送新的请求。

  //示例
  HTTP/1.1 429 Too Many Requests
  Content-Type: text/html
  Retry-After: 3600
  

431 Request Header Fields Too Large

• 响应主体：表示由于请求中的首部字段的值过大，服务器拒绝接受客户端的请求。客户端可以在缩减首部字段的体积后再次发送请求。

• 应用场景：该响应码可以用于首部总体体积过大的情况，也可以用于单个首部体积过大的情况。

  这种错误不应该出现于经过良好测试的投入使用的系统当中，而是更多出现于测试新系统的时候

451 Unavailable For LegalReason（因法律原因不可用）

• 响应结果：是一种HTTP协议的错误状态代码，表示服务器由于法律原因，无法提供客户端请求的资源，例如可能会导致法律诉讼的页面。

  <!--
  这个响应示例来自 IETF RFC 规范（见下文），其中提到了英国戏剧电影Monty Python's Life of Brian （《蒙提·派森之布莱恩的一生》）。
  
  注意 Link 首部中可能会包含一个 rel="blocked-by" 字段，用于标明为该资源无法提供负责的主体，例如颁布法令将资源删除的个人或组织的名称。
  -->
  HTTP/1.1 451 Unavailable For Legal Reasons
  Link: <https://spqr.example.org/legislatione>; rel="blocked-by"
  Content-Type: text/html
  
  <html>
  <head><title>Unavailable For Legal Reasons</title></head>
  <body>
  <h1>Unavailable For Legal Reasons</h1>
  <p>This request may not be serviced in the Roman Province
  of Judea due to the Lex Julia Majestatis, which disallows
  access to resources hosted on servers deemed to be
  operated by the People's Front of Judea.</p>
  </body>
  </html>
  

5xx Server Error 服务器错误

5XX 响应结果表明服务器本身发生错误。

500 Internal Server Error（内部资源出错）

• 响应结果：表明服务器端在执行请求时发生了错误。也有可能是Web应用存在的bug或某些临时的故障。
• 解决方案：这个错误代码是一个通用的“全方位”响应代码。通常服务器管理员对于类似于 500 这样的错误会更加详细地记录相关的请求信息来防止以后同样错误的出现。

501 Not Implemented

• 响应结果：服务器错误响应码表示请求的方法不被服务器支持，因此无法被处理。服务器必须支持的方法（即不会返回这个状态码的方法）只有 GET 和 HEAD。

• 解决方法：你无法修复 501 错误，需要被访问的 web 服务器去修复该问题。

502 Bad Gateway

• 响应结果：是一种HTTP协议的服务器端错误状态代码，它表示扮演网关或代理角色的服务器，从上游服务器中接收到的响应是无效的。
• 解决方法：502 错误通常不是客户端能够修复的，而是需要由途径的Web服务器或者代理服务器对其进行修复。

503 Service Unavailable

• 响应结果：表明服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。如果事先得知解除以上状况需要的视觉，最好写入Retry-After首部字段在返回给客户端。
• 出现原因：在服务器503错误出现了之后，大家不必担心的， 服务器或许就是正在维护或者暂停了，你可以联系一下服务器空间商。还有的时候cpu占用的频率大导致的。

504 Gateway Timeout（网关超时）

• 响应结果：与状态吗408类似， 但是响应来自网关或代理，此网关或代理在等待另一台服务器的响应时出现了超时

505 HTTP Version Not Supported（不支持的HTTP版本）

• 响应结果：服务器收到的请求使用了它不支持的HTTP协议版本。 有些服务器不支持HTTP早期的HTTP协议版本，也不支持太高的协议版本

511 Network Authentication Required

• 响应结果：表示客户端需要通过验证才能使用该网络。该状态码不是由源头服务器生成的，而是由控制网络访问的拦截代理服务器生成的。
• 出现原因：网络运营商们有时候会在准许使用网络之前要求用户进行身份验证、接受某些条款，或者进行其他形式的与用户之间的互动（例如在网络咖啡厅或者机场）。他们通常用用户设备的 MAC 地址来进行识别。

以上就是常见的一些状态码，如有不正确的地方，欢迎指正。

参考链接：

• http://blog.csdn.net/hzw05103020/article/details/47276005
• https://zh.wikipedia.org/wiki/HTTP%E7%8A%B6%E6%80%81%E7%A0%81
• https://tools.ietf.org/html/rfc2616
• https://developer.mozilla.org/zh-CN/docs/tag/%E7%8A%B6%E6%80%81%E7%A0%81
• https://www.zhihu.com/question/51771270
• http://kentt.top/2017/10/11/http-304/
• http://huang-jerryc.com/2016/05/22/%E3%80%8C%E7%90%86%E8%A7%A3HTTP%E3%80%8D%E4%B9%8B%E5%B8%B8%E8%A7%81%E7%9A%84%E7%8A%B6%E6%80%81%E7%A0%81/
• 《图解HTTP》【日】上野宣 （著） 于均良 （译） 人民邮电出版社