Nginx配置文件（2）

1、配置文件結構

一、全局塊：配置影響nginx全局的指令。通常有運行nginx服務器的用戶組，nginx進程pid存放路徑，日誌存放路徑，配置文件引入，容許生成worker process數等。

二、events塊：配置影響nginx服務器或與用戶的網絡鏈接。有每一個進程的最大鏈接數，選取哪一種事件驅動模型處理鏈接請求，是否容許同時接受多個網路鏈接，開啓多個網絡鏈接序列化等。

三、http塊：能夠嵌套多個server，配置代理，緩存，日誌定義等絕大多數功能和第三方模塊的配置。如文件引入，mime-type定義，日誌自定義，是否使用sendfile傳輸文件，鏈接超時時間，單鏈接請求數等。

四、server塊：配置虛擬主機的相關參數，一個http中能夠有多個server。

五、location塊：配置請求的路由，以及各類頁面的處理狀況。

 

1.1 Nginx的全局配置

代碼以下：

user nobody nobody; worker_processes 2; error_log logs/error.log notice; pid logs/nginx.pid; worker_rlimit_nofile 65535; events{ use epoll; worker_connections 65536; }

 每一個配置選項的含義解釋以下：

• user是個主模塊指令，指定Nginx Worker進程運行用戶以及用戶組，默認由nobody帳號運行。
• worker_processes是個主模塊指令，指定了Nginx要開啓的進程數。每一個Nginx進程平均耗費10M~12M內存。建議指定和CPU的數量一致便可。
• error_log是個主模塊指令，用來定義全局錯誤日誌文件。日誌輸出級別有debug、info、notice、warn、error、crit可供選擇，其中，debug輸出日誌最爲最詳細，而crit輸出日誌最少。
• pid是個主模塊指令，用來指定進程pid的存儲文件位置。
• worker_rlimit_nofile用於綁定worker進程和CPU， Linux內核2.4以上可用。

events事件指令是設定Nginx的工做模式及鏈接數上限：

use是個事件模塊指令，用來指定Nginx的工做模式。Nginx支持的工做模式有select、poll、kqueue、epoll、rtsig和/dev/poll。其中select和poll都是標準的工做模式，kqueue和epoll是高效的工做模式，不一樣的是epoll用在Linux平臺上，而kqueue用在BSD系統中。對於Linux系統，epoll工做模式是首選。

worker_connections也是個事件模塊指令，用於定義Nginx每一個進程的最大鏈接數，默認是1024。最大客戶端鏈接數由worker_processes和worker_connections決定，即Max_client=worker_processes*worker_connections。

在做爲反向代理時，max_clients變爲：max_clients = worker_processes * worker_connections/4。

進程的最大鏈接數受Linux系統進程的最大打開文件數限制，在執行操做系統命令「ulimit -n 65536」後worker_connections的設置才能生效。

 

1.2 HTTP服務器配置

Nginx對HTTP服務器相關屬性的配置代碼以下：

http{ include conf/mime.types; default_type application/octet-stream; log_format main '$remote_addr - $remote_user [$time_local] '
    '"$request" $status $bytes_sent '
    '"$http_referer" "$http_user_agent" '
    '"$gzip_ratio"'; log_format download '$remote_addr - $remote_user [$time_local] '
    '"$request" $status $bytes_sent '
    '"$http_referer" "$http_user_agent" '
    '"$http_range" "$sent_http_content_range"'; client_max_body_size 20m; client_header_buffer_size 32K; large_client_header_buffers 4 32k; Sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 60; client_header_timeout 10; client_body_timeout 10; send_timeout 10;

 

下面詳細介紹下這段代碼中每一個配置選項的含義。

include是個主模塊指令，實現對配置文件所包含的文件的設定，能夠減小主配置文件的複雜度。相似於Apache中的include方法。

default_type屬於HTTP核心模塊指令，這裏設定默認類型爲二進制流，也就是當文件類型未定義時使用這種方式，例如在沒有配置PHP環境時，Nginx是不予解析的，此時，用瀏覽器訪問PHP文件就會出現下載窗口。

下面的代碼實現對日誌格式的設定：

log_format main '$remote_addr - $remote_user [$time_local] '
'"$request" $status $bytes_sent '
'"$http_referer" "$http_user_agent" '
'"$gzip_ratio"'; log_format download '$remote_addr - $remote_user [$time_local] '
'"$request" $status $bytes_sent '
'"$http_referer" "$http_user_agent" '
'"$http_range" "$sent_http_content_range"';

 

log_format是Nginx的HttpLog模塊指令，用於指定Nginx日誌的輸出格式。main爲此日誌輸出格式的名稱，能夠在下面的access_log指令中引用。

• client_max_body_size用來設置容許客戶端請求的最大的單個文件字節數；
• client_header_buffer_size用於指定來自客戶端請求頭的headerbuffer大小。對於大多數請求，1K的緩衝區大小已經足夠，若是自定義了消息頭或有更大的Cookie，能夠增長緩衝區大小。這裏設置爲32K；
• large_client_header_buffers用來指定客戶端請求中較大的消息頭的緩存最大數量和大小， 「4」爲個數，「128K」爲大小，最大緩存量爲4個128K；
• sendfile參數用於開啓高效文件傳輸模式。將tcp_nopush和tcp_nodelay兩個指令設置爲on用於防止網絡阻塞；
• keepalive_timeout設置客戶端鏈接保持活動的超時時間。在超過這個時間以後，服務器會關閉該鏈接；
• client_header_timeout設置客戶端請求頭讀取超時時間。若是超過這個時間，客戶端尚未發送任何數據，Nginx將返回「Request time out（408）」錯誤；
• client_body_timeout設置客戶端請求主體讀取超時時間。若是超過這個時間，客戶端尚未發送任何數據，Nginx將返回「Request time out（408）」錯誤，默認值是60；
• send_timeout指定響應客戶端的超時時間。這個超時僅限於兩個鏈接活動之間的時間，若是超過這個時間，客戶端沒有任何活動，Nginx將會關閉鏈接。

1.3 HttpGzip模塊配置

下面配置Nginx的HttpGzip模塊。這個模塊支持在線實時壓縮輸出數據流。

看是否安裝了HttpGzip模塊：

[root@vps ~]# /opt/nginx/sbin/nginx -V

nginx version: nginx/1.0.14

built by gcc 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC)

