nginx,ingress-nginx日常维护及报错

1 简介

记录一些nginx常见报错信息及对应原因;

2 Nginx快速定位异常

3 nginx错误原因

3.1 连接已经被上游close

readv() failed (104: Connection reset by peer) while reading upstream

服务端确实已经关闭了连接： upstream发送了RST，将连接重置。

erron = 104 错误表明你在对一个对端socket已经关闭的的连接调用write或send方法，在这种情况下，调用write或send方法后，对端socket便会向本端socket发送一个RESET信号，在此之后如果继续执行write或send操作，就会得到errno为104，错误描述为connection reset by peer。

如果对方socket已经执行了close的操作，本端socket还继续在这个连接上收发数据，就会触发对端socket发送RST报文。按照TCP的四次握手原理，这时候本端socket应该也要开始执行close的操作流程了，而不是接着收发数据。

抓包确认下:

tcpdump -i any -s0 -A port

RESET信号可以抓包看到，如下所示:

比如:

当后端为php程序时:

如果php运行较慢，并超出php-fpm.conf的request_terminate_timeout设置的秒数。request_terminate_timeout用于设置当某个php脚本运行最长时间，若超出php-fpm进程管理器强行中止当前程序，并关闭fastcgi和nginx的网络连接，然后nginx中就会出现Connection reset by peer的错误了。

也就是说，产生这个错误的原因是：php 程序的运行时间超出request_terminate_timeout设置的值。

在php-fpm环境下，在php的安装目录的etc/php-fpm.conf中有此值的设置项，可将其设置为0或更大的值。这样将php的request_terminate_timeout设置为较大的值或0，可减少因php脚本执行时行过长导致nginx产生Connection reset by peer错误。

比如，当后端为java 程序时:

java 的也类似，不能Java端主动关闭连接。 如果上游的tomcat 或者 netty 已经关闭连接， 那么nginx 肯定就是 Connection reset by peer;

3.2 数据长度不一致

发送端和接收端事先约定好的数据长度不一致导致的，接收端被通知要收的数据长度小于发送端实际要发送的数据长度。

3.3 nginx的buffer太小,timeout太小

3.4 FastCGI缓存小,timeout太小

nginx的buffer太小，timeout太小;

主要指php的环境，nginx如果要解析php脚本语言，就必须通过配置fastcgi模块来提供对php支持。

问题概述：图片bit 64生成数据流太大，导致小程序分享弹窗的二维码图片生成失败

nginx http模块添加以下参数配置:

fastcgi_buffer_size 128k;
fastcgi_buffers 4 128k;
fastcgi_busy_buffers_size 128k;
fastcgi_temp_file_write_size 128k;

后台报错:

排查

Client------>nginx------->h5------>nginx---------->client

1 客户端通过h5的nginx页面点击，nginx反向代理到h5 [无异常]

2 h5通过客户端请求调取相应接口 [无异常]

3 接口返回数据通过nginx展示给客户端 [异常]

Ps: 图片通过bit 64解析生成返回给客户端，由于数据长度太长导致;

解决办法

调整nginx配置参数,修改后参数:

fastcgi_buffer_size 256k;
fastcgi_buffers 4 256k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;

先简单的说一下 Nginx 的 buffer 机制，对于来自 FastCGI Server 的 Response，Nginx 将其缓冲到内存中，然后依次发送到客户端浏览器。缓冲区的大小由 fastcgi_buffers 和 fastcgi_buffer_size 两个值控制。

比如如下配置:

fastcgi_buffers 8 4K;
fastcgi_buffer_size 4K;

fastcgi_buffers 控制 nginx 最多创建 8 个大小为 4K 的缓冲区，而 fastcgi_buffer_size 则是处理 Response 时第一个缓冲区的大小，不包含在前者中。所以总计能创建的最大内存缓冲区大小是 84K+4K = 36k。而这些缓冲区是根据实际的 Response 大小动态生成的，并不是一次性创建的。比如一个 8K 的页面，Nginx 会创建 24K 共 2 个 buffers。

当 Response 小于等于 36k 时，所有数据当然全部在内存中处理。如果 Response 大于 36k 呢？fastcgi_temp 的作用就在于此。多出来的数据会被临时写入到文件中，放在这个目录下面。同时你会在 error.log 中看到一条类似 warning。

显然，缓冲区设置的太小的话，Nginx 会频繁读写硬盘，对性能有很大的影响，但也不是越大越好，没意义，呵呵！

3.5 FastCGI缓冲配置主要参数

fastcgi_buffers 4 64k

