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問題，可以優先考慮按照以下兩個步驟去解決。
1、查看當前的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
2、部分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錯誤的臨時解決辦法是：
1、調整php-fpm.conf的相關設置：
<value name=”max_children”>32</value>
<value name=”request_terminate_timeout”>30s</value> fast-cgi的執行腳本時間
--------------------------終級解決方案：
標題3中所示的解決方案只能臨時解決問題，而如果網站的訪問量確實非常非常大，而Nginx+FastCGI只能對處理瞬間或短時間內的高並發有很好的效果，所以目前唯一的終極解決方案是：定時平滑重啟php-cgi。
具體配置如下：
1、寫一個非常簡單的腳本：
#vi /home/www/scripts/php-fpm.sh
內容如下：
#!/bin/bash
# This script run at */1
/usr/local/php/sbin/php-fpm reload
2、將腳本添加至計划任務：
#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