Nginx配置文件詳解

Nginx的主配置文件是nginx.conf，這個配置文件一共由三部分組成，分別爲全局塊、events塊和http塊。在http塊中，又包含http全局塊、多個server塊。每一個server塊中，能夠包含server全局塊和多個location塊。在同一配置塊中嵌套的配置塊，各個之間不存在次序關係。

配置文件支持大量可配置的指令，絕大多數指令不是特定屬於某一個塊的。同一個指令放在不一樣層級的塊中，其做用域也不一樣，通常狀況下，高一級塊中的指令能夠做用於自身所在的塊和此塊包含的全部低層級塊。若是某個指令在兩個不一樣層級的塊中同時出現，則採用「就近原則」，即以較低層級塊中的配置爲準。好比，某指令同時出如今http全局塊中和server塊中，而且配置不一樣，則應該以server塊中的配置爲準。

整個配置文件的結構大體以下：

#全局塊
#user  nobody;
worker_processes  1;

#event塊
events {
    worker_connections  1024;
}

#http塊
http {
    #http全局塊
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
    #server塊
    server {
        #server全局塊
        listen       8000;
        server_name  localhost;
        #location塊
        location / {
            root   html;
            index  index.html index.htm;
        }
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
    }
    #這邊能夠有多個server塊
    server {
      ...
    }
}

全局塊

全局塊是默認配置文件從開始到events塊之間的一部份內容，主要設置一些影響Nginx服務器總體運行的配置指令，所以，這些指令的做用域是Nginx服務器全局。

一般包括配置運行Nginx服務器的用戶（組）、容許生成的worker process數、Nginx進程PID存放路徑、日誌的存放路徑和類型以及配置文件引入等。

# 指定能夠運行nginx服務的用戶和用戶組，只能在全局塊配置
# user [user] [group]
# 將user指令註釋掉，或者配置成nobody的話全部用戶均可以運行
# user nobody nobody;
# user指令在Windows上不生效，若是你制定具體用戶和用戶組會報小面警告
# nginx: [warn] "user" is not supported, ignored in D:\software\nginx-1.18.0/conf/nginx.conf:2

# 指定工做線程數，能夠制定具體的進程數，也可以使用自動模式，這個指令只能在全局塊配置
# worker_processes number | auto；
# 列子：指定4個工做線程，這種狀況下會生成一個master進程和4個worker進程
# worker_processes 4;

# 指定pid文件存放的路徑，這個指令只能在全局塊配置
# pid logs/nginx.pid;

# 指定錯誤日誌的路徑和日誌級別，此指令能夠在全局塊、http塊、server塊以及location塊中配置。(在不一樣的塊配置有啥區別？？)
# 其中debug級別的日誌須要編譯時使用--with-debug開啓debug開關
# error_log [path] [debug | info | notice | warn | error | crit | alert | emerg] 
# error_log  logs/error.log  notice;
# error_log  logs/error.log  info;

events塊

events塊涉及的指令主要影響Nginx服務器與用戶的網絡鏈接。經常使用到的設置包括是否開啓對多worker process下的網絡鏈接進行序列化，是否容許同時接收多個網絡鏈接，選取哪一種事件驅動模型處理鏈接請求，每一個worker process能夠同時支持的最大鏈接數等。

這一部分的指令對Nginx服務器的性能影響較大，在實際配置中應該根據實際狀況靈活調整。

# 當某一時刻只有一個網絡鏈接到來時，多個睡眠進程會被同時叫醒，但只有一個進程可得到鏈接。若是每次喚醒的進程數目太多，會影響一部分系統性能。在Nginx服務器的多進程下，就有可能出現這樣的問題。
# 開啓的時候，將會對多個Nginx進程接收鏈接進行序列化，防止多個進程對鏈接的爭搶
# 默認是開啓狀態，只能在events塊中進行配置
# accept_mutex on | off;

# 若是multi_accept被禁止了，nginx一個工做進程只能同時接受一個新的鏈接。不然，一個工做進程能夠同時接受全部的新鏈接。 
# 若是nginx使用kqueue鏈接方法，那麼這條指令會被忽略，由於這個方法會報告在等待被接受的新鏈接的數量。
# 默認是off狀態，只能在event塊配置
# multi_accept on | off;

# 指定使用哪一種網絡IO模型，method可選擇的內容有：select、poll、kqueue、epoll、rtsig、/dev/poll以及eventport，通常操做系統不是支持上面全部模型的。
# 只能在events塊中進行配置
# use method
# use epoll

