Nginx常见错误与解决方法汇总

Nginx常见错误与解决方法汇总

Nginx是一款自由的、开源的、高性能的HTTP服务器和反向代理服务器;同时也是一个IMAP、POP3、SMTP代理服务器;放眼全球，很多网站都是建立在nginx的基础之上。本篇笔记主要为大家分享下日常运维中常见的nginx错误及解决办法。

1、Nginx 常见启动错误。

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

sbin/nginx -c conf/nginx.conf

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

cannot open shared object file: No such file or directory

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

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

小小的配置一下

解决方法(直接运行)：

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

64位系统 [root@sever lib]# ln -s /usr/local/lib/libpcre.so.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.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错误的原因和解决办法。

配置nginx.conf相关设置如下.

client_header_buffer_size 16k;

large_client_header_buffers 4 64k;

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

 

3、Nginx 502 Bad Gateway错误。

在php.ini和php-fpm.conf中分别有这样两个配置项：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: test.com, request: "POST /index.php HTTP/1.1", upstream: "fastcgi://unix:/dev/shm/php-fcgi.sock:",
host: "test.com", referrer: "http://test.com/index.php"

 

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.ini，那只改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主配置文件Nginx.conf，找到http{}段，添加

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

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

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, 我们可以设置大点在nginx.conf里, 加入： 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: test.com, request: "POST /index.php HTTP/1.1", upstream: "fastcgi://unix:/dev/shm/php-fcgi.sock:",
host: "test.com", referrer: "http://test.com/index.php"

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

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

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

配置举例：

  1. location ~ \.php$ {
  2.                 root                    /home/cdai/test.com;
  3.                 include                 fastcgi_params;
  4.                 fastcgi_connect_timeout      180;
  5.                 fastcgi_read_timeout            600;
  6.                 fastcgi_send_timeout            600;
  7.                 fastcgi_pass            unix:/dev/shm/php-fcgi.sock;
  8.                 fastcgi_index           index.php;
  9.                 fastcgi_param          SCRIPT_FILENAME /home/cdai/test.com$fastcgi_script_name;
  10.      }

 

6、如何使用Nginx Proxy。

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

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

在192.168.1.8的nginx.conf上配置如下:

 

server {

listen 80;

server_name java.linuxtone.org

location / {

proxy_pass http://192.168.1.2:8080;

include /usr/local/nginx/conf/proxy.conf;

}

}

 

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

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

如果用telnet的话，提示：

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

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

Connecting to 192.168.0.100:80... 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" 用户在连接时，若遇到后端upstream挂掉或者不通，会收到该错误
"(111: Connection refused) while reading response header from upstream" 用户在连接成功后读取数据时，若遇到后端upstream挂掉或者不通，会收到该错误
"(111: Connection refused) while sending request to upstream" Nginx和upstream连接成功后发送数据时，若遇到后端upstream挂掉或者不通，会收到该错误
"(110: Connection timed out) while connecting to upstream" nginx连接后面的upstream时超时
"(110: Connection timed out) while reading upstream" nginx读取来自upstream的响应时超时

 
"(110: Connection timed out) while reading response header from upstream" nginx读取来自upstream的响应头时超时
"(110: Connection timed out) while reading upstream" nginx读取来自upstream的响应时超时
"(104: Connection reset by peer) while connecting to upstream" upstream发送了RST，将连接重置
"upstream sent invalid header while reading response header from upstream" upstream发送的响应头无效
"upstream sent no valid HTTP/1.0 header while reading response header from upstream" upstream发送的响应头无效
"client intended to send too large body" 用于设置允许接受的客户端请求内容的最大值，默认值是1M，client发送的body超过了设置值
"reopening logs" 用户发送kill  -USR1命令
"gracefully shutting down", 用户发送kill  -WINCH命令
"no servers are inside upstream" upstream下未配置server
"no live upstreams while connecting to upstream" upstream下的server全都挂了
"SSL_do_handshake() failed" SSL握手失败
"ngx_slab_alloc() failed: no memory in SSL session shared cache" ssl_session_cache大小不够等原因造成
"could not add new SSL session to the session cache while SSL handshaking" ssl_session_cache大小不够等原因造成

 

9、Nginx出现upstream prematurely closed connection while reading response header from upstream错误。

这个错误的意思是 nginx不能从后端的服务器获取响应头今日突然之间PHP的环境不好使了，打开什么页面都是502错误，查看日志错误如下：

2015/05/19 10:29:39 [error] 1616#3708: *7 upstream prematurely closed connection while reading response header from upstream, client: 127.0.0.1, server: localhost, request: “GET /phpinfo.php HTTP/1.1″, upstream: “fastcgi://127.0.0.1:9000″, host: “localhost”

应该是看起来应该是PHP处理出现问题了。那么查看一下PHP的9000端口 看看是否有进程在占用

1.在运行中输入cmd打开dos命令窗口，比如我想找到端口9000对应的PID（通过PID找到相应的进程）

键入命令：netstat -ano|findstr 9000

2.根据PID找到对应的进程，打开任务管理器-点击查看选项-选择（选择列）

这样就会在任务管理器上看到PID的值

3.找到对应的PID关闭进程，关闭PID为1944的进程，查出来之后竟然是Eclipse或 ZendStudio的XDebug占用了 为何占用 挺疑惑的。。。

修改XDebug的端口为9090:窗口->首选项->PHP->调试->Debuggers,双击XDebug

修改php.ini为xdebug.remote_port=9090 ;反向连接zend studio使用的端口

 

。。。待补充，如果您在服务器运维中遇到有其他问题欢迎留言。

 

你想把广告放到这里吗？

发表评论

您必须 登录 才能发表留言！