HTTP 状态码

1xx

接受的请求正在处理

100 Continue

继续。

客户端应继续其请求

服务器已接收到请求的头部，客户端可以继续发送请求体。

101 Switching Protocols

切换协议。

服务器根据客户端的请求切换协议。只能切换到更高级的协议。

例如：

切换到HTTP的新版本协议

从 HTTP/1.1 切换到 WebSocket

102 Processing

处理中

正在处理客户端的请求，但由于某些操作需要花费较长时间，服务器暂时无法返回最终的响应。

是一种临时响应，主要用于 WebDAV

WebDAV 批量操作：像 PROPFIND（获取属性）或 MOVE（移动资源）这样的 WebDAV 方法，可能需要遍历大量文件和目录，或者在数据库中执行复杂查询。如果这些操作需要超过某个预期的超时时间（例如 20 秒），服务器可能会在处理过程中发送 102 响应。
避免客户端超时：许多 HTTP 客户端和代理都有一个默认的超时时间。如果服务器在超时时间内没有发送任何响应，客户端可能会中断连接并报告错误。发送 102 响应可以“重置”客户端的超时计时器，让它知道服务器还在工作，请继续等待。
复杂计算或资源密集型任务：虽然 102 主要在 WebDAV 中定义，但其概念可以扩展到其他需要长时间处理的 HTTP 请求。它提供了一种机制，让服务器能够告知客户端“我正在忙，请稍等”。

103 Early Hints

早期提示

提前发送一些响应头。优化网页加载性能，让客户端在等待最终 HTML 内容时，能够并行地开始预连接、预加载或预获取一些关键资源。

服务器计算耗时：当服务器需要一些时间来生成最终的响应（例如，执行复杂的数据库查询、渲染动态内容、等待后端微服务响应）时，它可能已经知道最终响应会包含哪些关键的子资源（如 CSS 文件、JavaScript 文件、字体或图片）。
提前告知浏览器关键资源：服务器可以在等待计算完成的同时，发送一个 103 响应，其中包含 Link 头部。这些 Link 头部可以指示浏览器预加载（preload）、预连接（preconnect）或预获取（prefetch）这些关键资源。
优化首字节时间 (TTFB)：虽然 103 不会减少服务器实际处理请求的时间，但它可以让客户端在服务器忙碌时就开始进行一些有用的网络操作，从而可能缩短整体的页面加载时间，特别是感知到的加载时间。

2xx

请求成功

200 OK

请求成功。

一般用于GET与POST请求

201 Created

已创建。

成功请求并创建了新的资源

202 Accepted

已接受。

已经接受请求，但未处理完成

与102不同，102是请求还未断，而202请求已经结束，示例：

你向一个 API 发送一个请求，要求生成一份复杂的报告。服务器收到请求后，将生成报告的任务放入一个队列，并立即返回 202 Accepted，并在响应体中包含一个指向报告状态查询页面的 URL。你可以在稍后通过这个 URL 查询报告是否生成完成。

异步处理：请求已被服务器接受，但实际处理可能在一个单独的进程、线程或另一个服务中异步进行。
立即响应：服务器立即返回 202 响应，告知客户端请求已收到，无需等待处理完成。这对于长时间运行的任务非常有用，避免客户端阻塞。
不保证最终结果：与 102 类似，202 也不保证最终结果。处理可能会成功，也可能会失败。服务器通常会提供一个机制（例如，一个状态查询 URL）供客户端后续查询任务进度和结果。
可能包含响应体：202 响应通常会包含一个实体主体，提供关于已接受请求的详细信息，例如：
- 异步任务的 ID。
- 一个用于查询任务状态的 URL。
- 预期的完成时间。

203 Non-Authoritative Information

非授权信息。

请求成功。但返回的meta信息不在原始的服务器，而是一个副本。

缓存代理（Caching Proxies）：当客户端通过一个代理服务器请求资源时，如果代理服务器自身缓存了该资源，并且该缓存是基于旧的或非权威的源，它可能会返回 203 状态码。这意味着代理服务器提供了它所拥有的信息，即使这些信息不是来自原始服务器的最新或直接响应。
内容分发网络（CDN）：CDN 边缘节点有时会根据配置返回 203 状态码，表示它提供的资源是其本地缓存，而不是直接从源站获取的。虽然 CDN 通常会努力提供最新内容，但在某些配置下，或当缓存策略允许时，可能会出现 203。
数据转换或修改（Data Transformation or Modification）：如果一个中间代理在将响应传递给客户端之前对内容进行了修改、转换或聚合，并且这些修改并非由原始服务器完成，那么它可能会使用 203 状态码来指示这种非权威性。例如，代理服务器为了适应客户端的特定要求（如压缩、格式转换）而修改了响应。
本地副本或备份（Local Copy or Backup）：在某些复杂的系统架构中，如果请求的资源是从一个本地副本或备份源获取的，而不是主权威源，服务器可能会返回 203。

204 No Content

无内容。

服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档。

成功的删除操作：当客户端向服务器发送一个删除资源的请求（如 DELETE 方法），服务器成功删除了资源后，通常不需要返回被删除资源的任何信息，只需要告知客户端操作已成功。这时，返回 204 状态码是一个很好的选择。
成功的更新操作但无需返回数据：对于某些 PUT 或 POST 请求，如果服务器成功更新了资源，但更新后的资源状态或任何其他信息都不需要返回给客户端，就可以使用 204 状态码。例如，客户端只是提交了一些配置信息，服务器保存后无需提供额外反馈。
客户端轮询（Polling）：在某些长轮询或事件通知系统中，如果客户端定期向服务器发送请求以检查是否有新数据，而当前没有新数据可发送时，服务器可以返回 204 状态码，表示“目前没有新内容”。
表单提交后不进行页面跳转：在一个 AJAX 驱动的 Web 应用中，用户提交表单后，服务器成功处理了数据，但不需要刷新页面或跳转到新页面，可以直接返回 204，让前端 JavaScript 继续处理后续的用户界面更新。