# 設置容許每個worker process同時開啓的最大鏈接數，當每一個工做進程接受的鏈接數超過這個值時將再也不接收鏈接
# 當全部的工做進程都接收滿時，鏈接進入logback，logback滿後鏈接被拒絕
# 只能在events塊中進行配置
# 注意：這個值不能超過超過系統支持打開的最大文件數，也不能超過單個進程支持打開的最大文件數，具體能夠參考這篇文章：https://cloud.tencent.com/developer/article/1114773
# worker_connections  1024;

http塊

http塊是Nginx服務器配置中的重要部分，代理、緩存和日誌定義等絕大多數的功能和第三方模塊的配置均可以放在這個模塊中。

前面已經提到，http塊中能夠包含本身的全局塊，也能夠包含server塊，server塊中又能夠進一步包含location塊，在本書中咱們使用「http全局塊」來表示http中本身的全局塊，即http塊中不包含在server塊中的部分。

能夠在http全局塊中配置的指令包括文件引入、MIME-Type定義、日誌自定義、是否使用sendfile傳輸文件、鏈接超時時間、單鏈接請求數上限等。

# 經常使用的瀏覽器中，能夠顯示的內容有HTML、XML、GIF及Flash等種類繁多的文本、媒體等資源，瀏覽器爲區分這些資源，須要使用MIME Type。換言之，MIME Type是網絡資源的媒體類型。Nginx服務器做爲Web服務器，必須可以識別前端請求的資源類型。

# include指令，用於包含其餘的配置文件，能夠放在配置文件的任何地方，可是要注意你包含進來的配置文件必定符合配置規範，好比說你include進來的配置是worker_processes指令的配置，而你將這個指令包含到了http塊中，着確定是不行的，上面已經介紹過worker_processes指令只能在全局塊中。
# 下面的指令將mime.types包含進來，mime.types和ngin.cfg同級目錄，不一樣級的話須要指定具體路徑
# include  mime.types;

# 配置默認類型，若是不加此指令，默認值爲text/plain。
# 此指令還能夠在http塊、server塊或者location塊中進行配置。
# default_type  application/octet-stream;

# access_log配置，此指令能夠在http塊、server塊或者location塊中進行設置
# 在全局塊中，咱們介紹過errer_log指令，其用於配置Nginx進程運行時的日誌存放和級別，此處所指的日誌與常規的不一樣，它是指記錄Nginx服務器提供服務過程應答前端請求的日誌
# access_log path [format [buffer=size]]
# 若是你要關閉access_log,你可使用下面的命令
# access_log off;

# log_format指令，用於定義日誌格式，此指令只能在http塊中進行配置
# log_format  main '$remote_addr - $remote_user [$time_local] "$request" '
#                  '$status $body_bytes_sent "$http_referer" '
#                  '"$http_user_agent" "$http_x_forwarded_for"';
# 定義了上面的日誌格式後，能夠如下面的形式使用日誌
# access_log  logs/access.log  main;

# 開啓關閉sendfile方式傳輸文件，能夠在http塊、server塊或者location塊中進行配置
# sendfile  on | off;

# 設置sendfile最大數據量,此指令能夠在http塊、server塊或location塊中配置
# sendfile_max_chunk size;
# 其中，size值若是大於0，Nginx進程的每一個worker process每次調用sendfile()傳輸的數據量最大不能超過這個值(這裏是128k，因此每次不能超過128k)；若是設置爲0，則無限制。默認值爲0。
# sendfile_max_chunk 128k;

# 配置鏈接超時時間,此指令能夠在http塊、server塊或location塊中配置。
# 與用戶創建會話鏈接後，Nginx服務器能夠保持這些鏈接打開一段時間
# timeout，服務器端對鏈接的保持時間。默認值爲75s;header_timeout，可選項，在應答報文頭部的Keep-Alive域設置超時時間：「Keep-Alive:timeout= header_timeout」。報文中的這個指令能夠被Mozilla或者Konqueror識別。
# keepalive_timeout timeout [header_timeout]
# 下面配置的含義是，在服務器端保持鏈接的時間設置爲120 s，發給用戶端的應答報文頭部中Keep-Alive域的超時時間設置爲100 s。
# keepalive_timeout 120s 100s

# 配置單鏈接請求數上限，此指令能夠在http塊、server塊或location塊中配置。
# Nginx服務器端和用戶端創建會話鏈接後，用戶端經過此鏈接發送請求。指令keepalive_requests用於限制用戶經過某一鏈接向Nginx服務器發送請求的次數。默認是100
# keepalive_requests number;

server塊

server塊和「虛擬主機」的概念有密切聯繫。