这个参数指定了从FastCGI进程到来的应答，本地将用多少和多大的缓冲区读取，假设一个PHP或JAVA脚本所产生页面大小为256kb，那么会为其分配4个64kb的缓冲来缓存；若页面大于256kb，那么大于256kb的部分会缓存到fastcgi_temp指定路径中，这并非是个好办法，内存数据处理快于硬盘，一般该值应该为站点中PHP或JAVA脚本所产生页面大小中间值，如果站点大部分脚本所产生的页面大小为256kb，那么可把值设置为16 16k,4 64k等。

fastcgi_buffer_size=64k

读取fastcgi应答第一部分需要多大缓冲区，该值表示使用1个64kb的缓冲区读取应答第一部分(应答头),可以设置为fastcgi_buffers选项缓冲区大小。

fastcgi_connect_timeout=300

连接到后端fastcgi超时时间，单位秒，下同。

fastcgi_send_timeout=300

向fastcgi请求超时时间(这个指定值已经完成两次握手后向fastcgi传送请求的超时时间)

fastcgi_reAd_timeout=300

接收fastcgi应答超时时间，同理也是2次握手后。

3.6 proxy_buffer缓存小

原因就是请求的头文件过大导致502错误:

解决方法就是提高头部的缓存:

http{
		client_header_buffer_size 5m;
		location / {
				proxy_buffer_size 128k;
				proxy_busy_buffers_size 192k;
				proxy_buffers 4 192k;
		}
}

另外可能:

nginx的buffer太小，timeout太小;

nginx http模块添加以下参数配置:

client_header_buffer_size 64k;
large_client_header_buffers 4 64k;
client_body_buffer_size 20m;
fastcgi_buffer_size 128k;
fastcgi_buffers 4 128k;
fastcgi_busy_buffers_size 256k;
gzip_buffers 16 8k;
proxy_buffer_size 64k;
proxy_buffers 4 128k;
proxy_busy_buffers_size 256k;
 
keepalive_timeout 240;
fastcgi_connect_timeout 600;
fastcgi_send_timeout 600;
fastcgi_read_timeout 600;
 
proxy_connect_timeout 600s;
proxy_send_timeout 1200;
proxy_read_timeout 1200;

3.7 proxy_max_temp_file_size太小

比如服务器架构是nginx + tomcat 提供下载上传以及其他服务，nginx上配置proxy_max_temp_file_size=200m，在前后端速度不对等的时候提供数据缓存。但是实际运行中发现，当客户端下载速度比较慢时，大文件下到200多M时就会失败。

针对这个问题，主要是由于客户端下载速度比较慢，而nginx和tomcat之间高速传输，两端速度不对等，导致nginx和tomcat之间的连接一直处于idle状态，一定时间(tomcat的keepalive时间)后tomcat主动断开连接，客户端下载失败。

3.8 没有设置keepalive

ngx_http_upstream_check_module这个模块，在使用tcp检测后端状态时，只进行了TCP的三次握手，没有主动断开这个连接，而是等待服务端来断开。当后端是nginx或者tomcat时（linux上），超时后后端会发fin包关闭这个连接。这个错误日志recv() failed (104: Connection reset by peer)是在后端为IIS的情况下抛出的，抓包发现IIS并不会发fin包来断开链接，而是在超时后发RST包重置连接，所以导致了这个问题。

从这个问题也反应出ngx_http_upstream_check_module这个模块还是需要完善下检测机制的，如果是在检测后端状态后主动关闭这个连接，应该就不会出现connect reset这个问题;

通过修改源代码已经解决了该问题:

