科普文：软件架构Nginx系列之【常见http错误码以及Nginx处理】

概叙

科普文：HTTP1.1协议【1.1、2.0、3.0】-CSDN博客

科普文：软件架构Nginx系列之【Nginx最大连接数配置详解】_nginx 如何设置最大连接数-CSDN博客

科普文：软件架构Nginx系列之【Nginx的超时timeout配置详解】-CSDN博客

科普文：软件架构Nginx系列之【CORS和Nginx跨域配置详解】_nginx cors配置-CSDN博客

前面文章有提到部分HTTP错误码及其Nginx处理，今天这里就做一个汇总。

下面nginx错误码，以上图所示的java web架构模型为参考，Nginx作为入口流量网关。

HTTP错误码

完整的HTTP 1.1规范说明书来自于RFC 2616，HTTP 1.1的状态码被标记为新特性，因为许多浏览器只支持HTTP 1.0。你应只把状态码发送给支持HTTP 1.1的客户端，支持协议版本可以通过调用request.getRequestProtocol来检查。

在RFC2616对HTTP协议做了定义，其对错误码定义分为5大类，依次分为100-199、200-299、300-399、400-499、500-599。具体分类如下：

1. 　　100-199 用于指定客户端应相应的某些动作。
2. 　　200-299 用于表示请求成功。
3. 　　300-399 用于已经移动的文件并且常被包含在定位头信息中指定新的地址信息。
4. 　　400-499 用于指出客户端的错误。
5. 　　500-599 用于支持服务器错误。

而作为错误码，在Nginx的日志中，我们需要关注的是4**(客户端错误)和5**（服务端错误）。

一般客户端错误4**都是请求不合法或者某个指标超过Nginx的默认配置，而服务端错误5**基本都是Nginx代理的上游服务出错。

客户端错误4**

HTTP 400：Bad Request

nginx的400错误比较难查找原因，因为此错误并不是每次都会出现的，另外，出现错误的时候，通常在浏览器和日志里看不到任何有关提示。
经长时间观察和大量试验查明，此乃request header过大所引起，request过大，通常是由于cookie中写入了较大的值所引起。

Nginx日志“ [error] 16613#0: *105 upstream sent too big header while reading response header from upstream, client: 。。。。。。。。。。。。。”
解决办法：在nginx.conf中，将client_header_buffer_size和large_client_header_buffers都调大，可缓解此问题。

client_header_buffer_size

（1）设置用于读取客户端请求头的缓冲区大小

（2）对于大多数请求，1K 字节的缓冲区足够，但若一个请求包括长的 cookies，或者来自 WAP 客户端，它可能不适合在 1K 内

（3）如果一个请求行或一个请求头字段不适合这个缓冲区，那么就会分配更大的缓冲区，由 large_client_header_buffers 指令配置

（4）如果该指令是在服务器层面指定的，可以使用默认服务器的值

（5）语法

client_header_buffer_size size;

（6）默认值

client_header_buffer_size 1k;

（7）位置：http、server

large_client_header_buffers

（1）设置用于读取大型客户端请求头的缓冲区的最大数量和大小

（2）请求行不能超过一个缓冲区的大小，否则 414（请求-URI 太大）错误将返回到客户端

（3）请求头字段也不能超过一个缓冲区的大小，否则 400（错误请求）错误将返回到客户端

（4）缓冲区仅按需分配

（5）默认情况下，缓冲区大小等于 8K 字节

（6）如果在请求处理结束后，连接转换为保持活动状态，则会释放这些缓冲区

（7）如果在服务器级别指定了该指令，则可以使用默认服务器中的值

（8）语法

large_client_header_buffers number size;

（9）默认值

large_client_header_buffers 4 8k;

（10）位置：http、server

详细原因

请求行和请求头可参考：科普文：HTTP1.1协议【1.1、2.0、3.0】-CSDN博客

​

核心代码文件所在路径: src/http/ngx_http_request.c

nginx处理请求行和请求头流程
​

client_header_buffer_size
Syntax: client_header_buffer_size size;
Default: client_header_buffer_size 1k;
Context: http, server
假设client_header_buffer_size的配置为1k，如果(请求行+请求头)的大小如果没超过1k，放行请求。如果(请求行+请求头)的大小如果超过1k，则以large_client_header_buffers配置为准

注意，这里和请求体不同的是，请求体会往文件里放，但请求头不会，不够了再根据其它配置申请更大的内存。毕竟请求头的内容再大也大不到像需要上传文件的请求体一样。最终它的配置其实不会导致什么影响，因为最终如果不够了它会根据 large_client_header_buffers 的配置进行申请分配，因此，我们紧接着就看看 large_client_header_buffers 的配置。

large_client_header_buffers
Syntax: large_client_header_buffers number size;
Default: large_client_header_buffers 4 8k;
Context: http, server
假设large_client_header_buffers的配置为4 8k即 4*8K=32k，则对请求有如下要求

1.请求行(request line)的大小不能超过8k，否则返回414错误
2.请求头(request header)中的每一个头部字段的大小不能超过8k，否则返回400错误（实际是494错误，但nginx统一返回400了）
curl -H "header1=aaa" -H "header2=bbb" -v http://127.0.0.1/，这里的header1=xxx和header2=xxx就是请求头中的头部字段
3.(请求行+请求头)的大小不能超过32k(4 * 8k)

400和414错误复现验证

// nginx.conf
……
server {
 client_header_buffer_size 256;
 large_client_header_buffers 2 512;
 ……
}
……

注意，large_client_header_buffers 第二个参数必须要大于等于 connection_pool_size 这个配置项的大小，我这里默认是 512 ，所以这里只能配置为 512 ；第一个参数也不能设置为 0 ，必须是大于 0 的数字。
注意，这里为了验证，所以设置的比较小。



GET http://127.0.0.1/？bigparams=abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnop
 
User-Agent: PostmanRuntime/7.29.2
Accept: */*
Postman-Token: 328e2a7a-84e9-4622-9c83-2bdeb67ea94a
Host: 127.0.0.1
Accept-Encoding: gzip, deflate, br
Connection: keep-alive


如果我们在日常的应用中出现了 400 或者 414 的报错信息，可以来检查一下这两个的配置是否有问题。


LongHeader 正好 512 个字节，直接报 400 Request Header Or Cookie Too Large 错误。

GET http://127.0.0.1/
 
LongHeader: abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcde
User-Agent: PostmanRuntime/7.29.2
Accept: */*
Postman-Token: 200ad116-daca-4129-81a3-c17039021865
Host: 127.0.0.1
Accept-Encoding: gzip, deflate, br
Connection: keep-alive


这个请求，正好卡在报错的长度节点上，会返回 414 Request-URI Too Large 错误。
GET http://127.0.0.1/?bigparams=abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqr

HTTP 401：Unauthorized

• 情景：客户端请求需要认证的资源，但是未提供有效的认证信息或者认证失败。
• 解决方案：客户端需要提供有效的认证信息，或者重新登录获取访问权限。
•  401 Unauthorized --> 权限认证机制、Cookie、Token --> 请求没有经过'授权'

Nginx作为web服务器时，不可能产生401错误，很少在Nginx上配置客户端认证信息。一般都是基于后端业务。

例如：在前后端分离场景下，访问后端api，需要确保在请求头中包含了正确的 Authorization 字段，格式通常是 Authorization: Basic <base64-encoded-username-password> 或者JWT。通过lua脚本验证请求头没有Authorization或者Authorization非法时，才可能会配置一个401的错误响应（一般都是响应200，但是body里面会有无权访问的错误提示信息）。

vim nginx.conf
# 注释这两行
	                # auth_basic "auth needed";
                   # auth_basic_user_file /opt/project/nginx/conf/passwd.conf;

以Woocommerce Rest API为例，Woocommerce是一款基于WordPress的电子商务插件，它提供了一套REST API，用于与Woocommerce商店进行交互。NGINX是一款高性能的Web服务器和反向代理服务器，常用于部署和管理Web应用程序。

使用Woocommerce Rest API时出现的401错误。401错误表示未经授权，即请求缺乏有效的身份验证凭据。

如果出现401错误，可能是由于以下原因：

1. 未提供有效的身份验证凭据：在使用Woocommerce Rest API时，需要提供有效的身份验证凭据，例如API密钥或OAuth令牌。请确保在请求中包含正确的身份验证凭据。
2. 身份验证凭据无效或过期：如果提供的身份验证凭据无效或已过期，服务器将返回401错误。请确保使用有效的凭据，并在必要时更新凭据。
3. 访问权限限制：Woocommerce Rest API可以配置访问权限，限制某些API端点的访问。如果请求的API端点受到访问限制，服务器将返回401错误。请确保请求的API端点在访问权限范围内。

解决Woocommerce Rest API 401错误的方法包括：

1. 检查身份验证凭据：确保在请求中正确提供有效的API密钥或OAuth令牌。
2. 更新身份验证凭据：如果身份验证凭据已过期或无效，需要更新凭据。在Woocommerce后台或相关的身份验证提供商处生成新的API密钥或OAuth令牌。
3. 检查访问权限配置：确保所请求的API端点在访问权限范围内。可以在Woocommerce后台或相关的配置文件中进行访问权限的配置。

HTTP 402：Payment Required

402状态码是为了将来可能的需求而预留的。

402错误通常不是标准的HTTP状态码，但在某些情况下，特别是在使用Nginx作为反向代理时，它可能代表“Payment Required”（付款要求），这是一个非标准状态码，用于Nginx的商业版本中，当客户端没有提供有效的支付凭证来访问受保护的内容时，可能会返回这个状态码。

解决方法：

1. 确认是否使用了Nginx的商业版本，并且是否有相关的授权和支付设置。

2. 如果是商业版本，确保客户端在请求时提供了正确的支付凭证。

3. 如果不需要支付凭证，考虑是否配置了错误的授权或支付流程，检查Nginx配置文件，确保支付相关的配置是正确的。

4. 查看Nginx的访问日志和错误日志，以获取更多关于402错误产生原因的信息。

5. 如果不是商业版本，检查是否有第三方模块或插件引入了自定义的402状态码处理，并进行相应的调整。

6. 如果问题依旧无法解决，考虑联系Nginx官方支持获取帮助。

HTTP 403：Forbidden        

• 情景：客户端请求了服务器上的资源，但是服务器拒绝了访问，通常是由于权限不足或者IP被禁止访问等原因。
• 解决方案：检查服务器配置，确保客户端有权限访问所请求的资源。

 Nginx 403错误表示服务器理解请求客户端的请求，但是拒绝执行这个请求。这通常是因为服务器上的资源的访问权限设置不当。

可能原因及解决方法：

1. 文件权限问题：

   • 检查nginx配置文件中指向的文件或目录的权限，确保nginx用户（通常是nginx、www-data或http）有足够的权限来访问这些文件或目录。

   • 解决方法：修改文件或目录的权限，使用命令chmod和chown。

2. 配置文件中的错误：

   • 检查nginx配置文件中的location块，确保没有错误的配置，如错误的路径或权限设置。

   • 解决方法：修正配置文件中的错误。

3. SELinux 策略问题：

   • 如果服务器使用SELinux，可能是因为SELinux策略阻止了访问。

   • 解决方法：调整或禁用SELinux的策略，或者为nginx设置正确的上下文类型。

4. index.html或index.php文件缺失：

   • 如果nginx配置文件中设置了index指令，但相应的文件不存在，会导致403错误。

   • 解决方法：确保指定的索引文件存在。