虛擬主機，又稱虛擬服務器、主機空間或是網頁空間，它是一種技術。該技術是爲了節省互聯網服務器硬件成本而出現的。這裏的「主機」或「空間」是由實體的服務器延伸而來，硬件系統能夠基於服務器羣，或者單個服務器等。虛擬主機技術主要應用於HTTP、FTP及EMAIL等多項服務，將一臺服務器的某項或者所有服務內容邏輯劃分爲多個服務單位，對外表現爲多個服務器，從而充分利用服務器硬件資源。從用戶角度來看，一臺虛擬主機和一臺獨立的硬件主機是徹底同樣的。

在使用Nginx服務器提供Web服務時，利用虛擬主機的技術就能夠避免爲每個要運行的網站提供單獨的Nginx服務器，也無需爲每一個網站對應運行一組Nginx進程。虛擬主機技術使得Nginx服務器能夠在同一臺服務器上只運行一組Nginx進程，就能夠運行多個網站。

在前面提到過，每個http塊均可以包含多個server塊，而每一個server塊就至關於一臺虛擬主機，它內部可有多臺主機聯合提供服務，一塊兒對外提供在邏輯上關係密切的一組服務（或網站）。

和http塊相同，server塊也能夠包含本身的全局塊，同時能夠包含多個location塊。在server全局塊中，最多見的兩個配置項是本虛擬主機的監聽配置和本虛擬主機的名稱或IP配置。

listen指令

server塊中最重要的指令就是listen指令，這個指令有三種配置語法。這個指令默認的配置值是：listen *:80 | *:8000；只能在server塊種配置這個指令。

//第一種
listen address[:port] [default_server] [ssl] [http2 | spdy] [proxy_protocol] [setfib=number] [fastopen=number] [backlog=number] [rcvbuf=size] [sndbuf=size] [accept_filter=filter] [deferred] [bind] [ipv6only=on|off] [reuseport] [so_keepalive=on|off|[keepidle]:[keepintvl]:[keepcnt]];

//第二種
listen port [default_server] [ssl] [http2 | spdy] [proxy_protocol] [setfib=number] [fastopen=number] [backlog=number] [rcvbuf=size] [sndbuf=size] [accept_filter=filter] [deferred] [bind] [ipv6only=on|off] [reuseport] [so_keepalive=on|off|[keepidle]:[keepintvl]:[keepcnt]];

//第三種（能夠不用重點關注）
listen unix:path [default_server] [ssl] [http2 | spdy] [proxy_protocol] [backlog=number] [rcvbuf=size] [sndbuf=size] [accept_filter=filter] [deferred] [bind] [so_keepalive=on|off|[keepidle]:[keepintvl]:[keepcnt]];

listen指令的配置很是靈活，能夠單獨制定ip，單獨指定端口或者同時指定ip和端口。

listen 127.0.0.1:8000;  #只監聽來自127.0.0.1這個IP，請求8000端口的請求
listen 127.0.0.1; #只監聽來自127.0.0.1這個IP，請求80端口的請求（不指定端口，默認80）
listen 8000; #監聽來自全部IP，請求8000端口的請求
listen *:8000; #和上面效果同樣
listen localhost:8000; #和第一種效果一致

關於上面的一些重要參數作以下說明：

• address：監聽的IP地址（請求來源的IP地址），若是是IPv6的地址，須要使用中括號「[]」括起來，好比[fe80::1]等。
• port：端口號，若是隻定義了IP地址沒有定義端口號，就使用80端口。這邊須要作個說明：要是你壓根沒配置listen指令，那麼那麼若是nginx以超級用戶權限運行，則使用*:80，不然使用*:8000。多個虛擬主機能夠同時監聽同一個端口,可是server_name須要設置成不同；
• default_server：假如經過Host沒匹配到對應的虛擬主機，則經過這臺虛擬主機處理。具體的能夠參考這篇文章，寫的不錯。
• backlog=number：設置監聽函數listen()最多容許多少網絡鏈接同時處於掛起狀態，在FreeBSD中默認爲-1，其餘平臺默認爲511。
• accept_filter=filter，設置監聽端口對請求的過濾，被過濾的內容不能被接收和處理。本指令只在FreeBSD和NetBSD 5.0+平臺下有效。filter能夠設置爲dataready或httpready，感興趣的讀者能夠參閱Nginx的官方文檔。
• bind：標識符，使用獨立的bind()處理此address:port；通常狀況下，對於端口相同而IP地址不一樣的多個鏈接，Nginx服務器將只使用一個監聽命令，並使用bind()處理端口相同的全部鏈接。
• ssl：標識符，設置會話鏈接使用SSL模式進行，此標識符和Nginx服務器提供的HTTPS服務有關。

listen指令的使用看起來比較複雜，但其實在通常的使用過程當中，相對來講比較簡單，並不會進行太複雜的配置。

