分享

Nginx常见错误与解决方法

 博雅书屋lhs 2016-01-05

目的:

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

 

保密:

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

 

概述:

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

 

安装环境:

系统环境:redhat enterprise 6.5 64bit

 

 

 

 

 

 

 

 

 

 

 

 

 

1Nginx 常见启动错误

 

有的时候初次安装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工作进程)masternginx主进程)

 

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

 

2400 bad request错误的原因和解决办法

 

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

 

client_header_buffer_size 16k;

large_client_header_buffers 4 64k;

 

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

 

3Nginx 502 Bad Gateway错误

 

php.iniphp-fpm.conf中分别有这样两个配置项:max_execution_timerequest_terminate_timeout

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

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

 

PHP-FPMrequest_terminate_timeout=30秒时为例,报502 Bad Gateway错误的具体信息如下:

1Nginx错误访问日志:

     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 /index.php HTTP/1.1", upstream: "fastcgi://unix:/dev/shm/php-fcgi.sock:", 

     host: "", referrer: "http:///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的配置就可以了。

 

此外要注意的是Nginxupstream模块中的max_failfail_timeout两项。有时Nginx与上游服务器(如TomcatFastCGI)的通信只是偶然断掉了,

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

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

 

4Nginx出现的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: , request: "POST /index.php HTTP/1.1", upstream: "fastcgi://unix:/dev/shm/php-fcgi.sock:", 

     host: "", referrer: "http:///index.php"

 

调高这三项的值(主要是readsend两项,默认不配置的话Nginx会将超时时间设为60秒)之后,504错误也解决了。

而且这三项配置可以配置在httpserver级别,也可以配置在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/php-fcgi.sock;
                fastcgi_index           index.php;
                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. 朋友想通过访问http://192.168.1.8即可访问tomcat服务.配置如下:

 

192.168.1.8nginx.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一个常见的问题是无法站外访问,本机wgettelnet都正常。而服务器之外,不管是局域网的其它主机还是互联网的主机都无法访问站点。如果用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、如何关闭NginxLOG

 

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"

Nginxupstream连接成功后发送数据时,若遇到后端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"

用于设置允许接受的客户端请求内容的最大值,默认值是1Mclient发送的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大小不够等原因造成

 


    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多