5. 错误的服务器路径配置：

   • 如果在nginx配置文件中为站点配置了错误的根路径（root），会导致无法找到文件。

   • 解决方法：修正配置文件中的路径。

6. 访问控制：

   • 如果nginx配置文件中使用了allow和deny指令，可能是这些指令导致了403错误。

   • 解决方法：检查并调整这些指令。

7. 错误的错误页面文件：

   • 如果在nginx配置文件中设置了自定义的错误页面，但页面文件不存在或路径错误，会导致403错误。

   • 解决方法：修正错误页面的配置或确保文件存在。

常用的检查步骤：

1. 检查文件权限：ls -l /path/to/your/files。

2. 检查nginx配置文件的语法是否正确：nginx -t。

3. 查看nginx错误日志：通常位于/var/log/nginx/error.log，可以提供更多错误信息。

4. 根据错误日志的详细信息进行相应的解决。

如果以上步骤无法解决问题，可能需要进一步检查服务器的安全策略和网络配置。

HTTP 404：Not Found

• 情景：客户端请求的资源不存在，可能是由于URL错误或者资源被删除。
• 解决方案：确保URL路径正确，并且资源存在于服务器上。

Nginx 报 404 错误通常意味着所请求的资源在服务器上不存在。这可能是因为资源已被删除、URL 输入错误，或者服务器配置问题。

解决方法：

1. 检查 URL 是否正确输入，没有拼写错误。

2. 确认文件或目录是否存在于服务器上指定的路径。

3. 检查 Nginx 配置文件（通常是 nginx.conf 和任何 server 块配置），确保 root 指令指向正确的文件夹，且 location 块中的正则表达式或路径匹配请求的 URL。

4. 如果使用了别名（alias），确保别名的路径是正确的。

5. 检查文件权限，确保 Nginx 用户（通常是 nginx 或 www-data）有权限访问请求的文件。

6. 如果配置了重写规则（rewrite rules），检查这些规则是否可能导致 404 错误。

7. 查看 Nginx 错误日志，通常位于 /var/log/nginx/error.log，可能会提供更多关于问题的信息。

8. 如果使用了第三方模块或特殊配置，确保它们正确无误。

如果以上步骤无法解决问题，可能需要进一步调试 Nginx 配置或搜索特定的服务配置问题。

504错误导致的404错误

nginx作为反向代理，代理java服务，但是通过代理访问服务的时候，报了404的错误。

问题引起的原因
原因是nginx后面的服务处理很慢，超过proxy_read_timeout, 此时应该报一个504的错误，也就是返回50x.html 

关键点来了， 50x.html文件不存在，此时就返回404了。

解决方法：

proxy_connect_timeout 90; 
后端服务器连接的超时时间_发起握手等候响应超时时间
proxy_read_timeout 180;
连接成功后_等候后端服务器响应时间_其实已经进入后端的排队之中等候处理（也可以说是后端服务器处理请求的时间）
proxy_send_timeout 180;
后端服务器数据回传时间_就是在规定时间之内后端服务器必须传完所有的数据

5**错误导致的404错误

现象和原因同504.

HTTP 405： Method Not Allowed

HTTP 状态码 405 表示客户端发送了不被允许的方法（HTTP 方法）到服务器，服务器因此拒绝了该请求。以下是关于 HTTP 状态码 405 的分析：405 Method Not Allowed
情景：

1. 当客户端发送了服务器不支持的 HTTP 方法时，服务器会返回 405 状态码。

可能原因：

1. 客户端发送了不被允许的 HTTP 方法，如使用 GET 请求去访问只接受 POST 请求的资源。
2. 服务器配置错误或者限制了某些 HTTP 方法的访问。

常见应用：

1. 当服务器端只支持特定的 HTTP 方法时（如 GET、POST、PUT、DELETE 等），当客户端发送了不支持的方法时会返回 405 状态码。
2. Web 应用程序中，如果某个 URL 路径只支持 POST 请求提交表单，当客户端使用其他方法（如 GET）提交表单时可能会收到 405 状态码。

405错误表示方法不被允许。在Nginx中，这通常意味着客户端尝试使用不被服务器配置所允许的HTTP方法进行请求，例如使用了PUT或DELETE方法，但服务器配置只允许GET和HEAD。

解决方法：

1. 检查客户端请求的HTTP方法是否正确。如果不是，更改请求方法以匹配服务器配置。

2. 检查Nginx配置文件中的location块，确保对应的路径允许使用客户端尝试使用的方法。例如，如果你希望允许PUT和DELETE方法，可以在location块中添加allow指令。

3. 如果你正在使用第三方应用程序或API，确保它们是最新的，并且支持你正在尝试使用的HTTP方法。

4. 如果你正在使用RESTful API，确保客户端和服务器遵循相同的API规范，比如使用正确的HTTP头部（如Accept, Content-Type）。

5. 如果你不是服务器管理员，可能需要联系管理员来进行配置更改。

示例配置：

location / {
    # 允许的方法
    allow  GET POST PUT DELETE;
    # 其他配置
}

HTTP 406：Not Acceptable Fielding

406 Not Acceptable是一个HTTP响应状态码，指示服务器无法实现客户端的一个 Accept-标头的请求响应。这通常是用户代理（即浏览器）指定一个可接受的字符集（通过Accept-Charset）、语言（通过Accept-Language）等应响应的结果，并且服务器无法提供此类响应。

与大多数 HTTP 响应代码一样 — 尤其是那些指示错误的响应代码 — 406 Not Acceptable 错误代码的原因可能难以跟踪和修复。具有 50 多个状态代码的潜在池，这些代码表示客户端、Web 应用程序、Web 服务器以及通常有多个第三方 Web 服务之间的复杂关系，这导致了在最佳情况下，确定特定状态代码的原因可能是一项挑战。
 

诊断一个406 Not Acceptable 错误
如简介中所述，406 Not Acceptable 表示用户代理（在大多数情况下是 Web 浏览器）请求了有效的资源，但请求包含一个特殊的 Accept- 标头，该标头向服务器指示有效响应只能包含特定类型的信息。下面是此类场景的几个栗子：

1. 用户代理可能本地化为服务器无法提供的特定区域设置或语言。例如，用户代理可以使用 Accept-Language 请求标头来指定有效的法语语言（Accept-Language:fr），但如果服务器无法使用法语提供响应，则 406 代码可能是唯一正确的响应。
2. 用户代理可能请求服务器返回特定类型的内容。这些内容类型通常称为 MIME 类型，用于定义如纯文本（text/plain）、PNG 图像（image/png）、mp4 视频（video/mp4）等内容。因此，客户端可以在请求中包含 Accept 标头，并定义应由服务器提供的显式 MIME 类型（例如，Accept:application/xml）。如果服务器无法响应请求的匹配内容类型，则可能需要 406 Not Acceptable 响应。

在 HTTP 请求中可以提供少量其他 Accept- 标头，但绝大多数场景与上述类似：用户代理需要显式类型的响应，服务器要么提供响应，要么返回 406 代码以指示它无法实现请求。

客户端故障排除

既然 406 Not Acceptable 是客户端错误响应代码，因此最好首先排除可能导致此错误的任何潜在客户端问题。下面是一些提示，用于在出现问题的浏览器或设备上尝试下。

检查请求的URL
406 Not Acceptable 的最常见原因是仅仅输入了不正确的 URL。许多服务器都受到严密保护，因此不允许对客户端/用户代理不应访问的资源发出意外请求。可能是请求的 URL 稍有错误，从而导致用户代理请求特定类型的响应。例如，对 URI  https://airbrake.io?json 的请求可能会向服务器指示需要 JSON 响应。由于 406 代码不如 404 代码常见，因此 406 的出现可能意味着请求的 URL 有效，但浏览器可能会误解预期的请求类型。无论采用哪种方式，仔细检查返回 406 Not Acceptable 错误的确切 URL以确保它是预期资源是一个好主意。

调试通用平台
如果你在得到 406 Not Acceptable 响应的服务器上运行常见软件包，则可能需要首先查看这些平台的稳定性和功能。最常见的内容管理系统——如 WordPress、Joomla！和 Drupal——通常都是经过精心测试的，但一旦您开始对基础扩展或 PHP 代码（这个语言几乎用在所有现代内容管理系统）进行了修改，将很容易导致不可预见的问题，进而导致 406 Not Acceptable 错误。

下面有几个提示，旨在帮助您解决这些流行的软件平台故障。

回滚最近升级
如果您最近刚好在 406 Not Acceptable 错误出现之前更新了内容管理系统本身，您可能需要考虑回滚到在工作正常时安装的早期版本。同样，您最近升级的任何扩展或模块也可能导致服务器端问题，因此还原到这些扩展或模块的早期版本也可能有所帮助。要获得此任务的帮助，只需使用搜索"降级 [平台名称]"然后跟进即可。然鹅，在某些情况下，某些 CMSs 并不真正提供版本降级功能，这表明他们认为基本应用程序以及发布的每个新版本都极其稳定且无错误。对于较流行的平台，典型情况就是如此，所以如果您找不到将平台还原到旧版本的简单方法，请不要害怕。

卸载新扩展、模块或插件
根据您的应用程序使用的特定内容管理系统，这些组件的确切名称将有所不同，但它们在每个系统中都具有相同的用途：改进平台的功能和特性，使其超出其通常的预期。但请注意：这些扩展或多或少可以完全控制系统，并几乎可以进行任何更改，无论是对 PHP 代码、HTML、CSS、JavaScript 还是数据库。因此，卸载最近可能添加的任何新扩展可能是明智的。再说一次，通过搜索这些扩展的名称以获取这个进程的官方文档和协助。

检查意外的数据库更改
值得注意的是，即使您通过 CMS 仪表板卸载了扩展，也不保证该扩展所做的更改已完全还原。对于许多 WordPress 扩展来说尤其如此，这些扩展在应用程序中提供全权委托，包括数据库的完全访问权限。除非扩展作者在代码中显式编码此类内容，否则在某些场景下，扩展可能会修改不"属于"扩展本身，而是由其他扩展（甚至基本 CMS 本身）创建和管理的数据库记录。在这些情况下，扩展可能不知道如何还原对数据库记录的更改，因此在卸载期间将忽略此类内容。诊断此类问题可能比较棘手，但我本人多次遇到此类情况，因此，假设您有理由相信扩展可能是 406 Not Acceptable 的罪魁祸首，因此，您的最佳操作方案是打开数据库，手动查看可能由扩展修改的表和记录。

最重要的是，不要害怕搜索你的问题。尝试搜索与您的问题相关的特定术语，例如应用程序的 CMS 名称随同 406 Not Acceptable。你很有可能会找到经历过同样问题的人。

服务器端的故障排除

如果您未运行 CMS 应用程序——或者即使您运行了 CMS 应用程序，但您确信 406 Not Acceptable 与该应用程序无关——下面是一些其他提示，可帮助您解决在服务器端可能导致的此类问题。

确认您的服务器配置
您的应用程序可能在使用两个最流行的 Web 服务器软件之一 Apache 或 nginx 的服务器上运行。在发布时，这两个网络服务器软件占了世界上所有网络服务器软件的 84%！因此，您可以采取的第一步，以确定是什么可能导致这些 406 Not Acceptable 响应代码是检查您的 Web 服务器软件的配置文件是否无意的重定向或请求处理指令。