205 Reset Content

重置内容。

服务器处理成功，用户终端（例如：浏览器）应重置文档视图。可通过此返回码清除浏览器的表单域

表单提交后重置表单：这是 205 状态码最典型的应用场景。当用户提交了一个表单（例如，注册表单、评论表单、搜索表单），服务器成功处理了数据后，如果希望客户端将表单中的输入字段清空，以便用户可以再次输入或提交新的信息，就可以返回 205。
- 例如，用户成功提交了一个注册信息，服务器处理后返回 205。客户端浏览器接收到这个状态码后，会自动清空注册表单中的用户名、密码等字段，让表单回到初始状态，方便用户进行下一次注册或避免重复提交。
Web 应用中需要清空用户界面的特定部分：在一些复杂的 Web 应用程序中，可能需要在特定操作完成后，清空或重置用户界面的某个特定区域，而不是整个页面。在这种情况下，服务器可以返回 205 来指示客户端进行此操作。

206 Partial Content

部分内容。

服务器成功处理了部分GET请求

断点续传（Resuming Interrupted Downloads）：当文件下载中断时，客户端可以从上次中断的地方继续下载，而不是从头开始。
流媒体（Streaming Media）：播放器可以只下载视频或音频文件中正在播放的部分，而不是整个文件。
大型文件预览：客户端可能只想预览一个大型文件的前几KB，而不是下载整个文件。

207 Multi-Status

多状态

成功处理了多资源请求，但响应体中包含了多个独立的状态码，每个状态码对应请求中一个子资源或操作的结果。

PROPFIND 请求：客户端请求一个目录及其子目录中所有文件的属性（例如大小、创建日期、修改日期等）。服务器会返回 207 状态码，响应体中包含一个 XML 结构，列出每个文件的 URI，以及每个文件获取属性的状态（例如，某个文件成功返回了属性，而另一个文件可能因为权限问题而返回 403 Forbidden）。
PROPPATCH 请求：客户端尝试批量修改多个资源的属性。服务器返回 207，XML 响应体中显示每个属性修改操作的成功或失败状态。
其他 WebDAV 批量操作：任何允许对多个资源进行操作的 WebDAV 方法都可能返回 207。

208 Already Reported

已报告

已经处理了 DAV (Distributed Authoring and Versioning) 绑定中的成员，并且在之前的响应中包含了这些成员的状态。

主要用于 WebDAV。

避免循环引用报告：如果一个集合（目录）A 包含一个指向集合 B 的资源，而集合 B 又包含一个指向集合 A 的资源（形成一个循环），那么在 PROPFIND 操作中，服务器可能会无限地报告这些循环。208 状态码允许服务器在首次报告某个资源的状态后，如果再次遇到该资源，就返回 208，表示其状态已经在响应的某个更早部分中报告过了。
避免重复报告：当 PROPFIND 请求的深度超过 1 时，或者在处理共享或链接资源时，一个资源可能会在响应中出现多次。208 状态码指示该资源的具体状态已在响应的先前部分中提供，因此无需再次详细列出。

226 IM Used

IM 已使用

成功处理了请求，响应包含了资源的所有或部分实例操作 (Instance Manipulations) 的结果。

允许客户端请求资源的增量更新 (Delta Encoding)，而不是每次都下载完整的资源。

客户端请求增量更新： 客户端在 GET 请求中使用了特定的请求头（如 A-IM，它列出了客户端支持的实例操作，如“diff”、“vcdiff”等），表明它希望获取资源的增量更新。
服务器支持增量编码： 服务器支持客户端请求的增量编码方法。
服务器成功生成并发送了增量响应： 服务器成功计算出资源的“变化部分”，并将其作为响应发送给客户端。这个响应可能不是完整的资源，而是一个描述如何从旧版本构建新版本的“补丁”文件。

注意：226 状态码来自RFC (RFC 3229，发布于 2002 年)，208 状态码来自RFC (RFC 5842，发布于 2010 年)，226比上面的208还要早。

3xx

重定向。

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

300 Multiple Choices

多种选择。

请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择

内容协商（Content Negotiation）：当一个资源可以用多种语言、多种格式（例如，HTML、JSON、XML）或多种编码（例如，gzip、deflate）提供时，并且客户端在请求中没有通过 Accept、Accept-Language 或 Accept-Encoding 等头部字段明确指出其偏好，服务器就会返回 300 状态码。它会列出所有可用的选项，让客户端或用户来决定选择哪个。
- 示例：一个文档既有英文版也有中文版，或者既有 PDF 版也有 HTML 版。如果客户端没有明确要求某个版本，服务器就可能返回 300。
资源存在于多个位置：在某些情况下，一个逻辑资源可能在服务器上实际存储于多个不同的物理位置。服务器可能会返回 300 状态码，列出这些位置，让客户端选择一个。
处理不明确的 URL：如果一个 URL 可能指向多个不同的资源（例如，一个目录没有默认索引文件，但包含了多个文件，且这些文件都可能是用户想访问的），服务器可能会返回 300。

当服务器返回 300 状态码时，它会在响应中包含以下信息：

Location 头部字段（可选）：通常会包含一个 URI，指示服务器的首选选择。如果服务器有一个明确的首选，它会放在这里。
响应实体（Entity Body）：通常包含一个列表，列出所有可用的资源表示形式的 URI 和相关元数据（例如，每个表示形式的类型、大小、语言等）。这个列表可以是 HTML 页面、XML、JSON 或其他格式，以便客户端能够解析并向用户展示选项。

301 Moved Permanently

永久移动。

请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替。

主要特点：

