HTTP 状态码 (响应码) 对照表
HTTP 状态码是服务器在响应客户端请求时返回的一个3位数字代码。通过这个数字状态码，可以得知服务器想要告诉客户端的结果，技术人员也可以判断服务器的情况，所谓的网站挂了，通过状态码就能知道一些原因。
HTTP 状态码速查，指南最近联动 柔科导航 开始陆续增加站长、运维、服务器相关的内容，补充运维技术方向的短板，常规下 HTTP 状态码分为五大类。
| 状态码范围 | 类别 | 通俗解释 |
|---|---|---|
| 1xx | 消息响应 | 「收到请求，继续处理」 |
| 2xx | 成功 | 「请求成功，这里是结果」 |
| 3xx | 重定向 | 「资源换了地址，去别处找」 |
| 4xx | 客户端错误 | 「你的请求有问题」 |
| 5xx | 服务器错误 | 「服务器出故障了」 |
使用快捷键 Ctrl + F 或 Cmd + F (Mac)对网页进行快速搜索吧
HTTP 状态码表
| 状态码 | 短语 | 描述 | 最低版本 |
|---|---|---|---|
| 100 | Continue 继续 | 客户端应当继续发送请求。这个临时响应是用来通知客户端它的部分请求已经被服务器接收，且仍未被拒绝。客户端应当继续发送请求的剩余部分，或者如果请求已经完成，忽略这个响应。服务器必须在请求完成后向客户端发送一个最终响应。 | HTTP/1.1 |
| 101 | Switching Protocol 切换协议 | 服务器已经理解了客户端的请求，并将通过 Upgrade 消息头通知客户端采用不同的协议来完成这个请求。在发送完这个响应最后的空行后，服务器将会切换到在 Upgrade 消息头中定义的那些协议。只有在切换新的协议更有好处的时候才应该采取类似措施。例如，切换到新的 HTTP 版本比旧版本更有优势，或者切换到一个实时且同步的协议以传送利用此类特性的资源。 | HTTP/1.1 |
| 200 | OK 成功 | 请求成功。成功的意义根据请求所使用的方法不同而不同。 GET: 资源已被提取，并作为响应体传回客户端。 HEAD: 实体头已作为响应头传回客户端。 POST: 经过服务器处理客户端传来的数据，适合的资源作为响应体传回客户端。 TRACE: 服务器收到请求消息作为响应体传回客户端。 | HTTP/0.9 |
| 201 | Created 已创建 | 请求成功，而且有一个新的资源已经依据请求的需要而建立，通常这是 PUT 方法得到的响应码。 | HTTP/0.9 |
| 202 | Accepted 已接受 | 服务器已接受请求，但尚未处理。正如它可能被拒绝一样，最终该请求可能会也可能不会被执行。在异步操作的场合下，没有比发送这个状态码更方便的做法了。返回 202 状态码的响应的目的是允许服务器接受其他过程的请求（例如某个每天只执行一次的基于批处理的操作），而不必让客户端一直保持与服务器的连接直到批处理操作全部完成。在接受请求处理并返回 202 状态码的响应应当在返回的实体中包含一些指示处理当前状态的信息，以及指向处理状态监视器或状态预测的指针，以便用户能够估计操作是否已经完成。 | HTTP/0.9 |
| 203 | Non-Authoritative Information 未授权信息 | 服务器已成功处理了请求，但返回的实体头部元信息不是在原始服务器上有效的确定集合，而是来自本地或者第三方的拷贝，如果不是上述情况，使用 200 状态码才是最合适的。 | HTTP/0.9 |
| 204 | No Content 无内容 | 该响应没有响应内容，只有响应头，响应头也可能是有用的。用户代理可以根据新的响应头来更新对应资源的缓存信息。 | HTTP/0.9 |
| 205 | Reset Content 重置内容 | 告诉用户代理去重置发送该请求的窗口的文档视图。 | HTTP/1.1 |
| 206 | Partial Content 部分内容 | 当客户端通过使用 range 头字段进行文件分段下载时使用该状态码。 | HTTP/1.1 |
| 300 | Multiple Choice 多种选择 | 该请求有多种可能的响应，用户代理或者用户必须选择它们其中的一个。服务器没有任何标准可以遵循去代替用户来进行选择。 | HTTP/1.1 |
| 301 | Moved Permanently 永久移动 | 该状态码表示所请求的 URI 资源路径已经改变，新的 URL 会在响应的 Location: 头字段里找到。 | HTTP/0.9 |
| 302 | Found 临时移动 | 该状态码表示所请求的 URI 资源路径临时改变，并且还可能继续改变。因此客户端在以后访问时还得继续使用该 URI。新的 URL 会在响应的 Location: 头字段里找到。 | HTTP/0.9 |
| 303 | See Other 查看其他位置 | 服务器发送该响应用来引导客户端使用 GET 方法访问另外一个 URI。 | HTTP/0.9 |
| 304 | Not Modified 未修改 | 告诉客户端，所请求的内容距离上次访问并没有变化。客户端可以直接从浏览器缓存里获取该资源。 | HTTP/0.9 |
| 305 | Use Proxy 使用代理 | 所请求的资源必须通过代理才能访问到。由于安全原因，该状态码并未受到广泛支持。 | HTTP/1.1 |
| 306 | unused 未使用 | 这个状态码已经不再被使用，当初它被用在 HTTP/1.1 规范的旧版本中。 | HTTP/1.1 |
| 307 | Temporary Redirect 临时重定向 | 服务器发送该响应用来引导客户端使用相同的方法访问另外一个 URI 来获取想要获取的资源。新的 URL 会在响应的 Location: 头字段里找到。与 302 状态码有相同的语义，且前后两次访问必须使用相同的方法 (GET/POST)。 | HTTP/1.1 |
| 308 | Permanent Redirect 永久重定向 | 所请求的资源将永久地位于另外一个 URI 上。新的 URL 会在响应的 Location: 头字段里找到。与 301 状态码有相同的语义，且前后两次访问必须使用相同的方法 (GET/POST)。 | HTTP/1.1 |
| 400 | Bad Request 错误请求 | 因发送的请求语法错误，服务器无法正常读取。 | HTTP/0.9 |
| 401 | Unauthorized 未授权 | 需要身份验证后才能获取所请求的内容，类似于 403 错误。不同点是 401 错误后，只要正确输入帐号密码，验证即可通过。 | HTTP/0.9 |
| 402 | Payment Required 需要付款 | 该状态码被保留以供将来使用。创建此代码最初的目的是为数字支付系统而用，然而到现在也没投入使用。 | HTTP/0.9 |
| 403 | Forbidden 禁止访问 | 客户端没有权利访问所请求内容，服务器拒绝本次请求。 | HTTP/0.9 |
| 404 | Not Found 未找到 | 服务器找不到所请求的资源。由于经常发生此种情况，所以该状态码在上网时是非常常见的。 | HTTP/0.9 |
| 405 | Method Not Allowed 不允许使用该方法 | 该请求使用的方法被服务器端禁止使用，RFC2616 中规定，GET 和 HEAD 方法不能被禁止。 | HTTP/1.1 |
| 406 | Not Acceptable 无法接受 | 在进行服务器驱动内容协商后，没有发现合适的内容传回给客户端。 | HTTP/1.1 |
| 407 | Proxy Authentication Required 要求代理身份验证 | 类似于状态码 401，不过需要通过代理才能进行验证。 | HTTP/1.1 |
| 408 | Request Timeout 请求超时 | 客户端没有在服务器预备等待的时间内完成一个请求的发送。这意味着服务器将会切断和客户端的连接。在其他浏览器中，这种响应更常见一些，例如 Chrome 和 IE9，目的是为了使用 HTTP 预连机制加快浏览速度。同时注意，一些服务器不发送此种响应就直接切断连接。 | HTTP/1.1 |
| 409 | Conflict 冲突 | 该请求与服务器的当前状态所冲突。 | HTTP/1.1 |
| 410 | Gone 已失效 | 所请求的资源已经被删除。 | HTTP/1.1 |
| 411 | Length Required 需要内容长度头 | 因服务器在本次请求中需要 Content-Length 头字段，而客户端没有发送，所以服务器拒绝了该请求。 | HTTP/1.1 |
| 412 | Precondition Failed 预处理失败 | 服务器没能满足客户端在获取资源时在请求头字段中设置的先决条件。 | HTTP/1.1 |
| 413 | Request Entity Too Large 请求实体过长 | 请求实体大小超过服务器的设置的最大限制，服务器可能会关闭 HTTP 链接并返回 Retry-After 头字段。 | HTTP/1.1 |
| 414 | Request-URI Too Long 请求网址过长 | 客户端请求所包含的 URI 地址太长，以至于服务器无法处理。 | HTTP/1.1 |
| 415 | Unsupported Media Type 媒体类型不支持 | 服务器不支持客户端所请求的媒体类型，因此拒绝该请求。 | HTTP/1.1 |
| 416 | Requested Range Not Satisfiable 请求范围不合要求 | 请求中包含的 Range 头字段无法被满足，通常是因为 Range 中的数字范围超出所请求资源的大小。 | HTTP/1.1 |
| 417 | Expectation Failed 预期结果失败 | 在请求头 Expect 中指定的预期内容无法被服务器满足。 | HTTP/1.1 |
| 418 | I'm a teapot 服务端拒绝用茶壶煮咖啡 | 超文本咖啡壶控制协议（HTCPCP）是由 IETF 虚构的一种协议。这个协议在文档 RFC 2324（1998 年 4 月 1 日发布）中定义，是一个恶搞 RFC。该协议被设计为一个类似 HTTP 的协议，可以用于控制、监测和诊断咖啡壶，后来也被拓展到茶壶；该协议有时也可以视作一种早期的物联网实验。 | HTTP/1.1 |
| 500 | Internal Server Error 内部服务器错误 | 服务器遇到未知的无法解决的问题。 | HTTP/0.9 |
| 501 | Not Implemented 未实现 | 服务器不支持该请求中使用的方法，比如 POST 和 PUT。只有 GET 和 HEAD 是 RFC2616 规范中规定服务器必须实现的方法。 | HTTP/0.9 |
| 502 | Bad Gateway 网关错误 | 服务器作为网关且从上游服务器获取到了一个无效的 HTTP 响应。 | HTTP/0.9 |
| 503 | Service Unavailable 服务不可用 | 由于临时的服务器维护或者过载，服务器当前无法处理请求。这个状况是临时的，并且将在一段时间以后恢复。如果能够预计延迟时间，那么响应中可以包含一个 Retry-After: 头用以标明这个延迟时间。如果没有给出这个 Retry-After 信息，那么客户端应当以处理 500 响应的方式处理它。同时，这种情况下，一个友好的用于解释服务器出现问题的页面应当被返回，并且缓存相关的 HTTP 头信息也应该包含，因为通常这种错误提示网页不应当被客户端缓存。 | HTTP/0.9 |
| 504 | Gateway Timeout 网关超时 | 服务器作为网关且不能从上游服务器及时地得到响应返回给客户端。 | HTTP/1.1 |
| 505 | HTTP Version Not Supported HTTP 版本不受支持 | 服务器不支持客户端发送的 HTTP 请求中所使用的 HTTP 协议版本。 | HTTP/1.1 |
相关链接
正确的获取各类百科资料
https://zhinan.blog/guide/pa18202510.html
适合任何人的搜索引擎语法技巧
https://zhinan.blog/guide/pa23202521.html
对于想加入我们的朋友，可联络指南来开通编辑后台或者线上进行投稿。
如需匿名投稿，请在投稿内容中说明匿名，或在撰稿人中填写路人甲。
你们的支持，是指南能够继续前进的动力，是我们可以拒绝软文植入，发自本心书写内容的信心。