要确定您的应用程序正在使用哪个Web 服务器，您需要查找一个密钥文件。如果您的 Web 服务器是 Apache，则在网站文件系统的根目录中查找 .htaccess 文件。例如，如果您的应用程序位于共享主机上，则可能具有与托管帐户关联的用户名。在这种情况下，应用程序根目录通常位于 /home//public_html/的路径上，因此 .htaccess 文件将在 /home//public_html/.htaccess 处。

如果找到 .htaccess 文件，然后在文本编辑器中打开该文件，并查找使用 RewriteXXX 指令的行，这些指令是 Apache 中mod_rewrite模块的一部分。但是，涵盖这些规则如何工作完全超出了本文的范围，但基本概念是，RewriteCond 指令定义了一个基于文本的模式，该模式将与输入的 URL 匹配。如果站点的访问者请求了匹配的 URL，则遵循一个或多个 RewriteCond 指令的 RewriteRule 指令用于执行请求到相应 URL 的实际重定向。

例如，下面是一个简单的RewriteRule，它匹配所有传入中不包含Accept:application/json 标头的请求到https://airbrake.io/users/json。结果是重定向和 406 Not Acceptable 的响应错误代码：

RewriteEngine on
RewriteCond %{REQUEST_URI} ^/users/json/?.*$
RewriteCond %{HTTP_ACCEPT} !application/json
RewriteRule ^(.*)$ http://airbrake.io/users/json$1 [R=406,L]

请注意RewriteRule末尾的 R=406 标志，该标志明确声明响应代码应为 406，向用户代理指示资源存在，但无法实现显式 Accept- 标头。因此，如果您在 .htaccess 文件中发现任何看似非我同类的奇怪的 RewriteCond 或 RewriteRule 指令，请尝试暂时注释掉它们（使用 # 字符前缀），然后重新启动 Web 服务器以查看这是否解决了问题。

另一方面，如果您的服务器在 nginx 上运行，则需要查找完全不同的配置文件。默认情况下，此文件名为 nginx.conf，位于几个通用目录之一：/usr/local/nginx/conf、/etc/nginx 或 /usr/local/etc/nginx。找到以后，在文本编辑器中打开 nginx.conf 并查找使用 406 响应代码标志的指令。例如，下面是一个简单的块指令（即一组命名的指令），该指令为airbrake.io配置虚拟服务器，并确保与上述类似，对不包括Accept:application/json 请求标头至  https://airbrake.io/users/json 的请求将会失败，并且返回 406 响应代码：

server {     
    listen 80;    
    listen 443 ssl;        
    server_name airbrake.io;        
    location /users/json 
    {        
        if ($http_accept != application/json) 
        {            
            return 406 https://airbrake.io/users/json$request_uri;        
        }    
    }
}

请查看 nginx.conf 文件，了解包含 406 标志的任何异常指令或行。在重新启动服务器之前注释掉任何异常，以查看问题是否得到解决。

每种不同类型的 Web 服务器的配置选项可能巨大差异，因此，我们将仅列出一些流行的项目，以便为您提供一些资源，具体取决于您的应用程序在哪种类型的服务器上运行：

Apache
Nginx
IIS
Node.js
Apache Tomcat
查看日志
几乎每个 Web 应用程序都会保留某种形式的服务器端日志。应用程序日志通常是应用程序所执行操作的历史记录，例如请求了哪些页面、它连接到哪些服务器、它提供的哪些数据库结果，等等。服务器日志与运行应用程序的实际硬件相关，并且通常会提供有关所有已连接服务的运行状况和状态的详细信息，甚至仅提供服务器本身的详细信息。如果您使用的是 CMS，搜索"日志 平台名称";如果您正在运行自定义应用程序，则使用"日志 编程语言"和"日志 操作系统"来进行搜索，以获取有关查找出现问题相关日志的详细信息。

调试应用程序代码或脚本
如果所有其他操作都失败，可能是应用程序中某些自定义代码中的问题导致了该问题。尝试通过手动调试应用程序以及分析应用程序和服务器日志来诊断问题可能来自何处。理想情况下，将整个应用程序的副本复制到本地开发计算机，并执行分步调试过程，这将允许您重新创建发生 406 Not Acceptable 的确切场景，并在错误发生时查看应用程序代码。
 

批量接口的Post请求状态码为406，如何解决？

批量接口的Post请求状态码为406表示服务器无法根据请求中的内容特性完成请求。这通常是因为服务器无法理解或不支持请求中所包含的内容类型。

要解决这个问题，可以尝试以下几个步骤：

1. 检查请求头中的Content-Type字段：确保请求头中的Content-Type字段正确设置为服务器支持的内容类型。常见的内容类型包括application/json、application/xml、application/x-www-form-urlencoded等。如果Content-Type字段不正确，可以根据服务器要求进行修改。
2. 检查请求体中的数据格式：确保请求体中的数据格式符合服务器要求的格式。例如，如果服务器要求请求体为JSON格式，那么需要确保请求体中的数据是合法的JSON格式。
3. 检查服务器端的接口实现：如果以上步骤都没有问题，那么可能是服务器端接口实现存在问题。可以联系服务器端开发人员或相关团队，共同排查接口实现中可能导致406状态码的问题。

总结起来，解决批量接口的Post请求状态码为406的问题需要确保请求头中的Content-Type字段正确设置，请求体中的数据格式符合服务器要求，并排查服务器端接口实现可能存在的问题。

HTTP 407：Proxy Authentication Required

同HTTP 401，授权问题，只是407是代理授权。一般不会在Nginx中进行配置客户授权信息。

HTTP状态码407错误表示“代理认证请求”（Proxy Authentication Required）。这意味着客户端必须先向代理服务器提供有效的认证信息，才能获取所请求的资源。

解决方法：

1. 如果你是浏览器用户，通常浏览器会弹出一个对话框让你输入代理的用户名和密码。输入正确的认证信息后，就可以继续访问网站。

2. 如果你是服务器管理员，需要检查Nginx配置文件中的代理设置。确保你有正确配置代理服务器的认证信息。例如，你可能需要在nginx.conf文件中的相关location块或者server块中添加以下指令：proxy_set_header Proxy-Authorization "Basic [base64编码的用户名:密码]";

这里的"Basic [base64编码的用户名:密码]"是一个经过Base64编码的字符串，用于提供代理服务器所需的认证信息。

1. 如果你是开发者，并且是在编写代码时遇到这个错误，你需要确保你的HTTP请求中包含了正确的代理认证头部。通常这涉及到计算Base64编码的认证字符串，并在HTTP请求中添加Proxy-Authorization头部。

确保在处理这个问题时，遵循最佳安全实践，不要在配置文件或代码中明文存储敏感信息。

HTTP 408：Request Time-out  

HTTP 408 请求超时错误表明客户端尝试在服务器准备响应之前过长时间等待了。具体来说，这通常意味着 Nginx 服务器设定了一个超时时间，在这个时间内客户端没有完成请求的发送。

408错误是一种常见的网络错误，通常是由于网络连接不稳定或者服务器负载过高导致的。针对这种错误，可以采取一些优化措施，来避免错误的发生，提高网站的稳定性和用户体验。希望能够帮助大家更好地理解和解决408错误。

408错误通常是由于以下几个原因造成的：1、网络连接不稳定，导致请求无法及时到达服务器；2、服务器负载过高，无法及时处理客户端请求；3、客户端发送的请求过于复杂，导致服务器处理时间过长。

针对408错误，可以采取以下几种解决方法：1、优化网络连接，确保请求能够及时到达服务器；2、优化服务器性能，提高服务器的处理能力；3、优化客户端请求，减少请求的复杂度，减少服务器处理时间。

为了避免408错误的发生，可以采取以下几种措施：1、优化网络环境，确保网络连接的稳定性；2、优化服务器性能，提高服务器的处理能力；3、优化网站代码和资源，减少请求的复杂度，提高网站的响应速度。

408错误对网站的影响是非常严重的，一方面会影响用户体验，导致用户无法正常访问网站；另一方面也会影响网站的排名和流量，降低网站的访问量和收益

解决方法：

1. 增加客户端请求的超时时间：

   • 如果你是网站访问者，可以尝试在浏览器设置中增加超时时间。

   • 如果你是网站管理员，可以在服务器配置中调整 Nginx 的超时设置。编辑 Nginx 配置文件（通常是 /etc/nginx/nginx.conf 或者某个特定站点配置文件），找到 keepalive_timeout 指令，并增加其值。

2. 优化服务器性能：

   • 如果服务器负载过高，可以尝试增加资源或优化服务器配置以减少处理请求的时间。

3. 检查网络问题：

   • 有时网络延迟或不稳定可能导致超时，检查网络连接或与服务提供商联系。

4. 检查客户端问题：

   • 如果你是开发者，检查客户端代码，确保请求被正确地发送和接收。

调整配置或解决网络问题后，记得重新加载或重启 Nginx 服务以使更改生效。

HTTP 409：Conflict          

已存在(HTTP 409)错误是指在进行数据操作时，由于冲突或重复导致操作无法完成，服务器返回的状态码为409。

这种错误通常发生在并发操作或多用户同时访问同一资源时。已存在(HTTP 409)错误属于HTTP状态码的一种，表示客户端请求的资源在服务器端已经存在，无法创建或修改。

优势：

1. 提供了明确的错误信息：已存在(HTTP 409)错误告知客户端请求的资源已经存在，避免了客户端进行无效的重复操作。
2. 避免了数据冲突：通过返回409错误，服务器可以确保资源的一致性，避免多个客户端同时对同一资源进行修改而导致的数据冲突。

应用场景：

1. 数据库操作：在进行数据库操作时，如果要插入或更新的数据已经存在，服务器可以返回409错误，提示客户端数据已存在。
2. 文件上传：当用户尝试上传一个已经存在的文件时，服务器可以返回409错误，告知客户端文件已存在。

409错误是HTTP协议中的一种状态码，表示“冲突”(Conflict)。在Nginx中，这个错误通常表示客户端在执行某些需要确保资源状态一致性的操作时（如PUT请求），服务器端的资源状态与客户端所期望的不一致。

解决方法：

1. 检查请求的内容：确保客户端在发送409错误相关的请求时，提供了正确的状态信息或版本控制信息。

2. 检查服务器端状态：确认服务器上的资源状态是否真的与客户端发送的状态冲突，如果是，则需要解决这些冲突。

3. 检查Nginx配置：如果Nginx配置中有相关的状态检查或条件请求处理（如使用if指令），确保这些配置是正确的。

4. 查看Nginx的错误日志：通常Nginx会在错误日志中记录更详细的信息，可以通过错误日志来获取更多线索。

5. 如果是并发控制问题，考虑实现适当的并发控制策略。

如果问题仍然无法解决，可能需要进一步查看Nginx的配置文件和相关的应用程序代码。

HTTP 410：Gone    

     HTTP 410错误表示客户端请求的资源已经不再可用。服务器知道资源已经被删除，并且不会再次提供该资源。这是一个永久性的移除，而不是临时的。

问题解决：

1. 如果资源确实已经不存在，并且没有替代的URL，那么你可以修改Nginx配置，返回一个410状态码，并提供一个说明为什么资源不再可用的页面。

2. 如果资源被移动到了新的URL，你可以配置Nginx使用301重定向，将请求者永久性地重定向到新的URL。

3. 如果资源被移动但是希望保持可以访问，可以使用302临时重定向，但这不是推荐的做法，因为可能会导致搜索引擎等持续使用旧的URL。

配置示例：

server {
    listen 80;
    server_name example.com;
 
    location /old-path {
        # 如果资源被永久移除，使用以下配置
        # return 410;
 
        # 如果资源被移动到了新的URL，使用以下配置
        return 301 http://example.com/new-path;
 
        # 如果资源被移动但希望用户能继续访问，使用以下配置
        # return 302 http://example.com/new-path;
    }
}

