Nginx常见错误与解决方法

上海纽斯达科技

Nginx常见错误与解决方法

上海纽斯达科技有限公司

2014-10-25

文档状态

文件状态：

【 】草稿

【 】修改稿

文档编号

作 者

审 核 人

Nsdkj-778

刘恒亮

保 密 等 级

最后完成日期

最后审核日期

最后批准日期

限制

2014-12-25

2014-12-25

2014-12-25

【√】正式发布

批 准 人

目的：

在Nginx服务器出现故障时，能快速定位并解决相关错误。

保密：

本文档仅供内部使用，请勿外传

概述：

Nginx常见错误与问题之解决方法技术指南。

安装环境：

系统环境：redhat enterprise 6.5 64bit

1、Nginx 常见启动错误

有的时候初次安装nginx的时候会报这样的错误

sbin/nginx -c conf/

报错内容：sbin/nginx: error while loading shared libraries: .1:

cannot open shared object file: No such file or directory

启动时如果报异常error while loading shared libraries: .1: cannot open

shared object file: No such file or directory 这说明我们的环境还不是和启动需要

小小的配置一下

解决方法(直接运行)：

32位系统 [root@sever lib]# ln -s /usr/local/lib/.1 /lib

64位系统 [root@sever lib]# ln -s /usr/local/lib/.1 /lib64

然后执行ps -ef | grep nginx 查看nginx进程确认是否真的已经启动了，在进程列表里会

有最起码两个， worker(nginx工作进程)和master（nginx主进程）

root 4349 1 0 02:24 ? 00:00:00 nginx: master process sbin/nginx -c

conf/

nginx 4350 4349 0 02:24 ? 00:00:00 nginx: worker process

root 4356 28335 0 02:30 pts/1 00:00:00 grep nginx

NGINX 就 OK了

2、400 bad request错误的原因和解决办法

配置相关设置如下.

client_header_buffer_size 16k;

large_client_header_buffers 4 64k;

根据具体情况调整，一般适当调整值就可以。

3、Nginx 502 Bad Gateway错误

在和中分别有这样两个配置项：max_execution_time和request_terminate_timeout。

这两项都是用来配置一个PHP脚本的最大执行时间的。当超过这个时间时，PHP-FPM不只会终止脚本的执行，

还会终止执行脚本的Worker进程。所以Nginx会发现与自己通信的连接断掉了，就会返回给客户端502错误。

以PHP-FPM的request_terminate_timeout=30秒时为例，报502 Bad Gateway错误的具体信息如下：

1）Nginx错误访问日志：

2013/09/19 01:09:00 [error] 27600#0: *78887 recv() failed (104: Connection

reset by peer) while reading response header from upstream,

client: 192.168.1.101, server: , request: "POST /

HTTP/1.1", upstream: "fastcgi://unix:/dev/shm/:",

host: "", referrer: "/"

2）PHP-FPM报错日志：

WARNING: child 25708 exited on signal 15 (SIGTERM) after 21008.883410

seconds from start

所以只需将这两项的值调大一些就可以让PHP脚本不会因为执行时间长而被终止了。request_terminate_timeout可以覆盖max_execution_time，

所以如果不想改全局的，那只改PHP-FPM的配置就可以了。

此外要注意的是Nginx的upstream模块中的max_fail和fail_timeout两项。有时Nginx与上游服务器（如Tomcat、FastCGI）的通信只是偶然断掉了，

但max_fail如果设置的比较小的话，那么在接下来的fail_timeout时间内，Nginx都会认为上游服务器挂掉了，都会返回502错误。

所以可以将max_fail调大一些，将fail_timeout调小一些。

4、Nginx出现的413 Request Entity Too Large错误

这个错误一般在上传文件的时候会出现，

编辑Nginx主配置文件，找到http{}段，添加

client_max_body_size 10m; //设置多大根据自己的需求作调整.

如果运行php的话这个大小client_max_body_size要和中的如下值的最大值一致或

者稍大，这样就不会因为提交数据大小不一致出现的错误。

post_max_size = 10M

upload_max_filesize = 2M

5、解决504 Gateway Time-out(nginx)

遇到这个问题是在升级discuz论坛的时候遇到的一般看来, 这种情况可能是由于nginx默认的

fastcgi进程响应的缓冲区太小造成的, 这将导致fastcgi进程被挂起, 如果你的fastcgi服务

对这个挂起处理的不好, 那么最后就极有可能导致504 Gateway Time-out,现在的网站, 尤其某

些论坛有大量的回复和很多内容的, 一个页面甚至有几百K。默认的fastcgi进程响应的缓冲区

是8K, 我们可以设置大点在里, 加入： fastcgi_buffers 8 128k这表示设置

fastcgi缓冲区为8×128

当然如果您在进行某一项即时的操作, 可能需要nginx的超时参数调大点，例如设置成90秒：

send_timeout 90;只是调整了这两个参数, 结果就是没有再显示那个超时, 效果不错