server_name指令

用於配置虛擬主機的名稱。語法是：

Syntax:	server_name name ...;
Default:	
server_name "";
Context:	server

對於name 來講，能夠只有一個名稱，也能夠由多個名稱並列，之間用空格隔開。每一個名字就是一個域名，由兩段或者三段組成，之間由點號「.」隔開。好比

server_name myserver.com www.myserver.com

在該例中，此虛擬主機的名稱設置爲myserver.com或www. myserver.com。Nginx服務器規定，第一個名稱做爲此虛擬主機的主要名稱。

在name 中可使用通配符「*」，但通配符只能用在由三段字符串組成的名稱的首段或尾段，或者由兩段字符串組成的名稱的尾段，如：

server_name myserver.* *.myserver.com

另外name還支持正則表達式的形式。這邊就不詳細展開了。

因爲server_name指令支持使用通配符和正則表達式兩種配置名稱的方式，所以在包含有多個虛擬主機的配置文件中，可能會出現一個名稱被多個虛擬主機的server_name匹配成功。那麼，來自這個名稱的請求到底要交給哪一個虛擬主機處理呢？Nginx服務器作出以下規定：

a. 對於匹配方式不一樣的，按照如下的優先級選擇虛擬主機，排在前面的優先處理請求。

• ① 準確匹配server_name
• ② 通配符在開始時匹配server_name成功
• ③ 通配符在結尾時匹配server_name成功
• ④ 正則表達式匹配server_name成功

b. 在以上四種匹配方式中，若是server_name被處於同一優先級的匹配方式屢次匹配成功，則首次匹配成功的虛擬主機處理請求。

有時候咱們但願使用基於IP地址的虛擬主機配置，好比訪問192.168.1.31有虛擬主機1處理，訪問192.168.1.32由虛擬主機2處理。

這時咱們要先網卡綁定別名，好比說網卡以前綁定的IP是192.168.1.30，如今將192.168.1.31和192.168.1.32這兩個IP都綁定到這個網卡上，那麼請求這個兩個IP的請求才會到達這臺機器。

綁定別名後進行如下配置便可：

http
{
	{
	   listen:  80;
	   server_name:  192.168.1.31;
     ...
	}
	{
	   listen:  80;
	   server_name:  192.168.1.32;
     ...
	}
}

location塊

每一個server塊中能夠包含多個location塊。在整個Nginx配置文檔中起着重要的做用，並且Nginx服務器在許多功能上的靈活性每每在location指令的配置中體現出來。

location塊的主要做用是，基於Nginx服務器接收到的請求字符串（例如， server_name/uri-string），對除虛擬主機名稱（也能夠是IP別名，後文有詳細闡述）以外的字符串（前例中「/uri-string」部分）進行匹配，對特定的請求進行處理。地址定向、數據緩存和應答控制等功能都是在這部分實現。許多第三方模塊的配置也是在location塊中提供功能。

在Nginx的官方文檔中定義的location的語法結構爲：

location [ = | ~ | ~* | ^~ ] uri { ... }

其中，uri變量是待匹配的請求字符串，能夠是不含正則表達的字符串，如/myserver.php等；也能夠是包含有正則表達的字符串，如 .php$（表示以.php結尾的URL）等。爲了下文敘述方便，咱們約定，不含正則表達的uri稱爲「標準uri」，使用正則表達式的uri稱爲「正則uri」。

其中方括號裏的部分，是可選項，用來改變請求字符串與 uri 的匹配方式。在介紹四種標識的含義以前，咱們須要先了解不添加此選項時，Nginx服務器是如何在server塊中搜索並使用location塊的uri和請求字符串匹配的。

在不添加此選項時，Nginx服務器首先在server塊的多個location塊中搜索是否有標準uri和請求字符串匹配，若是有多個能夠匹配，就記錄匹配度最高的一個。而後，服務器再用location塊中的正則uri和請求字符串匹配，當第一個正則uri匹配成功，結束搜索，並使用這個location塊處理此請求；若是正則匹配所有失敗，就使用剛纔記錄的匹配度最高的location塊處理此請求。

瞭解了上面的內容，就能夠解釋可選項中各個標識的含義了：

• 「=」，用於標準uri前，要求請求字符串與uri嚴格匹配。若是已經匹配成功，就中止繼續向下搜索並當即處理此請求。

• 「^～」，用於標準uri前，要求Nginx服務器找到標識uri和請求字符串匹配度最高的location後，當即使用此location處理請求，而再也不使用location塊中的正則uri和請求字符串作匹配。

• 「～」，用於表示uri包含正則表達式，而且區分大小寫。