根据实际情况选择适当的配置。如果资源被移除，使用410状态码；如果资源被永久移动，使用301；如果资源暂时移动，使用302。

HTTP 411： Length Required  

HTTP 411错误表示服务器不接受不含Content-Length头的客户端发送的请求。这个头部用于告知服务器请求的消息体大小。

引起Nginx报错411的原因：

1. client sent invalid “Content-Length” header

2. client sent … method without “Content-Length” header

3. client sent “Transfer-Encoding: chunked” header

解决方法：

1. 如果你是客户端用户，请检查你的浏览器设置或者尝试使用其他浏览器。

2. 如果你是服务器管理员，请检查你的Nginx配置：

   • 确保客户端请求中包含了Content-Length头部。如果是POST或PUT请求，通常需要这个头部。

   • 如果你正在编写客户端程序，确保在发送请求时添加了Content-Length头部。

   • 如果你正在编写服务器程序，确保服务器能够处理没有Content-Length头部的请求，或者在需要时强制添加。

示例配置调整（Nginx）：

server {
    listen 80;
    server_name your_domain.com;
 
    location / {
        proxy_set_header Content-Length "";  # 强制添加Content-Length头部
        proxy_pass http://backend_server;
    }
}

确保在location块中的proxy_set_header指令正确配置。如果你不希望Nginx添加这个头部，确保你的后端服务器能够处理没有这个头部的请求。

HTTP 412： Precondition Failed  

412错误是HTTP协议中的一种状态码，表示客户端的前置条件失败。

在Nginx中，这通常与请求头中的If-Match、If-Modified-Since、If-None-Match、If-Range、If-Unmodified-Since等条件请求头有关。

412错误通常是由于客户端发送的请求中缺少必要的前提条件，导致服务器无法处理请求。

具体来说，可能是以下原因：

1. 请求头中缺少必要的信息；

2. 请求中缺少必要的参数或参数不正确；

3. 请求的资源不存在或已被删除；

4. 请求的资源已过期或被修改；

5. 请求中包含的条件不满足服务器的要求。

解决方法：

1. 检查请求头中是否缺少必要的信息，如User-Agent、Accept等；

2. 检查请求中是否缺少必要的参数或参数不正确；

3. 检查请求的资源是否存在或已被删除；

4. 检查请求的资源是否已过期或被修改；

5. 检查请求中包含的条件是否满足服务器的要求。

如果你不是服务器管理员或开发人员，你可能需要联系他们来解决这个问题。如果你是管理员或开发人员但不确定如何操作，可以查看Nginx的错误日志文件，它通常会提供更多关于412错误的信息，并可能指向具体的配置问题或代码问题。

HTTP 413：Request Entity Too Large

Nginx 报 413 错误表示请求实体过大（Request Entity Too Large）。这通常发生在客户端尝试上传一个超过服务器配置允许的大小的文件时。

当客户端发送的请求体大小超过Nginx服务器配置的最大请求体大小限制时（默认是1M），Nginx会返回错误码413。这个错误码告诉客户端请求实体太大，超过了服务器的处理能力。

Nginx相关参数

client_max_body_size     50m; //文件大小限制，默认1m
client_header_timeout    1m;
client_body_timeout      1m;
proxy_connect_timeout     60s;
proxy_read_timeout      1m;
proxy_send_timeout      1m;


参数说明
client_max_body_size
限制请求体的大小，若超过所设定的大小，返回413错误。

client_header_timeout
读取请求头的超时时间，若超过所设定的大小，返回408错误。

client_body_timeout
读取请求实体的超时时间，若超过所设定的大小，返回413错误。

proxy_connect_timeout
http请求无法立即被容器(tomcat, netty等)处理，被放在nginx的待处理池中等待被处理。此参数为等待的最长时间，默认为60秒，官方推荐最长不要超过75秒。

proxy_read_timeout
http请求被容器(tomcat, netty等)处理后，nginx会等待处理结果，也就是容器返回的response。此参数即为服务器响应时间，默认60秒。

proxy_send_timeout
http请求被服务器处理完后，把数据传返回给Nginx的用时，默认60秒。


Syntax: client_max_body_size size;
Default:
client_max_body_size 1m;
Context: http, server, location

Sets the maximum allowed size of the client request body, specified in the “Content-Length” request header field.
If the size in a request exceeds the configured value, the 413 (Request Entity Too Large) error is returned to the client.
Please be aware that browsers cannot correctly display this error.
Setting size to 0 disables checking of client request body size.

解决Nginx错误413的方法有两种：

1. 修改Nginx配置文件：可以通过修改Nginx配置文件中的client_max_body_size参数来增大请求体大小限制。该参数用于设置Nginx服务器接收请求体的最大大小。例如，可以将其设置为10M，表示最大接收10MB大小的请求体。修改配置文件后，需要重新加载Nginx配置。
2. 修改应用程序配置：如果Nginx作为反向代理服务器，将请求转发给后端应用程序处理，那么还需要确保后端应用程序的配置也允许接收较大的请求体。具体的配置方法需要根据后端应用程序的类型和框架来确定。

HTTP 414：Request-URI Too Large

Nginx 报 414 Request-URI Too Large 错误表明客户端请求的 URI（统一资源标识符，例如URL）过长，服务器因为 URI 过长而无法处理该请求。

解决方法： 增加 Nginx 配置中的 large_client_header_buffers 指令的大小。打开 Nginx 配置文件（通常是 nginx.conf），在 http 块中添加或修改这一指令

参考HTTP 400

 
​

HTTP 415： Unsupported Media Type  

HTTP 415错误表示Unsupported Media Type，即不支持的媒体类型。

这个错误发生在客户端发送请求到服务器，但是请求的Content-Type头部和服务器能够处理的类型不匹配时。415错误是HTTP状态码中的一种，表示服务器拒绝接受由于媒体类型不受支持而发起的请求。这通常是由于上传的文件的媒体类型与服务器期望的媒体类型不匹配导致的。

解决方法：

1. 检查客户端请求的Content-Type头部是否正确。例如，如果服务器期望接收JSON格式的数据，那么客户端发送请求时必须将Content-Type设置为application/json。

2. 检查服务器端的配置文件（通常是nginx.conf），确保配置了正确的mime.types，并且相应的类型处理器（如mod_php）已经被正确安装和配置。

3. 如果是通过PHP脚本处理请求，确保在脚本开始处加上正确的Content-Type头信息，例如：

   header('Content-Type: application/json');

4. 如果你使用的是第三方应用程序或服务，确保该应用程序或服务正确设置了Content-Type。

5. 如果你正在使用nginx的代理功能，确保代理设置中正确设置了proxy_set_header命令，例如：proxy_set_header Content-Type 'application/json';

6. 如果问题依然存在，可以尝试重启nginx服务，并检查nginx的错误日志文件，通常位于/var/log/nginx/error.log，以获取更多线索。

HTTP 416： Requested range not satisfiable

416 Requested Range Not Satisfiable（RFC 7233） 前称“Requested Range Not Satisfiable”。客户端已经要求文件的一部分（Byte serving），但服务器不能提供该部分。例如，如果客户端要求文件的一部分超出文件尾端。

HTTP 416错误表示客户端（在这种情况下是Nginx）在请求中包含了一个Range头部，但是这个范围无法被服务器满足。这通常发生在客户端请求的资源的一个范围不可用时。

416错误是指在HTTP协议中，客户端发送的请求中包含了一个范围请求头字段（Range header field），而该范围请求头字段指定的范围不符合服务器的要求。这种错误通常出现在下载大文件时，客户端希望只下载文件的一部分，但服务器无法满足请求的范围。

解决方法：

1. 检查客户端发送的Range头部是否正确，确保请求的范围对应于资源的实际大小。

2. 如果资源大小改变，确保服务器端的资源大小与客户端的Range头部匹配。

3. 如果服务器上的资源已经不存在，可能需要更新客户端的请求范围或者确保请求的资源仍然存在。

4. 检查Nginx配置文件中是否有相关的配置导致无法处理范围请求，如sendfile指令或者aio设置。

5. 如果是动态生成的内容，确保服务器端逻辑能正确处理范围请求。

6. 如果不需要范围请求，可以在客户端去掉Range头部后重新发起请求。

在调整配置或代码后，重新测试以确认问题是否解决。

1. 请求范围的含义：HTTP协议中的范围请求头字段（Range header field）用于指定客户端希望获取的资源的范围。该字段的格式为"Range: bytes=start-end"，其中start和end分别表示起始和结束位置的字节偏移量。

2. 错误原因：416错误通常有以下几种可能的原因：

- 客户端请求的范围超出了服务器上资源的实际范围。

- 客户端请求的范围格式不正确，无法被服务器解析。

- 服务器不支持范围请求，无法满足客户端的需求。

3. 可能的解决方案：针对不同的错误原因，可以采取以下解决方案：

- 确保客户端请求的范围在服务器资源的实际范围内，可以通过检查资源的大小来确认范围是否正确。

- 检查客户端请求的范围格式是否正确，确保其符合HTTP协议规范。

- 如果服务器不支持范围请求，可以尝试使用其他方式下载文件，如将文件分割成多个部分进行下载。

处理416错误的方法取决于错误的原因和具体情况。以下是几种常见的处理方法：

1. 检查请求范围：需要检查客户端请求的范围是否超出了服务器资源的实际范围。可以通过查看资源的大小和客户端请求的范围来判断是否超出范围。如果超出范围，可以尝试修改范围，确保其在服务器资源的有效范围内。

2. 检查请求格式：需要检查客户端请求的范围格式是否正确。范围请求头字段的格式应为"Range: bytes=start-end"，其中start和end分别表示起始和结束位置的字节偏移量。如果格式不正确，可以尝试修复格式错误，确保其符合HTTP协议规范。

3. 使用其他下载方式：如果服务器不支持范围请求，可以尝试使用其他下载方式。一种常见的方法是将文件分割成多个部分进行下载，然后在客户端将这些部分合并成完整的文件。

4. 更新服务器配置：如果频繁出现416错误，可以考虑更新服务器的配置。确保服务器支持范围请求，并能够正确处理客户端发送的范围请求头字段。

416错误是由于客户端发送的范围请求不符合服务器要求而导致的错误。通过检查请求范围、请求格式和使用其他下载方式等方法，可以解决和处理416错误。

HTTP 417：Expectation Failed  

417 Expectation Failed 在请求头Expect中指定的预期内容无法被服务器满足，或者这个服务器是一个代理服显的证据证明在当前路由的下一个节点上，Expect的内容无法被满足。

Nginx 报 417 错误通常是指 "Expectation Failed"。这个状态码表示服务器无法满足客户端在请求中设置的期望值。在 HTTP 协议中，客户端可以发送一个 "Expect" 头部来告知服务器期望服务器能够满足某些特定条件。例如，客户端可能期望服务器能够处理 chunked 编码的消息体。如果服务器无法满足这些期望，它会返回 417 错误。

解决方法：

1. 检查客户端请求中的 "Expect" 头部是否合法且服务器是否支持。如果不需要特定的 "Expect" 行为，可以从请求中移除该头部。

2. 如果你是服务器管理员，确保 Nginx 配置正确，并且没有任何限制或条件导致无法满足客户端的期望。

3. 如果你正在使用代理服务器或者负载均衡器，确保它们配置正确，并且没有干扰请求处理的设置。