永久性：明确指示资源已经永久改变了位置。
搜索引擎优化 (SEO) 影响：这是 301 最重要的一个特点。搜索引擎（如 Google）会将旧 URL 的“链接权重”或“排名信号”（也称“SEO 价值”或“Link Equity”）传递给新的 URL。这意味着，如果你的一个页面因为 URL 改变而使用了 301 重定向，它在搜索引擎中的排名通常会保持或大部分转移到新页面。
浏览器缓存：浏览器通常会缓存 301 重定向。这意味着一旦浏览器访问了旧 URL 并收到了 301 响应，它就会记住这个重定向，并在后续请求中直接访问新 URL，而不再去请求旧 URL。这提高了访问速度，但也意味着如果你想撤销一个 301 重定向，可能会因为客户端缓存而导致一些问题。
请求方法：对于 GET 或 HEAD 请求，客户端在重定向后仍会使用 GET 方法。但如果原始请求是 POST 方法，HTTP/1.1 标准允许客户端在重定向后将方法改为 GET，这可能导致一些问题。为了避免这种情况，可以考虑使用 308 Permanent Redirect。

常见使用场景：

网站结构调整：改变页面 URL、目录结构或文件名。
域名迁移：将整个网站从一个域名迁移到另一个域名（例如 old-domain.com 迁移到 new-domain.com）。
HTTP 到 HTTPS 迁移：将网站从不安全的 HTTP 版本重定向到安全的 HTTPS 版本。
合并重复内容：将多个相似内容的页面重定向到权威页面，解决重复内容问题。
修正拼写错误或过期链接：纠正旧的、错误的 URL，将流量引导到正确的页面。

302 Found

临时移动。

与301类似。但资源只是临时被移动。客户端应继续使用原有URI。

主要特点：

临时性：明确指示资源只是暂时改变了位置。
搜索引擎优化 (SEO) 影响：传统上，302 重定向不会传递旧 URL 的链接权重到新 URL。这意味着搜索引擎会继续索引和排名原始 URL，而不是重定向到的新 URL。然而，值得注意的是，Google 已经表示，如果 302 重定向长时间存在，它可能会将其视为 301 重定向，并传递链接权重。但为了确保 SEO 效果，最好还是根据实际情况选择 301 或 302。
浏览器缓存：浏览器通常不会缓存 302 重定向，或者只会进行短期缓存。这意味着每次访问旧 URL 时，浏览器都会重新向服务器发送请求，以检查资源是否已回到原始位置。
请求方法：与 301 类似，如果原始请求是 POST 方法，客户端在重定向后可能会将方法改为 GET。为了避免方法改变，可以考虑使用 307 Temporary Redirect。

常见使用场景：

网站维护或更新：当某个页面暂时下线进行维护或内容更新时，将其重定向到临时页面或通知页面。
A/B 测试：将部分用户临时重定向到测试页面，而不影响原始页面的 SEO 排名。
促销活动或限时优惠：为了某个短期的活动，将用户重定向到特定的活动页面。
用户登录或表单提交后的重定向：例如，用户尝试访问一个需要登录的页面，被临时重定向到登录页面，登录成功后再重定向回原页面。

303 See Other

查看其它地址。

成功处理了请求，但客户端应该通过 GET 方法重定向到另一个 URI 来获取请求的最终响应。

这意味着原始请求的资源实际上并没有改变位置，而是服务器希望你通过一个新的 URL 来获取结果。

POST 请求后的重定向：这是 303 状态码最主要且推荐的使用场景，旨在解决 “POST/Redirect/GET” 模式（也称为 PRG 模式）。
- 当用户提交一个表单（通常是 POST 请求）来执行某个操作（例如，创建订单、发布评论），服务器处理完这个 POST 请求后，不直接返回操作结果页面。
- 相反，服务器会返回一个 303 状态码，并在 Location 头部中包含一个新的 URL（通常是显示操作结果或新创建资源的页面）。
- 客户端浏览器收到 303 后，会立即向这个新的 URL 发送一个 GET 请求。
- 为什么这样做？
  1. 防止表单重复提交（F5 问题）：如果没有 303 重定向，用户在 POST 请求后刷新页面（按 F5）可能会导致表单数据被再次提交，造成重复订单或重复发布。通过 PRG 模式，用户刷新的是 GET 请求的结果页面，而不是 POST 请求，从而避免了重复提交。
  2. 改善用户体验：用户的浏览器地址栏会显示最终的 GET 请求 URL，而不是原始的 POST 请求 URL，这使得用户可以更方便地收藏或分享结果页面。
  3. 遵循 HTTP 语义：POST 请求的目的是提交数据并引起副作用，而获取数据应该使用 GET 请求。303 状态码强制客户端使用 GET 获取最终结果，符合 RESTful 设计原则。
非 POST 请求的其他用途：虽然 303 主要用于 POST 请求，但它也可以用于其他请求方法。例如，服务器可能在收到一个 GET 请求后，发现原始资源不可直接访问，但有一个相关的资源可以通过 GET 请求来查看，这时也可以返回 303。

304 Not Modified

未修改。

所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源。

304 状态码通常发生在客户端发起条件请求（Conditional Request）时。客户端在请求中包含特定的头部字段，询问服务器资源是否在某个时间点之后被修改，或者是否与某个特定版本相匹配。

305 Use Proxy

使用代理。

已经被 HTTP/1.1 规范弃用，所请求的资源必须通过代理访问。

在某些受控的网络环境（例如企业内部网络）中，可能要求所有对特定资源的访问都必须通过一个指定的代理服务器，以实现安全审计、内容过滤或缓存。服务器返回 305 并指定代理地址，强制客户端遵守。

306 Unused

Switch Proxy

在 HTTP/1.1 规范中被标记为 "Switch Proxy"，但后来在 RFC 7231 (HTTP/1.1 Semantics and Content) 中被明确指出不再使用，并且客户端或服务器都不应该发送这个状态码。

306 状态码的设想是作为一种机制，让服务器告诉客户端它应该切换到另一个代理服务器。

指示客户端在未来的请求中切换到 Location 头部中指定的新代理。这与 305 "Use Proxy" 有些相似，但 306 更多的是指在已经使用代理的情况下，切换到不同的代理。

307 Temporary Redirect

临时重定向。