configure arguments: --with-http_stub_status_module --with-http_gzip_static_module --prefix=/opt/nginx

經過/opt/nginx/sbin/nginx -V命令能夠查看安裝Nginx時的編譯選項，由輸出可知，咱們已經安裝了HttpGzip模塊。

下面是HttpGzip模塊在Nginx配置中的相關屬性設置：

gzip on; gzip_min_length 1k; gzip_buffers 4 16k; gzip_http_version 1.1; gzip_comp_level 2; gzip_types text/plain application/x-javascript text/css application/xml; gzip_vary on;

• gzip用於設置開啓或者關閉gzip模塊，「gzip on」表示開啓GZIP壓縮，實時壓縮輸出數據流；
• gzip_min_length設置容許壓縮的頁面最小字節數，頁面字節數從header頭的Content-Length中獲取。默認值是0，無論頁面多大都進行壓縮。建議設置成大於1K的字節數，小於1K可能會越壓越大；
• gzip_buffers表示申請4個單位爲16K的內存做爲壓縮結果流緩存，默認值是申請與原始數據大小相同的內存空間來存儲gzip壓縮結果；
• gzip_http_version用於設置識別HTTP協議版本，默認是1.1，目前大部分瀏覽器已經支持GZIP解壓，使用默認便可；
• gzip_comp_level用來指定GZIP壓縮比，1 壓縮比最小，處理速度最快；9 壓縮比最大，傳輸速度快，但處理最慢，也比較消耗cpu資源；
• gzip_types用來指定壓縮的類型，不管是否指定，「text/html」類型老是會被壓縮的；
• gzip_vary選項可讓前端的緩存服務器緩存通過GZIP壓縮的頁面，例如用Squid緩存通過Nginx壓縮的數據。

1.4 負載均衡配置

下面設定負載均衡的服務器列表：

upstream cs.com{ ip_hash; server 192.168.8.11:80; server 192.168.8.12:80 down; server 192.168.8.13:8009  max_fails=3  fail_timeout=20s; server 192.168.8.146:8080; }

 

upstream是Nginx的HTTP Upstream模塊，這個模塊經過一個簡單的調度算法來實現客戶端IP到後端服務器的負載均衡。

在上面的設定中，經過upstream指令指定了一個負載均衡器的名稱cszhi.com。這個名稱能夠任意指定，在後面須要的地方直接調用便可。

Nginx的負載均衡模塊目前支持4種調度算法，下面進行分別介紹，其中後兩項屬於第三方的調度方法。

• 輪詢（默認）：每一個請求按時間順序逐一分配到不一樣的後端服務器，若是後端某臺服務器宕機，故障系統被自動剔除，使用戶訪問不受影響；
• Weight：指定輪詢權值，Weight值越大，分配到的訪問機率越高，主要用於後端每一個服務器性能不均的狀況下；
• ip_hash：每一個請求按訪問IP的hash結果分配，這樣來自同一個IP的訪客固定訪問一個後端服務器，有效解決了動態網頁存在的session共享問題；
• fair：比上面兩個更加智能的負載均衡算法。此種算法能夠依據頁面大小和加載時間長短智能地進行負載均衡，也就是根據後端服務器的響應時間來分配請求，響應時間短的優先分配。Nginx自己是不支持fair的，若是須要使用這種調度算法，必須下載Nginx的upstream_fair模塊；
• url_hash：按訪問url的hash結果來分配請求，使每一個url定向到同一個後端服務器，能夠進一步提升後端緩存服務器的效率。Nginx自己是不支持url_hash的，若是須要使用這種調度算法，必須安裝Nginx 的hash軟件包。

在HTTP Upstream模塊中，能夠經過server指令指定後端服務器的IP地址和端口，同時還能夠設定每一個後端服務器在負載均衡調度中的狀態。經常使用的狀態有：