4. 查看 Nginx 的访问日志和错误日志，以获取更多关于为什么发生 417 错误的信息。

5. 如果你对 Nginx 配置不熟悉，可以查看 Nginx 官方文档或者寻求专业人士的帮助。

在修改配置时，请确保测试配置的正确性，并在对生产环境做出更改前备份关键配置。

HTTP 421 ：There are too many connections from your internet address

Change: the "421 Misdirected Request" response now used when
       rejecting requests to a virtual server different from one negotiated
       during an SSL handshake; this improves interoperability with some
       HTTP/2 clients when using client certificates.

Nginx 报 421 错误  以 Nginx 与邮件服务器通信为例

Nginx 作为反向代理服务器，可能会尝试通过 SMTP 协议转发邮件，如果邮件服务器要求的连接太过单调或者认为是垃圾邮件发送，就可能返回 421 错误。这个错误代表“No SMTP service”，意味着邮件服务器暂时不提供 SMTP 服务。

解决方法：

1. 检查 Nginx 配置文件中的 SMTP 后端设置，确保邮件服务器的地址、端口和认证信息配置正确。

2. 如果邮件服务器要求特定的发件人策略或者身份验证，确保 Nginx 正确地遵守这些要求。

3. 查看邮件服务器的发送策略和限制，确认没有超出发送限额或者被列入黑名单。

4. 如果问题依然存在，可以尝试联系邮件服务提供商了解具体的错误原因和解决方案。

5. 如果 Nginx 配置中使用了邮件缓冲或者邮件代理模块，确保这些模块配置正确，并且没有因为错误配置导致邮件发送失败。

请根据实际情况检查和调整 Nginx 的配置，并参考邮件服务器的文档来解决 421 错误。

Nginx 反代提示421 misdirected request

server {
listen 88;
server_name localhost;
location /api/ {
proxy_pass https://api.zsxq.com/;
proxy_set_header Host api.zsxq.com;
}
}

如上所示，方向代理报错421的状态码。

是什么导致“421 错误定向请求”错误？

客户端需要为此请求建立新连接，因为请求的主机名与用于此连接的服务器名称指示 (SNI) 不匹配。Misdirected Request

当一个 TLS 证书在多个域之间共享时，该证书要么具有通配符名称，例如“*.example.org”，要么带有多个备用名称。使用 HTTP/2 的浏览器会识别这一点，并为此类主机重用已打开的连接。
但是当在同一个 TLS 连接上有多个主机的多个请求时，重新协商就变得不可能了。然后它可能会向客户端触发错误“421 Misdirected Request”。

上面的配置报错也是这种情况。*.zsxq.com使用了通配符的域名证书。nginx 不知道具体要访问哪一个网站，所以需要指定对应的 proxy_ssl_name 。

正确的配置如下，指定ssl_name多个参数：

server {
listen 88;
server_name localhost;
location /api/ {
proxy_ssl_server_name on;
proxy_ssl_name api.zsxq.com;
proxy_ssl_verify off;
proxy_pass https://api.zsxq.com/;
proxy_set_header Host api.zsxq.com;
proxy_set_header Accept-Encoding '';
proxy_set_header Cookie 'xxxx';
}
}

反向代理sub_filter字符替换不生效

通常有以下两种原因：

1. 源站点启用了gzip压缩。
2. 需替换的MIME类型为text/html之外的字符串，比如server端返回json格式的内容，sub_filter是不会进行替换的。

第一种的解决方案如下：

proxy_set_header Accept-Encoding "";

如果增加这行代码后问题依旧存在，大概率是源站点启用了强制gzip压缩。nginx反代替换关键字前并不会自动解压缩，所以无法执行替换内容。

解决思路：
反代2次。第一次反代时增加gzip off;设置项，以输出无压缩的内容，第二次反代本机地址，实现关键字替换。

location /unzip/ {

# 负责解压缩内容

proxy_set_header Host target.com; #目标域名

proxy_pass https://target.com/; #目标域名

}

location / {

proxy_set_header Host my.target.com; #自己的域名

proxy_set_header Accept-Encoding '';

gzip off;

sub_filter_types *; #替换所有类型

sub_filter 'xxxxx' 'xxxxxxx'; #替换内容

sub_filter_once off; #所有匹配到的都替换

proxy_pass http://127.0.0.1/unzip/; #多走一次转发, 让/go先解压缩gzip

}

第二种的解决方案如下：

sub_filter_types *; #替换所有类型

Location 和 proxy_pass 加不加斜杠的区别？

proxy_pass 指令后面的参数有讲究，但在实际的应用中就分为两种情况。

proxy_pass 后面不带路径，就原封不动传给后端。
proxy_pass 后面带路径，就去掉 Location 的匹配再传给后端。

proxy_pass 后面url只有host没有路径

这里指不包含 $uri ，如：

• http://host  ✅
• https://host  ✅
• http://host:port  ✅
• https://host:port  ✅
• http://host/  ❌
• http://host:port/  ❌

这时候 location 匹配的完整路径将直接透传给后端，如：

// 访问： / 后端： /

// 访问： /api/xx 后端： /api/xx

// 访问： /api/xx?aa 后端： /api/xx?aa

location / {

proxy_pass http://node:8080;

}

// 访问： /api/ 后端： /api/

// 访问： /api/xx 后端： /api/xx

// 访问： /api/xx?aa 后端： /api/xx?aa

// 访问： /api-xx?aa 后端：

location /api/ {

proxy_pass http://node:8080;

}

// 访问： /api/ 后端： /api/

// 访问： /api/xx 后端： /api/xx

// 访问： /api/xx?aa 后端： /api/xx?aa

// 访问： /api-xx?aa 后端： /api-xx?aa

location /api {

proxy_pass http://node:8080;

}

proxy_pass 后面的url中带有路径

注意，这里的路径哪怕只是一个 / 也是存在的，如：

• http://host  ❌
• https//host/  ✅
• http://host:port  ❌
• https://host:port/  ✅
• http://host/api  ✅
• http://host/api/  ✅

当 proxy_pass url 的 url 包含路径时，匹配时会根据 location 的匹配后的链接透传给 url ，注意匹配后是下面这样。

location 规则	访问的原始链接	匹配之后的路径
location /	/
location /	/a	a
location /	/a/b/c?d	a/b/c?d
location /a/	/a/
location /a/	/a/b/c?d	b/c?d

// 访问： / 后端： /

// 访问： /api/xx 后端： /api/xx

// 访问： /api/xx?aa 后端： /api/xx?aa

location / {

proxy_pass http://node:8080/;

}

// 访问： /api/ 后端： /

// 访问： /api/xx 后端： /xx

// 访问： /api/xx?aa 后端： /xx?aa

// 访问： /api-xx?aa 未匹配

location /api/ {

proxy_pass http://node:8080/;

}

// 访问： /api 后端： /

// 访问： /api/ 后端： //

// 访问： /api/xx 后端： //xx

// 访问： /api/xx?aa 后端： //xx?aa

// 访问： /api-xx?aa 后端： /-xx?aa

location /api {

proxy_pass http://node:8080/;

}

// 访问： /api/ 后端： /v1

// 访问： /api/xx 后端： /v1xx

// 访问： /api/xx?aa 后端： /v1xx

// 访问： /api-xx?aa 未匹配

location /api/ {

proxy_pass http://node:8080/v1;

}

// 访问： /api/ 后端： /v1/

// 访问： /api/xx 后端： /v1/xx

// 访问： /api/xx?aa 后端： /v1/xx

// 访问： /api-xx?aa 未匹配

location /api/ {

proxy_pass http://node:8080/v1/;

}

可以看出，当 proxy_pass url 中包含路径时，结尾的 / 最好同 location 匹配规则一致。

alias指定返回某个文件

alias使用注意两点：

1. Windows使用绝对路径一定要用反斜杠 \ 。
2. 使用相对路径注意将文件放到默认路径下面，直接指定文件名。

location = /api/v2/groups {

default_type application/json;

alias C:\phpstudy_pro\Extensions\Nginx1.15.11\groups.json;

#alias groups.json; #使用相对路径

}

这里测试发现使用alias默认会拼接路径导致报错。可以通过error.log进行debug。

比如我是用绝对路径，但是注意一定要用 \ ，不然会出现下面的 failed (3: The system cannot find the path specified) 的报错。

root与alias的区别?

root与alias主要区别在于nginx如何解释location后面的uri，这会使两者分别以不同的方式将请求映射到服务器文件上。

root的处理结果是：root路径＋location路径
alias的处理结果是：使用alias路径替换location路径
alias是一个目录别名的定义，root则是最上层目录的定义。

还有一个重要的区别是alias后面必须要用“/”结束，否则会找不到文件的，而root则可有可无。

location ^~ /path/ {

root /www/root/html/;

}

如果一个请求的URI是/path/a.html时，web服务器将会返回服务器上的/www/root/html/path/a.html的文件。

location ^~ /path/ {

alias /www/root/html/new_path/;

}

如果一个请求的URI是/path/a.html时，web服务器将会返回服务器上的/www/root/html/new_path/a.html的文件。注意这里是new_path，因为alias会把location后面配置的路径丢弃掉，把当前匹配到的目录指向到指定的目录。

注意：
1. 使用alias时，目录名后面一定要加”/”。
3. alias在使用正则匹配时，必须捕捉要匹配的内容并在指定的内容处使用。
4. alias只能位于location块中。（root可以不放在location中）

HTTP 499：Expectation Failed  

499 - 客户端关闭请求（Nginx）

被用在Nginx日志去表明一个连接已经被客户端关闭当服务器仍然正在处理它的请求，是的服务器无法返货状态码。

Nginx 报 499 错误通常表示客户端在服务器响应完毕之前关闭了连接。这个错误是 Nginx 特有的，意味着客户端在请求处理过程中主动关闭了连接，导致 Nginx 记录了一个客户端提前终止的请求的日志。

ngx_string(ngx_http_error_495_page), /* 495, https certificate error */
ngx_string(ngx_http_error_496_page), /* 496, https no certificate */
ngx_string(ngx_http_error_497_page), /* 497, http to https */
ngx_string(ngx_http_error_404_page), /* 498, canceled */
ngx_null_string, /* 499, client has closed connection */

499 - 需要令牌（Esri）

由ArcGIS for Server返回。意味着需要一个令牌（如果没有令牌被提交）。

情景：
客户端在接收到服务器响应前关闭了连接，导致服务器记录了 499 错误码。

可能原因：

在上述架构下，客户端发起一个请求大约要经历下面这些阶段

 

499的触发时机

由于499是nginx记录的状态码，所以客户端断开连接的时机是要在nginx接收HTTP请求行，到nginx发送响应这个区间内，所以如果客户端在DNS解析或者TCP建连之前就超时的话是不会触发499的，毕竟请求都没有到达nginx。如果nginx已经开始返回响应了，此时客户端就断开连接的话，不会记录499，会以响应的状态码为准，比如200。

499的影响

上面说过，499代表客户端超时断开了连接，大部分情况下499代表请求失败了，需要根据业务场景评估影响。比如如果客户端有重试逻辑， 499之后重试成功，那么实际上可能不会有很大的影响。

499还有一个比较容易被忽视的影响，由于499代表客户端断开了连接，那么客户端重试的时候意味着会重新建立tcp连接甚至重新tls握手，在一些高并发的场景下，大量的499导致的客户端重试可能会对服务端造成一定的压力，此时我们需要考虑在服务端做一些降级策略，减少499造成的重试压力。

499的原因