与302类似。但要求使用相同的请求方法重定向，如 post 提交。

POST 请求的临时重定向：这是 307 的核心用途。当原始请求是 POST 方法时，服务器希望客户端重定向到新的 URL，并且在重定向后的请求中仍然保持使用 POST 方法。
- 示例：客户端向一个 URL 发送 POST 请求，但该服务暂时迁移到了另一个 URL。服务器返回 307，Location 头部指向新 URL。客户端收到 307 后，会向新 URL 发送一个带有相同请求体的 POST 请求。
- 对比 302：在 HTTP/1.0 中，客户端收到 302 重定向后，可能会将 POST 请求意外地改变为 GET 请求。虽然 HTTP/1.1 规范试图纠正这一点，但由于历史实现的原因，许多浏览器在遇到 302 时仍然会将 POST 变为 GET。307 的引入就是为了明确解决这个问题，确保请求方法的严格不变性。
临时服务转移：当某个服务或资源需要临时从一个 URL 转移到另一个 URL，并且你希望客户端（特别是那些不应该改变请求方法的客户端）能够精确地跟随这个重定向时，可以使用 307。
特定表单提交流程：在某些复杂的 Web 应用流程中，可能需要在多个服务器之间转发 POST 请求的数据，而不想让数据在中间变成 GET 请求的参数。

308 Permanent Redirect

永久重定向

与301类似。但要求使用相同的请求方法重定向，如 post 提交。

永久性 API 端点迁移：如果一个 API 端点需要永久迁移到新的 URL，并且你希望客户端（特别是那些发送 POST、PUT、DELETE 等请求的客户端）在重定向后仍然使用原始的 HTTP 方法，那么 308 是最佳选择。
- 示例：你的旧 API 地址 /api/v1/users 永久迁移到 /api/v2/users。如果客户端对 /api/v1/users 发送了一个 POST 请求，服务器返回 308。客户端收到 308 后，会向 /api/v2/users 发送一个相同请求体和方法的 POST 请求。
确保 POST 请求的幂等性：在某些设计中，如果 POST 请求需要被重定向，但又不希望它被转换为 GET 请求（这会改变语义并可能导致问题），308 提供了明确的保障。
HTTP 到 HTTPS 的强制重定向：虽然 301 也可以用于将 HTTP 流量永久重定向到 HTTPS，但 308 在理论上提供了更严格的方法保持性，尤其对于非 GET 请求。然而，在实践中，由于浏览器对 301 处理 POST 到 GET 的行为已经形成习惯，并且对于 HTTP 到 HTTPS 的初始请求，通常是 GET，所以 301 仍被广泛使用。

4xx

客户端发生错误。

400 Bad Request

错误的请求

客户端请求的语法错误，服务器无法理解

通常用于语法错误、格式不正确或包含无效的参数。

401 Unauthorized

未授权

请求要求用户的身份认证

一般用于用户未登录，或者登录凭证无效和过期。

402 Payment Required

需要付款

保留，将来使用

请求无法完成，因为它需要付款。

403 Forbidden

禁止访问

服务器理解请求客户端的请求，但是拒绝执行此请求

权限不足：
- 登录用户但无权访问：你已经成功登录网站，但尝试访问一个只有管理员或特定用户组才能访问的页面或功能。
- API 密钥/令牌权限不足：你提供了有效的 API 密钥或 OAuth 令牌，但该密钥/令牌不具备访问特定资源或执行特定操作的权限。例如，你的 API 密钥只允许读取数据，但你尝试进行写入操作。
IP 地址限制：服务器配置为只允许来自特定 IP 地址范围的请求。如果你的 IP 不在允许列表内，即使你提供了正确的凭据，也可能收到 403。
目录浏览被禁止：你尝试访问一个服务器上禁止目录列表显示的目录（例如 http://example.com/some/directory/），服务器会返回 403 而不是列出文件。
防火墙或安全规则：服务器或其前面的防火墙/WAF（Web Application Firewall）检测到请求触发了某些安全规则，并主动阻止了请求。
资源只读：你尝试修改一个只读的资源，服务器会拒绝你的写入请求并返回 403。

404 Not Found

未找到

服务器无法根据客户端的请求找到资源（网页）。

URL 拼写错误：这是最常见的原因。用户或开发者在输入 URL 时，不小心打错了字母、数字、斜杠或文件扩展名。
- 例如：你访问 example.com/aboutus，但正确的 URL 应该是 example.com/about-us。
资源已被删除或移动：网站所有者可能已经删除了某个页面、图片或文件，或者将其移动到了新的 URL，但没有设置相应的重定向。
链接已失效（Dead Link）：一个外部网站或内部页面链接到了一个不再存在或已更改的 URL。
域名解析问题但资源路径错误：虽然域名能解析到服务器，但服务器上并没有对应的资源。
用户或爬虫试图访问不存在的路径：有时用户或搜索引擎爬虫会尝试访问一些不存在的默认路径或猜测的路径。
Web 服务器配置错误：虽然不常见，但服务器配置（例如 Nginx 或 Apache 的重写规则）可能错误地导致某些有效请求返回 404。

405 Method Not Allowed

方法不允许

客户端请求中的方法被禁止

客户端请求的 URL 是有效的，但请求中使用的 HTTP 方法（例如 GET、POST、PUT、DELETE 等）不被允许用于该资源。

API 端点限制：最常见的情况是 API 设计中，某个端点只允许特定的 HTTP 方法。
- 示例 1：一个 API 端点 /users 可能允许 GET（获取用户列表）和 POST（创建新用户），但如果你尝试对 /users 发送 DELETE 或 PUT 请求，服务器就可能返回 405。
- 示例 2：一个获取特定用户详情的端点 /users/{id} 可能只允许 GET 方法，如果你尝试对其发送 POST 或 DELETE 请求，就会收到 405。
静态文件服务器：某些 Web 服务器配置为只允许对静态文件进行 GET 和 HEAD 请求。如果你尝试对一个图片文件或 HTML 文件发送 POST、PUT 或 DELETE 请求，就会收到 405。
WebDAV 禁用：如果服务器支持 WebDAV（Web Distributed Authoring and Versioning）但未启用，或者特定资源不支持 WebDAV 方法，尝试使用 PROPFIND、LOCK 等 WebDAV 方法也可能导致 405。
服务器配置错误：尽管不常见，但服务器（如 Apache、Nginx）的配置文件可能错误地限制了某些 URL 允许的 HTTP 方法。

