nginx常見內部參數，錯誤總結

一、日誌簡介

nginx日誌主要有兩種：訪問日誌和錯誤日誌。訪問日誌主要記錄客戶端訪問nginx的每個請求，格式能夠自定義；錯誤日誌主要記錄客戶端訪問nginx出錯時的日誌，格式不支持自定義。兩種日誌均可以選擇性關閉。

經過訪問日誌，你能夠獲得用戶地域來源、跳轉來源、使用終端、某個URL訪問量等相關信息；經過錯誤日誌，你能夠獲得系統某個服務或server的性能瓶頸等。所以，將日誌好好利用，你能夠獲得不少有價值的信息。

二、訪問日誌

[Access.log]

log_format  main  '$remote_addr $remote_user [$time_local] "$request" $http_host '

                  '$status $upstream_status $body_bytes_sent "$http_referer" '

                  '"$http_user_agent" $ssl_protocol $ssl_cipher $upstream_addr '

                  '$request_time $upstream_response_time'; 

變量名稱	變量描述	舉例說明
$remote_addr	客戶端地址	113.140.15.90
$remote_user	客戶端用戶名稱	-
$time_local	訪問時間和時區	18/Jul/2012:17:00:01 +0800
$request	請求的URI和HTTP協議	"GET /pa/img/home/logo-alipay-t.png HTTP/1.1"
$http_host	請求地址，即瀏覽器中你輸入的地址（IP或域名）	img.alipay.com 10.253.70.103
$status	HTTP請求狀態	200
$upstream_status	upstream狀態	200
$body_bytes_sent	發送給客戶端文件內容大小	547
$http_referer	跳轉來源	"https://cashier.alipay.com.../"
$http_user_agent	用戶終端代理	"Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; SV1; GTB7.0; .NET4.0C;
$ssl_protocol	SSL協議版本	TLSv1
$ssl_cipher	交換數據中的算法	RC4-SHA
$upstream_addr	後臺upstream的地址，即真正提供服務的主機地址	10.228.35.247:80
$request_time	整個請求的總時間	0.205
$upstream_response_time	請求過程當中，upstream響應時間	0.002

線上實例：

116.9.137.90 - [02/Aug/2012:14:47:12 +0800] "GET /images/XX/20100324752729.png HTTP/1.1"img.alipay.com 200 200 2038 https://cashier.alipay.com/XX/PaymentResult.htm?payNo=XX&outBizNo=2012XX "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; Tablet PC 2.0; 360SE)" TLSv1 AES128-SHA 10.228.21.237:80 0.198 0.001

 

線下測試（$http_referer）：

10.14.21.197 - - [14/Aug/2012:17:28:22 +0800] "GET /spanner/watch/v1?--db=ztg-1&--mode=compare&--index=status&--option=&--cluster=whole&-F=2012%2F8%2F12-00%3A00%3A00&-T=%2B2880&-i=1&-n=0&_=1344936501292 HTTP/1.1" 200 94193 "http://spanner.alipay.NET/optionFrame/history.html" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.60 Safari/537.1"

備註：$http_referer和重定向有關。

 

線下測試（$http_host）：

備註：$http_host的值和你在瀏覽器裏輸入的值有關。

三、錯誤日誌

錯誤信息	錯誤說明
"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握手失敗
"SSL_write() failed (SSL:) while sending to client"
"(13: Permission denied) while reading upstream"
"(98: Address already in use) while connecting to upstream"
"(99: Cannot assign requested address) while connecting to upstream"
"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大小不夠等緣由形成
"send() failed (111: Connection refused)"

 

 

 

 

 

 

1.[warn] conflicting server name "192.168.1.86" on 0.0.0.0:80, ignored

 [warn]: conflicting server name 「abc.com」 on 0.0.0.0:80, ignored

出現這個錯誤通常是因爲技術員的粗心形成的，緣由是相同的域名abc.com出現兩次甚至是屢次。通常在把配置文件分離出來寫時候會容易犯。技術員常常複製配置文件，而後忘記修改裏面的內容。

解決方法就是把全部配置文件查一遍看是否有重複出現的。或者查詢哪一個配置文件中有abc.com。
WINDOW下用搜索
Linux下用grep "abc.com"

 

2.NGINX 啓動時報錯「[warn]: conflicting server name 「xxx.com」 on 0.0.0.0:80, ignored」

 

 

