在Nginx配置文件中，每一條指令配置都必須以分號結束，請不要忘記。
用戶組配置
用于配置運行Nginx服務器用戶（組）的指令是user，其語法格式為：
user user [group];
- user，指定可以運行Nginx服務器的用戶。
- group，可選項，指定可以運行Nginx服務器的用戶組。
只有被設置的用戶或者用戶組成員才有權限啟動Nginx進程，如果是其他用戶（test_user）嘗試啟用Nginx進程，將會報錯:
nginx: [emerg] getpwnam("test_user") failed (2: No such file or directory) in
/Nginx/conf/nginx.conf:2
可以從錯誤信息中看到，Nginx無法運行的原因是查找test_user失敗，引起錯誤的原因是nginx.conf的第二行內容，即配置Nginx服務器用戶（組）的內容。 如果希望所有用戶都可以啟動Nginx進程，有兩種辦法：一是將此指令行注釋掉：
#user [user] [group];
或者將用戶（和用戶組）設置為nobody：
user nobody nobody;
這也是user指令的默認配置。user指令只能在全局塊中配置。
配置worker-process數
worker process是Nginx服務器實現并發處理服務的關鍵所在。從理論上來說，worker process的值越大，可以支持的并發處理量也越多，但實際上它還要受到來自軟件本身、操作系統本身資源和能力、硬件設備（如CPU和磁盤驅動器）等的制約。后面會用專門的章節來討論Nginx服務器的高級配置。
配置允許生成的worker process數的指令是worker_processes，其語法格式為：
worker_processes number | auto;
- number，指定Nginx進程最多可以產生的worker process數。
- auto，設置此值，Nginx進程將自動檢測。
在默認的配置文件中，number=1。啟動Nginx服務器以后，使用以下命令可以看到Nginx服務器除了主進程master process ../sbin/nginx之外，還生成了一個worker process：
#ps ax | grep nginx
8579 ? Ss 0:00 nginx: master process ../sbin/nginx
8580 ? S 0:00 nginx: worker process
如果將number改為3，重新運行Nginx進程，再次使用以上命令，則可以看到此時的Nginx服務器除了主進程master process ../sbin/nginx之外，已經生成了三個worker process：
#ps ax | grep nginx
8626 ? Ss 0:00 nginx: master process ../sbin/nginx
8627 ? S 0:00 nginx: worker process
8628 ? S 0:00 nginx: worker process
8629 ? S 0:00 nginx: worker process
此指令只能在全局塊中設置。
配置最大連接數
指令worker_connections主要用來設置允許每一個worker process同時開啟的最大連接數。其語法結構為：
worker_connections number;
此指令的默認設置為512。
MIME-Type配置
在常用的瀏覽器中，可以顯示的內容有HTML、XML、GIF及Flash等種類繁多的文本、媒體等資源，瀏覽器為區分這些資源，需要使用MIME Type。換言之，MIME Type是網絡資源的媒體類型。Nginx服務器作為Web服務器，必須能夠識別前端請求的資源類型。
在默認的Nginx配置文件中，我們看到在http全局塊中有以下兩行配置：
include mime.types;
default_type application/octet-stream;
第二行中使用指令default_type配置了用于處理前端請求的MIME類型，其語法結構為：
default_type mime-type;
其中，mime-type為types塊中定義的MIME-type，如果不加此指令，默認值為text/plain。此指令還可以在http塊、server塊或者location塊中進行配置。
PID存放路徑
Nginx進程作為系統的守護進程運行，我們需要在某文件中保存當前運行程序的主進程號。Nginx支持對它的存放路徑進行自定義配置，指令是pid，其語法格式為：
pid file ;
其中，file指定存放路徑和文件名稱。
配置文件默認將此文件存放在Nginx安裝目錄logs下，名字為nginx.pid。path可以是絕對路徑，也可以是以Nginx安裝目錄為根目錄的相對路徑。比如要把nginx.pid放置到Nginx安裝目錄sbin下，文件名為web_nginx，則可以使用以下配置：
pid sbin/web_nginx
錯誤日志路徑配置
在全局塊、http塊和server塊中都可以對Nginx服務器的日志進行相關配置。這里首先介紹全局塊下日志的存放配置，后兩種情況的配置基本相同，只是作用域不同。使用的指令是error_log，其語法結構是：
error_log file| stderr [debug | info | notice | warn | error | crit | alert | emerg];
從語法結構可以看到，Nginx服務器的日志支持輸出到某一固定的文件file或者輸出到標準錯誤輸出stderr；日志的級別是可選項，由低到高分為debug（需要在編譯時使用--with-debug開啟debug開關）、info、notice、warn、error、crit、alert、emerg等。需要注意的是，設置某一級別后，比這一級別高的日志也會被記錄。比如設置warn級別后，級別為warn以及error、crit、alert和emerg的日志都會被記錄下來。
下面我們先看一個配置的實例，這也是Nginx默認的日志存放和級別設置：
error_log logs/error.log error;
配置access_log
在全局塊中，我們介紹過errer_log指令，其用于配置Nginx進程運行時的日志存放和級別，此處所指的日志與常規的不同，它是指記錄Nginx服務器提供服務過程應答前端請求的日志，我們將其稱為服務日志以示區分。
Nginx服務器支持對服務日志的格式、大小、輸出等進行配置，需要使用兩個指令，分別是access_log和log_format指令。
access_log指令的語法結構為：
access_log path [format [buffer=size]];
- path，配置服務日志的文件存放的路徑和名稱。
- format，可選項，自定義服務日志的格式字符串，也可以通過“格式串的名稱”使用log_format指令定義好的格式。“格式串的名稱”在log_format指令中定義。
- size，配置臨時存放日志的內存緩存區大小。
此指令可以在http塊、server塊或者location塊中進行設置。默認的配置為：
access_log logs/access.log combined;
其中，combined為log_format指令默認定義的日志格式字符串的名稱。 如果要取消記錄服務日志的功能，則使用：
access_log off;
和access_log聯合使用的另一個指令是log_format，它專門用于定義服務日志的格式，并且可以為格式字符串定義一個名字，以便access_log指令可以直接調用。其語法格式為：
log_format name string …;
- name，格式字符串的名字，默認的名字為combined。
- string，服務日志的格式字符串。在定義過程中，可以使用Nginx配置預設的一些變量獲取相關內容，變量的名稱使用雙引號括起來，string整體使用單引號括起來。
我們來看一個示例以加深理解：
log_format exampleLog '$remote_addr - [$time_local] $request '
'$status $body_bytes_sent $http_referer '
'$http_user_agent';
這條配置定義了服務日志文件的名稱為exampleLog。筆者對其測試的結果，輸出了如下日志片段：
192.168.1.102 - [31/Oct/2019:20:41:39 +0800] "GET / HTTP/1.1" 200 151 "-" "Mozilla/5.0
(compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0)"
192.168.1.102 - [31/Oct/2019:20:41:39 +0800] "GET /favicon.ico HTTP/1.1" 404 570 "-"
"Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0)"
簡單分析一下第二條日志，$remote_addr獲取到用戶機的IP地址為192.168.1.102，$time_local獲取到本地時間為31/Oct/2019:20:41:39 +0800，$request獲取到請求為GET /favicon.ico HTTP/1.1，$status獲取到請求狀態為404（未找到，這是筆者將請求的網頁暫時移除造成的），$body_bytes_sent獲取到請求體的大小為570B，$http_referer未獲取到任何內容，$http_user_agent獲取到用戶使用Mozilla瀏覽器。
sendfile 傳輸文件配置
在Apache、lighttd等Web服務器配置中，都有和sendfile相關的配置，這里主要學習一下配置sendfile傳輸方式的相關指令sendfile和sendfile_max_chunk以及它們的語法結構：
sendfile on | off;
用于開啟或者關閉使用sendfile()傳輸文件，默認值為off，可以在http塊、server塊或者location塊中進行配置。
sendfile_max_chunk size;
其中，size值如果大于0，Nginx進程的每個worker process每次調用sendfile()傳輸的數據量最大不能超過這個值；如果設置為0，則無限制。默認值為0。此指令可以在http塊、server塊或location塊中配置。
下面是第二個指令的配置示例：
sendfile_max_chunk 128k;
配置連接超時時間
與用戶建立會話連接后，Nginx服務器可以保持這些連接打開一段時間，指令keepalive_timeout就是用來設置此時間的，其語法結構是：
keepalive_timeout timeout [header_timeout];
- timeout，服務器端對連接的保持時間。默認值為75s。
- header_timeout，可選項，在應答報文頭部的Keep-Alive域設置超時時間：“Keep-Alive:timeout= header_timeout”。報文中的這個指令可以被Mozilla或者Konqueror識別。
此指令還可以出現在server塊和location塊中，如下是一個配置示例：
keepalive_timeout 120s 100s;
其含義是，在服務器端保持連接的時間設置為120 s，發給用戶端的應答報文頭部中Keep-Alive域的超時時間設置為100 s。
單連接請求數上限
Nginx服務器端和用戶端建立會話連接后，用戶端通過此連接發送請求。指令keepalive_requests用于限制用戶通過某一連接向Nginx服務器發送請求的次數。其語法結構為：
keepalive_requests number;
此指令還可以出現在server塊和location塊中，默認設置為100。
監聽端口配置
配置監聽使用指令listen，其配置方法主要有三種，我們先分別介紹三種配置的語法結構，然后統一介紹涉及的相關變量和標識符。第一種配置監聽的IP地址，語法結構為：
listen address[:port] [default_server] [setfib=number] [backlog=number] [rcvbuf=size]
[sndbuf=size] [deferred]
[accept_filter=filter] [bind] [ssl];
第二種配置監聽端口，其語法結構是：
listen port[default_server][setfib=number][backlog=number][rcvbuf=size][sndbuf=
size] [accept_filter=filter]
[deferred] [bind] [ipv6only=on|off] [ssl];
第三種配置UNIX Domain Socket（一種在原有Socket框架上發展起來的IPC機制，用于在單個主機上執行客戶/服務器通信，這不是本書的重點，請讀者自行參閱相關書籍），其語法結構為：
listen unix:path [default_server] [backlog=number] [rcvbuf=size] [sndbuf=size]
[accept_filter=filter] [deferred]
[bind] [ssl];
- address，IP地址，如果是IPv6的地址，需要使用中括號“[]”括起來，比如[fe80::1]等。
- port，端口號，如果只定義了IP地址沒有定義端口號，就使用80端口。
- path，socket文件路徑，如/var/run/nginx.sock等。
- default_server，標識符，將此虛擬主機設置為address:port的默認主機。
基于server_name的主機配置
這里的“主機”，就是指此server塊對外提供的虛擬主機。設置了主機的名稱并配置好DNS，用戶就可以使用這個名稱向此虛擬主機發送請求了。配置主機名稱的指令為server_name，其語法結構為：
server_name name …;
對于name 來說，可以只有一個名稱，也可以由多個名稱并列，之間用空格隔開。每個名字就是一個域名，由兩段或者三段組成，之間由點號“.”隔開。下面是一個簡單的示例：
server_name myserver.com www.myserver.com;
在該例中，此虛擬主機的名稱設置為myserver.com或www. myserver.com。Nginx服務器規定，第一個名稱作為此虛擬主機的主要名稱。
在name 中可以使用通配符“*”，但通配符只能用在由三段字符串組成的名稱的首段或尾段，或者由兩段字符串組成的名稱的尾段，如：
server_name ＊.myserver.com www.myserver.＊;
在name中還可以使用正則表達式，并使用波浪號“～”作為正則表達式字符串的開始標記，如：
server_name ～^www\d+\.myserver\.com$;
正則表達式的主機配置
理解正則表達式的捕獲功能，大家看一個示例。虛擬主機的名稱設置如下：
server_name ～^www\.(.+)\.com$;
當請求通過www.myserver.com到達Nginx服務器端時，其將會被上面的正則表達式配置成功，其中的“myserver”將會被捕獲，并記錄到$1中。在本server塊的下文配置中，當需要“myserver”時，就可以使用$1代替“myserver”了。
由于server_name指令支持使用通配符和正則表達式兩種配置名稱的方式，因此在包含有多個虛擬主機的配置文件中，可能會出現一個名稱被多個虛擬主機的server_name匹配成功。那么，來自這個名稱的請求到底要交給哪個虛擬主機處理呢？Nginx服務器做出如下規定：
對于匹配方式不同的，按照以下的優先級選擇虛擬主機，排在前面的優先處理請求。
- 準確匹配server_name
- 通配符在開始時匹配server_name成功
- 通配符在結尾時匹配server_name成功
- 正則表達式匹配server_name成功
在以上四種匹配方式中，如果server_name被處于同一優先級的匹配方式多次匹配成功，則首次匹配成功的虛擬主機處理請求。
基于ip地址的主機配置
參考以下配置信息：
http
{
…
server #第一臺虛擬主機
{
listen: 80;
server_name: 192.168.1.31;
…
}
server #第二臺虛擬主機
{
listen: 80;
server_name: 192.168.1.32;
…
}
…
}
經過以上的配置，來自192.168.1.31的前端請求將由第一臺虛擬主機接收和處理，來自192.168.1.32的前端請求將由第二臺虛擬主機接收和處理。
基于ip的訪問權限配置
Nginx配置通過兩種途徑支持基本訪問權限的控制，其中一種是由HTTP標準模塊ngx_http_access_module支持的，其通過IP來判斷客戶端是否擁有對Nginx的訪問權限，這里有兩個指令需要我們學習。
allow指令
用于設置允許訪問Nginx的客戶端IP，語法結構為：
allow address | CIDR | all;
- address，允許訪問的客戶端的IP，不支持同時設置多個。如果有多個IP需要設置，需要重復使用allow指令。
- CIDR，允許訪問的客戶端的CIDR地址，例如202.80.18.23/25，前面是32位IP地址，后面“/25”代表該IP地址中前25位是網絡部分，其余位代表主機部分。
- all，代表允許所有客戶端訪問。
從Nginx 0.8.22版本以后，該命令也支持IPv6地址，比如：
allow 2620:100:e000::8001;
deny指令
作用剛好和allow指令相反，它用于設置禁止訪問Nginx的客戶端IP，語法結構為：
deny address | CIDR | all;
- address，禁止訪問的客戶端的IP，不支持同時設置多個。如果有多個IP需要設置，需要重復使用deny指令。
- CIDR，禁止訪問的客戶端的CIDR地址。
- all，代表禁止所有客戶端訪問。
這兩個指令可以在http塊、server塊或者location塊中配置。在使用這兩個指令時，要注意設置為all的用法。請看下面的例子：
location / {
deny 192.168.1.1;
allow 192.168.1.0/24;
deny all;
}
在上面的配置示例中我們首先配置禁止192.168.1.1訪問Nginx，然后配置允許192.168.1.0/24訪問Nginx，最后又使用all配置禁止所有IP的訪問。那么，192.168.1.0/24客戶端到底可不可以訪問呢？是可以的。Nginx配置在解析的過程中，遇到deny指令或者allow指令是按照順序對當前客戶端的連接進行訪問權限檢查的。如果遇到匹配的配置時，則停止繼續向下搜索相關配置。因此，當192.168.1.0/24客戶端訪問時，Nginx在第3行解析配置發現允許該客戶端訪問，就不會繼續向下解析第4行了。
基于密碼配置Nginx的訪問權限
Nginx還支持基于HTTP Basic Authentication協議的認證。該協議是一種HTTP性質的認證辦法，需要識別用戶名和密碼，認證失敗的客戶端不擁有訪問Nginx服務器的權限。該功能由HTTP標準模塊ngx_http_auth_basic_module支持，這里有兩個指令需要學習。
- auth_basic指令
用于開啟或者關閉該認證功能，語法結構為：
auth_basic string | off;
string，開啟該認證功能，并配置驗證時的指示信息。
off，關閉該認證功能。
auth_basic_user_file指令
用于設置包含用戶名和密碼信息的文件路徑，語法結構為：
auth_basic_user_file file;
其中，file為密碼文件的絕對路徑。
這里的密碼文件支持明文或者密碼加密后的文件。明文的格式如下所示：
name1:password1
name2:password2:comment
name3:password3
加密密碼可以使用crypt()函數進行密碼加密的格式，在Linux平臺上可以使用htpasswd命令生成。在PHP和Perl等語言中，也提供crypt()函數。使用htpasswd命令的一個示例為：
# htpasswd -c -d /nginx/conf/pass_file username
運行后輸入密碼即可。
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包含正則表達式，并且區分大小寫。
- “～*”，用于表示uri包含正則表達式，并且不區分大小寫。
如果uri包含正則表達式，就必須要使用“～”或者“～*”標識。
“^～”，用于標準uri前，要求Nginx服務器找到標識uri和請求字符串匹配度最高的location后，立即使用此location處理請求，而不再使用location塊中的正則uri和請求字符串做匹配。
我們知道，在瀏覽器傳送URI時對一部分字符進行URL編碼，比如空格被編碼為“%20”，問號被編碼為“%3f”等。“～”有一個特點是，它對uri中的這些符號將會進行編碼處理。比如，如果location塊收到的URI為“/html/%20/data”，則當Nginx服務器搜索到配置為“～ /html/ /data”的location時，可以匹配成功。
location root配置
Web服務器接收到網絡請求之后，首先要在服務器端指定目錄中尋找請求資源。在Nginx服務器中，指令root就是用來配置這個根目錄的，其語法結構為：
root path;
其中，path為Nginx服務器接收到請求以后查找資源的根目錄路徑。path變量中可以包含Nginx服務器預設的大多數變量，只有$document_root和$realpath_root不可以使用。
此指令可以在http塊、server塊或者location塊中配置。由于使用Nginx服務器多數情況下要配置多個location塊對不同的請求分別做出處理，因此該指令通常在location塊中進行設置。
這個指令的一個示例為：
location /data/
{
root /locationtest1;
}
當location塊接收到“/data/index.htm”的請求時，將在/locationtest1/data/目錄下找到index.htm響應請求。
location alias配置
在location塊中，除了使用root指令指明請求處理根目錄，還可以使用alias指令改變location接收到的URI的請求路徑，其語法結構為：
alias path;
其中，path即為修改后的根路徑。同樣，此變量中也可以包含除了realpath_root之外的其他Nginx服務器預設變量。
這個指令的作用有點不好理解，我們來看一個示例：
location ～ ^/data/(.+\.(htm|htm))$
{
alias /locationtest1/other/$1;
}
當此location塊接收到/data/index.htm的請求時，匹配成功，之后根據alias指令的配置，Nginx服務器將到/locationtest1/other目錄下找到index.htm并響應請求。可以看到，通過alias指令的配置，根路徑已經從/data更改為/locationtest1/other了。
index首頁配置
指令index用于設置網站的默認首頁，它一般可以有兩個作用：一是，用戶在發出請求訪問網站時，請求地址可以不寫首頁名稱；二是，可以對一個請求，根據其請求內容而設置不同的首頁。該指令的語法結構為：
index file ...;
其中，file變量可以包括多個文件名，其間使用空格分隔，也可以包含其他變量。此變量默認為“index.html”。
看一個示例：
location ～ ^/data/(.+)/web/ $
{
index index.$1.html index.my1.html index.html;
}
當location塊接收到/data/locationtest/web/時，匹配成功，它首先將預置變量$1置為locationtest，然后在/data/locationtest/web/路徑下按照index的配置次序依次尋找index.locationtest.html頁、index.my1.html頁和index.html頁，首先找到哪個頁面，就使用哪個頁面響應請求。
error_page錯誤頁面配置
如果用戶端嘗試查看網頁時遇到問題，服務器會將HTTP錯誤從網站發送到Web瀏覽器。如果無法顯示網頁，Web瀏覽器會顯示網站發送的實際錯誤網頁或Web瀏覽器內置的友好錯誤消息。Nginx服務器支持自定義錯誤網頁的顯示內容。可以通過這一功能在網站發生錯誤時為用戶提供人性化的錯誤顯示頁面。
一般來說，HTTP 2XX代表請求正常完成，HTTP 3XX代表網站重定向，HTTP 4XX代表客戶端出現錯誤，HTT 5XX代表服務器端出現錯誤。
Nginx服務器設置網站錯誤頁面的指令為error_page，語法結構為：
error_page code ... [=[response]] uri
- code，要處理的HTTP錯誤代碼，常見的在表2.2中已經列出。
- response，可選項，將code指定的錯誤代碼轉化為新的錯誤代碼response。
- uri，錯誤頁面的路徑或者網站地址。如果設置為路徑，則是以Nginx服務器安裝路徑下的html目錄為根路徑的相對路徑；如果設置為網址，則Nginx服務器會直接訪問該網址獲取錯誤頁面，并返回給用戶端。
看幾個error_page指令的示例：
error_page 404 /404.html
設置Nginx服務器使用“Nginx安裝路徑/html/404.html”頁面響應404錯誤（“無法找到網頁”錯誤）。再如：
error_page 403 http://somewebsite.com/forbidden.html;
設置Nginx服務器使用http://somewebsite.com/forbidden.html頁面響應403錯誤（“拒絕顯示網頁”錯誤）。再如：
error_page 410 =301 /empty.gif
設置Nginx服務器產生410的HTTP消息時，使用“Nginx安裝路徑/html/empty.gif”返回給用戶端301消息（“已移動”消息）。
在前面對error_page指令的分析中我們看到，變量uri實際上是一個相對于Nginx服務器安裝路徑的相對路徑。那么，如果不想將錯誤頁面放到Nginx服務器的安裝路徑下管理，該怎么做呢？
其實這個很簡單，只需要另外使用一個location指令定向錯誤頁面到新的路徑下面了就可以了。比如對于上面的第一個示例，我們希望Nginx服務器使用“/myserver/errorpages/404.html”頁面響應404錯誤，那么在設置完：
error_page 404 /404.html
之后，我們再添加這樣一個location塊：
location /404.html
{
root /myserver/errorpages/
}
首先捕獲“/404.html”請求，然后將請求定向到新的路徑下面即可。 errer_page指令可以在http塊、server塊和location塊中配置。
include指令
在一些情況下，我們可能需要將其他的Nginx配置或者第三方模塊的配置引用到當前的主配置文件中。Nginx提供了include指令來完成配置文件的引入，其語法結構為：
include file;
其中，file是要引入的配置文件，它支持相對路徑。
配置是否同時接收多個網絡連接
每個Nginx服務器的worker process都有能力同時接收多個新到達的網絡連接，但是這需要在配置文件中進行設置，其指令為multi_accept，語法結構為：
multi_accept on | off;
此指令默認為關閉（off）狀態，即每個worker process一次只能接收一個新到達的網絡連接。此指令只能在events塊中進行配置。
配置事件驅動模型
Nginx服務器提供了多種事件驅動模型來處理網絡消息。配置文件中為我們提供了相關的指令來強制Nginx服務器選擇哪種事件驅動模型進行消息處理，指令為use，語法結構為：
use method;
其中，method可選擇的內容有：select、poll、kqueue、epoll、rtsig、/dev/poll以及eventport。
配置網絡連接序列化
在《UNIX網絡編程》里提到過一個叫“驚群”的問題（Thundering herd problem），大致意思是，當某一時刻只有一個網絡連接到來時，多個睡眠進程會被同時叫醒，但只有一個進程可獲得連接。如果每次喚醒的進程數目太多，會影響一部分系統性能。在Nginx服務器的多進程下，就有可能出現這樣的問題。
為了解決這樣的問題，Nginx配置中包含了這樣一條指令accept_mutex，當其設置為開啟的時候，將會對多個Nginx進程接收連接進行序列化，防止多個進程對連接的爭搶。其語法結構為：
accept_mutex on | off;
此指令默認為開啟（on）狀態，其只能在events塊中進行配置