406 Not Acceptable

不可接受

服务器无法根据客户端请求的内容特性完成请求

无法根据客户端请求的 Accept 头部字段（如 Accept、Accept-Charset、Accept-Encoding、Accept-Language）来生成一个可接受的响应。

Accept 头部不匹配（媒体类型）：
- 客户端请求：Accept: application/json (客户端只接受 JSON 格式的数据)。
- 服务器情况：服务器只能提供 text/html 或 application/xml 格式的资源，无法生成 JSON。
- 结果：服务器返回 406。
Accept-Language 头部不匹配（语言）：
- 客户端请求：Accept-Language: fr-CA (客户端只接受加拿大法语)。
- 服务器情况：服务器只有英文或西班牙文版本的资源。
- 结果：服务器返回 406。
Accept-Encoding 头部不匹配（编码）：
- 客户端请求：Accept-Encoding: deflate (客户端只接受 deflate 编码的数据)。
- 服务器情况：服务器只能提供 gzip 编码或未压缩的数据。
- 结果：服务器返回 406。
Accept-Charset 头部不匹配（字符集）：
- 客户端请求：Accept-Charset: UTF-16 (客户端只接受 UTF-16 字符集)。
- 服务器情况：服务器只能提供 UTF-8 字符集。
- 结果：服务器返回 406。

407 Proxy Authentication Required

需要代理身份认证

请求要求代理的身份认证，与401类似，但请求者应当使用代理进行授权

企业内部网络：许多公司或组织使用代理服务器来管理其内部网络流量，进行安全审计、内容过滤或缓存。这些代理服务器通常要求员工在访问外部网络资源之前进行身份认证。
公共 Wi-Fi 网络：一些公共 Wi-Fi 热点可能使用代理服务器，并要求用户通过认证页面或提供凭据才能上网。
受限网络环境：在某些受控环境中，所有出站请求都必须通过一个需要身份验证的代理。

408 Request Time-out

请求超时

服务器等待客户端发送的请求时间过长，超时

客户端网络问题：
- 网络连接不稳定或中断：客户端在发送请求的过程中网络突然断开或非常缓慢，导致请求数据无法在服务器规定的时间内全部送达。
- 客户端在发送数据时停止：例如，客户端在上传大文件时突然崩溃或用户关闭了浏览器。
客户端应用程序问题：
- 客户端程序逻辑错误：应用程序可能在构建请求时出现死循环或延迟，导致无法在规定时间内发送请求的全部数据。
- 低效的客户端实现：某些客户端库或应用程序在处理网络请求时效率低下，无法及时将数据写入网络套接字。
服务器配置：
- 服务器为了避免长时间等待不完整的请求而占用资源，会设置一个超时时间。如果客户端在超时时间内没有完成请求的发送，服务器就会返回 408。
- 这通常是为了保护服务器资源，防止恶意客户端或僵尸连接占用过多连接。
代理服务器问题：如果客户端通过代理服务器发送请求，可能是代理服务器与客户端之间的连接超时，而不是客户端与最终服务器之间的连接超时。

409 Conflict

冲突

服务器完成客户端的PUT请求是可能返回此代码，服务器处理请求时发生了冲突

并发修改冲突：这是 409 最常见的用途，尤其在 RESTful API 中。
- 示例：两个用户同时尝试编辑同一个文档。用户 A 获取了文档，用户 B 也获取了文档。用户 A 修改并保存了文档。当用户 B 也尝试保存他修改过的版本时，服务器发现文档在用户 B 开始编辑后已经被用户 A 改变了。为了避免覆盖用户 A 的更改，服务器会返回 409 冲突，而不是盲目接受用户 B 的请求。
- 为了处理这种情况，API 通常会使用乐观锁机制，例如通过 ETag 或 If-Match 头部来检测冲突。客户端在 PUT 或 DELETE 请求中包含 If-Match 头部，值为它上次获取资源时的 ETag。如果服务器发现资源的当前 ETag 与客户端提供的 If-Match 不匹配，就返回 409。
资源已存在（但特定操作不允许）：你尝试创建一个资源，但该资源（具有相同的唯一标识符）已经存在，并且当前的 API 语义不允许重复创建。
- 示例：你尝试注册一个新用户，但提供的用户名已被占用。如果 API 设计者认为这是一种“冲突”而不是“不可处理的实体”，就可能返回 409。
资源处于错误状态：你尝试对一个资源执行某种操作，但该资源当前的状态不允许该操作。
- 示例：你尝试启动一个已经处于“运行中”状态的虚拟机，或者尝试删除一个正在使用的文件。
版本控制冲突：在分布式版本控制系统（如 Git）的 Web 接口中，尝试提交代码但存在合并冲突时，可能会返回 409。

410 Gone

永久消失

客户端请求的资源已经不存在。与 404 不同，服务器明确知道这个资源曾经存在，但现在已经不存在了，而且将来也不会再存在于这个 URL。

资源被永久删除：网站管理员或内容发布者决定永久删除某个页面、文件、API 端点或用户数据，并且不打算提供替代内容或重定向到其他地方。
- 示例：一个旧的产品页面，由于产品已停产且没有替代品，被明确删除。
清理过期内容：对于有时效性的内容（如过期的新闻稿、已结束的活动页面、旧版本的 API 文档），当它们被永久移除后，可以使用 410。
维护旧的或失效的链接：如果你发现有大量指向已删除资源的旧链接，并且不希望这些链接继续存在或被爬虫尝试访问，返回 410 是一个明确的信号。

