nginx錯誤總結

 

2、訪問日誌

 

log_format main '$http_x_forwarded_for $remote_user [$time_local] '

                    '"$request" $status $request_time '

                    '"$http_referer" "$http_user_agent" "$remote_addr" '

                    '$upstream_response_time "$server_name"';

 

[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的值和你在瀏覽器裏輸入的值有關。

3、錯誤日誌

錯誤信息	錯誤說明
"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)"

 

 

錯誤代碼

[emerg]: could not build the proxy_headers_hash, you should increase either proxy_headers_hash_max_size: 512 or proxy_headers_hash_bucket_size: 64

解決辦法

在配置文件中新增如下配置項：proxy_headers_hash_max_size 51200；
proxy_headers_hash_bucket_size 6400；

 

錯誤2：

在使用 Nginx 的過程當中，由於 Nginx 本地使用了緩存，而後發佈了靜態資源後， CDN 回源的時候，發現沒有正常回源，通過查詢發現，是由於 Nginx 本地有緩存，而有沒有對緩存進行刷新的緣由，要刷新本地緩存，能夠安裝 Purge 模塊。

Nginx 的緩存設置：

複製代碼 代碼以下:

location /
      {
       proxy_cache cache_go;
       proxy_cache_valid 200 304 1d;
       proxy_cache_key $host$uri$is_args$args;
       proxy_set_header Host  $host;
       proxy_set_header X-Forwarded-For  $remote_addr;
       proxy_pass http://127.0.0.1:8800;
       expires      3024010s;

       }

       location ~ /purge(/.*)
       {
        #設置只容許指定的IP或IP段才能夠清除URL緩存。
        allow            127.0.0.1;
        deny             all;
        proxy_cache_purge    cache_go   $host$1$is_args$args;
       }

 Purge 模塊是用來清除緩存的，首先下載安裝 Puerge 模塊。

下載 Purge 模塊：
wget http://labs.frickle.com/files/ngx_cache_purge-1.2.tar.gz

 解壓：
tar -zxvf ngx_cache_purge-1.2.tar.gz

 再編譯前先使用以下命令查看 nginx 的編譯選項：

複製代碼 代碼以下:

/home/nginx/sbin/nginx -V
nginx version: xxxx
TLS SNI support enabled
configure arguments: --prefix=/home/nginx-1.2.8 --with-pcre=../pcre-8.31 --with-zlib=../zlib-1.2.3 --with-openssl=../openssl-1.0.0d --with-http_ssl_module --with-http_stub_status_module --without-mail_pop3_module --without-mail_imap_module --without-mail_smtp_module --add-module=../ngx_cache_purge-1.5 --add-module=../perusio-nginx-http-concat-321e344 --add-module=../ngx_http_vipshop_hostname_filter --with-ld-opt=-static

 上面個人編譯顯示有 puerge 模塊，是由於我已經編譯過了，而後在原有的編譯參數後面加上：

複製代碼 代碼以下:

--add-module=/home/ngx_cache_purge-1.5

 退出 Nginx ，並從新啓動：

複製代碼 代碼以下:

./nginx -s quit
./nginx

 配置 Puerge ：

複製代碼 代碼以下:

location ~ /purge(/.*)
       {
        #設置只容許指定的IP或IP段才能夠清除URL緩存。
        allow            127.0.0.1;
        deny             all;
        proxy_cache_purge    cache_go   $host$1$is_args$args;
       }

 清楚 Nginx 緩存的方式，好比你的 url 是 http://test.com/test/test.js
 那清除該 js 緩存的命令即爲：

複製代碼 代碼以下:

curl http://test.com/purge/test/test.js

 通用的方式就是：

複製代碼 代碼以下:

curl http://test.com/purge/uri

 其中 uri 就是你的 URL 「http://test.com/test/test.js」 的 「test/test.js」 部分

 

－－－－－－－－－－－－－－－－－－－[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"

 

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

 

 

include vhost/*.conf;

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

 

 

 

 

 

=======================今天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;
        }

 

 

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝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這個錯誤。






----------------通常解決辦法

遇到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;

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

有的時候初次安裝

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

生效的。

 

 

配置舉例：

 

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 

 

朋友一臺服務器運行

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/nul