include vhost/*.conf;

通常是因爲技術人員配置時使用Include 語句，使用了nginx.conf以外的配置文件，若是兩個配置文件重複配置了xxx.com就會出現這個錯誤。 

 

3.今天PHP的導出EXCEL裏面忽然出現超時

雖然我在PHP腳本里面寫了set_time_limit(0);可是它仍是出現那種50x錯誤。查看日誌文件後發現裏面寫着：
upstream timed out (110: Connection timed out) while reading response header from upstream

解決辦法以下：
編輯ngnix對應的虛擬主機配置文件

 

fastcgi_read_timeout 後面的時間能夠根據本身的狀況設置，默認是60秒
        location ~ .+\.php?$
        {
            fastcgi_pass          127.0.0.1:1025;
        #   fastcgi_pass          unix:/usr/local/webserver/fastcgi/sock/fastcgi.sock;
            fastcgi_index         index.php;
        #   For Time out                這句是註釋，能夠不寫
            fastcgi_read_timeout 500;
            include               fastcgi_params;
        }

 

4.nginx502 Bad Gateway 

 

Nginx 502 Bad Gateway的含義是請求的PHP-CGI已經執行，可是因爲某種緣由（通常是讀取資源的問題）沒有執行完畢而致使PHP-CGI進程終止。

Nginx 502錯誤的緣由比較多，是由於在代理模式下後端服務器出現問題引發的。

這些錯誤通常都不是nginx自己的問題，必定要從後端找緣由！php-cgi進程數不夠用、php執行時間長、或者是php-cgi進程死掉，都會出現502錯誤  。502錯誤最一般的出現狀況就是後端主機宕機。

vim /usr/local/webserver/php/etc/php-fpm.conf
通常來講Nginx 502 Bad Gateway和php-fpm.conf的設置有關，php-fpm.conf有兩個相當重要的參數，一個是」max_children」,另外一個是」request_terminate_timeout」 ，可是這個值不是通用的，而是須要本身計算的。

計算的方式以下：

若是你的服務器性能足夠好，且寬帶資源足夠充足，PHP腳本沒有系循環或BUG的話你能夠直接將」request_terminate_timeout」設置成0s。0s的含義是讓PHP-CGI一直執行下去而沒有時間限制。而若是你作不到這一點，也就是說你的PHP-CGI可能出現某個BUG，或者你的寬帶不夠充足或者其它的緣由致使你的PHP-CGI可以假死那麼就建議你給」request_terminate_timeout」賦一個值，這個值能夠根據你服務器的性能進行設定。通常來講性能越好你能夠設置越高，20分鐘 -30分鐘均可以。因爲個人服務器PHP腳本須要長時間運行，有的可能會超過10分鐘所以我設置了900秒，這樣不會致使PHP-CGI死掉而出現502 Bad gateway這個錯誤。

而」max_children」這個值又是怎麼計算出來的呢？這個值原則上是越大越好，php-cgi的進程多了就會處理的很快，排隊的請求就會不多。設置」max_children」也須要根據服務器的性能進行設定，通常來講一臺服務器正常狀況下每個php-cgi所耗費的內存在20M左右，所以個人」max_children」我設置成40個，20M*40=800M也就是說在峯值的時候全部PHP-CGI所耗內存在800M之內，低於個人有效內存1Gb。而若是個人」max_children」設置的較小，好比5-10個，那麼 php-cgi就會「很累」，處理速度也很慢，等待的時間也較長。若是長時間沒有獲得處理的請求就會出現504 Gateway Time-out這個錯誤，而正在處理的很累的那幾個php-cgi若是遇到了問題就會出現502 Bad gateway這個錯誤。

5.通常解決辦法

遇到502問題，能夠優先考慮按照如下兩個步驟去解決。

一、查看當前的PHP FastCGI進程數是否夠用：

netstat -anpo | grep "php-cgi" | wc -l

若是實際使用的「FastCGI進程數」接近預設的「FastCGI進程數」，那麼，說明「FastCGI進程數」不夠用，須要增大。

# ps aux | grep php-cgi |wc -l
130

# netstat -anpo | grep "php-cgi" | wc -l
450

# netstat -anpo | grep "php-cgi" |more
tcp        0      0 192.168.12.201:52719        192.168.12.203:13002        ESTABLISHED 27687/php-cgi       off (0.00/0/0)
tcp        0      0 192.168.12.201:52713        192.168.12.203:13002        ESTABLISHED 27685/php-cgi       off (0.00/0/0)
tcp        0      0 192.168.12.201:52694        192.168.12.203:13002        ESTABLISHED 27682/php-cgi       off (0.00/0/0)
tcp        0      0 192.168.12.201:52688        192.168.12.203:13002        ESTABLISHED 27681/php-cgi       off (0.00/0/0)
tcp        0      0 192.168.12.201:52701        192.168.12.203:13002        ESTABLISHED 27683/php-cgi       off (0.00/0/0)

重啓後#   netstat -anpo | grep "php-cgi" | wc -l
46


[root@jushanweb1 ~]#  netstat -anpo | grep "nginx" | wc -l
17
[root@jushanweb1 ~]#  ps aux | grep nginx |wc -l
10

二、部分PHP程序的執行時間超過了Nginx的等待時間，能夠適當增長nginx.conf配置文件中FastCGI的timeout時間，例如：

...... http { ...... fastcgi_connect_timeout 300; fastcgi_send_timeout 300; fastcgi_read_timeout 300; ...... } ......



php.ini中memory_limit設低了會出錯，修改了php.ini的memory_limit爲128M，重啓nginx，發現好了，原來是PHP的內存不足了。


臨時解決辦法：

綜上所述，Nginx提示502和504錯誤的臨時解決辦法是：

一、調整php-fpm.conf的相關設置：

<value name=」max_children」>32</value>

<value name=」request_terminate_timeout」>30s</value>  fast-cgi的執行腳本時間

終級解決方案：

標題3中所示的解決方案只能臨時解決問題，而若是網站的訪問量確實很是很是大，而Nginx+FastCGI只能對處理瞬間或短期內的高併發有很好的效果，因此目前惟一的終極解決方案是：定時平滑重啓php-cgi。

具體配置以下：

一、寫一個很是簡單的腳本：

#vi /home/www/scripts/php-fpm.sh

內容以下：

#!/bin/bash
#This script run at */1
/usr/local/php/sbin/php-fpm reload