411 Length Required

需要长度

服务器无法处理客户端发送的不带Content-Length的请求信息

HTTP/1.1 要求：根据 HTTP/1.1 规范，如果请求包含实体主体（如 POST、PUT 等方法），并且不是分块编码（chunked transfer encoding），则必须包含 Content-Length 头部字段。这是为了让服务器知道何时读取完整个请求体，从而避免无限期等待。
服务器配置：某些服务器或代理为了资源管理和安全性考虑，会严格执行 Content-Length 的要求。如果没有这个头部，服务器就无法预先分配资源或判断请求是否完整。
不规范的客户端实现：某些客户端库、脚本或旧的 HTTP 客户端可能没有正确地设置 Content-Length 头部，尤其是在发送带有请求体的请求时。

412 Precondition Failed

先决条件失败

客户端在请求中设置的一个或多个先决条件没有被服务器满足。

If-Match 头部：客户端发送其上次获取资源时服务器提供的 ETag（实体标签）值。
- 客户端意图：“只有当资源的 ETag 仍然是这个值时，才执行我的 PUT/DELETE 请求。”
- 服务器行为：如果资源的当前 ETag 与客户端提供的 If-Match 不匹配，就表示资源在客户端上次获取后已被其他地方修改过。服务器会返回 412，以避免覆盖他人的更改。
- 常见场景：并发编辑、乐观锁，确保你修改的是你看到的那个版本。
If-None-Match 头部：客户端发送一个或多个 ETag 值。
- 客户端意图：“只有当资源的 ETag 不在这个列表中的任何一个值时，才执行我的 GET 请求。” (常用于避免下载已缓存内容，但如果资源已存在，则用于创建)
- 服务器行为：如果请求中包含 If-None-Match: *（星号表示任何 ETag），而服务器上请求的资源已经存在，服务器就会返回 412，表示资源已存在。
- 常见场景：防止重复创建资源（例如，你尝试创建的资源已存在）。
If-Unmodified-Since 头部：客户端发送一个日期和时间。
- 客户端意图：“只有当资源自这个日期以来没有被修改过时，才执行我的 PUT/DELETE 请求。”
- 服务器行为：如果资源在 If-Unmodified-Since 指定的时间之后被修改过，服务器就返回 412。
- 常见场景：类似于 If-Match，用于时间戳方式的并发控制。
If-Range 头部：当客户端尝试恢复一个中断的下载（范围请求），并且希望只有在文件没有被修改过的情况下才继续下载。
- 客户端意图：“如果文件自上次下载后没有变化，请给我指定范围的数据；否则，给我整个文件。”
- 服务器行为：如果文件已更改，服务器会返回 200 OK (发送整个文件) 或 412 (如果服务器选择拒绝范围请求)。

413 Content Too Large (Request Entity Too Large)

内容过大

由于请求的实体过大，服务器无法处理，因此拒绝请求。为防止客户端的连续请求，服务器可能会关闭连接。如果只是服务器暂时无法处理，则会包含一个Retry-After的响应信息

在 HTTP/1.1 规范中最初是 413 Request Entity Too Large，在 RFC 9110 (HTTP Semantics) 中更新为 413 Content Too Large，语义保持不变。

文件上传大小限制：网站或 API 通常会对用户上传的文件大小设置限制（例如，头像不能超过 2MB，视频不能超过 1GB）。如果用户尝试上传一个超出此限制的文件，服务器就会返回 413。
请求体数据量过大：除了文件上传，POST 或 PUT 请求的 JSON、XML 或其他数据量也可能非常庞大，超出了服务器配置的处理能力。
- 例如，客户端尝试发送一个包含数十万条记录的批量插入请求，其请求体大小可能超过服务器设定的上限。
服务器或代理配置：Web 服务器（如 Nginx、Apache、IIS）和反向代理（如 HAProxy、Cloudflare）都有配置来限制接收请求体的最大大小。这是为了防止拒绝服务攻击（DoS）或资源耗尽。
- client_max_body_size (Nginx)
- LimitRequestBody (Apache)
- maxRequestLength (IIS)
HTTP/2 的帧大小限制：在 HTTP/2 中，数据通过帧传输。如果请求体太大，超出了服务器接受的单个帧或整体有效载荷的限制，也可能导致 413 错误。

414 URI Too Long (Request-URI Too Large)

URI 过长

请求的URI过长（URI通常为网址），服务器无法处理

在 HTTP/1.1 规范中最初是 414 Request-URI Too Long，在 RFC 9110 (HTTP Semantics) 中更新为 414 URI Too Long，语义保持不变。

GET 请求中带有过多或过大的查询参数：
- 示例：客户端尝试通过 GET 请求传递大量数据，将它们编码在 URL 的查询字符串中（例如 ?param1=value1&param2=value2...）。如果这些参数非常多或每个参数的值非常长，URL 就会超出服务器限制。
- 这常见于一些不规范的实践，例如将整个 JSON 对象编码为 URL 参数，或者在 URL 中包含过多的过滤器、ID 列表等。
不正确的重定向循环：在某些情况下，错误的重定向配置（例如，重定向到自身或导致无限循环）可能会导致客户端在每次重定向时不断向 URL 添加额外的路径信息，最终使 URL 变得过长。
客户端恶意攻击或编程错误：恶意客户端可能会尝试发送极长的 URL 来测试服务器的漏洞或引发拒绝服务（DoS）。同样，客户端代码中的错误也可能无意中生成过长的 URL。
Web 服务器或代理的配置限制：
- Web 服务器（如 Nginx、Apache）和反向代理（如 Cloudflare、负载均衡器）都有针对请求行（包括 URI）长度的内部限制。这是为了保护服务器资源，防止恶意请求。
- 例如，Nginx 的 large_client_header_buffers 配置项间接影响请求行的最大长度。

415 Unsupported Media Type

不支持的媒体类型

服务器无法处理请求附带的媒体格式