Nginx中关于与上游服务器通信超时时间的配置factcgi_connect/read/send_timeout。

以Nginx超时时间为90秒，PHP-FPM超时时间为300秒为例，报504 Gateway Timeout错误时的Nginx错误访问日志如下：

2013/09/19 00:55:51 [error] 27600#0: *78877 upstream timed out (110:

Connection timed out) while reading response header from upstream,

client: 192.168.1.101, server: , request: "POST /

HTTP/1.1", upstream: "fastcgi://unix:/dev/shm/:",

host: "", referrer: "/"

调高这三项的值（主要是read和send两项，默认不配置的话Nginx会将超时时间设为60秒）之后，504错误也解决了。

而且这三项配置可以配置在http、server级别，也可以配置在location级别。担心影响其他应用的话，就配置在自己应用的location中吧。

要注意的是factcgi_connect/read/send_timeout是对FastCGI生效的，而proxy_connect/read/send_timeout是对proxy_pass生效的。

配置举例：

location ~ .php$ {

root /home/cdai/;

include fastcgi_params;

fastcgi_connect_timeout 180;

fastcgi_read_timeout 600;

fastcgi_send_timeout 600;

fastcgi_pass unix:/dev/shm/;

fastcgi_index ;

fastcgi_param SCRIPT_FILENAME

/home/cdai/$fastcgi_script_name;

}

6、如何使用Nginx Proxy

朋友一台服务器运行tomcat 为8080端口,IP:192.168.1.2:8080,另一台机器

IP:192.168.1.8. 朋友想通过访问192.168.1.8即可访问tomcat服务.配置如下:

在192.168.1.8的上配置如下:

server {

listen 80;

server_name

location / {

proxy_pass 192.168.1.2:8080;

include /usr/local/nginx/conf/;

}

}

7. 安装完成Nginx后无法站外访问？

刚安装好nginx一个常见的问题是无法站外访问，本机wget、telnet都正常。而服务器之外，不管是局域网的其它主机还是互联网的主机都无法访问站点。如果用telnet的话，提示：

正在连接到...不能打开到主机的连接， 在端口 80: 连接失败

如果用wget命令的话，提示：

Connecting to 192.168.0. failed: No route to host.

如果是以上的故障现象，很可能是被CentOS的防火墙把80端口拦住了，尝试执行以下命令，打开80端口：

iptables -I INPUT -p tcp --dport 80 -j ACCEPT

然后用：

/etc/init.d/iptables status

查看当前的防火墙规则，如果发现有这样一条：

ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80

就说明防火墙规则已经添加成功了，再在站外访问就正常了。

8、如何关闭Nginx的LOG

access_log /dev/null

error_log /dev/null

此外，错误日志主要记录客户端访问nginx出错时的日志，通过错误日志，能快速定位客户端访问异常！

错误信息

"upstream prematurely（过早的） closed connection"

错误说明

请求uri的时候出现的异常，是由于upstream还未返回应答给用户时用户断掉连接造成的，对系统没有影响，可以忽略

"recv() failed (104: Connection reset

by peer)"

（1）服务器的并发连接数超过了其承载量，服务器会将其中一些连接Down掉；

（2）客户关掉了浏览器，而服务器还在给客户端发送数据；

（3）浏览器端按了Stop

"(111: Connection refused) while

connecting to upstream"

"(111: Connection refused) while

reading response header from

upstream"

"(111: Connection refused) while

sending request to upstream"

"(110: Connection timed out) while

connecting to upstream"

"(110: Connection timed out) while

用户在连接时，若遇到后端upstream挂掉或者不通，会收到该错误

用户在连接成功后读取数据时，若遇到后端upstream挂掉或者不通，会收到该错误

Nginx和upstream连接成功后发送数据时，若遇到后端upstream挂掉或者不通，会收到该错误

nginx连接后面的upstream时超时

nginx读取来自upstream的响应时超时

reading upstream"

"(110: Connection timed out) while

reading response header from

upstream"

"(110: Connection timed out) while

reading upstream"

"(104: Connection reset by peer) while

connecting to upstream"

"upstream sent invalid header while

reading response header from

upstream"

"upstream sent no valid HTTP/1.0

header while reading response header

from upstream"

"client intended to send too large

body"

"reopening logs"

"gracefully shutting down",

"no servers are inside upstream"

"no live upstreams while connecting to

upstream"

"SSL_do_handshake() failed"

SSL session shared cache"

"could not add new SSL session to the

session cache while SSL handshaking"

nginx读取来自upstream的响应头时超时

nginx读取来自upstream的响应时超时

upstream发送了RST，将连接重置

upstream发送的响应头无效

upstream发送的响应头无效

用于设置允许接受的客户端请求内容的最大值，默认值是1M，client发送的body超过了设置值

用户发送kill -USR1命令

用户发送kill -WINCH命令

upstream下未配置server

upstream下的server全都挂了

SSL握手失败

"ngx_slab_alloc() failed: no memory in

ssl_session_cache大小不够等原因造成

ssl_session_cache大小不够等原因造成