客户端发起请求后中断连接，比如在请求未完成前关闭了页面或者网络中断。
负载均衡设备或者防火墙在客户端和服务器之间中断了连接。

1. 用户手动停止了浏览器加载页面。

2. 长时间没有收到服务器的响应数据，用户终止了请求。

3. 客户端网络问题导致连接意外断开。

4. 服务器端长时间处理请求，客户端超时断开连接。

5. 负载均衡器（如 Nginx 后面有应用服务器），在应用服务器处理请求时超时，导致连接被关闭。

499的解决方法：

1. 如果这是正常的用户行为，可以不需要任何操作。备注：客户端发起了一些很重的请求超时后，可能会不断重试，开启此参数nginx则不会中断之前向后端发起的请求，可能会导致加重对后端资源的使用。

2. 如果服务器响应时间过长，需要优化服务器性能，提高响应速度。

3. 增加客户端的超时时间设置。例如增加 client_body_timeout 和 client_header_timeout。

4. 检查网络设备和配置，确保网络稳定。

5. 如果使用了负载均衡，检查负载均衡器的超时设置，适当增加超时时间。

服务端错误5**

HTTP 500： Internal Server Error

• 情景：服务器在处理请求时发生了内部错误，可能是由于程序错误、配置问题或者服务器资源不足等原因。
• 解决方案：检查服务器日志，查找错误原因并进行修复，可能需要修改代码或者调整服务器配置。

HTTP状态码500内部服务器错误表示服务器遇到了意外情况，导致它无法完成对请求的处理。在Nginx中，这通常是由于配置错误、资源不足、或者后端服务（如PHP-FPM）返回错误导致的。

解决方法：

1. 检查Nginx和后端服务（如PHP-FPM）的日志文件，通常在/var/log/nginx/error.log和相应的PHP-FPM日志中。

2. 确认配置文件（如nginx.conf和php-fpm.conf）没有错误，语法正确，且指向正确的后端服务。

3. 检查文件权限，确保Nginx进程有权访问网站目录和文件。

4. 如果问题发生在特定的脚本或资源，尝试简化配置或代码，以便定位问题。

5. 检查系统资源（如内存、CPU）是否足够，高负载会导致500错误。

6. 如果使用了opcode缓存（如APC或eAccelerator），尝试清除缓存。

7. 如果问题持续，考虑重启Nginx和后端服务。

务必在做任何更改后测试配置文件的正确性（使用nginx -t），并重启Nginx（service nginx restart）和后端服务（如service php-fpm restart）。

HTTP 501：Not Implemented  

HTTP状态码501表示“Not Implemented”，即未实现。这个错误通常表示客户端请求了一个服务器支持但当前不支持的功能，或者请求的资源需要进行某些配置才能使用。

问题解决方法：

1. 检查Nginx配置文件中是否有相关location块配置错误，比如缺少必要的指令或者指令配置错误。

2. 如果是新配置的功能，确认是否所有必要的模块都已经安装并启用。

3. 检查是否有第三方模块或插件导致的问题，如果有，确保它们兼容当前的Nginx版本。

4. 查看Nginx的error log，通常位于/var/log/nginx/error.log，以获取更多关于501错误的详细信息。

5. 如果是在开发环境中，确保后端服务器正在运行，并且正确实现了请求的HTTP方法。

6. 如果问题涉及到特定的HTTP请求头或请求参数，确保Nginx配置正确处理它们。

如果以上步骤无法解决问题，可能需要进一步查看Nginx的配置文件和相关的第三方模块文档，或者寻求专业技术支持的帮助。

HTTP 502：Bad Gateway

502 网关错误
情景：
Nginx 作为代理服务器向后端服务器转发请求时未能正确获取响应，导致返回 502 错误码。

可能原因：

后端服务器响应超时或者无响应。
后端服务器出现故障或者服务不可用。
后端服务器返回了无效的响应。
解决方案：

检查后端服务器是否正常运行，是否存在性能问题或者故障。
调整 Nginx 配置中的代理设置，增加超时时间或者调整代理缓冲区大小。
查看后端服务器的日志，排查是否存在异常情况导致 502 错误。
针对 499 错误，主要需要注意客户端请求过程中的连接状态，避免在请求过程中意外关闭连接。对于 502 错误，则需要重点关注后端服务器的状态和响应情况，确保后端服务器能够正常响应请求，并且调整 Nginx 配置以提高稳定性和容错能力。

502错误通常是由于Nginx无法连接到后端服务器导致的。这个问题可能是由于以下原因导致的：
后端服务器宕机或无法响应请求。
后端服务器响应超时。
Nginx配置错误。

解决方法

1. 检查后端服务器是否正常运行

首先，我们需要检查后端服务器是否常运行。可以通过以下步骤检查：

1. ping命令检查后端服务器是否可以ping通。

ping your_server_ip

1. 使用telnet命令检查后端服务器是否可以连接。

telnet your_server_ip your_server_port

如果无法ping通或连接失败，说明后端服务器可能宕机或无法响应请求。需要检查后端服务器的状态解决问题。

2 调整Nginx的超时设置

如果后端服务器正常运行，但响应超时，我们可以尝试调整Nginx的超时设置。可以通过步骤调整：

1. 打开Nginx的配置文件，路径为：/etc/nginx/nginx.conf。

2 在http块中添加以下配置：

proxy_timeout 600;
proxy_send_timeout 600;
proxy_read_timeout 600;
send_timeout 600;

这个配置将Nginx的超时设置调整为600秒。

3.保存配置文件并重启Nginx。

service nginx restart

3. 检查Nginx配置文件

如果后端服务器正常运行，但Nginx配置错误，我们可以尝试检查Nginx的配置文件可以通过以下步骤检查：

1. 打开Nginx的配置文件，路径为：/etc/nginx/nginx.conf。

2. 检查配置文件中的语法错误，例如缺少分号、引号不匹配等。

3. 保存配置文件并重启Nginx。

service nginx restart

示例1：检查后端服务器是否正常运行

假设我们的端服务器IP地址为192.168.1.100，可以使用以下命令检查后端服务器是否正常运行：

ping 192.168.1.100

如果无法ping通，说明端服务器可能宕机或无法响应请求。需要检查后端服务器的状态并决问题。

示例2：调整Ng的超时

假设我们需要将Nginx的超时设置调整为600秒，可以在Nx的配置中添加以下配置：

http {
    ...
    proxy_connect_timeout 600;
    proxy_send_timeout 600;
    proxy_read_timeout 600;
    send_timeout 600;
    ...
}

这个配置将Nginx的超时设置调整为600秒。保存配置文件并重启Nginx即可生效。

nginx中有些超时设置，本文汇总了nginx中几个超时设置

Nginx 中的超时设置包括：

“client_body_timeout”：设置客户端向服务器发送请求体的超时时间，单位为秒。

“client_header_timeout”：设置客户端向服务器发送请求头的超时时间，单位为秒。

“send_timeout”：设置服务器向客户端发送响应的超时时间，单位为秒。

“keepalive_timeout”：设置服务器与客户端之间保持连接的超时时间，单位为秒。

“proxy_connect_timeout”：设置代理服务器与后端服务器建立连接的超时时间，单位为秒。

“proxy_read_timeout”：设置代理服务器从后端服务器读取数据的超时时间，单位为秒。

“proxy_send_timeout”：设置代理服务器向后端服务器发送数据的超时时间，单位为秒。

具体超时时间设置介绍可以参考如下

client_body_timeout

用于设置客户端在发送请求体时的超时时间，如果超过了设置的时间客户端还没有发送完请求体，则 Nginx 会返回 “408 Request Time-out” 错误。

默认值为 60s，可以在 “http” 或 “server” 块内使用 “client_body_timeout” 指令进行设置。

例如，要将 “client_body_timeout” 设置为 30 秒，可以在 “http” 或 “server” 块中加入以下指令：

client_body_timeout 30s;

此时，如果客户端在发送请求体时超过了 30 秒，则 Nginx 会返回 “408 Request Time-out” 错误。

client_header_timeout

用于设置客户端在发送请求头时的超时时间，如果超过了设置的时间客户端还没有发送完请求头，则 Nginx 会返回 “408 Request Time-out” 错误。

默认值为 60s，可以在 “http” 或 “server” 块内使用 “client_header_timeout” 指令进行设置。

例如，要将 “client_header_timeout” 设置为 30 秒，可以在 “http” 或 “server” 块中加入以下指令：

client_header_timeout 30s;

此时，如果客户端在发送请求头时超过了 30 秒，则 Nginx 会返回 “408 Request Time-out” 错误。

send_timeout

用于设置 Nginx 在响应请求时的超时时间。如果在设置的时间内 Nginx 还没有将响应完全发送出去，则会返回 “408 Request Time-out” 错误。

默认值为 60s，可以在 “http” 或 “server” 块内使用 “send_timeout” 指令进行设置。

例如，要将 “send_timeout” 设置为 30 秒，可以在 “http” 或 “server” 块中加入以下指令：

send_timeout 30s;

此时，如果 Nginx 在响应请求时超过了 30 秒还没有将响应完全发送出去，则会返回 “408 Request Time-out” 错误。

keepalive_timeout

用于设置 Nginx 保持连接的超时时间。当浏览器发送请求时，如果它已经与 Nginx 建立了连接，则可以直接使用该连接发送请求，而不需要再次建立连接。这样就可以减少建立连接的开销，提高性能。

默认值为 75s，可以在 “http” 或 “server” 块内使用 “keepalive_timeout” 指令进行设置。

例如，要将 “keepalive_timeout” 设置为 60 秒，可以在 “http” 或 “server” 块中加入以下指令：

keepalive_timeout 60s;

此时，如果浏览器与 Nginx 建立了连接，则在 60 秒内浏览器可以直接使用该连接发送请求。超过 60 秒后，如果浏览器还没有发送请求，则 Nginx 会断开连接。

proxy_connect_timeout

用于设置连接上游服务器的超时时间，单位为秒。当 Nginx 从客户端请求后，如果在规定时间内没有连接上游服务器，则会返回超时错误。这个超时时间也包含了建立连接的时间。这个参数通常用于配置反向代理，也可以用于配置负载均衡。

proxy_read_timeout

用于设置从上游服务器读取响应的超时时间，单位为秒。当 Nginx 连接上游服务器后，如果在规定时间内没有收到响应，则会返回超时错误。这个超时时间也包含了接收响应数据的时间。这个参数通常用于配置反向代理，也可以用于配置负载均衡。

proxy_send_timeout

用于设置向上游服务器发送请求的超时时间，单位为秒。当 Nginx 向上游服务器发送请求后，如果在规定时间内没有收到响应，则会返回超时错误。这个超时时间也包含了发送请求数据的时间。这个参数通常用于配置反向代理，也可以用于配置负载均衡。

其它

在调整 Nginx 的超时配置时，需要注意以下几点：

合理设置超时时间：超时时间设置过短会导致误判，设置过长会增加服务器的负担。需要根据实际情况合理调整。

超时时间的相互关系：有些超时配置之间存在相互关系，需要注意配置的先后顺序。例如，在配置反向代理时，proxy_read_timeout应该大于proxy_connect_timeout。

客户端超时设置：客户端也可能会设置超时时间，需要注意服务器端的超时配置是否会与客户端的超时配置冲突。

监控超时事件：应该定期监控超时事件的发生情况，如果发现超时事件过多，则可能需要调整超时配置。

注意超时配置的影响范围：有些超时配置只对特定的场景有效，需要注意在哪些场景下使用。例如，send_timeout只对发送响应给客户端的场景有效。