Content-Type 头部不匹配：这是最常见的原因。
- 示例 1：一个 API 端点只接受 JSON 格式的数据 (Content-Type: application/json)，但客户端却发送了 XML 格式的数据 (Content-Type: application/xml) 或表单数据 (Content-Type: application/x-www-form-urlencoded 或 multipart/form-data)。
- 客户端发送：Content-Type: application/xml
- 服务器期望：application/json
- 结果：服务器返回 415。
缺少 Content-Type 头部：在某些严格的 API 或服务器配置中，如果 POST 或 PUT 请求包含了请求体但没有指定 Content-Type，服务器可能无法确定数据类型而返回 415。
媒体类型不支持的特定编码：虽然不常见，但如果 Content-Type 指定了媒体类型，但其编码方式不被支持，也可能导致 415。
旧版浏览器或客户端问题：某些旧版浏览器或自定义客户端在发送请求时可能没有正确设置 Content-Type 头部。

416 Requested range not satisfiable

范围无法满足

客户端请求的范围无效

请求的范围超出文件大小：这是最常见的情况。客户端请求的范围的起始位置（或结束位置）超出了服务器上文件实际的总大小。
- 示例：一个文件总共有 1000 个字节。客户端请求 Range: bytes=1000-1500。由于文件只有到第 999 个字节，请求从第 1000 个字节开始就超出了文件范围。
起始范围大于结束范围：客户端请求的范围语法不正确，例如 Range: bytes=500-400。
无法满足多个不连续的范围请求：客户端请求了多个不连续的字节范围（例如 Range: bytes=0-99, 500-599），但服务器出于某种原因无法同时满足所有这些范围（尽管这通常会返回 500 级错误或 200 级完整响应）。

417 Expectation Failed

期望失败

服务器无法满足Expect的请求头信息

服务器不支持 Expect: 100-continue：有些旧的或配置不当的服务器/代理可能根本不支持 100-continue 机制，或者没有启用它。当客户端发送带有 Expect: 100-continue 的请求时，这些服务器会直接返回 417。
服务器知道后续会失败：服务器在接收到请求头部时，就已经判断出该请求的后续处理会失败（例如，权限不足、请求体过大等）。在这种情况下，为了节省带宽和资源，服务器会立即返回一个错误（通常是 417），而不是等待客户端发送完整个请求体后再返回错误。
- 例如，客户端尝试向一个只有特定权限才能访问的资源发送一个大文件。服务器在看到 Expect: 100-continue 和认证头部后，如果判断权限不足，就会直接返回 417 或 401/403，而不是等待文件上传完成。

5xx

服务器发生错误

500 Internal Server Error

内部服务器错误

服务器内部错误，无法完成请求（正常来说，500不是你的锅）

501 Not Implemented

未实现

服务器不支持请求的功能，无法完成请求

不支持的 HTTP 方法：
- 自定义或不常见的方法：例如，如果一个客户端发送了一个自定义的 HTTP 方法（比如 PURGE、REPORT 等），而服务器没有实现对这些方法的处理。虽然一些方法在 WebDAV 等扩展中定义，但如果服务器不实现这些扩展，它就会返回 501。
- 不适用的标准方法：尽管 GET、POST、PUT、DELETE 等是标准方法，但如果一个服务器（或某个特定的 API 端点）被设计为不支持某些方法，它就会返回 501。例如，一个纯粹的数据读取 API 可能只支持 GET，如果你尝试发送 PUT 或 DELETE，它就可能返回 501。
功能未实现：
- 请求中的某些特定功能或协议扩展是服务器无法理解或处理的。
开发阶段的 API 端点：在 API 开发过程中，某个端点可能已经定义了路径，但后端处理逻辑尚未完全实现。此时，如果请求到达该端点，服务器可能被配置为返回 501。

502 Bad Gateway

错误网关

作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应。

后端服务器宕机或无响应：这是最常见的原因。作为网关的服务器尝试连接到上游的（真正的）应用服务器，但该应用服务器已崩溃、正在重启、负载过高而无法响应，或者根本没有运行。
后端服务器返回无效响应：上游服务器可能返回了 HTTP 协议不兼容或格式错误的响应，导致网关无法解析。
防火墙或网络问题：网关服务器与上游服务器之间的网络连接可能被防火墙阻止，或者存在其他网络故障。
DNS 解析问题：网关服务器无法解析后端服务器的域名。
代理服务器配置错误：网关或代理服务器的配置可能不正确，导致它无法正确地将请求转发到后端服务器。
后端服务器超时：后端服务器在处理请求时超时，而网关在等待后端响应时也达到了自己的超时限制。这可能导致网关返回 502。
连接池耗尽：在某些情况下，后端服务器的连接池可能已满，导致无法接受新的连接。

503 Service Unavailable

服务不可用

由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中

服务器过载 (Overload)：服务器处理的请求数量超出了其容量限制，导致无法响应新的请求。这可能是由于流量激增、资源（CPU、内存、网络带宽）耗尽或应用程序本身效率低下。
服务器维护 (Maintenance)：服务器正在进行计划内的维护，例如软件更新、系统升级或数据备份。在维护期间，服务可能会暂时关闭或限制访问。
后端服务故障：服务器依赖的某个关键后端服务（例如数据库服务器、缓存服务、认证服务）出现故障或不可用，导致主服务器无法完成请求。
应用程序启动或重启：应用程序可能正在启动、重启或部署新版本，导致在短时间内无法处理请求。
Web 服务器或应用服务器配置问题：虽然不太常见，但错误的配置可能导致服务器无法正常运行。
负载均衡器/代理问题：如果请求通过负载均衡器或反向代理，它可能无法将请求路由到健康的后端服务器，从而返回 503。

504 Gateway Time-out

网关超时

充当网关或代理的服务器，未及时从远端服务器获取请求

与502不同，502是上游服务器“说话”了，但它说的是“胡话”或者半句话，导致网关无法正常理解和处理。