二、將腳本添加至計劃任務：

#crontab -e

內容以下：

*/1 * * * * /home/www/scripts/php-fpm.sh

注：爲了省事起見，也能夠不寫腳本，直接在crontab裏寫入php-fpm的平滑重啓命令。

 

 

Nginx 502錯誤狀況1：
網站的訪問量大，而php-cgi的進程數偏少。
針對這種狀況的502錯誤，只需增長php-cgi的進程數。具體就是修改/usr/local/php/etc/php-fpm.conf 文件，將其中的max_children值適當增長。這個數據要依據你的VPS或獨立服務器的配置進行設置。通常一個php-cgi進程佔20M內存，你能夠本身計算下，適量增多。
/usr/local/php/sbin/php-fpm restart 而後重啓一下.

 

Nginx 502錯誤狀況2:
CPU佔用率、內存佔用率很是高，遭到CC攻擊.
解決方法請參考：LinuxVPS簡單解決CC攻擊

Nginx 502錯誤狀況3：
CPU佔用率不高，內存溢出。
檢查一下網站程序有沒有問題？通常小偷站點經常會出現內存溢出。
檢查一下/var/log/目錄下的日誌，看看是否是有人爆破SSH和FTP端口？
SSH、FTP遭到窮舉也會佔用大量內存。是的話改掉SSH端口和FTP端口便可。

 

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝nginx 504 time out

 

Nginx 504 Gateway Time-out的含義是所請求的網關沒有請求到，
簡單來講就是沒有請求到能夠執行的PHP-CGI。

Nginx 504 Gateway Time-out則是與nginx.conf的設置有關。

504 Gateway Time-out問題常見於使用nginx做爲web server的服務器的網站


通常看來, 這種狀況多是因爲nginx默認的fastcgi進程響應的緩衝區過小形成的, 
這將致使fastcgi進程被掛起, 若是你的fastcgi服務對這個掛起處理的很差, 
那麼最後就極有可能致使504 Gateway Time-out
如今的網站, 尤爲某些論壇有大量的回覆和不少內容的, 一個頁面甚至有幾百K
默認的fastcgi進程響應的緩衝區是8K, 咱們能夠設置大點
在nginx.conf裏, 加入:

fastcgi_buffers 8 128k

這表示設置fastcgi緩衝區爲8×128k
固然若是您在進行某一項即時的操做, 可能須要nginx的超時參數調大點, 例如設置成60秒:

send_timeout 60;

我只是調整了這兩個參數, 結果就是沒有再顯示那個超時, 能夠說效果不錯, 可是也多是因爲其餘的緣由, 目前關於nginx的資料不是不少, 不少事情都須要長期的經驗累計纔有結果, 期待您的發現哈!


---------------解決辦法：

調整nginx.conf的相關設置：

 

fastcgi_connect_timeout 600;
fastcgi_send_timeout 600;
fastcgi_read_timeout 600;
fastcgi_buffer_size 256k;
fastcgi_buffers 16 256k;
fastcgi_busy_buffers_size 512k;
fastcgi_temp_file_write_size 512k;