Nginx常見的錯誤及解決方法

時間  2020-05-27
標籤 nginx 常見的 錯誤 解決 方法 欄目 Nginx 简体版
原文   原文鏈接

http://nanchunle.blog.51cto.com/9244770/1657410 php

一、Nginx 常見啓動錯誤 java

有的時候初次安裝nginx的時候會報這樣的錯誤 linux

sbin/nginx -c conf/nginx.conf nginx

報錯內容：sbin/nginx: error while loading shared libraries: libpcre.so.1:  後端

cannot open shared object file: No such file or directory瀏覽器

啓動時若是報異常tomcat

1服務器

2session

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了 

二、400 bad request錯誤的緣由和解決辦法

配置nginx.conf相關設置以下.

1

2

client_header_buffer_size 16k;

large_client_header_buffers 4 64k;

根據具體狀況調整，通常適當調整值就能夠。

三、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調小一些。

四、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

五、解決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;

     }

六、如何使用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

就說明防火牆規則已經添加成功了，再在站外訪問就正常了。

八、如何關閉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+php-fpm模式php內存泄漏探究 

http://blog.csdn.net/blakefez/article/details/46691171

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程