而504是直接“哑巴”了。

后端服务器响应缓慢或无响应：这是最常见的原因。作为网关的服务器连接到上游的应用服务器，但该应用服务器处理请求的时间过长，超出了网关设定的等待时间，或者根本没有响应。
后端服务器过载：后端服务器可能因流量激增或资源耗尽而变得响应缓慢，无法在规定时间内处理请求。
数据库查询缓慢：后端应用在执行复杂的数据库查询时耗时过长。
与第三方服务集成延迟：后端应用在等待外部第三方 API 响应时出现延迟。
网络连接问题：网关服务器与上游服务器之间的网络连接可能不稳定或存在高延迟。
代理服务器超时设置过低：作为网关或代理的服务器，其等待后端响应的超时时间设置得太短，不适应后端服务的正常处理时间。
防火墙或网络设备问题：某些网络设备可能在数据传输过程中引入不必要的延迟。

505 HTTP Version Not Supported

HTTP 版本不支持

服务器不支持或拒绝支持客户端请求中使用的 HTTP 协议版本。

客户端使用了过时或未来的 HTTP 版本： 客户端可能正在使用一个非常老的（例如，HTTP/0.9）或者一个服务器尚未支持的实验性 HTTP 版本。
服务器配置错误： 服务器可能被错误地配置为只接受特定的 HTTP 版本，而拒绝了其他有效的版本（比如，服务器可能只接受 HTTP/2，但客户端却用 HTTP/1.1）。
代理或防火墙问题： 有时，中间的代理服务器或防火墙可能会修改请求中的 HTTP 版本，导致服务器无法识别。
恶意请求或误用： 少数情况下，这可能表示有非标准或恶意的请求试图与服务器通信。

506 Variant Also Negotiates

变体协商

服务器在处理一个透明内容协商 (Transparent Content Negotiation) 请求时，发现一个内部服务器错误。

内部配置错误：对请求的透明内容协商导致循环引用。

Apache 中出现 506 状态码的典型场景

# 示例： Apache 配置中启用了 MultiViews
# 这通常在 <Directory> 或 <VirtualHost> 块中
<Directory /var/www/html>
    Options Indexes FollowSymLinks MultiViews
    AllowOverride All
    Require all granted
</Directory>

在 /var/www/html 目录下有以下文件：

document.html
document.txt
document (这是一个没有扩展名的文件，或者是一个目录)

当客户端请求 http://yourdomain.com/document 时，可能发生 506 错误：

Apache 收到请求 document。
由于 MultiViews 已启用，Apache 会尝试查找与 document 匹配的文件变体。
Apache 发现 document.html 和 document.txt。
如果同时存在一个名为 document 的文件（无扩展名）或一个名为 document 的目录，问题就来了。
mod_negotiation 会尝试将 document (无扩展名) 也作为内容的潜在变体进行协商。
如果这个 document 文件（或目录）本身被配置为需要进一步的内容协商，或者 Apache 内部逻辑错误地将它视为一个需要再次进行协商的“协商器”，就会形成一个递归循环。Apache 在尝试为 document 协商最佳变体时，发现 document 本身又是另一个需要协商的“变体”，导致循环无法终止，最终返回 506 错误。

507 Insufficient Storage

存储空间不足

服务器无法存储完成请求所必须的内容。这个状况被认为是临时的。

一般用在WebDAV

上传大文件： 客户端尝试上传一个非常大的文件，超出了服务器的可用磁盘空间。
创建新目录或文件： 在服务器上创建新的目录或文件时，服务器发现没有足够的存储配额或物理空间来完成操作。
修改现有文件： 修改一个文件（例如，增加其内容）导致文件大小超出存储限制。
版本控制操作： 在 WebDAV 的版本控制系统中，创建新的文件版本需要额外的存储空间，如果空间不足，也可能触发 507。
数据库或应用存储： 虽然 507 主要与文件系统存储相关，但如果后端应用程序将数据存储在数据库中，而数据库的存储空间不足，并通过 WebDAV 接口暴露出来，也可能间接导致此错误。

508 Loop Detected

循环检测

在尝试执行请求的过程中，发现自己陷入了一个永无止境的循环，无法得出最终结果。

一般用在WebDAV

文件系统中的符号链接 (Symbolic Links) 循环： 这是最常见的原因。如果服务器的文件系统中有两个或多个目录（或文件）通过符号链接相互引用，形成一个闭环，那么当 WebDAV 客户端尝试递归地遍历这些目录时，服务器就会陷入无限循环。
- 例如： 目录 A 包含一个指向目录 B 的符号链接，而目录 B 又包含一个指向目录 A 的符号链接。当 PROPFIND 请求尝试获取 A 的所有属性（包括其内容 B）时，它会发现 B 又指向 A，从而形成循环。
配置错误导致的内部重定向循环： 虽然不如文件系统链接那样直接，但服务器的 WebDAV 模块或底层文件系统映射配置如果存在错误，导致请求在内部被无限重定向或处理，也可能引发 508。
恶意或错误的客户端请求： 理论上，一个结构异常或设计错误的 WebDAV 请求也可能导致服务器在处理时陷入内部循环，尽管这相对罕见。

509 Bandwidth Limit Exceeded

带宽限制超出

已经达到了其带宽限制或存储空间配额。这不是一个官方的状态码，但是仍被广泛使用。

月度流量超出： 你的网站访问量很大，在计费周期内（通常是一个月）产生的下载流量（带宽）超过了你购买的服务套餐所允许的上限。
存储空间超出： 你的网站文件、数据库或其他数据占用的磁盘空间超出了你的托管账户所允许的上限。
并发连接数超出： 某些主机提供商也可能用类似的错误代码来表示你网站的同时连接数或进程数超出了限制（尽管这不是 509 的标准含义，但实践中可能被用于此目的）。
恶意攻击或异常流量： 如果你的网站遭遇了 DDoS 攻击或大量的非正常访问，也可能导致带宽在短时间内耗尽。