• 「～*」，用於表示uri包含正則表達式，而且不區分大小寫。注意若是uri包含正則表達式，就必需要使用「～」或者「～*」標識。

咱們知道，在瀏覽器傳送URI時對一部分字符進行URL編碼，好比空格被編碼爲「%20」，問號被編碼爲「%3f」等。「^{～」有一個特色是，它對uri中的這些符號將會進行編碼處理。好比，若是location塊收到的URI爲「/html/%20/data」，則當Nginx服務器搜索到配置爲「}～ /html/ /data」的location時，能夠匹配成功。

root指令

這個指令用於設置請求尋找資源的跟目錄，此指令能夠在http塊、server塊或者location塊中配置。因爲使用Nginx服務器多數狀況下要配置多個location塊對不一樣的請求分別作出處理，所以該指令一般在location塊中進行設置。

root path

path變量中能夠包含Nginx服務器預設的大多數變量，只有$document_root和$realpath_root不可使用。

alisa指令

index指令

error_page指令

一點說明

上面列舉了Nignx中全局塊、event塊和http塊的一些配置指令，可是Nginx的指令遠遠不止這些。其實這邊最主要的仍是講解整個配置文件的結構，若是你們要看比較全的指令介紹、模塊介紹的話，建議去Nginx的官網。

一個配置文件的列子

######Nginx配置文件nginx.conf中文詳解#####

#定義Nginx運行的用戶和用戶組
user www www;

#nginx進程數，建議設置爲等於CPU總核心數。
worker_processes 8;
 
#全局錯誤日誌定義類型，[ debug | info | notice | warn | error | crit ]
error_log /usr/local/nginx/logs/error.log info;

#進程pid文件
pid /usr/local/nginx/logs/nginx.pid;

#指定進程能夠打開的最大描述符：數目
#工做模式與鏈接數上限
#這個指令是指當一個nginx進程打開的最多文件描述符數目，理論值應該是最多打開文件數（ulimit -n）與nginx進程數相除，可是nginx分配請求並非那麼均勻，因此最好與ulimit -n 的值保持一致。
#如今在linux 2.6內核下開啓文件打開數爲65535，worker_rlimit_nofile就相應應該填寫65535。
#這是由於nginx調度時分配請求到進程並非那麼的均衡，因此假如填寫10240，總併發量達到3-4萬時就有進程可能超過10240了，這時會返回502錯誤。
worker_rlimit_nofile 65535;


events
{
    #參考事件模型，use [ kqueue | rtsig | epoll | /dev/poll | select | poll ]; epoll模型
    #是Linux 2.6以上版本內核中的高性能網絡I/O模型，linux建議epoll，若是跑在FreeBSD上面，就用kqueue模型。
    #補充說明：
    #與apache相類，nginx針對不一樣的操做系統，有不一樣的事件模型
    #A）標準事件模型
    #Select、poll屬於標準事件模型，若是當前系統不存在更有效的方法，nginx會選擇select或poll
    #B）高效事件模型
    #Kqueue：使用於FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 和 MacOS X.使用雙處理器的MacOS X系統使用kqueue可能會形成內核崩潰。
    #Epoll：使用於Linux內核2.6版本及之後的系統。
    #/dev/poll：使用於Solaris 7 11/99+，HP/UX 11.22+ (eventport)，IRIX 6.5.15+ 和 Tru64 UNIX 5.1A+。
    #Eventport：使用於Solaris 10。 爲了防止出現內核崩潰的問題， 有必要安裝安全補丁。
    use epoll;

    #單個進程最大鏈接數（最大鏈接數=鏈接數*進程數）
    #根據硬件調整，和前面工做進程配合起來用，儘可能大，可是別把cpu跑到100%就行。每一個進程容許的最多鏈接數，理論上每臺nginx服務器的最大鏈接數爲。
    worker_connections 65535;

    #keepalive超時時間。
    keepalive_timeout 60;

    #客戶端請求頭部的緩衝區大小。這個能夠根據你的系統分頁大小來設置，通常一個請求頭的大小不會超過1k，不過因爲通常系統分頁都要大於1k，因此這裏設置爲分頁大小。
    #分頁大小能夠用命令getconf PAGESIZE 取得。
    #[root@web001 ~]# getconf PAGESIZE
    #4096
    #但也有client_header_buffer_size超過4k的狀況，可是client_header_buffer_size該值必須設置爲「系統分頁大小」的整倍數。
    client_header_buffer_size 4k;

    #這個將爲打開文件指定緩存，默認是沒有啓用的，max指定緩存數量，建議和打開文件數一致，inactive是指通過多長時間文件沒被請求後刪除緩存。
    open_file_cache max=65535 inactive=60s;

    #這個是指多長時間檢查一次緩存的有效信息。
    #語法:open_file_cache_valid time 默認值:open_file_cache_valid 60 使用字段:http, server, location 這個指令指定了什麼時候須要檢查open_file_cache中緩存項目的有效信息.
    open_file_cache_valid 80s;

    #open_file_cache指令中的inactive參數時間內文件的最少使用次數，若是超過這個數字，文件描述符一直是在緩存中打開的，如上例，若是有一個文件在inactive時間內一次沒被使用，它將被移除。
    #語法:open_file_cache_min_uses number 默認值:open_file_cache_min_uses 1 使用字段:http, server, location  這個指令指定了在open_file_cache指令無效的參數中必定的時間範圍內可使用的最小文件數,若是使用更大的值,文件描述符在cache中老是打開狀態.
    open_file_cache_min_uses 1;
    
    #語法:open_file_cache_errors on | off 默認值:open_file_cache_errors off 使用字段:http, server, location 這個指令指定是否在搜索一個文件時記錄cache錯誤.
    open_file_cache_errors on;
}
 
 
 
