Nginx配置文件主要分成四部分：
main（全局設置）、server（主機設置）、upstream（負載均衡服務器設置）和 location（URL匹配特定位置的設置）。 main 部分設置的指令將影響其他所有設置; server 部分的指令主要用於指定主機和端口; upstream 指令主要用於負載均衡，設置一系列的後端服務器; location 部分用於匹配網頁位置。 這四者之間的關係式：server繼承main，location繼承server，upstream既不會繼承其他設置也不會被繼承。 在這四個部分當中，每個部分都包含若干指令，這些指令主要包含Nginx的主模塊指令、事件模塊指令、HTTP核心模塊指令，同時每個部分還可以使用其他HTTP模塊指令， 例如Http SSL模塊、HttpGzip Static模塊和Http Addition模塊等。
下面通過一個Nginx配置實例，詳細介紹下nginx.conf每個指令的含義。爲了能更清楚地瞭解Nginx的結構和每個配置選項的含義，這裏按照功能點將Nginx配置文件分爲7個部分逐次講解，下面就圍繞這7個部分進行介紹。
1.Nginx的全局配置
下面這段內容是對Nginx的全局屬性配置，代碼如下：
user nobody nobody; # 主模塊指令，指定Nginx Worker進程運行用戶以及用戶組，默認由nobody賬號運行。
worker_processes 4; # 主模塊指令，指定了Nginx要開啓的進程數。每個Nginx進程平均耗費10M~12M內存。根據經驗，一般指定一個進程足夠了，如果是多核CPU，建議指定和CPU的數量一樣的進程數即可。
error_log logs/error.log notice; # 主模塊指令，用來定義全局錯誤日誌文件。日誌輸出級別有debug、info、notice、warn、error、crit可供選擇，其中，debug輸出日誌最爲最詳細，而crit輸出日誌最少。
pid logs/nginx.pid; # 主模塊指令，用來指定進程id的存儲文件位置。
worker_rlimit_nofile 65535; # 用於指定一個nginx進程可以打開的最多文件描述符數目，這裏是65535，需要使用命令“ulimit -n 65535”來設置。
events{ # 設定Nginx的工作模式及連接數上限。
use epoll;
worker_connections 65536;
}
events{
use epoll; # 事件模塊指令，用來指定Nginx的工作模式。Nginx支持的工作模式有select、poll、kqueue、epoll、rtsig和/dev/poll。其中select和poll都是標準的工作模式，kqueue和epoll是高效的工作模式，不同的是epoll用在Linux平臺上，而kqueue用在BSD系統中。對於Linux系統，epoll工作模式是首選。
worker_connections 65536; # 事件模塊指令，用於定義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的設置才能生效。
}
2.HTTP服務器配置
接下來開始進行HTTP服務器設置。
下面這段內容是Nginx對HTTP服務器相關屬性的配置，代碼如下：
http{
include conf/mime.types; # 主模塊指令,實現對配置文件所包含的文件的設定，可以減少主配置文件的複雜度。類似於Apache中的include方法
default_type application/octet-stream; # 屬於HTTP核心模塊指令，這裏設定默認類型爲二進制流，也就是當文件類型未定義時使用這種方式，例如在沒有配置PHP環境時，Nginx是不予解析的，此時，用瀏覽器訪問PHP文件就會出現下載窗口。
log_format main '$remote_addr - $remote_user [$time_local]' # 是Nginx的HttpLog模塊指令，用於指定Nginx日誌的輸出格式。main爲此日誌輸出格式的名稱，可以在下面的access_log指令中引用。
'"$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; # 用於指定來自客戶端請求頭的headerbuffer大小。對於大多數請求，1K的緩衝區大小已經足夠，如果自定義了消息頭或有更大的Cookie，可以增加緩衝區大小。這裏設置爲32K。
large_client_header_buffers 4 32k; # 用來指定客戶端請求中較大的消息頭的緩存最大數量和大小， “4”爲個數，“128K”爲大小，最大緩存量爲4個128K。
Sendfile on; # 用於開啓高效文件傳輸模式
tcp_nopush on; # 防止網絡阻塞
tcp_nodelay on; # 防止網絡阻塞
keepalive_timeout 60; # 客戶端連接保持活動的超時時間。在超過這個時間之後，服務器會關閉該連接
client_header_timeout 10; # 客戶端請求頭讀取超時時間。如果超過這個時間，客戶端還沒有發送任何數據，Nginx將返回“Request time out（408）”錯誤。
client_body_timeout 10; # 客戶端請求主體讀取超時時間。如果超過這個時間，客戶端還沒有發送任何數據，Nginx將返回“Request time out（408）”錯誤，默認值是60。
send_timeout 10; # 響應客戶端的超時時間。這個超時僅限於兩個連接活動之間的時間，如果超過這個時間，客戶端沒有任何活動，Nginx將會關閉連接。3.HttpGzip模塊配置
下面配置Nginx的HttpGzip模塊。這個模塊支持在線實時壓縮輸出數據流。要查看是否安裝了此模塊，需要使用下面的命令:
/opt/nginx/sbin/nginx -V nginx version: nginx/0.7.65 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模塊,表示開啓GZIP壓縮，實時壓縮輸出數據流 gzip_min_length 1k; # 允許壓縮的頁面最小字節數，頁面字節數從header頭的Content-Length中獲取。默認值是0，不管頁面多大都進行壓縮。建議設置成大於1K的字節數，小於1K可能會越壓越大。 gzip_buffers 4 16k; # 表示申請4個單位爲16K的內存作爲壓縮結果流緩存，默認值是申請與原始數據大小相同的內存空間來存儲gzip壓縮結果。 gzip_http_version 1.1; # 設置識別HTTP協議版本，默認是1.1 gzip_comp_level 2; # 用來指定GZIP壓縮比，1 壓縮比最小，處理速度最快；9 壓縮比最大，傳輸速度快，但處理最慢，也比較消耗cpu資源。 gzip_types text/plain application/x-javascript text/css application/xml; #指定壓縮的類型，無論是否指定，“text/html”類型總是會被壓縮的。 gzip_vary on; # 可以讓前端的緩存服務器緩存經過GZIP壓縮的頁面，例如用Squid緩存經過Nginx壓縮的數據
4.負載均衡配置
下面設定負載均衡的服務器列表。
upstream ixdba.net{ # upstream是Nginx的HTTP Upstream模塊，這個模塊通過一個簡單的調度算法來實現客戶端IP到後端服務器的負載均衡。在上面的設定中，通過upstream指令指定了一個負載均衡器的名稱ixdba.net。這個名稱可以任意指定，在後面需要的地方直接調用即可
ip_hash; # 每個請求按訪問IP的hash結果分配，這樣來自同一個IP的訪客固定訪問一個後端服務器，有效解決了動態網頁存在的session共享問題
server 192.168.12.133:80;
server 192.168.12.134:80 down;
server 192.168.12.135:8009 max_fails=3 fail_timeout=20s;
server 192.168.12.136:8080;
}Nginx的負載均衡模塊目前支持4種調度算法，下面進行分別介紹，其中後兩項屬於第三方的調度方法。
1)輪詢(默認) 每個請求按時間順序逐一分配到不同的後端服務器，如果後端某臺服務器宕機，故障系統被自動剔除，使用戶訪問不受影響。 2)Weight 指定輪詢權值，Weight值越大，分配到的訪問機率越高，主要用於後端每個服務器性能不均的情況下。 3)ip_hash 每個請求按訪問IP的hash結果分配，這樣來自同一個IP的訪客固定訪問一個後端服務器，有效解決了動態網頁存在的session共享問題。 4)fair 比上面兩個更加智能的負載均衡算法。此種算法可以依據頁面大小和加載時間長短智能地進行負載均衡，也就是根據後端服務器的響應時間來分配請求，響應時間短的優先分配。Nginx本身是不支持fair的，如果需要使用這種調度算法，必須下載Nginx的upstream_fair模塊。 5)url_hash 按訪問url的hash結果來分配請求，使每個url定向到同一個後端服務器，可以進一步提高後端緩存服務器的效率。Nginx本身是不支持url_hash的，如果需要使用這種調度算法，必須安裝Nginx 的hash軟件包。
在HTTP Upstream模塊中，可以通過server指令指定後端服務器的IP地址和端口，同時還可以設定每個後端服務器在負載均衡調度中的狀態。常用的狀態有： down 表示當前的server暫時不參與負載均衡。 backup 預留的備份機器。當其他所有的非backup機器出現故障或者忙的時候，纔會請求backup機器，因此這臺機器的壓力最輕。 weight 權重，默認爲1。權值越高被分配到的機率越大 max_fails 允許請求失敗的次數，默認爲1。當超過最大次數時，返回proxy_next_upstream 模塊定義的錯誤。 fail_timeout 在經歷了max_fails次失敗後，暫停服務的時間。 max_fails可以和fail_timeout一起使用。 注意,當負載調度算法爲ip_hash時，後端服務器在負載均衡調度中的狀態不能是weight和backup。
5.server虛擬主機配置
下面介紹對虛擬主機的配置。建議將對虛擬主機進行配置的內容寫進另外一個文件，然後通過include指令包含進來，這樣更便於維護和管理。
server{ # 標誌定義虛擬主機開始
listen 80; # 指定虛擬主機的服務端口
server_name 192.168.12.188 ; # 用來指定IP地址或者域名，多個域名之間用空格分開
index index.html index.htm index.jsp;# 用於設定訪問的默認首頁地址
root /web/wwwroot/www.ixdba.net; # 用於指定虛擬主機的網頁根目錄，這個目錄可以是相對路徑，也可以是絕對路徑
charset gb2312; # 設置網頁的默認編碼格式
access_log logs/www.ixdba.net.access.log main; # access_log用來指定此虛擬主機的訪問日誌存放路徑，最後的main用於指定訪問日誌的輸出格式。6.URL匹配配置
URL地址匹配是進行Nginx配置中最靈活的部分。 location支持正則表達式匹配，也支持條件判斷匹配，用戶可以通過location指令實現Nginx對動、靜態網頁進行過濾處理。
以下這段設置是通過location指令來對網頁URL進行分析處理，所有擴展名以.gif、.jpg、.jpeg、.png、.bmp、.swf結尾的
靜態文件都交給nginx處理，而expires用來指定靜態文件的過期時間，這裏是30天。
location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$ {
root /web/wwwroot/www.ixdba.net;
expires 30d;
}
以下這段設置是將upload和html下的所有文件都交給nginx來處理，當然 upload和 html目錄包含在/web/wwwroot/www.ixdba.net目錄中。
location ~ ^/(upload|html)/ {
root /web/wwwroot/www.ixdba.net;
expires 30d;
}
在最後這段設置中，location是對此虛擬主機下動態網頁的過濾處理，也就是將所有以.jsp爲後綴的文件都交給本機的8080端口處理。
location ~ .*.jsp$ {
index index.jsp;
proxy_pass http:#localhost:8080;
}7.StubStatus模塊配置
StubStatus模塊能夠獲取Nginx自上次啓動以來的工作狀態，此模塊非核心模塊，需要在Nginx編譯安裝時手工指定才能使用此功能。
以下指令實指定啓用獲取Nginx工作狀態的功能。
location /NginxStatus {
stub_status on; #“on”表示啓用StubStatus的工作狀態統計功能
access_log logs/NginxStatus.log; # 用來指定StubStatus模塊的訪問日誌文件
auth_basic "NginxStatus"; # 認證機制
auth_basic_user_file ../htpasswd; # 指定認證的密碼文件，由於Nginx的auth_basic認證採用的是與Apache兼容的密碼文件，因此需要用Apache的htpasswd命令來生成密碼文件
例如要添加一個webadmin用戶，可以使用下面方式生成密碼文件：
/usr/local/apache/bin/htpasswd -c /opt/nginx/conf/htpasswd webadmin
會得到以下提示信息：
New password:
輸入密碼之後，系統會要求再次輸入密碼。確認之後添加用戶成功。
}要查看Nginx的運行狀態，可以輸入http:#ip/ NginxStatus，然後輸入剛剛創建的用戶名和密碼就可以看到如下信息：
Active connections: 1 # 表示當前活躍的連接數
server accepts handled requests #
393411 393411 393799 # Nginx當前總共處理了393411個連接， 成功創建393411次握手， 總共處理了393799個請求
Reading: 0 Writing: 1 Waiting: 0 # 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;
}
}
}