HTTP 响应状态代码批示特定 HTTP 申请是否已胜利实现。状态代码由 section 10 of RFC 2616定义。响应分为五类：
- 1xx：信息
- 2xx：胜利
- 3xx：重定向
- 4xx：客户端谬误
- 5xx：服务器谬误
个别故障排除提醒
- 当应用
Web浏览器测试Web服务器时，在更改服务器后刷新浏览器 - 查看服务器日志以获取无关服务器如何解决申请的更多详细信息。例如，网络服务器，如
Apache或Nginx的生成两个文件名为access.log和error.log，能够为相干的信息进行扫描。 - 请记住：HTTP 状态代码定义是由提供申请的应用程序实现的规范的一部分。这意味着返回的 理论状态代码取决于服务器软件如何解决特定谬误 – 本指南通常应该指向正确的方向
一些常见的状态码为：
1xx（长期响应）示意长期响应并须要请求者继续执行操作的状态代码。
这一类型的状态码，代表申请已被承受，须要持续解决。这类响应只蕴含状态行和某些可选的响应头信息，并以空行完结。
因为 HTTP/1.0 协定中没有定义任何 1xx 状态码，所以除非在某些试验条件下，服务器禁止向此类客户端发送 1xx 响应。
100（持续）：迄今为止的所有内容都是可行的，客户端应该持续申请，如果曾经实现，则疏忽它。
服务器曾经接管到申请头，并且客户端应持续发送申请主体（在须要发送身材的申请的状况下：例如，POST 申请），或者如果申请曾经实现，疏忽这个响应。服务器必须在申请实现后向客户端发送一个最终响应。要使服务器查看申请的头部，客户端必须在其初始申请中发送 Expect: 100-continue 作为头部，并在发送注释之前接管 100 Continue 状态代码。
101（切换协定）：该代码是响应客户端的 Upgrade 标头发送的，并且批示服务器也正在切换的协定。
服务器曾经了解了客户端的申请，并将通过 Upgrade 音讯头告诉客户端采纳不同的协定来实现这个申请。在发送完这个响应最初的空行后，服务器将会切换到在 Upgrade 音讯头中定义的那些协定。
只有在切换新的协定更有益处的时候才应该采取相似措施。例如，切换到新的 HTTP 版本（如 HTTP/2）比旧版本更有劣势，或者切换到一个实时且同步的协定（如WebSocket）以传送利用此类个性的资源。
102 Processing（WebDAV；RFC 2518）：
WebDAV申请可能蕴含许多波及文件操作的子申请，须要很长时间能力实现申请。该代码示意服务器曾经收到并正在解决申请，但无响应可用。这样能够避免客户端超时，并假如申请失落。
103 Early Hints： 此状态代码次要用于与 Link 链接头一起应用，以容许用户代理在服务器仍在筹备响应时开始预加载资源。
2xx（胜利）示意申请已胜利被服务器接管、了解、并承受。
200（胜利）：申请已胜利，申请所心愿的响应头或数据体将随此响应返回。
胜利的含意取决于 HTTP 办法：
- GET：资源已被提取并在音讯注释中传输。
- HEAD：实体标头位于音讯注释中。
- POST：形容动作后果的资源在音讯体中传输。
- TRACE：音讯注释蕴含服务器收到的申请音讯
201（已创立）：该申请已胜利，并因而创立了一个新的资源。这通常是在 POST 申请，或是某些 PUT 申请之后返回的响应。
202（已承受）：服务器已承受申请，但尚未解决。最终该申请可能会也可能不会被执行，并且可能在解决产生时被禁止。如：须要的资源无奈及时创立。
203（非受权信息）（自 HTTP / 1.1 起）：服务器已胜利解决了申请，但返回的信息可能来自另一起源。
204（无内容）：服务器胜利解决了申请，没有返回任何内容。
205（重置内容）：服务器胜利解决了申请，但没有返回任何内容。
然而与 204 响应不同，返回此状态码的响应要求请求者重置文档视图。该响应次要是被用于承受用户输出后，立刻重置表单，以便用户可能轻松地开始另一次输出。与 204 响应一样，该响应也被禁止蕴含任何音讯体，且以音讯头后的第一个空行完结。
206（局部内容）：服务器胜利解决了局部 GET 申请。实现断点续传或者将一个大文档合成为多个下载段同时下载。如：视频播放时的数据加载申请。
该申请必须蕴含 Range 头信息来批示客户端心愿失去的内容范畴，并且可能蕴含 If-Range 来作为申请条件。
207（多状态）：由 WebDAV(RFC 2518) 扩大的状态码，代表之后的音讯体将是一个 XML 音讯，并且可能按照之前子申请数量的不同，蕴含一系列独立的响应代码。
208 (已报告)（WebDAV；RFC 5842）：在 DAV 外面应用: propstat 响应元素以防止反复枚举多个绑定的外部成员到同一个汇合。
226（IM Used）（RFC 3229）：服务器曾经实现了对资源的 GET 申请，并且响应是对以后实例利用的一个或多个实例操作后果的示意。
3xx（重定向）示意要实现申请，须要进一步操作。
示意要实现申请，须要进一步操作。通常，这些状态代码用来重定向。
当且仅当后续的申请所应用的办法是 GET 或者 HEAD 时，用户浏览器才能够在没有用户染指的状况下主动提交所须要的后续申请。客户端该当主动监测有限循环重定向（例如：A→B→C→……→A 或 A→A），因为这会导致服务器和客户端大量不必要的资源耗费。依照 HTTP/1.0 版标准的倡议，浏览器不应主动拜访超过 5 次的重定向。
300（多种抉择）：被申请的资源有一系列可供选择的回馈信息，每个都有本人特定的地址和浏览器驱动的商议信息。用户或浏览器可能自行抉择一个首选的地址进行重定向。
如果服务器自身曾经有了首选的回馈抉择，那么在 Location 中该当指明这个回馈的 URI；浏览器可能会将这个 Location 值作为主动重定向的地址。此外，除非额定指定，否则这个响应也是可缓存的。
301（永恒移除）：申请的网页已永恒挪动到新地位。服务器返回此响应（对 GET 或 HEAD 申请的响应）时，会主动将请求者转到新地位。
如果可能，领有链接编辑性能的客户端该当主动把申请的地址批改为从服务器反馈回来的地址。除非额定指定，否则这个响应也是可缓存的。
新的永久性的 URI 该当在响应的 Location 域中返回。除非这是一个 HEAD 申请，否则响应的实体中该当蕴含指向新的 URI 的超链接及简短阐明。如果这不是一个 GET 或者 HEAD 申请，因而浏览器禁止主动进行重定向，除非失去用户的确认，因为申请的条件可能因而发生变化。
对于某些应用 HTTP/1.0 协定的浏览器，当它们发送的 POST 申请失去了一个 301 响应的话，接下来的重定向申请将会变成 GET 形式。
302（长期挪动）：服务器目前从不同地位的网页响应申请，但请求者应持续应用原有地位来进行当前的申请。
只有在 Cache-Control 或Expires中进行了指定的状况下，这个响应才是可缓存的。
新的临时性的 URI 该当在响应的 Location 域中返回。除非这是一个 HEAD 申请，否则响应的实体中该当蕴含指向新的 URI 的超链接及简短阐明。
如果这不是一个 GET 或者 HEAD 申请，那么浏览器禁止主动进行重定向，除非失去用户的确认，因为申请的条件可能因而发生变化。
尽管 RFC 1945 和 RFC 2068 标准不容许客户端在重定向时扭转申请的办法，然而很多现存的浏览器将 302 响应视作为 303 响应，并且应用 GET 形式拜访在 Location 中规定的 URI，而忽视原先申请的办法。因而状态码 303 和 307 被增加了进来，用以明确服务器期待客户端进行何种反馈。
303（查看其余地位）：对应以后申请的响应能够在另一个 URI 上被找到，而且客户端该当采纳 GET 的形式拜访那个资源。这个办法的存在次要是为了容许由脚本激活的 POST 申请输入重定向到一个新的资源。
同时，303 响应禁止被缓存。当然，第二个申请（重定向）可能被缓存。
新的 URI 该当在响应的 Location 域中返回。除非这是一个 HEAD 申请，否则响应的实体中该当蕴含指向新的 URI 的超链接及简短阐明。
许多 HTTP/1.1 版以前的浏览器不能正确理解 303 状态。如果须要思考与这些浏览器之间的互动，302 状态码应该能够胜任，因为大多数的浏览器解决 302 响应时的形式恰好就是上述标准要求客户端解决 303 响应时该当做的。
304（未修改）：示意资源未被批改，因为申请头指定的版本 If-Modified-Since 或If-None-Match。在这种状况下，因为客户端依然具备以前下载的正本，因而不须要从新传输资源。
304 响应禁止蕴含音讯体，因而始终以音讯头后的第一个空行结尾。
305（应用代理）：被申请的资源必须通过指定的代理能力被拜访。
Location 域中将给出指定的代理所在的 URI 信息，接收者须要反复发送一个独自的申请，通过这个代理能力拜访相应资源。只有原始服务器能力建设 305 响应。
RFC 2068 中没有明确 305 响应是为了重定向一个独自的申请，而且只能被原始服务器建设。漠视这些限度可能导致重大的平安结果。
306（长期重定向）：在最新版的标准中，306 状态码曾经不再被应用。
307（长期重定向）： 申请的资源当初长期从不同的 URI 响应申请。
因为这样的重定向是长期的，客户端该当持续向原有地址发送当前的申请。只有在 Cache-Control 或 Expires 中进行了指定的状况下，这个响应才是可缓存的。
308（永恒重定向）：这意味着资源当初永恒位于由 Location: HTTP Response 标头指定的另一个 URI。
这意味着资源当初永恒位于由 Location: HTTP Response 标头指定的另一个 URI。这与 301 Moved Permanently HTTP 响应代码具备雷同的语义，但用户代理不能更改所应用的 HTTP 办法：如果在第一个申请中应用 POST，则必须在第二个申请中应用 POST。
4xx（客户端谬误）示意申请可能出错，障碍了服务器的解决。
这类的状态码代表了 客户端看起来可能产生了谬误，障碍了服务器的解决。除非响应的是一个 HEAD 申请，否则服务器就应该返回一个解释以后谬误情况的实体，以及这是长期的还是永久性的情况。
如果谬误产生时客户端正在传送数据，那么应用 TCP 的服务器实现该当认真确保在敞开客户端与服务器之间的连贯之前，客户端曾经收到了蕴含错误信息的数据包。如果客户端在收到错误信息后持续向服务器发送数据，服务器的 TCP 栈将向客户端发送一个重置数据包，以革除该客户端所有还未辨认的输出缓冲，免得这些数据被服务器上的应用程序读取并烦扰后者。
400（谬误申请）：因为显著的客户端谬误，服务器不能或不会解决该申请。
- 语义有误，以后申请无奈被服务器了解。除非进行批改，否则客户端不应该反复提交这个申请。
- 申请参数有误。比方：传参的数据结构不对
- 申请格局有误。如：因为浏览器故障，导致申请格局谬误
- 参数数据量太大
- 有效的申请音讯或欺骗性路由申请
- 与该网站相关联的用户
Cookie已损坏。革除浏览器的缓存和Cookie能够解决此问题 - 恶意代码的申请因为人为谬误手动造成 HTTP 申请时（例如，应用 curl 谬误）
401（未受权）： 申请要求身份验证。对于须要登录的网页，服务器可能返回此响应。
以后申请须要用户验证。该响应必须蕴含一个实用于被申请资源的 WWW-Authenticate 信息头用以询问用户信息。客户端能够反复提交一个蕴含失当的 Authorization 头信息的申请。如果以后申请曾经蕴含了 Authorization 证书，那么 401 响应代表着服务器验证曾经回绝了那些证书。如果 401 响应蕴含了与前一个响应雷同的身份验证询问，且浏览器曾经至多尝试了一次验证，那么浏览器该当向用户展现响应中蕴含的实体信息，因为这个实体信息中可能蕴含了相干诊断信息。
留神：当网站（通常是网站域名）禁止 IP 地址时，有些网站状态码显示的 401，示意该特定地址被回绝拜访网站。
402（要求付费）：此响应码保留以便未来应用，发明此响应码的最后目标是用于数字领取零碎，然而当初并未应用。
如果特定开发人员已超过申请的每日限度，Google Developers API会应用此状态码。
403（禁止）：服务器曾经了解申请，然而拒绝执行它。
与 401 响应不同的是，身份验证并不能提供任何帮忙，而且这个申请也不应该被反复提交。如果这不是一个 HEAD 申请，而且服务器心愿可能讲清楚为何申请不能被执行，那么就应该在实体内形容回绝的起因。当然服务器也能够返回一个 404 响应，如果它不心愿让客户端取得任何信息。
- 执行拜访被禁止。
- 读拜访被禁止。
- 写访问被禁止。
- 要求 SSL。
- 要求 SSL 128。
- IP 地址被回绝。
- 要求客户端证书。
- 站点拜访被回绝。
- 用户数过多。
- 配置有效。
- 明码更改。
- 回绝拜访映射表。
- 客户端证书被撤消。
- 回绝目录列表。
- 超出客户端拜访许可。
- 客户端证书不受信赖或有效。
- 客户端证书已过期或尚未失效。
- 在以后的应用程序池中不能执行所申请的 URL。
- 不能为这个应用程序池中的客户端执行 CGI。
- Passport 登录失败。
404（未找到）：申请失败，申请所心愿失去的资源未被在服务器上发现。
没有信息可能通知用户这个情况到底是临时的还是永恒的。如果服务器晓得状况的话，该当应用 410 状态码来告知旧资源因为某些外部的配置机制问题，曾经永恒的不可用，而且没有任何能够跳转的地址。404 这个状态码被广泛应用于当服务器不想揭示到底为何申请被回绝或者没有其余适宜的响应可用的状况下。
- 资源的链接是否有打字谬误？
- 用户键入的网址有误吗？
- 文件是否存在于服务器上的正确地位？资源是否已在服务器上挪动或删除？
- 服务器配置是否具备正确的文档根地位？
- 领有 Web 服务器工作过程的用户是否有权限遍历到申请的文件所在的目录？（提醒：目录须要拜访读取和执行权限）
- 拜访的资源是否是符号链接？如果是，请确保 Web 服务器配置为遵循符号链接
405（办法禁用）：申请行中指定的申请办法（post、get、put、delete 等）不能被用于申请相应的资源。
该响应必须返回一个 Allow 头信息用以示意出以后资源可能承受的申请办法的列表。鉴于 PUT，DELETE 办法会对服务器上的资源进行写操作，因此绝大部分的网页服务器都不反对或者在默认配置下不容许上述申请办法，对于此类申请均会返回 405 谬误。
406（（不承受））：申请的资源的内容个性无奈满足申请头中的条件，因此无奈生成响应实体。
除非这是一个 HEAD 申请，否则该响应就该当返回一个蕴含能够让用户或者浏览器从中抉择最合适的实体个性以及地址列表的实体。实体的格局由 Content-Type 头 中定义的媒体类型决定。浏览器能够依据格局及本身能力自行作出最佳抉择。然而，标准中并没有定义任何作出此类主动抉择的规范。
407（（须要代理受权））：与 401 响应相似，只不过客户端必须在代理服务器上进行身份验证。
代理服务器必须返回一个 Proxy-Authenticate 用以进行身份询问。客户端能够返回一个 Proxy-Authorization 信息头用以验证。
408（（申请超时））：申请超时。客户端没有在服务器准备期待的工夫内实现一个申请的发送。客户端能够随时再次提交这一申请而无需进行任何更改。
409（抵触）：因为和被申请的资源的以后状态之间存在抵触，申请无奈实现。
这个代码只容许用在这样的状况下能力被应用：用户被认为可能解决抵触，并且会从新提交新的申请。该响应该当蕴含足够的信息以便用户发现抵触的源头。如：多个同步更新之间的编辑抵触。
410（已删除）：被申请的资源在服务器上曾经不再可用，而且没有任何已知的转发地址。
这样的情况该当被认为是永久性的。如果可能，领有链接编辑性能的客户端该当在取得用户许可后删除所有指向这个地址的援用。如果服务器不晓得或者无奈确定这个情况是否是永恒的，那么就应该应用 404 状态码。除非额定阐明，否则这个响应是可缓存的。
411（须要无效长度）：服务器回绝在没有定义 Content-Length 头的状况下承受申请。在增加了表明申请音讯体长度的无效 Content-Length 头之后，客户端能够再次提交该申请。
412（前提条件失败）：服务器在验证在申请的头字段中给出先决条件时，没能满足其中的一个或多个。这个状态码容许客户端在获取资源时在申请的元信息（申请头字段数据）中设置先决条件，以此防止该申请办法被利用到其心愿的内容以外的资源上。
413（申请实体过大）：服务器回绝解决以后申请，因为该申请提交的实体数据大小超过了服务器违心或者可能解决的范畴。
此种状况下，服务器能够敞开连贯免得客户端持续发送此申请。如果这个情况是长期的，服务器该当返回一个 Retry-After 的响应头，以告知客户端能够在多少工夫当前从新尝试。
414（申请的 URI 过长）：申请的 URI 长度超过了服务器可能解释的长度，因而服务器回绝对该申请提供服务。
- 本应应用 POST 办法的表单提交变成了 GET 办法，导致查问字符串（Query String）过长。
- 重定向 URI“黑洞”，例如每次重定向把旧的 URI 作为新的 URI 的一部分，导致在若干次重定向后 URI 超长。
- 客户端正在尝试利用某些服务器中存在的安全漏洞攻打服务器。这类服务器应用固定长度的缓冲读取或操作申请的 URI，当 GET 后的参数超过某个数值后，可能会产生缓冲区溢出，导致任意代码被执行。
415（不反对的媒体类型）：对于以后申请的办法和所申请的资源，申请中提交的实体并不是服务器中所反对的格局，因而申请被回绝。
416（申请范畴不符合要求）（RFC 7233）：如果申请中蕴含了 Range 申请头，并且 Range 中指定的任何数据范畴都与以后资源的可用范畴不重合，同时申请中又没有定义 If-Range 申请头。
417（未满足期望值）：此响应代码意味着服务器无奈满足 Expect 申请标头字段批示的期望值。
418（I’m a teapot）（RFC 2324）：本操作码是在 1998 年作为 IETF 的传统愚人节笑话，在 RFC 2324 超文本咖啡壶控制协议中定义的，并不需要在实在的 HTTP 服务器中定义。当一个管制茶壶的 HTCPCP 收到 BREW 或 POST 指令要求其煮咖啡时该当回传此谬误。
这个 HTTP 状态码在某些网站（包含 Google.com）与我的项目（如Node.js、ASP.NET 和Go语言）中用作彩蛋。
420（放弃沉着）：Twitter Search与Trends API 在客户端被限速的状况下返回。
421（谬误申请）（RFC 7540）：该申请针对的是无奈产生响应的服务器。这能够由服务器发送，该服务器未配置为针对蕴含在申请 URI 中的计划和权限的组合产生响应。
422（无奈解决的实体）（WebDAV；RFC 4918）：申请格局良好，但因为语义谬误而无奈遵循。
423（锁定）（WebDAV；RFC 4918）：正在拜访的资源被锁定。
424（依赖）（WebDAV；RFC 4918）：因为先前的申请失败，所以此次申请失败。
425（太早了）：服务器不违心冒着危险去解决可能重播的申请。如：平安验证未实现。
426（须要降级）（RFC 2817）：服务器回绝应用以后协定执行申请，但可能在客户机降级到其余协定后违心这样做。
428（须要前提条件）(RFC 6585)：原始服务器要求该申请是有条件的。旨在避免“失落更新”问题，即客户端获取资源状态，批改该状态并将其返回服务器，同时第三方批改服务器上的状态，从而导致抵触。
429（申请过多）（RFC 6585）：用户在给定的工夫内发送了太多申请（“限度申请速率”）。
431（申请头过大）（RFC 6585）：服务器不违心解决申请，因为它的 申请头字段太大（Request Header Fields Too Large）。申请能够在减小申请头字段的大小后从新提交。
444 (不响应)：Nginx 上 HTTP 服务器扩大。服务器不向客户端返回任何信息，并敞开连贯（有助于阻止恶意软件）。
450（被 Windows 家长控制系统阻止）：这是一个由 Windows 家庭管制（Microsoft）HTTP 阻止的 450 状态代码的示例，用于信息和测试。
451（因为法律起因无奈应用）：用户申请非法资源，例如：由政府审查的网页。
5xx（服务器谬误）示意服务器在尝试解决申请时产生外部谬误。
这类状态码代表了服务器在解决申请的过程中有谬误或者异样状态产生，也有可能是服务器意识到以以后的软硬件资源无奈实现对申请的解决。除非这是一个 HEAD 申请，否则服务器该当蕴含一个解释以后谬误状态以及这个情况是长期的还是永恒的解释信息实体。浏览器该当向用户展现任何在以后响应中被蕴含的实体。这些状态码实用于任何响应办法。
500（外部服务器谬误）：通用谬误音讯，服务器遇到了一个未曾意料的情况，导致了它无奈实现对申请的解决。
这此谬误最常见的起因是服务器配置谬误（例如，一个畸形.htaccess 文件）或缺失的软件包（如试图在没有装置正确 PHP 执行的 PHP 文件）。
501（尚未施行）：此申请办法不被服务器反对且无奈被解决。只有 GET 和HEAD是要求服务器反对的，它们必然不会返回此错误代码。
502（谬误网关）：这意味着服务器的网关或代理服务器，它没有收到来自理论应该履行申请的后端服务器的无效响应。
如果有问题的服务器是逆向代理服务器，例如负载均衡器，则须要查看以下几项：
- 后端服务器（HTTP 申请转发到的）是失常的
- 正确配置逆向代理，指定适当的后端
- 后端服务器和逆向代理服务器之间的网络连接是失常的。如果服务器能够在其余端口上通信，请确保防火墙容许它们之间的流量
- 如果 Web 应用程序配置为侦听套接字，请确保套接字存在于正确的地位，并且具备适当的权限
503（服务不可用）： 示意服务器超载或正在保护。这个谬误意味着服务应该在某个时候可用。
请留神，与此响应一起，应发送解释问题的用户敌对页面。这个响应应该用于长期条件和 Retry-After：如果可能的话，HTTP 头应该蕴含复原服务之前的预计工夫。网站管理员还必须留神与此响应一起发送的与缓存相干的标头，因为这些长期条件响应通常不应被缓存。
如果服务器未处于保护状态，则这能够批示服务器没有足够的 CPU 或内存资源来解决所有传入的申请，或者 Web 服务器须要配置为容许更多的用户，线程或过程
504（网关超时）：当服务器作为网关，不能及时失去响应时返回此错误代码。
- 服务器之间的网络连接很差
- 因为性能不佳，履行申请的后端服务器太慢
- 网关或代理服务器的超时持续时间太短
505（HTTP 版本不受反对）：服务器不反对申请中所应用的 HTTP 协定版本。
506（协商引起的异样）（RFC 2295）：对申请的通明内容协商导致循环援用。
507（存储有余）（WebDAV；RFC 4918）：服务器无奈存储实现申请所必须的内容。这个情况被认为是长期的。
508（循环检测）（WebDAV；RFC 5842）：服务器在解决申请时陷入死循环。可代替 208 状态码
510（扩大有余）（RFC 2774）：获取资源所须要的策略并没有被满足，客户端须要对申请进一步扩大，服务器能力实现它。服务器会回复客户端收回扩大申请所需的所有信息。
511（网络身份验证要求）（RFC 6585）：客户端须要进行身份验证能力取得网络拜访权限，旨在限度用户群拜访特定网络。如：连贯 WiFi 热点时的强制网络门户
参考链接
MDN HTTP 响应代码