static ngx_check_conf_t ngx_check_types[] = {
	{ NGX_HTTP_CHECK_TCP,
		ngx_string("tcp"),
		ngx_null_string,
		0,
		ngx_http_upstream_check_peek_handler,
		ngx_http_upstream_check_peek_handler,
		NULL,
		NULL,
		NULL,
		0,
		1 
  },
    
将最后一行的1改为0即可，根据数据结构分析可得知，这个1代表启用keepalived，所以客户端才不会主动断开连接，因为这是tcp的端口连通性检查，不需要keepalived，将其改为0禁止keepalived即可。
    
static ngx_check_conf_t ngx_check_types[] = {
	{ NGX_HTTP_CHECK_TCP,
		ngx_string("tcp"),
		ngx_null_string,
		0,
		ngx_http_upstream_check_peek_handler,
		ngx_http_upstream_check_peek_handler,
		NULL,
		NULL,
		NULL,
		0,
		0
  },

如果使用了proxy_pass upstream,可以配置keepalive

upstream gateway{
            server 192.168.88.31:8081;
            server 192.168.88.44:8081;
            server 192.168.88.115:8081;
            server 192.168.88.80:8081;
            #以下是新增配置
            keepalive 100;
}
 
location / {
           proxy_pass http://gateway;
           proxy_set_header   Host             $host;
           proxy_set_header   X-Real-IP        $remote_addr;
           proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
           #以下是新增配置
           proxy_connect_timeout      120;   
           proxy_send_timeout         300;    
           proxy_read_timeout         300; 
           proxy_http_version 1.1;    
           proxy_set_header Connection ""; 
}

3.9 设置lingering_close

即使你禁用了 http keepalive，nginx 仍然会尝试处理 HTTP 1.1 pipeline 的请求。你可以配置 lingering_close off 禁用此行为，但这不是推荐的做法，因为会违反 HTTP 协议。见

3.10 upstream sent invalid chunked response while reading upstream解决

http1.0 对keepalive是不支持

默认http_version是1.0，http1.0对keepalive是不支持的，所以导致了此问题;

proxy_http_version 1.1;

proxy_set_header Connection "";

两条规则缺一不可，都是为了支持后端请求 HTTP1.1 协议;

反向代理配置这里不展开，参考2中重点提到一句:

Be extra sure to include proxy_http_version 1.1 or the web socket connection will fail.

对比自己的NGINX配置，确实少了此配置项。

问题背景

一开始是一个下载文件的需求,但是不能直接下载,需要通过nginx做代理转发后,才能将文件流输出给合作方.然后我们将url的请求通过nginx代理到真实去下载文件流的服务器发现并不能下载到文件.(是通过请求浏览器去下载的,浏览器会显示此网页无法正常运作)

问题分析

1.一开始以为是代码问题,检查了代码,发现直接调用接口是可以下载成功的,那么问题就出在转发上面了.

2.然后查看nginx的error日志,发现报的错误是upstream sent invalid chunked response while reading upstream.之后就是google搜索问题,发现在nginx的location模块里面加上proxy_http_version 1.1就可以了.

3.也可以查看nginx官网对于proxy_http_version的描述;

如果不填写http的版本的话,默认是http1.0.从nginx的error日志上看出原始请求是使用的http1.1的版本,而且下载文件是使用的分块传递,http1.0是不支持这个特性的.可以简单的了解一下分块传递;

http1.0是建立连接,发送请求信息,接收请求信息,断掉连接.不支持分块传递,所以nginx报错了.

问题总结

这个问题与其说是nginx报错,不如说是不了解http不同版本之间特性的差异.而且要记住一点的是nginx代理后的默认http版本是1.0.如果原始请求是长连接或者分块传递,记得加上http1.1的参数.

proxy_http_version 1.1;

proxy_set_header Connection "";

两条规则缺一不可，都是为了支持后端请求 HTTP1.1 协议;

4 ingress-nginx错误原因

4.1 502

4.1.1 FastCGI worker进程数是否不够

运行 netstat -anpo | grep “php-cgi” | wc -l 判断是否接近FastCGI进程，接近配置文件中设置的数值，表明worker进程数设置太少;

4.1.2 FastCGI执行时间过长

根据实际情况调高以下参数值 fastcgi_connect_timeout 300; fastcgi_send_timeout 300; fastcgi_read_timeout 300;

4.1.3 FastCGI Buffer不够

nginx和apache一样，有前端缓冲限制，可以调整缓冲参数 fastcgi_buffer_size 32k; fastcgi_buffers 8 32k;

4.1.4 Proxy Buffer不够

如果你用了Proxying，调整 proxy_buffer_size 16k; proxy_buffers 4 16k; 参见：http://www.server110.com

4.1.5 https转发配置错误

正确的配置方法:

server_name www.mydomain.com;
location /myproj/repos {
		set $fixed_destination $http_destination;
    if ( $http_destination ~* ^https(.*)$ )
    {
        set $fixed_destination http$1;
    }
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header Destination $fixed_destination;
		proxy_pass http://subversion_hosts;
}

当然，还要看你后端用的是哪种类型的FastCGI，我用过的有php-fpm，流量约为单台机器40万PV(动态页面), 现在基本上没有碰到502。

4.1.6 php脚本执行时间过长

将php-fpm.conf的<value name="request_terminate_timeout">0s</value>的0s改成一个时间;

4.1.7 nginx端口耗尽时，会返回502

4.1.8 连接被nginx-ingress close

readv() failed (104: Connection reset by peer) while reading upstream

服务端确实已经关闭了连接： upstream发送了RST，将连接重置。

erron = 104 错误表明你在对一个对端socket已经关闭的的连接调用write或send方法，在这种情况下，调用write或send方法后，对端socket便会向本端socket发送一个RESET信号，在此之后如果继续执行write或send操作，就会得到errno为104，错误描述为connection reset by peer。

如果对方socket已经执行了close的操作，本端socket还继续在这个连接上收发数据，就会触发对端socket发送RST报文。按照TCP的四次握手原理，这时候本端socket应该也要开始执行close的操作流程了，而不是接着收发数据。

抓包确认下:

tcpdump -i any -s0 -A port

RESET信号可以抓包看到，如下所示:

比如:

当后端为php程序时:

如果php运行较慢，并超出php-fpm.conf的request_terminate_timeout设置的秒数。request_terminate_timeout用于设置当某个php脚本运行最长时间，若超出php-fpm进程管理器强行中止当前程序，并关闭fastcgi和nginx的网络连接，然后nginx中就会出现Connection reset by peer的错误了。

也就是说，产生这个错误的原因是：php 程序的运行时间超出request_terminate_timeout设置的值。

在php-fpm环境下，在php的安装目录的etc/php-fpm.conf中有此值的设置项，可将其设置为0或更大的值。这样将php的request_terminate_timeout设置为较大的值或0，可减少因php脚本执行时行过长导致nginx产生Connection reset by peer错误。

比如，当后端为java 程序时:

java 的也类似，不能Java端主动关闭连接。 如果上游的tomcat 或者 netty 已经关闭连接， 那么nginx 肯定就是 Connection reset by peer;

4.1.9 服务端程序先于nginx断开连接

情况分两种:

1 服务端连接超时时间小于nginx配置

2 服务端配置的单个连接的最大请求数小于nginx配置

nginx配置与后端服务配置不一致时:

如果做反向代理的 nginx 中配置的连接断开条件比后端服务设置的条件宽松，那么就容易出现后端服务先断开连接的情况， 这时候 nginx 转发请求到 upstream，upstream 会返回 RST，nginx 打印下面的错误日志，给客户端返回 502:

2019/06/13 04:57:54 [error] 3429#3429: *21983075 upstream prematurely closed connection while reading 
response header from upstream, client: 10.19.167.120, server: XXXX.com, request: "POST XXXX HTTP/1.0",
upstream: "http://11.0.29.4:8080/XXXXXX", host: "XXXX.com"

2019/06/13 04:58:34 [error] 3063#3063: *21989359 recv() failed (104: Connection reset by peer) while 
reading response header from upstream, client: 10.19.138.139, server: XXXX.com, request: 
"POST /api/v1/XXXX HTTP/1.1", upstream: "http://11.0.145.9:8080/api/v1/XXXX", host: "XXXX.com"

建议设置

可以调整 nginx 的 upstream 中 keepalive_timeout 和 keepalive_requests，确保 nginx 先于 upstream 断开连接。只有 nginx 与 upstream 之间使用长连接的时候需要考虑这种情况，并进行类似的设置;

upstream record_upstream {
    server  127.0.0.1:9091;
    keepalive 16;
    keepalive_timeout  58s;    # 默认 60 s，根据实际情况调整，建议小于 60s
    keepalive_requests 98;     # 默认 100 个，根据实际情况调整，建议小于 100
}

server {
    ...
    location /http/ {
        proxy_pass http://record_upstream;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        ...
    }
}

nginx 的 keepalive_timeout 和 keepalive_requests 参数各有两个:

一组属于 ngx_http_core_module，在 http/server/location 中使用，限制的是 client 与 nginx 之间的连接;

另一组是上面使用的，属于 ngx_http_upstream_module，限制的是 nginx 与 upstream 之间的连接。

1 . nginx 的 keep-alive 的 idle 超时要小于 upstream 的 idle 超时;

2 . nginx 的 keepalive_request 要小于 upstream 的相关设置;

以上两个配置可以保证连接断开都是 nginx 发起的，从而可以避免向一个已经关闭的连接发送请求;

默认行为

nginx的upstream中没有明确keepalive，无论client和nginx之间是否有长连接,nginx与upstream都是短链接;

upstream record_upstream {
    server  127.0.0.1:9091;

    #keepalive 3;
    #keepalive_timeout  58s;
    #keepalive_requests 98;
}

server {
    listen       9000;
    listen       [::]:9000;
    server_name  echo.example;
    keepalive_requests  2000;
    keepalive_timeout 60s;

    location / {
        proxy_pass  http://record_upstream;
        #proxy_http_version 1.1;
        #proxy_set_header Connection "";
    }
}

使用长连接访问 nginx:

http-record 收到的请求是 “Connection: close”：

/go/src/Server/echo.go:46: {
    "RemoteAddr": "172.17.0.1:34522",
    "Method": "GET",
    "Host": "record_upstream",
    "RequestURI": "/",
    "Header": {
        "Connection": [
            "close"
        ]
    },
    "Body": ""
}

4.1.10 代理缓冲区设置过小

如果你使用的是nginx反向代理，如果header过大，超出了默认的1k，就会引发上述的upstream sent too big header （说白了就是nginx把外部请求给后端处理，后端返回的header太大，nginx处理不过来就会导致502。

4.1.11 第三方因素

如果做公众号这一块，注意有可能是微信服务器请求自己服务器过多导致的;

4.2 Nginx安全配置,缓冲区溢出攻击

缓冲区溢出攻击是通过将数据写入缓冲区并超出缓冲区边界和重写内存片段来实现的 一般防止方法 限制缓冲区大小:

client_body_buffer_size  1K;
client_header_buffer_size 1k;
client_max_body_size 1k;
large_client_header_buffers 2 1k;

client_header_buffer_size

表示客户端请求头部的缓冲区大小。 绝大多数情况下一个请求头不会大于1k，不过如果有来自于wap客户端的较大的cookie它可能会大于 1k，Nginx将分配给它一个更大的缓冲区，这个值可以在large_client_header_buffers里面设置

client_max_body_size

表示客户端请求的最大可接受body大小， 它出现在请求头部的Content-Length字段， 如果请求大于指定的值，客户端将收到一个”Request Entity Too Large” (413)错误，通常在上传文件到服务器时会受到限制;

large_client_header_buffers

表示一些比较大的请求头使用的缓冲区数量和大小， 默认一个缓冲区大小为操作系统中分页文件大小，通常是4k或8k，请求字段不能大于一个缓冲区大小， 如果客户端发送一个比较大的头，nginx将返回”Request URI too large” (414)，请求的头部最长字段不能大于一个缓冲区，否则服务器将返回”Bad request” (400)

同时修改几个超时时间的配置

client_body_timeout   10;
client_header_timeout 10;
keepalive_timeout     5 5;
send_timeout          10;

client_body_timeout

表示读取请求body的超时时间， 如果连接超过这个时间而客户端没有任何响应，Nginx将返回”Request time out” (408)错误;

client_header_timeout

表示读取客户端请求头的超时时间， 如果连接超过这个时间而客户端没有任何响应，Nginx将返回”Request time out” (408)错误;

keepalive_timetout

参数的第一个值表示客户端与服务器长连接的超时时间，超过这个时间，服务器将关闭连接;

可选的第二个参数参数表示Response头中Keep-Alive: timeout=time的time值，这个值可以使一些浏览器知道什么时候关闭连接，以便服务器不用重复关闭，如果不指定这个参数，nginx不会在应Response头中发送Keep-Alive信息;

send_timetout

表示发送给客户端应答后的超时时间， Timeout是指没有进入完整established状态，只完成了两次握手， 如果超过这个时间客户端没有任何响应，nginx将关闭连接

4.3 413

4.3.1 修改上传文件大小限制

在上传时nginx返回了413错误，查看log文件，显示的错误信息是:”413 Request Entity Too Large”, 于是在网上找了下“nginx 413错误”发现需要做以下设置： 在nginx.conf增加 client_max_body_size的相关设置, 这个值默认是1m，可以增加到8m以增加提高文件大小限制；

如果运行的是php，那么还要检查php.ini，这个大小client_max_body_size要和php.ini中的如下值的最大值一致或者稍大，这样就不会因为提交数据大小不一致出现的错误。

post_max_size = 8M
upload_max_filesize = 2M

4.4 400

4.4.1 HTTP头/Cookie过大

今天有人汇报nginx的HTTP400错误，而且这个HTTP400错误并不是每次都会出现的，查了一下发现nginx400错误是由于request header过大，通常是由于cookie中写入了较长的字符串所引起的。

解决方法是不要在cookie里记录过多数据，如果实在需要的话可以考虑调整在nginx.conf中的client_header_buffer_size(默认1k)

若cookie太大，可能还需要调整large_client_header_buffers(默认4k)，该参数说明如下： 请求行如果超过buffer，就会报HTTP 414错误(URI Too Long)

nginx接受最长的HTTP头部大小必须比其中一个buffer大，否则就会报400的HTTP错误(Bad Request)。

本文根据众多互联网博客内容整理后形成，引用内容的版权归原始作者所有，仅限于学习研究使用。