#設定http服務器，利用它的反向代理功能提供負載均衡支持
http
{
    #文件擴展名與文件類型映射表
    include mime.types;

    #默認文件類型
    default_type application/octet-stream;

    #默認編碼
    #charset utf-8;

    #服務器名字的hash表大小
    #保存服務器名字的hash表是由指令server_names_hash_max_size 和server_names_hash_bucket_size所控制的。參數hash bucket size老是等於hash表的大小，而且是一路處理器緩存大小的倍數。在減小了在內存中的存取次數後，使在處理器中加速查找hash表鍵值成爲可能。若是hash bucket size等於一路處理器緩存的大小，那麼在查找鍵的時候，最壞的狀況下在內存中查找的次數爲2。第一次是肯定存儲單元的地址，第二次是在存儲單元中查找鍵 值。所以，若是Nginx給出須要增大hash max size 或 hash bucket size的提示，那麼首要的是增大前一個參數的大小.
    server_names_hash_bucket_size 128;

    #客戶端請求頭部的緩衝區大小。這個能夠根據你的系統分頁大小來設置，通常一個請求的頭部大小不會超過1k，不過因爲通常系統分頁都要大於1k，因此這裏設置爲分頁大小。分頁大小能夠用命令getconf PAGESIZE取得。
    client_header_buffer_size 32k;

    #客戶請求頭緩衝大小。nginx默認會用client_header_buffer_size這個buffer來讀取header值，若是header過大，它會使用large_client_header_buffers來讀取。
    large_client_header_buffers 4 64k;

    #設定經過nginx上傳文件的大小
    client_max_body_size 8m;

    #開啓高效文件傳輸模式，sendfile指令指定nginx是否調用sendfile函數來輸出文件，對於普通應用設爲 on，若是用來進行下載等應用磁盤IO重負載應用，可設置爲off，以平衡磁盤與網絡I/O處理速度，下降系統的負載。注意：若是圖片顯示不正常把這個改爲off。
    #sendfile指令指定 nginx 是否調用sendfile 函數（zero copy 方式）來輸出文件，對於普通應用，必須設爲on。若是用來進行下載等應用磁盤IO重負載應用，可設置爲off，以平衡磁盤與網絡IO處理速度，下降系統uptime。
    sendfile on;

    #開啓目錄列表訪問，合適下載服務器，默認關閉。
    autoindex on;

    #此選項容許或禁止使用socke的TCP_CORK的選項，此選項僅在使用sendfile的時候使用
    tcp_nopush on;
     
    tcp_nodelay on;

    #長鏈接超時時間，單位是秒
    keepalive_timeout 120;

    #FastCGI相關參數是爲了改善網站的性能：減小資源佔用，提升訪問速度。下面參數看字面意思都能理解。
    fastcgi_connect_timeout 300;
    fastcgi_send_timeout 300;
    fastcgi_read_timeout 300;
    fastcgi_buffer_size 64k;
    fastcgi_buffers 4 64k;
    fastcgi_busy_buffers_size 128k;
    fastcgi_temp_file_write_size 128k;

    #gzip模塊設置
    gzip on; #開啓gzip壓縮輸出
    gzip_min_length 1k;    #最小壓縮文件大小
    gzip_buffers 4 16k;    #壓縮緩衝區
    gzip_http_version 1.0;    #壓縮版本（默認1.1，前端若是是squid2.5請使用1.0）
    gzip_comp_level 2;    #壓縮等級
    gzip_types text/plain application/x-javascript text/css application/xml;    #壓縮類型，默認就已經包含textml，因此下面就不用再寫了，寫上去也不會有問題，可是會有一個warn。
    gzip_vary on;

    #開啓限制IP鏈接數的時候須要使用
    #limit_zone crawler $binary_remote_addr 10m;



    #負載均衡配置
    upstream jh.w3cschool.cn {
     
        #upstream的負載均衡，weight是權重，能夠根據機器配置定義權重。weigth參數表示權值，權值越高被分配到的概率越大。
        server 192.168.80.121:80 weight=3;
        server 192.168.80.122:80 weight=2;
        server 192.168.80.123:80 weight=3;

        #nginx的upstream目前支持4種方式的分配
        #一、輪詢（默認）
        #每一個請求按時間順序逐一分配到不一樣的後端服務器，若是後端服務器down掉，能自動剔除。
        #二、weight
        #指定輪詢概率，weight和訪問比率成正比，用於後端服務器性能不均的狀況。
        #例如：
        #upstream bakend {
        #    server 192.168.0.14 weight=10;
        #    server 192.168.0.15 weight=10;
        #}
        #二、ip_hash
        #每一個請求按訪問ip的hash結果分配，這樣每一個訪客固定訪問一個後端服務器，能夠解決session的問題。
        #例如：
        #upstream bakend {
        #    ip_hash;
        #    server 192.168.0.14:88;
        #    server 192.168.0.15:80;
        #}
        #三、fair（第三方）
        #按後端服務器的響應時間來分配請求，響應時間短的優先分配。
        #upstream backend {
        #    server server1;
        #    server server2;
        #    fair;
        #}
        #四、url_hash（第三方）
        #按訪問url的hash結果來分配請求，使每一個url定向到同一個後端服務器，後端服務器爲緩存時比較有效。
        #例：在upstream中加入hash語句，server語句中不能寫入weight等其餘的參數，hash_method是使用的hash算法
        #upstream backend {
        #    server squid1:3128;
        #    server squid2:3128;
        #    hash $request_uri;
        #    hash_method crc32;
        #}

        #tips:
        #upstream bakend{#定義負載均衡設備的Ip及設備狀態}{
        #    ip_hash;
        #    server 127.0.0.1:9090 down;
        #    server 127.0.0.1:8080 weight=2;
        #    server 127.0.0.1:6060;
        #    server 127.0.0.1:7070 backup;
        #}
        #在須要使用負載均衡的server中增長 proxy_pass http://bakend/;

        #每一個設備的狀態設置爲:
        #1.down表示單前的server暫時不參與負載
        #2.weight爲weight越大，負載的權重就越大。
        #3.max_fails：容許請求失敗的次數默認爲1.當超過最大次數時，返回proxy_next_upstream模塊定義的錯誤
        #4.fail_timeout:max_fails次失敗後，暫停的時間。
        #5.backup： 其它全部的非backup機器down或者忙的時候，請求backup機器。因此這臺機器壓力會最輕。

        #nginx支持同時設置多組的負載均衡，用來給不用的server來使用。
        #client_body_in_file_only設置爲On 能夠講client post過來的數據記錄到文件中用來作debug
        #client_body_temp_path設置記錄文件的目錄 能夠設置最多3層目錄
        #location對URL進行匹配.能夠進行重定向或者進行新的代理 負載均衡
    }
     
     
     
    #虛擬主機的配置
    server
    {
        #監聽端口
        listen 80;

        #域名能夠有多個，用空格隔開
        server_name www.w3cschool.cn w3cschool.cn;
        index index.html index.htm index.php;
        root /data/www/w3cschool;

        #對******進行負載均衡
        location ~ .*.(php|php5)?$
        {
            fastcgi_pass 127.0.0.1:9000;
            fastcgi_index index.php;
            include fastcgi.conf;
        }
         
        #圖片緩存時間設置
        location ~ .*.(gif|jpg|jpeg|png|bmp|swf)$
        {
            expires 10d;
        }
         
        #JS和CSS緩存時間設置
        location ~ .*.(js|css)?$
        {
            expires 1h;
        }
         
        #日誌格式設定
        #$remote_addr與$http_x_forwarded_for用以記錄客戶端的ip地址；
        #$remote_user：用來記錄客戶端用戶名稱；
        #$time_local： 用來記錄訪問時間與時區；
        #$request： 用來記錄請求的url與http協議；
        #$status： 用來記錄請求狀態；成功是200，
        #$body_bytes_sent ：記錄發送給客戶端文件主體內容大小；
        #$http_referer：用來記錄從那個頁面連接訪問過來的；
        #$http_user_agent：記錄客戶瀏覽器的相關信息；
        #一般web服務器放在反向代理的後面，這樣就不能獲取到客戶的IP地址了，經過$remote_add拿到的IP地址是反向代理服務器的iP地址。反向代理服務器在轉發請求的http頭信息中，能夠增長x_forwarded_for信息，用以記錄原有客戶端的IP地址和原來客戶端的請求的服務器地址。
        log_format access '$remote_addr - $remote_user [$time_local] "$request" '
        '$status $body_bytes_sent "$http_referer" '
        '"$http_user_agent" $http_x_forwarded_for';
         
        #定義本虛擬主機的訪問日誌
        access_log  /usr/local/nginx/logs/host.access.log  main;
        access_log  /usr/local/nginx/logs/host.access.404.log  log404;
         
        #對 "/" 啓用反向代理
        location / {
            proxy_pass http://127.0.0.1:88;
            proxy_redirect off;
            proxy_set_header X-Real-IP $remote_addr;
             
            #後端的Web服務器能夠經過X-Forwarded-For獲取用戶真實IP
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
             
            #如下是一些反向代理的配置，可選。
            proxy_set_header Host $host;

            #容許客戶端請求的最大單文件字節數
            client_max_body_size 10m;

            #緩衝區代理緩衝用戶端請求的最大字節數，
            #若是把它設置爲比較大的數值，例如256k，那麼，不管使用firefox仍是IE瀏覽器，來提交任意小於256k的圖片，都很正常。若是註釋該指令，使用默認的client_body_buffer_size設置，也就是操做系統頁面大小的兩倍，8k或者16k，問題就出現了。
            #不管使用firefox4.0仍是IE8.0，提交一個比較大，200k左右的圖片，都返回500 Internal Server Error錯誤
            client_body_buffer_size 128k;

            #表示使nginx阻止HTTP應答代碼爲400或者更高的應答。
            proxy_intercept_errors on;

            #後端服務器鏈接的超時時間_發起握手等候響應超時時間
            #nginx跟後端服務器鏈接超時時間(代理鏈接超時)
            proxy_connect_timeout 90;

            #後端服務器數據回傳時間(代理髮送超時)
            #後端服務器數據回傳時間_就是在規定時間以內後端服務器必須傳完全部的數據
            proxy_send_timeout 90;

            #鏈接成功後，後端服務器響應時間(代理接收超時)
            #鏈接成功後_等候後端服務器響應時間_其實已經進入後端的排隊之中等候處理（也能夠說是後端服務器處理請求的時間）
            proxy_read_timeout 90;

            #設置代理服務器（nginx）保存用戶頭信息的緩衝區大小
            #設置從被代理服務器讀取的第一部分應答的緩衝區大小，一般狀況下這部分應答中包含一個小的應答頭，默認狀況下這個值的大小爲指令proxy_buffers中指定的一個緩衝區的大小，不過能夠將其設置爲更小
            proxy_buffer_size 4k;

            #proxy_buffers緩衝區，網頁平均在32k如下的設置
            #設置用於讀取應答（來自被代理服務器）的緩衝區數目和大小，默認狀況也爲分頁大小，根據操做系統的不一樣多是4k或者8k
            proxy_buffers 4 32k;

            #高負荷下緩衝大小（proxy_buffers*2）
            proxy_busy_buffers_size 64k;

            #設置在寫入proxy_temp_path時數據的大小，預防一個工做進程在傳遞文件時阻塞太長
            #設定緩存文件夾大小，大於這個值，將從upstream服務器傳
            proxy_temp_file_write_size 64k;
        }
         
         
        #設定查看Nginx狀態的地址
        location /NginxStatus {
            stub_status on;
            access_log on;
            auth_basic "NginxStatus";
            auth_basic_user_file confpasswd;
            #htpasswd文件的內容能夠用apache提供的htpasswd工具來產生。
        }
         
        #本地動靜分離反向代理配置
        #全部jsp的頁面均交由tomcat或resin處理
        location ~ .(jsp|jspx|do)?$ {
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_pass http://127.0.0.1:8080;
        }
         
        #全部靜態文件由nginx直接讀取不通過tomcat或resin
        location ~ .*.(htm|html|gif|jpg|jpeg|png|bmp|swf|ioc|rar|zip|txt|flv|mid|doc|ppt|
        pdf|xls|mp3|wma)$
        {
            expires 15d; 
        }
         
        location ~ .*.(js|css)?$
        {
            expires 1h;
        }
    }
}
######Nginx配置文件nginx.conf中文詳解#####

參考

• 《Nginx高性能Web服務器詳解》苗澤 電子工業出版社
• Nginx官網
• 操做系統可否支持百萬鏈接?
• Nginx系列博客
• nginx 的 default_server 定義及匹配規則
• W3C Nginx教程