Nginx配置过程中常见的问题

Nginx常见的错误及解决方法（详细参考：https://www.nginx.cn/76.html）

原创 小南学技术 2015-06-02 11:13:09 评论(0)

18070人阅读

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

启动时如果报异常

1 2	error  while  loading shared libraries: libpcre.so.1: cannot  open  shared object  file : No such  file  or directory

这说明我们的环境还不是和启动需要小小的配置一下

解决方法(直接运行)：

32位系统

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

64位系统 

1	[root@sever lib] # ln -s /usr/local/lib/libpcre.so.1 /lib64

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

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

1 2 3 4

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相关设置如下.

1 2	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错误访问日志：

1 2 3

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报错日志：

1	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{}段，添加

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

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

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

1 2	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里,加入：

1	fastcgi_buffers 8 128k  #表示设置fastcgi缓冲区为8×128

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

1	send_timeout 90;

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

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

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

1 2 3

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 2 3 4 5 6 7 8 9 10

location ~ \.php$ {               root   /home/cdai/test .com;                  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/test .com$fastcgi_script_name;       }

6、如何使用Nginx Proxy

服务器A运行tomcat为8080端口,IP:192.168.1.2:8080；

服务器B IP:192.168.1.8。现在想通过访问http://192.168.1.8即可访问tomcat服务。

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

1 2 3 4 5 6 7 8

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的话，提示：

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

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

1	Connecting to 192.168.0.100:80... failed: No route to host.

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

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

然后：

1	/etc/init .d /iptables  status

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

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

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

8、如何关闭Nginx的LOG

1 2	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大小不够等原因造成

服务器常见Nginx错误汇总

1.nginx:no live upstreams while connecting to upstream

Java代码  

1. no live upstreams while connecting to upstream  
2.   
3. [error] 27212#0: *314 no live upstreams while connecting to   upstream, client: ip_address , server: example.com, request: "GET / HTTP/1.1", upstream: "http://example.com", host: "example.com", referrer: "http://example.com/mypages/"  

    fail_timeout=15s其实就是如果上次请求发现服务无法正常返回，那么有15s的时间该server会不可用，但是一旦超过15s请求也会再次转发到该server上的，不管该server到底有没有真正的恢复。

Java代码  

1. upstream example.com  {  
2.    #  ip_hash;  
3.      server php01 max_fails=3 fail_timeout=15s;  
4.      server php02 max_fails=3 fail_timeout=15s;  
5.    }  
6.   
7.    server {  
8.      listen IP:80;  
9.      server_name example.com;  
10.      access_log /var/log/nginx/example.com.access;  
11.      error_log /var/log/nginx/example.com.error error;  
12.   
13.     location / {  
14.        proxy_set_header Host $host;  
15.        proxy_set_header X-Real-IP $remote_addr;  
16.        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;  
17.        proxy_set_header X-Forwarded-Proto $scheme;  
18.        proxy_pass  http://$server_name/$uri;  
19.        proxy_cache_bypass $cookie_nocache $arg_nocache $arg_comment;  
20.        proxy_cache_bypass $http_pragma $http_authorization;  
21.        proxy_no_cache $cookie_nocache $arg_nocache $arg_comment;  
22.        proxy_no_cache $http_pragma $http_authorization;  
23.      }  
24.   
25.    }  

 

    如果你用过nginx plus其实你会发现nginx plus 提供的health_check机制更加强大，说几个关键词，你们自己去查! zone slow_start health_check match ! 这个slow_start其实就很好的解决了缓存预热的问题，比如nginx发现一台机器重启了，那么会等待slow_starts设定的时间才会再次发送请求到该服务器上，这就给缓存预热提供了时间。

 

 

2.nginx:connect() failed (110:connection timed out )while connecting to upstream

 

Java代码  

1. [error] upstream timed out (110: Connection timed out) while reading response header from upstream, client: xxx.xxx.xxx.xxx, server: howtounix.info, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:8080", host: "howtounix.info", referrer: "requested_url"  

    nginx配置如下： 

    

Java代码  

1. worker_processes 4;  
2. pid /run/nginx.pid;  
3. worker_rlimit_nofile 16384;  
4.   
5. events {  
6.       worker_connections 10000;  
7.       # multi_accept on;  
8. }  
9.   
10. server {  
11.     listen       80;  
12.     server_name  howtounix.info;  
13.    
14.     location / {  
15.         ...  
16.         proxy_read_timeout 60;  
17.         ...  
18.     }  
19.     ...  
20. }  

    出现这种问题意味着，Web服务在60内没有获得相应，导致超时。如修改为120则表示Nginx等待相应时间为120秒，默认为60秒。

 

    服务器文件数配置：

 

Java代码  

1. #########  
2.  ulimit -a    
3. core file size              (blocks, -c) 0    
4. data seg size               (kbytes, -d) unlimited    
5. scheduling priority                 (-e) 0    
6. file size               (blocks, -f) unlimited    
7. pending signals                 (-i) 32063    
8. max locked memory       (kbytes, -l) 64    
9. max memory size         (kbytes, -m) unlimited    
10. open files                      (-n) 65536    
11. pipe size            (512 bytes, -p) 8    
12. POSIX message queues     (bytes, -q) 819200    
13. real-time priority              (-r) 0     
14. stack size              (kbytes, -s) 8192    
15. cpu time               (seconds, -t) unlimited    
16. max user processes              (-u) 32063    
17. virtual memory          (kbytes, -v) unlimited    
18. file locks                      (-x) unlimited    

   

 

    Tomcat相关配置

Java代码  

1. maxThreads="500" minSpareThreads="150" acceptCount="250" acceptorThreadCount="2"  

 

    优化方案：

     1.调整tcp_fin_timeout 

       2.调整端口范围

       3.增加Nginx服务器数据量，减少单台Nginx服务器接受请求数

 

    查看当前接口范围     

Java代码  

1. $ sysctl net.ipv4.ip_local_port_range  

    输出结果如下    

Java代码  

1. net.ipv4.ip_local_port_range = 32768    61000  

    设置新的端口范围   

Java代码  

1. # echo 1024 65535 > /proc/sys/net/ipv4/ip_local_port_range  

    或者使用如下方式  

Java代码  

1. $ sudo sysctl -w net.ipv4.ip_local_port_range="1024 64000"  

    编辑/etc/sysctl.conf 文件，使修改结果永久生效，在文件末尾添加

Java代码  

1. # increase system IP port limits  
2. net.ipv4.ip_local_port_range = 1024 65535  

   查看连接情况

    netstat | grep 'TIME_WAIT' |wc -l

如果出现大量的Time_Wait不必担心，可能问题在于存在大量的短连接，短时间内使用后快速关闭   

Java代码  

1. cat /proc/sys/net/ipv4/tcp_fin_timeout  
2.   
3. echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout  
4.   
5. 或者/etc/sysctl.conf文件尾部添加  
6. net.ipv4.tcp_fin_timeout=30  
7. 如果服务器不使用RPC服务或者NFS将他们关闭  
8. /etc/init.d/nfsd stop  
9. chkconfig nfsd off