HTTP 503： Service Unavailable

• 情景：服务器当前无法处理请求，通常是由于服务器过载、维护或者临时故障等原因。
• 解决方案：等待一段时间后重新尝试请求，或者联系服务器管理员进行排查和修复。

HTTP状态码503表示服务不可用（Service Unavailable）。这通常意味着web服务器存在但不能处理请求，通常是因为服务器过载或进行维护。

问题解决方法：

1. 检查Nginx服务器的日志文件，通常位于/var/log/nginx/error.log，以确定具体原因。

2. 如果服务器正在进行维护，等待维护完成。

3. 如果服务器过载，考虑增加服务器资源（如CPU、内存、带宽）或优化服务器配置，如增加worker进程数、调整事件处理模型等。

4. 确认后端服务（如PHP-FPM、数据库等）是否正在运行且响应正常。

5. 如果是配置问题，检查Nginx配置文件是否正确，无语法错误，且指向正确的后端服务。

6. 确认服务器的防火墙设置允许Nginx通过。

7. 如果问题依然存在，可以尝试重启Nginx服务。

执行这些步骤应该能够帮助你诊断并解决503错误。如果问题复杂，可能需要进一步的技术支持。

HTTP 504：Gateway Time-out

• 情景：服务器作为网关或者代理时，请求后端服务器超时未响应。
• 解决方案：增加后端服务器的处理时间，优化网络环境或者调整代理设置以减少超时发生。

HTTP 504错误是一个服务器端的错误，表示网关超时。在Nginx中，这通常意味着Nginx作为代理服务器时，尝试访问上游服务器（如应用服务器或API服务器），但是上游服务器响应超时了。

可能原因：

1. 上游服务器宕机或无法及时响应。

2. Nginx配置中的proxy_read_timeout设置过低，导致Nginx在等待上游服务器响应时超时。

3. 网络问题导致Nginx与上游服务器的通信受延迟。

解决方法：

1. 检查上游服务器的健康状况和日志，确保它正在运行并且没有性能问题。

2. 调整Nginx配置中的proxy_read_timeout参数，增加超时时间。例如：

   location / {

   proxy_pass http://upstream_server;

   proxy_read_timeout 300s;

   }

3. 检查网络连接，确保网络通畅无阻碍。

4. 如果问题依然存在，考虑增加Nginx的负载能力，比如增加工作进程数worker_processes或优化系统资源。

在调整配置或优化服务器性能后，记得重载Nginx配置或重启Nginx服务以使更改生效。

HTTP 505： HTTP Version not supported

HTTP 505错误表示 Nginx 服务器遇到了一个不支持当前请求版本的 HTTP 协议。这通常发生在客户端尝试使用 Nginx 不支持的某种 HTTP 方法或版本时。

解决方法：

1. 检查客户端发送请求的 HTTP 版本，确保它是 Nginx 支持的版本。通常，Nginx 支持 HTTP/1.0 和 HTTP/1.1。

2. 如果是因为客户端使用了不支持的 HTTP 方法（如 TRACE、SEARCH 等），需要更新客户端以避免这些方法的使用。

3. 如果你确信客户端使用的是合适的协议版本和方法，可能是 Nginx 配置了对请求方法的限制。检查 Nginx 配置文件中是否有 limit_except 指令或其他相关指令限制了 HTTP 方法，如果有，根据需要调整配置。

4. 如果问题依然存在，可能需要更新 Nginx 到最新版本，以获取最新的协议支持和安全修复。

5. 如果你不是服务器的管理员，可以联系管理员进行相应的配置更改或软件更新。

HTTP 509： Bandwidth Limit Exceeded

Nginx 报 509 错误通常表示客户端超过了服务器设置的超大请求数量限制。这个错误代码没有标准化，通常是由 Nginx 的 ngx_http_limit_req_module 模块产生的，该模块用于限制请求的频率和次数，以防止恶意请求导致的服务拒绝攻击（DoS）。

解决方法：

1. 检查 Nginx 配置文件中的 limit_req_zone 指令和相关的 limit_req 指令设置。

2. 增加 limit_req_zone 指令中定义的内存大小，或者减少 rate 设置，允许更多的请求通过。

3. 如果是应用发送了过多请求，考虑优化应用的行为，减少短时间内的请求量。

4. 重新加载或重启 Nginx 以应用更改（nginx -s reload 或重启服务，如 systemctl restart nginx）。

示例配置调整：

http {
    limit_req_zone $binary_remote_addr zone=mylimit:10m rate=5r/s;
 
    server {
        location / {
            limit_req zone=mylimit burst=10 nodelay;
        }
    }
}

在这个例子中，limit_req_zone 指令设置了一个名为 mylimit 的区域，使用 10MB 的内存来跟踪 IP 地址，并且每秒允许平均不超过 5 个请求。limit_req 指令应用了这个限制，并设置了 burst=10 来允许在超出速率限制时进行突发请求处理，nodelay 选项意味着超过速率限制的请求会立即返回 503 错误。根据实际情况调整 rate 值和内存大小可以解决或缓解问题。

HTTP 510： Not Extended

报错510错误通常是指Nginx返回了一个HTTP状态码510，这个状态码代表了一个未扩展的错误（510 Not Extended）。这个错误通常不是标准的HTTP状态码，而是由Nginx或者某些特定的代理服务器使用，表示一个额外的错误条件发生了。

解决这个问题，需要根据具体的上下文来进行。以下是一些可能的解决步骤：

1. 检查Nginx配置：确保Nginx配置文件中没有错误的指令或者配置。

2. 检查后端服务器：如果你的Nginx配置中包含了代理到其他服务器（比如应用服务器或者API端点），确保这些后端服务正在运行并且可以正确响应请求。

3. 查看Nginx日志：检查Nginx的错误日志，通常可以在/var/log/nginx/error.log找到。查看日志中的详细错误信息，这可能会提供问题的线索。

4. 检查代理设置：如果你在Nginx配置中使用了代理，确保proxy_next_upstream, proxy_connect_timeout, proxy_read_timeout等指令设置得当，以便当后端服务器出现问题时，Nginx可以适当地处理请求。

5. 检查网络问题：确保服务器之间的网络连接没有问题。

6. 查看Nginx版本：有时候错误可能是特定版本的Nginx的一个bug，检查你的Nginx版本，如果是已知的bug，可以考虑升级Nginx或者查找对应的修复补丁。

7. 搜索Nginx社区和文档：如果上述步骤都没有解决问题，可以尝试在Nginx社区论坛中搜索错误代码，或者查看官方文档获取更多帮助。

8. 联系技术支持：如果问题依然无法解决，可以考虑联系Nginx的技术支持团队。

请注意，由于510错误不是标准HTTP状态码，不同的Nginx配置和代理设置可能会导致不同的行为。因此，具体的解决方案需要根据实际环境和配置来确定。

限制客户端缓冲

ngx_http_core_module

1、client_body_buffer_size

（1）设置用于读取客户端请求体的缓冲区大小

（2）如果请求正文大于缓冲区，整个请求体或其部分将被写入一个临时文件中

（3）默认情况下，缓冲区的大小等于两个内存页。在 x86、其他 32 位平台、x86-64 上是 8K，在其他 64 位平台上通常为 16K

（4）语法

client_body_buffer_size size;

（5）默认值

client_body_buffer_size 8k|16k;

（6）位置：http、server、location

2、client_header_buffer_size

（1）设置用于读取客户端请求头的缓冲区大小

（2）对于大多数请求，1K 字节的缓冲区足够，但若一个请求包括长的 cookies，或者来自 WAP 客户端，它可能不适合在 1K 内

（3）如果一个请求行或一个请求头字段不适合这个缓冲区，那么就会分配更大的缓冲区，由 large_client_header_buffers 指令配置

（4）如果该指令是在服务器层面指定的，可以使用默认服务器的值

（5）语法

client_header_buffer_size size;

（6）默认值

client_header_buffer_size 1k;

（7）位置：http、server

3、client_max_body_size

（1）设置客户端请求体的最大大小

（2）如果请求中的大小超过配置值，413（请求实体过大）的错误会返回给客户端

（3）注意：浏览器不能正确显示这个错误

（4）将大小设置为 0，将禁止检查客户端请求体的大小

（5）语法

client_max_body_size size;

（6）默认值

client_max_body_size 1m;

（7）位置：http、server、location

4、client_body_timeout

（1）定义读取客户端请求体的超时时间

（2）超时仅设置为两个连续读取操作之间的时间段，而不是整个请求体的传输

（3）如果客户端在此时间内未传输任何内容，则请求将终止，并显示 408（请求超时）错误

（4）语法

client_body_timeout time;

（5）默认值

client_body_timeout 60s;

（6）位置：http、server、location

5、client_header_timeout

（1） 定义读取客户端请求头的超时时间

（2）如果客户端未在此时间内传输整个请求头，则请求将终止并显示 408（请求超时）错误

（3）语法

client_header_timeout time;

（4）默认值

client_header_timeout 60s;

（5）位置：http、server

6、client_body_temp_path path

（1）定义用于存储保存客户端请求体的临时文件的目录

（2）最多可以在指定目录下使用三级子目录层次结构

（3）语法

client_body_temp_path path [level1 [level2 [level3]]];

（4）默认值

client_body_temp_path client_body_temp;

（5）位置：http、server、location

7、client_body_in_file_only

（1）确定 nginx 是否应将整个客户端请求体保存到文件中

（2）此指令可以在调试期间使用，也可以在使用 变量，或模块的变量，或模块的requestbodyfile变量，或模块ngxhttpperlmodule的r>request_body_file 方法时使用

（3）如果设置为 on，则在处理请求后不会删除临时文件

（4）值为 clean，将导致删除请求处理后留下的临时文件

（5）语法

client_body_in_file_only on | clean | off;

（6）默认值

client_body_in_file_only off;

（7）位置：http、server、location

8、client_body_in_single_buffer

（1）确定 nginx 是否应将整个客户端请求体保存在单个缓冲区中

（2）使用 $request_body 变量时，建议使用该指令，以节省所涉及的复制操作数

（3）语法

client_body_in_single_buffer on | off;

（4）默认值

client_body_in_single_buffer off;

（5）位置：http、server、location

9、large_client_header_buffers

（1）设置用于读取大型客户端请求头的缓冲区的最大数量和大小

（2）请求行不能超过一个缓冲区的大小，否则 414（请求-URI 太大）错误将返回到客户端

（3）请求头字段也不能超过一个缓冲区的大小，否则 400（错误请求）错误将返回到客户端

（4）缓冲区仅按需分配

（5）默认情况下，缓冲区大小等于 8K 字节

（6）如果在请求处理结束后，连接转换为保持活动状态，则会释放这些缓冲区

（7）如果在服务器级别指定了该指令，则可以使用默认服务器中的值

（8）语法

large_client_header_buffers number size;

（9）默认值

large_client_header_buffers 4 8k;

（10）位置：http、server

HTTP错误码

RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1

​

4xx 客户端中出现的错误