• down：表示當前的server暫時不參與負載均衡；
• backup：預留的備份機器。當其餘全部的非backup機器出現故障或者忙的時候，纔會請求backup機器，所以這臺機器的壓力最輕；
• max_fails：容許請求失敗的次數，默認爲1。當超過最大次數時，返回proxy_next_upstream 模塊定義的錯誤；
• fail_timeout：在經歷了max_fails次失敗後，暫停服務的時間。max_fails能夠和fail_timeout一塊兒使用。

注意，當負載調度算法爲ip_hash時，後端服務器在負載均衡調度中的狀態不能是weight和backup。

1.5 server虛擬主機配置

下面介紹對虛擬主機的配置。

建議將對虛擬主機進行配置的內容寫進另一個文件，而後經過include指令包含進來，這樣更便於維護和管理。

server{ listen 80; server_name 192.168.8.18 cszhi.com; index index.html index.htm index.php; root /wwwroot/www.cszhi.com charset gb2312; access_log logs/www.ixdba.net.access.log  main;

server標誌定義虛擬主機開始，listen用於指定虛擬主機的服務端口，server_name用來指定IP地址或者域名，多個域名之間用空格分 開。index用於設定訪問的默認首頁地址，root指令用於指定虛擬主機的網頁根目錄，這個目錄能夠是相對路徑，也能夠是絕對路徑。Charset用於 設置網頁的默認編碼格式。access_log用來指定此虛擬主機的訪問日誌存放路徑，最後的main用於指定訪問日誌的輸出格式。

1.6 location URL匹配配置

URL地址匹配是進行Nginx配置中最靈活的部分。 location支持正則表達式匹配，也支持條件判斷匹配，用戶能夠經過location指令實現Nginx對動、靜態網頁進行過濾處理。使用location URL匹配配置還能夠實現反向代理，用於實現PHP動態解析或者負載負載均衡。

如下這段設置是經過location指令來對網頁URL進行分析處理，全部擴展名以.gif、.jpg、.jpeg、.png、.bmp、.swf結尾的靜態文件都交給nginx處理，而expires用來指定靜態文件的過時時間，這裏是30天。

location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$ { root /wwwroot/www.cszhi.com; expires 30d; }

如下這段設置是將upload和html下的全部文件都交給nginx來處理，固然，upload和html目錄包含在/web/wwwroot/www.cszhi.com目錄中。

location ~ ^/(upload|html)/ { root /web/wwwroot/www.cszhi.com; expires 30d; }

 在最後這段設置中，location是對此虛擬主機下動態網頁的過濾處理，也就是將全部以.jsp爲後綴的文件都交給本機的8080端口處理。

location ~ .*.php$ { index index.php; proxy_pass http://localhost:8080; }

 

1.7 StubStatus模塊配置

StubStatus模塊可以獲取Nginx自上次啓動以來的工做狀態，此模塊非核心模塊，須要在Nginx編譯安裝時手工指定才能使用此功能。

如下指令實指定啓用獲取Nginx工做狀態的功能。

location /NginxStatus {
     stub_status      on;
     access_log              logs/NginxStatus.log;
     auth_basic              "NginxStatus";
     auth_basic_user_file    ../htpasswd;
}

stub_status設置爲「on」表示啓用StubStatus的工做狀態統計功能。access_log 用來指定StubStatus模塊的訪問日誌文件。auth_basic是Nginx的一種認證機制。auth_basic_user_file用來指定認證的密碼文件，因爲Nginx的auth_basic認證採用的是與Apache兼容的密碼文件，所以須要用Apache的htpasswd命令來生成密碼文件，例如要添加一個test用戶，可使用下面方式生成密碼文件：

/usr/local/apache/bin/htpasswd -c /opt/nginx/conf/htpasswd test

而後輸入兩次密碼後確認以後添加用戶成功。

要查看Nginx的運行狀態，能夠輸入http://ip/NginxStatus，輸入建立的用戶名和密碼就能夠看到Nginx的運行狀態：

Active connections: 1

server accepts handled requests

34561 35731 354399

Reading: 0 Writing: 3 Waiting: 0

Active connections表示當前活躍的鏈接數，第三行的三個數字表示 Nginx當前總共處理了34561個鏈接， 成功建立次握手， 總共處理了354399個請求。最後一行的Reading表示Nginx讀取到客戶端Header信息數， Writing表示Nginx返回給客戶端的Header信息數

，「Waiting」表示Nginx已經處理完，正在等候下一次請求指令時的駐留鏈接數。

在最後這段設置中，設置了虛擬主機的錯誤信息返回頁面，經過error_page指令能夠定製各類錯誤信息的返回頁面。在默認狀況下，Nginx會在主目錄的html目錄中查找指定的返回頁面，特別須要注意的是，這些錯誤信息的返回頁面大小必定要超過512K，否者會被ie瀏覽器替換爲ie默認的錯誤頁面。

  error_page  404              /404.html; error_page 500 502 503 504  /50x.html; location = /50x.html { root html; } } }