400 Bad Request请求包含语法错误。 
401 Unauthorized当前请求需要用户验证。 
402 Payment Required保留。 
403 Forbidden服务器已理解请求，但拒绝执行它。 
404 Not Found请求所需要的资源为在服务器上被发现。 
405 Method Not Allowed请求行中指定的方法不能用于请求相应的资源。 
406 Not Acceptable请求的资源的内容特性无法满足请求头中的条件，因而无法生成响应实体。 
407 Proxy Authentication Required与401响应类似，只不过客户端必须在代理服务器上进行身份验证。 
408 Request Timeout请求超时。 
409 Conflict由于被请求的资源的当前状态之间存在冲突，请求无法完成。 
410 Gone被请求的资源在服务器上已经不再可用，而且没有任何已知的转发地址。 
411 Length Required服务器拒绝在没有定义Content-Length头的情况下接受请求。 
412 Precondition Failed服务器在验证在请求的头字段中给出先决条件时，没能满足其中的一个或多个。 
413 Request Entity Too Large服务器拒绝处理当前请求，因为该请求提交的实体数据大小超过了服务器愿意或者能够处理的范围。 
414 Request-URI Too Long请求的URI长度超过了服务器能够解释的长度，因此服务器拒绝对该请求提供服务。 
415 Unsupported Media Type对于当前请求的方法和所请求的资源，请求中提交的实体并不是服务器中所支持的格式，因此请求被拒绝。 
416 Requested Range Not Satisfiable如果请求中包含了Range请求头，并且Range中指定的任何数据范围都与当前资源的可用范围不重合，同时请求中又没有定义If-Range请求头，那么服务器就应当返回416状态码。 
417 Expectation Failed在请求头Expect中指定的预期内容无法被服务器满足，或者这个服务器是一个代理服务器，它有明显的证据证明在当前路由的下一个节点上，Expect的内容无法被满足。 
418 I’m a teapot 418 I'm a teapot（RFC 2324） 本操作码是在1998年作为IETF的传统愚人节笑话, 在RFC 2324超文本咖啡壶控制协议'中定义的，并不需要在真实的HTTP服务器中定义。当一个控制茶壶的HTCPCP收到BREW或POST指令要求其煮咖啡时应当回传此错误。这个HTTP状态码在某些网站（包括Google.com）与项目（如Node.js、ASP.NET和Go语言）中用作彩蛋。

420 Enhance Your Caim Twitter Search与Trends API在客户端被限速的情况下返回。

421 There are too many connections from your internet address从当前客户端所在的IP地址到服务器的连接数超过了服务器许可的最大范围。 421 Misdirected Request （RFC 7540） 该请求针对的是无法产生响应的服务器（例如因为连接重用）。
422 Unprocessable Entity请求格式正确，但是由于含有语义错误，无法响应。 422 Unprocessable Entity（WebDAV；RFC 4918 ） 请求格式正确，但是由于含有语义错误，无法响应。
423 Locked当前资源被锁定。 423 Locked（WebDAV；RFC 4918） 当前资源被锁定。

424 Failed Dependency由于之前的某个请求发生的错误，导致当前请求失败，例如PROPPATCH。 424 Failed Dependency（WebDAV；RFC 4918） 由于之前的某个请求发生的错误，导致当前请求失败，例如PROPPATCH。
425 Unordered Collection 425 Unordered Collection 在WebDAV Advanced Collections Protocol中定义，但Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol中并不存在。
426 Upgrade Required客户端应当切换到TLS/1.0。 426 Upgrade Required（RFC 2817） 客户端应当切换到TLS/1.0，并在HTTP/1.1 Upgrade header中给出。

428 Precondition Required (RFC 6585) 原服务器要求该请求满足一定条件。这是为了防止“‘未更新’问题，即客户端读取（GET）一个资源的状态，更改它，并将它写（PUT）回服务器，但这期间第三方已经在服务器上更改了该资源的状态，因此导致了冲突。”

429 Too Many Requests （RFC 6585） 用户在给定的时间内发送了太多的请求。旨在用于网络限速。

431 Request Header Fields Too Large （RFC 6585） 服务器不愿处理请求，因为一个或多个头字段过大。

444 No Response Nginx上HTTP服务器扩展。服务器不向客户端返回任何信息，并关闭连接（有助于阻止恶意软件）。

449 Retry With由微软扩展，代表请求应当在执行完适当的操作后进行重试。 

450 Blocked by Windows Parental Controls 这是一个由Windows家庭控制（Microsoft）HTTP阻止的450状态代码的示例，用于信息和测试。

451 Unavailable For Legal Reasons 该访问因法律的要求而被拒绝，由IETF在2015核准后新增加。451 Unavailable For Legal Reasons由IETF核准，代表该访问因法律的要求而被拒绝。

494 Request Header Too Large 在错误代码431提出之前Nginx上使用的扩展HTTP代码。

HTTP 401.1 - 未授权：登录失败

HTTP 401.2 - 未授权：服务器配置问题导致登录失败

HTTP 401.3 - ACL 禁止访问资源

HTTP 401.4 - 未授权：授权被筛选器拒绝

HTTP 401.5 - 未授权：ISAPI 或 CGI 授权失败

HTTP 403.1 禁止访问：禁止可执行访问

HTTP 403.2 - 禁止访问：禁止读访问

HTTP 403.3 - 禁止访问：禁止写访问

HTTP 403.4 - 禁止访问：要求 SSL

HTTP 403.5 - 禁止访问：要求 SSL 128

HTTP 403.6 - 禁止访问：IP 地址被拒绝

HTTP 403.7 - 禁止访问：要求客户证书

HTTP 403.8 - 禁止访问：禁止站点访问

HTTP 403.9 - 禁止访问：连接的用户过多

HTTP 403.10 - 禁止访问：配置无效

HTTP 403.11 - 禁止访问：密码更改

​​HTTP 403.12 - 禁止访问：映射器拒绝访问

HTTP 403.13 - 禁止访问：客户证书已被吊销

HTTP 403.15 - 禁止访问：客户访问许可过多

​​ HTTP 403.16 - 禁止访问：客户证书不可信或者无效

HTTP 403.17 - 禁止访问：客户证书已经到期或者尚未生效

HTTP 404.1 - 无法找到 Web 站点

403 报错：403报错是一个大类，403的报错基本上是权限问题，出现403报错时您需要检测权限配置问题。以下是关于403报错中具体报错的介绍。

403.1错误是由于执行访问被禁止而造成的。若试图从目录中执行CGI、ISAPI或其他可执行程序，但该目录不允许执行程序时便会出现此种错误。

403.2错误是由于读取访问被禁止而造成的。导致此错误是由于没有可用的默认网页并且没有对目录启用目录浏览，或者要显示的HTML网页所驻留的目录仅标记为“可执行”或“脚本”权限。

403.3错误是由于写入访问被禁止而造成的。当试图将文件上载到目录或在目录中修改文件，但该目录不允许“写”访问时就会出现此种错误。

403.4错误是由于要求SSL而造成的。您必须在要查看的网页的地址中使用HTTPS。

​403.5错误是由于要求使用128位加密算法的Web浏览器而造成的。如果您的浏览器不支持128位加密算法就会出现这个错误，您可以连接微软网站进行浏览器升级。

403.6错误是由于IP地址被拒绝而造成的。如果服务器中有不能访问该站点的IP地址列表，并且您使用的IP地址在该列表中时您就会返回这条错误信息。

403.7错误是因为要求客户证书。当需要访问的资源要求浏览器拥有服务器能够识别的安全套接字层（SSL）客户证书时会返回此种错误。

403.8错误是由于禁止站点访问而造成的。若服务器中有不能访问该站点的DNS名称列表，而您使用的DNS名称在列表中时就会返回此种信息。请注意区别403.6与403.8错误。

403.9错误是由于连接的用户过多而造成的，由于Web服务器很忙，因通讯量过多而无法处理请求时便会返回这条错误。

​403.10错误是由于无效配置而导致的错误。当试图从目录中执行CGI、ISAPI或其他可执行程序，但该目录不允许执行程序时便会返回这条错误。

403.11错误是由于密码更改而导致无权查看页面。

​​403.12错误是由于映射器拒绝访问而造成的。若要查看的网页要求使用有效的客户证书，而客户证书映射没有权限访问该Web站点时就会返回映射器拒绝访问的错误。

403.13错误是由于需要查看的网页要求使用有效的客户证书而使用的客户证书已经被吊销，或者无法确定证书是否已吊销造成的。

403.14错误Web服务器被配置为不列出此目录的内容，拒绝目录列表。

403.15错误是由于客户访问许可过多而造成的。当服务器超出其客户访问许可限制时会返回此条错误。

403.16错误是由于客户证书不可信或者无效而造成的。

​​403.17错误是由于客户证书已经到期或者尚未生效而造成的。

404 报错：404报错主要是页面显示问题或者页面的链接有问题，意味着链接指向的网页不存在，即原始网页的URL失效。

当 Web服务器接到类似请求时，会返回一个404状态码，告诉浏览器已请求的资源并不存在。导致这个错误的原因一般有以下几种情况。

1. 无法在所请求的端口上访问Web站点。
2. ​​Web服务扩展锁定策略阻止本请求。
3. MIME映射策略阻止本请求。
4. 网站更新改版，但某些局部板块沿用原来的模块，而原有的模块调用的文件已经被删除或转移了路径。
5. 跟踪访问的各类脚码或CSS文件无效但调用代码依然存在。
6. 某个目录被直接删除（导致一段时间该目录的文件在被爬行时全部报“404 Not Found”错误）。
7. ​​网页URL生成规则改变、网页文件更名或移动位置、导入链接拼写错误等，导致原来的URL地址无法访问。

5xx 服务器中出现的错误

500 Internal Server Error服务器遇到了一个未曾预料的状况，导致了它无法完成对请求的处理。 
501 Not Implemented服务器不支持当前请求所需要的某个功能。** 
502 Bad Gateway作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。 
503 Service Unavailable由于临时的服务器维护或者过载，服务器当前无法处理请求。 
504 Gateway Timeout作为网关或者代理工作的服务器尝试执行请求时，未能及时从上游服务器（URI标识出的服务器，例如HTTP、FTP、LDAP）或者辅助服务器（例如DNS）收到响应。 
505 HTTP Version Not Supported服务器不支持，或者拒绝支持在请求中使用的HTTP版本。 
506 Variant Also Negotiates代表服务器存在内部配置错误 
507 Insufficient Storage服务器无法存储完成请求所必须的内容。这个状况被认为是临时的。 

508 Loop Detected （WebDAV；RFC 5842） 服务器在处理请求时陷入死循环。 （可代替 208状态码）
509 Bandwidth Limit Exceeded服务器达到带宽限制。这不是一个官方的状态码，但是仍被广泛使用。 
510 Not Extended获取资源所需要的策略并没有被满足。510 Not Extended（RFC 2774） 获取资源所需要的策略并没有被满足。

511 Network Authentication Required （RFC 6585） 客户端需要进行身份验证才能获得网络访问权限，旨在限制用户群访问特定网络。（例如连接WiFi热点时的强制网络门户）

​​HTTP 500.100 - 内部服务器错误 - ASP 错误

HTTP 500-11 服务器关闭

HTTP 500-12 应用程序重新启动

HTTP 500-13 - 服务器太忙

HTTP 500-14 - 应用程序无效

HTTP 500-15 - 不允许请求 global.asa

Error 501 - 未实现

HTTP 502 - 网关错误

报错情况比较复杂，以下列出比较常见的几种报错内容。

​502 报错：当测试访问报错为502 Bad Gateway，这是Web程序配置异常导致的。建议结合Web访问日志，检测一下Web程序配置的参数设置是否有异常。

503 报错：503报错是一种HTTP状态码，与404同属一种网页状态出错码。两者的区别是：前者是服务器出错的一种返回状态，后者是网页程序没有相关结果后返回的一种状态。503报错产生的原因有可能是以下几种情况。