Nginx的基本配置

時間 2019-11-13

標籤 nginx 基本配置欄目 Nginx 简体版

原文原文鏈接

1. Nginx服務的基本配置

1.1 用於調試進程和定位問題的配置項

是否以守護進程的方式運行nginxphp
```
# 默認on
daemon on|off;
```

是否以master/worker方式工做html

# 默認on，指定了是否以master-worker進程的方式運行，若是設置爲off，那麼全部的請求將只會由master進程處理
master_process on|off;

error日誌的設置前端

# 指定了error日誌的目錄和日誌級別，第二個參數用於指定目錄，第三個參數用於指定日誌級別，總共有：debug、info、notice、warn、error、crit、alert、emerg，這些日誌級別中，從左往右優先級依次增大，默認爲info
error_log logs/error.log error;

是否處理幾個特殊的調試點node

# 指定了調試點
debug_points stop|abort

僅對指定的客戶端輸出debug級別的日誌nginx
```
debug_connection IP|CIDR
```
該參數主要用於events模塊中，針對指定的ip或者網段記錄debug日誌：web
```
events {
  debug_connection 10.224.66.14;
  debug_connection 10.224.57.0/24;
}
```
須要注意的是，在使用該參數時，必需要確保在進行configure時已經加入了--with-debug參數，不然不會生效；正則表達式
限制coredump核心轉儲文件的大小算法
```
worker_rlimit_core size;
```
在Linux操做系統中，若是一個進程因爲錯誤或者收到信號而終止時，會將進程執行時的內存內容寫入一個文件（core文件），以做爲調試之用，這就是所謂的核心轉儲。在nginx進程宕機時，其就會產生核心轉儲文件，並且該文件通常都有幾個G，於是若是不限制該文件的大小，那麼頗有可能會把服務器磁盤佔滿。該參數的做用就是限制核心轉儲文件的大小的。瀏覽器
指定coredump文件生成目錄緩存
```
working_directory path;
```
該參數指定了在生成核心轉儲文件時，將該文件存放的目錄。

1.2 正常運行的配置項

定義環境變量
```
env TESTPATH=/tmp/
```
這個配置項可讓用戶直接設置操做系統上的環境變量。
嵌入其餘配置文件
```
include /path/file
```
用於將其餘的配置文件引入進來，該路徑能夠是絕對路徑，也能夠是相對路徑，若是是相對路徑，則是基於nginx的配置目錄而指定的。
pid文件的路徑
```
pid path/file
```
用於指定存儲nginx的master進程運行所使用的進程id的文件的路徑。
Nginx的worker進程運行的用戶及用戶組
```
user username [groupName]
```
用於指定worker進程運行時所基於的用戶和用戶組，默認都爲nobody，這裏若是不指定groupName，那麼組名就與用戶名一致。
指定nginx的worker進程能夠打開的最大句柄描述符個數
```
worker_rlimit_nofile limit;
```
設置一個worker進程可以打開的最大句柄描述符個數。
限制信號隊列
```
worker_rlimit_sigpending limit;
```
設置了每一個用戶可以發往nginx的信號隊列的大小，若是信號隊列已滿，那麼新發送的信號將會被丟棄。

1.3 優化性能的配置項

nginx的worker進程的個數
```
worker_processes 1;
```
用於指定nginx運行時worker進程的個數，在nginx運行時，每一個worker進程都是單線程運行的，這裏須要判斷worker進程是否進行了阻塞性操做，若是有這樣的操做，那麼稍微多配置一些worker進程比較好，若是沒有，那麼將worker進程數量設置得與CPU數量同樣可以獲得更好的性能。
綁定nginx的worker進程到指定的CPU內核
```
worker_cpu_affinity cpumask [cpumask...]
```
將worker進程與指定的CPU進行綁定，這樣可以防止多個worker進程搶佔同一個CPU，從而避免出現同步問題。以下是一個4核CPU的配置方式：
```
worker_processes 4;
worker_cpu_affinity 1000 0100 0010 0001;
```
須要注意的是，worker_cpu_affinity僅對於Linux系統有效。
SSL硬件加速
```
ssl_engine device;
```
若是服務器上有SSL硬件加速設備，那麼就能夠進行配置以加快SSL協議的處理速度。用戶可使用OpenSSL提供的命令來查看是否有SSL硬件加速設備：
```
openssl engine -t
```
系統調用gettimeofday的執行頻率
```
timer_resolution -t
```
默認狀況下，每次內核的事件調用返回時，都會執行一次gettimeofday，在早期的Linux版本中，獲取系統時間都會有一次從內核態到用戶態的數據複製，其代價比較高，可是在最新的x86-64體系架構中，gettimeofday僅僅只是一次vsyscall，其僅僅只是對共享內存頁中的數據的訪問，代價不大。
nginx的worker進程優先級
```
worker_priority nice;
```
用於設置nginx的worker進程的優先級，其中，nice的默認值爲0。在Linux操做系統中，當有多個進程在競爭CPU執行資源時，其就會根據每一個進程設置的優先級來優先分配執行權限，而且所分配的時間片也要高一些。優先級的值在-20~+19之間，數值越低優先級越高，通常建議將nginx的優先級設置得更低一些，這樣才能保證其執行的權限，可是建議不要設置得比內核的進程優先級（其值爲-5）還要低。

1.4 事件類配置項

是否打開accept鎖
```
accept_mutex [on|off]
```
accept_mutex參數用於控制是否啓用負載均衡鎖，其默認值爲on，該鎖會保證各個worker輪流的、序列化的與新客戶端創建鏈接，而且當某個worker的鏈接數達到了worker_connections配置的最大鏈接數的7/8時，該鎖會下降該worker將要新創建的鏈接數，從而保證各個worker的負載均衡。
lock文件的路徑
```
lock_file path/file;
```
該參數指定了lock文件的路徑。nginx會使用操做系統提供的鎖功能，但若是操做系統不支持原子鎖，此時纔會使用文件鎖來實現lock。若是accept_mutex參數設置爲off，那麼該參數將不會生效。
使用accept鎖後到真正創建鏈接之間的延遲時間
```
accept_mutex_delay Nms;
```
若是一個worker進程嘗試獲取鎖失敗了，那麼其就會等待該參數指定的時間段以後再次嘗試獲取鎖，該值默認爲500ms。
批量創建新鏈接
```
multi_accept [on|off];
```
當事件模型通知這次有新的鏈接創建請求時，儘量的對本次調度中客戶端發起的的全部TCP請求都創建鏈接，該值默認爲off。
選擇事件模型
```
use [kqueue|rtsig|epoll|/dev/poll|select|poll|eventport];
```
nginx所選用的事件模型，其會自動使用最適合的模型。在Linux操做系統下支持poll、select和epoll三種，其中epoll的性能是最高的。
每一個worker的最大鏈接數
```
worker_connections number;
```
指定了每一個worker進程可以創建的最大鏈接數。

2. http核心模塊配置

2.1 監聽端口

listen address:port[default(deprecated)|default_server|[backlog=num|rcvbuf=size|sndbuf=size|accept_filter=filter|deferred|bind|ipv6only=[on|off]|ssl]]

這裏的IP地址和端口號的配置很是靈活，若是不配置端口號，則默認爲80端口，而ip地址則可使用通配符進行匹配，如：
```
listen 127.0.0.1:8080;
listen *:8080;
```
listen的各個參數含義以下：
- default和default_server：將當前server塊做爲整個web服務器的默認server塊，若是沒有server設置了該參數，則將nginx.conf中的第一個server塊做爲默認server塊。設置該參數的緣由在於，若是當前請求沒有匹配到任意一個server，那麼就使用第一個server處理請求；
- backlog=num：指定了TCP中的backlog隊列的大小，默認值爲-1。在TCP的三次握手過程當中，進程此時尚未開始處理監聽句柄，而這些請求都會放在backlog隊列中，當backlog隊列滿時，客戶端新的握手請求就會被拒絕；
- rcvbuf=size：設置監聽句柄的SO_RCVBUF參數；
- sndbuf=size：設置監聽句柄的SO_SNDBUF參數；
- accept_filter：設置accept過濾器，只對FreeBSD操做系統有用；
- deferred：若是設置了該參數，若是用戶發起了TCP鏈接請求，那麼在三次握手成功以後內核也不會調度相應的進程處理請求，而是在用戶真正的發送了數據包以後纔會將請求發送給具體的進程進行處理；
- bind：綁定當前端口/地址對，如127.0.0.1:8000，只有同時對一個端口監聽多個地址時纔會生效；
- ssl：在當前監聽的端口上創建的鏈接必須基於SSL協議；

2.2 主機名稱

語法：server_name name [...];
默認：server_name "";
配置塊：server

server_name後能夠跟多個主機名稱，在處理HTTP請求時，其會將請求中的Host頭部的主機名與server塊中的主機名進行匹配，若是遇到多個server塊中的主機名匹配，那麼將會按照以下規則與其進行匹配：
- 首先匹配主機名徹底匹配的server塊；
- 而後匹配前綴使用通配符的server塊；
- 接着匹配後綴使用通配符的server塊；
- 最後匹配使用正則表達式的server塊；、
若是沒有找到可以匹配的主機名，那麼就會按照以下規則尋找server塊：
- 優先選擇在listen項中加入了[default|default_server]的server塊；
- 找到匹配的listen端口的第一個server塊；

2.3 server_names_hash_bucket_size

語法：server_names_hash_bucket_size size;
默認：server_names_hash_bucket_size 32|64|128;
配置塊：http、server、location

server_names_hash_bucket_size的做用主要是進行server name的hash匹配的，在進行hash匹配時，該參數指定了hash表的每一個bucket佔用的內存大小。

2.4 server_names_hash_max_size

語法：server_names_hash_max_size size;
默認：server_names_hash_max_size 512;
配置塊：http、server、location

server_names_hash_max_size指定了進行server name查找時使用的hash表的大小，該值越大，那麼佔用的內存越多，可是查詢的效率也越高。

2.5 重定向主機名稱的處理

語法：server_name_in_redirect on|off;
默認：server_name_in_redirect on;
配置塊：http、server或者location

該配置須要配合server_name使用，在使用on打開時，表示在重定向請求時，會使用server_name裏配置的第一個主機名代替原來請求中的Host頭部，而使用off關閉時，表示在重定向請求時使用請求自己的Host頭部。

2.6 location

語法：location [=|~|~*|^~|@] /uri/{...}
配置塊：server

location的主要做用是與請求中的URI進行匹配，若是匹配了，就使用location塊中的配置來處理用戶請求。以下是location的匹配規則：
- =表示把URI做爲字符串，以便於參數中的uri作徹底匹配。例如：
```
location = / {
  # 只有當用戶請求是/時，纔會使用該location下的配置
}
```
- ~表示匹配URI時是字母大小寫敏感的；
- ~*表示匹配URI時是字母大小寫不敏感的；
- ^~表示匹配URI時只須要其前半部分與uri參數匹配便可。例如：
```
location ^~ /images/ {
  # 以/images/開始的請求都會匹配上
}
```
- @表示僅用於nginx服務內部請求之間的重定向，帶有@的location不直接處理用戶請求；
- 能夠在uir參數裏使用正則表達式。如：
```
location ~* \.(gif|jpg|jpeg)$ {
  # 匹配以.gif、.jpg、.jpeg結尾的請求
}
```
關於location的匹配須要說明的一點是，location的匹配是有順序的，當一個請求匹配了多個location時，實際上這個請求會被第一個location處理。

3. 文件路徑的定義

3.1 以root方式設置資源路徑

語法：root path;
默認：root html;
配置塊：http、server、locationo、if

示例以下：
```
location /download/ {
  root /opt/web/html/;
}
```
這種配置方式會將/download/開始的請求映射到/opt/web/html/目錄下，好比某個請求爲/download/test/index.html，那麼nginx就會到服務器上查找/opt/web/html/download/test/index.html文件。

3.2 以alias方式設置資源文件

語法：alias path;
配置塊：location;

與root同樣，alias也是配置資源文件路徑的，可是alias是location後的路徑以別名的方式替換目標路徑的指定部分，好比以下配置：
```
location /conf {
  alias /usr/local/nginx/conf;
}
```
此時若是一個請求爲/conf/index.html，那麼其前綴/conf將會與當前location匹配，而且會將alias參數替換請求uri中匹配的部分，也就是轉換後的uri爲/usr/local/nginx/conf/index.html。

3.3 訪問首頁

語法：index file...;
默認：index index.html;
配置塊：http、server、location

該配置塊的主要做用是將用戶訪問的某個地址映射到首頁，在進行首頁查找時，會按照順序查詢index參數後的文件，若是存在，則將其返回，若是不存在，則繼續查找下一個。好比以下示例：
```
location / {
  root path;
  index /index.html /html/index.php /index.php
}
```
當接收到用戶的/請求後，其首先會查詢/path/index.html文件是否存在，若是不存在，則查詢下一個/path/html/index.php是否存在，若是存在，則直接返回，依此類推。

3.4 根據http返回碼重定向頁面

語法：error_page code[code...][=|=answer-code]uri|@named_location
配置塊：http、server、location、if

該配置的主要做用是，若是當前請求返回了指定的狀態碼，那麼就將其重定向到後面的錯誤頁面。如：
```
error_page 404 /404.html
error_page 502 503 504 /50x.html
error_page 403 http://example.com/forbidden.html
error_page 404 = @fetch;
```
須要注意的是，即便重定向了URI，返回的HTTP狀態碼仍是原來的狀態碼，若是須要修改狀態碼，可使用=來修改原來的狀態碼，如：
```
error_page 404 =200 /empty.gif;
error_page 404 =403 /forbidden.gif;
```
也能夠不指定修改後的狀態碼，而是由重定向後的請求決定其返回的狀態碼：
```
error_page 404 = /empty.gif;
```
在重定向後，也能夠不修改URI，而是將這個請求重定向到另外一個location中進行處理，好比：
```
location / {
  error_page 404 @fallback;
}

location @fallback {
  proxy_pass http://backend;
}
```

3.5 是否支持遞歸的使用error_page

語法：recursive_error_pages [on|off];
默認：recursive_error_pages off;
配置塊：http、server、location;

該配置主要用於控制是否支持遞歸的定義error_page。

3.6 try_files

語法：try_files path1[path2]uri;
配置塊：server、location

該參數的主要做用是在用戶請求到達以後，會依次嘗試其後指定的各個path路徑，若是匹配上了，那麼就將該路徑的值直接返回。若是都沒有匹配上，那麼就會使用最後的uri做爲默認處理路徑。示例如：
```
try_files /system/maintenance.html $uri $uri/index.html $uri.html @other
location @other {
  proxy_pass http://backend;
}
```

4. 內存及磁盤資源的分配

4.1 http包體只存儲到磁盤文件中

語法：client_body_in_file_only on|clean|off;
默認：client_body_in_file_only off;
配置塊：http、server、location

當值配置爲非off時，用戶請求的http包體一概存儲到磁盤文件中，即便只有0字節也會存儲爲文件。當請求結束時，若是配置爲on，則這個文件不會被刪除，若是配置爲clean，則會刪除該文件。

4.2 http包體儘可能寫入到一個內存buffer中

語法：client_body_in_single_buffer on|off;
默認：client_body_in_single_buffer off;
配置塊：http、server、location

用戶請求的http包體一概存儲到內存buffer中，若是存儲的包體大小超過了client_body_buffer_size指定的大小，那麼該請求仍是會存儲到磁盤文件中。

4.3 存儲http頭部的內存buffer大小

語法：client_header_buffer_size size;
默認：client_header_buffer_size 1k;
配置塊：http、server

該參數指定了用戶請求的http頭部的size大小，若是請求頭部大小超過了該數值，那麼就會將請求就會交由large_client_header_buffers參數定義的buffer處理。

4.4 存儲超大http頭部的內存buffer大小

語法：large_client_header_buffers number size;
默認：large_client_header_buffers 48k;
配置塊：http、server

該參數主要是在用戶的請求頭部信息超過了client_header_buffer_size所能存儲的大小時使用，該參數定義了每一個header所能傳輸的數據的大小，以及最多可以傳輸多少個header。若是單個header大小超限，則會返回414（Request URI too large）狀態碼，若是是header個數超限，則會返回400（Bad Request）狀態碼。

4.5 存儲http包體的內存buffer的大小

語法：client_body_buffer_size size;
默認：client_body_buffer_size 8k/16k;
配置塊：http、server、location

該參數指定了nginx接收用戶http請求的包體buffer的大小，若是超過了該大小，那個請求包體將會存儲到磁盤文件中。
須要注意的是，若是用戶請求的header中包含Content-Length，而且其標識的長度小於上述參數指定的長度，那麼就會自動下降這次請求所使用的buffer大小。

4.6 http包體的臨時存放目錄

語法：client_body_temp_path dir-path[level1[level2[level3]]]
默認：client_body_temp_path client_body_temp;
配置塊：http、server、location

該參數的主要做用是指定了存儲http包體的磁盤目錄，後面的level表示能夠有幾級子目錄，這是由於若是請求比較多，那麼生成的文件就會比較多，頻繁的訪問同一個目錄可能會下降性能，於是能夠設置多級子目錄用於文件的存放；
須要注意的是，上述level參數表示的是所生成的目錄名佔有目標文件名字符的個數，好比生成的目標文件名爲00000123456，而上述參數按以下配置：
```
client_body_temp_path /opt/nginx/client_temp 1 2;
```
那麼nginx就會截取目標文件名的最後1個字符做爲一級目錄，倒數第二個和第三個總共兩個字符做爲二級目錄，最終文件將會存儲在以下目錄：
```
/opt/nginx/client_temp/6/45/00000123456
```
nginx在生成目標文件時，其文件名是以順序遞增的整數進行命名的。

4.7 connection_pool_size

語法：connection_pool_size size;
默認：connection_pool_size 256;
配置塊：http、server

該參數指定了nginx爲每一個創建成功的TCP鏈接預先分配的內存池大小，size指定的是預先分配的內存池大小。
該參數須要謹慎配置，由於更大的配置將會消耗服務器更多的內存，而更小的配置將會致使服務器爲了擴容而進行更屢次的內存分配。

4.8 request_pool_size

語法：request_pool_size size;
默認：request_pool_size 4k;
配置塊：http、server

nginx在接收到每一個http請求時，都會爲其申請一個內存池，該參數指定了該內存池的大小，須要注意的是，該內存池本質上就是從上面介紹的connection_pool_size內存池中進行申請；
在每次http請求結束時，其就會銷燬該請求申請的內存池，而將其返還給connection_pool_size內存池，而只有在這次TCP鏈接關閉時纔會銷燬整個鏈接的內存池。

5. 網絡鏈接的設置

5.1 讀取http頭部的超時時間

語法：client_header_timeout time（默認單位：秒）;
默認：client_header_timeout 60;
配置塊：http、server、location

在客戶端與服務器創建鏈接以後，nginx會讀取客戶端發來的http頭部，若是超過該參數指定的時間還未讀取到客戶端發來的字節，就會認爲其超時了，此時就會向客戶端返回408（Request timed out）狀態碼。

5.2 讀取http包體的超時時間

語法：client_body_timeout time（默認單位：秒）;
默認：client_body_timeout 60;
配置塊：http、server、location

該參數主要做用是指定nginx讀取請求包體的超時時間。

5.3 發送響應的超時時間

語法：send_timeout time;
默認：send_timeout 60;
配置塊：http、server、location

這個參數主要指定了nginx向客戶端發送響應的超時時間，若是客戶端一直沒有嘗試接收數據，那麼nginx就會關閉這個鏈接。

5.4 reset_timeout_connection

語法：reset_timeout_connection on|off;
默認：reset_timeout_connection off;
配置塊：http、server、location

若是開啓了該參數，在鏈接超時後，nginx會向客戶端發送RST包來直接重置鏈接，而且會釋放服務器上關於該鏈接的全部緩存數據（如TCP滑動窗口等）。相比於正常關閉的方式，它使得服務器可以避免產生許多處於FIN_WAIT_1、FIN_WAIT_2、TIME_WAIT狀態的TCP鏈接。
須要注意的是，使用RST重置包關閉鏈接會帶來一些問題，默認狀況下不會開啓。

5.5 lingering_close

語法：lingering_close off|on|always;
默認：lingering_close on;
配置塊：http、server、location

該配置塊控制nginx關閉用戶鏈接的方式。always表示關閉用戶鏈接前必須無條件的處理鏈接上全部用戶發送的數據。off表示關閉鏈接時徹底無論鏈接上是否有用戶準備就緒的數據。on是中間值，通常狀況下在關閉鏈接前都會處理鏈接上的用戶發送的數據，除非某些時候業務上認定這些數據是不須要的，此時就會拋棄這些數據。

5.6 lingering_time

語法：lingering_time time;
默認：lingering_time 30s;
配置塊：http、server、location

在lingering_close啓用後，這個配置項主要是針對大文件的傳輸用的，好比當某個請求傳輸的數據超過了max_client_body_size時，nginx就會向該客戶端發送413(Request entity too large)狀態碼，可是某些客戶端可能不會理會該狀態碼而仍是繼續向服務器發送數據，此時nginx就會在該參數的超時時間以後直接關閉該鏈接。

5.7 lingering_timeout

語法：lingering_timeout time;
默認：lingering_timeout 5s;
配置塊：http、server、location

在lingering_close啓用後，nginx在關閉鏈接前，會檢測用戶鏈接上是否還有未處理的數據，若是在該參數指定的時間以後尚未相應的數據到達，那麼就會關閉該連接。

5.8 對某些瀏覽器禁用keepalive功能

語法：keepalive_disable [msie6|safari|none]...
默認：keepalive_disablemsie6 safari
配置塊：http、server、location

該參數主要是指定對哪些瀏覽器禁用keepalive功能，keepalive會在客戶端與服務器之間創建一個長鏈接，這對於發送多個http請求是很是有用的，可是對於IE6和之前版本，還有Safari瀏覽器在處理POST請求時會有功能性問題，於是對於這些瀏覽器默認是禁用的。

5.9 keepalive超時時間

語法：keepalive_timeout time（默認單位：秒）;
默認：keepalive_timeout 75;
配置塊：http、server、location

該參數主要是在一個keepalive鏈接在指定時長內沒有接收到新的請求時，將會關閉該鏈接。

5.10 keepalive長鏈接上可以承載的最大請求數

語法：keepalive_requests n;
默認：keepalive_requests 100;
配置塊：http、server、location

該參數指定了一個keepalive長鏈接上可以承載的最大鏈接數，默認爲100。

5.11 tcp_nodelay

語法：tcp_nodelay on|off;
默認：tcp_nodelay on;
配置塊：http、server、location

肯定對keepalive鏈接是否使用TCP_NODELAY選項

5.12 tcp_nopush

語法：tcp_nopush on|off;
默認：tcp_nopush off;
配置塊：http、server、location

在打開sendfile選項時，肯定是否開啓FreeBSD系統上的TCP_NOPUSH或者Linux系統上的TCP_CORK功能。打開tcp_nopush後，將會在發送響應時把整個響應包頭放到一個TCP包中發送。

6. MIME類型的設置

6.1 MIME type與文件擴展的映射

語法：type {...};
配置塊：http、server、location

該配置項定義了MIME type到文件擴展名的映射。多個擴展名能夠映射到同一個MIME type。例如：
```
types {
  text/html html;
  text/html conf;
  image/gif gif;
  image/jpeg jpg;
}
```

6.2 默認MIME type

語法：default_type MIME-type;
默認：default_type text/plain;
配置塊：http、server、location

當找不到相應的MIME type與文件擴展名之間的映射時，使用默認的MIME type做爲http header的Content-Type。

6.3 types_hash_bucket_size

語法：types_hash_max_size size;
默認：types_hash_max_size 1024;
配置塊：http、server、location

nginx使用了一個散列表來保存MIME type與文件擴展名之間的映射，該參數就是指定該散列表桶的大小的。

6.4 types_hash_max_size

語法：types_hash_max_size size;
默認：types_hash_max_size 1024;
配置塊：http、server、location

該參數指定了存儲MIME type與文件擴展名的散列的最大大小，該值越大，散列的key就越稀疏，檢索速度越快，可是會佔用更多的內存；該值越小，佔用的內存越小，可是衝突率就會上升，檢索越慢。

7. 對客戶端請求的限制

7.1 按http方法名限制用戶請求

語法：limit_except method...{...}
配置塊：location

該配置項的主要做用是限制某些方法的請求的訪問，後面的參數可取GET、HEAD、POST、DELETE、MKCOL、COPY、MOVE、OPTIONS、PROPFIND、PROPPATCH、LOCK、UNLOCK或者PATCH。示例如：
```
limit_except GET {
  allow 192.168.1.0/32;
  deny all;
}
```
上述配置將會限制全部的GET請求的訪問，而容許其餘方法的請求。

7.2 http請求包體的最大值

語法：client_max_body_size size;
默認：client_max_body_size 1m;
配置塊：http、server、location

該參數指定了http請求的最大包體的大小，nginx會根據請求header中的Content-Length所表示的長度來判斷其與當前參數是否符合，若是不符合，則直接返回給客戶端413（Request too large）狀態碼。

7.3 對請求的限速

語法：limit_rate speed;
默認：limit_rate 0;
配置塊：http、server、location、if

該配置主要是對客戶端的請求進行每秒傳輸的字節大小進行限速，默認爲0，表示不限速；
針對不一樣的客戶端，可使用$limit_rate參數執行不一樣的限速策略。如：
```
server {
  if ($slow) {
    set $limit_rate 4k;
  }
}
```

7.4 limit_rate_after

語法：limit_rate_after time;
默認：limit_rate_after 1m;
配置塊：http、server、location、if

該參數表示nginx向客戶端發送的響應大小超過limit_rate_after指定的值以後纔開始限速。

8. 文件操做的優化

8.1 sendfile系統調用

語法：sendfile on|off;
默認：sendfile off;
配置塊：http、server、location

該參數用於打開Linux上的sendfile系統調用，在發送數據到網卡上時，它減小了兩次在用戶態與內核態之間的數據拷貝過程，而直接在磁盤讀取數據以後發送到網卡上，從而提高數據發送效率。

8.2 AIO系統調用

語法：aio on|off;
默認：aio off;
配置塊：http、server、location

該參數指定了是否在FreeBSD或Linux系統上啓動內核級別的異步文件I/O功能，須要注意的是，其與sendfile功能是互斥的。

8.3 directio

語法：directio size|off;
默認：directio off;
配置塊：http、server、location

該配置項在FreeBSD和Linux系統上使用O_DIRECT選項去讀取文件，緩衝區大小爲size，一般對大文件的讀取速度有優化做用。注意，它與sendfile指令是互斥的。

8.4 directio_alignment

語法：directio_alignment size;
默認：directio_alignment 512;
配置塊：http、server、location

它與directio配合使用，指定以directio方式讀取文件時的對其方式。通常狀況下，512B已經足夠了，但對於一些高性能文件系統，如Linux下的XFS文件系統，可能須要設置4KB做爲對齊方式。

8.5 打開文件緩存

語法：open_file_cache max=N[inactive=time]|off;
默認：open_file_cache off;
配置塊：http、server、location

文件緩存會在內存中存儲如下三種信息：
- 文件句柄、文件大小和上次修改時間；
- 已經打開過的目錄結構；
- 沒有找到的或者沒有權限操做的文件信息；
上面的配置項的三個參數的含義以下：
- max：表示內存中存儲元素的最大個數。當達到最大限制數量後，將採用LRU算法從緩存中淘汰最近最少使用的元素；
- inactive：表示在inactive指定的時間段內沒有被訪問過的元素將會被淘汰。默認時間爲60秒；
- off：關閉緩存功能。
示例以下：
```
open_file_cache max=1000 inactive=20s;
```

8.6 是否緩存打開文件錯誤的信息

語法：open_file_cache_errors on|off;
默認：open_file_cache_errors off;
配置塊：http、server、location

該配置項表示是否對打開文件時找不到文件或者權限錯誤等信息進行緩存。

8.7 不被淘汰的最小訪問次數

語法：open_file_cache_min_uses number;
默認：open_file_cache_min_uses 1;
配置塊：http、server、location

該參數與open_file_cache配合使用，若是在指定時間內訪問該文件的次數小於該參數指定的次數，那麼該文件仍是會被淘汰。

8.8 檢驗緩存中元素有效性的頻率

語法：open_file_cache_valid time;
默認：open_file_cahce_valid 60s;
配置塊：http、server、location

該參數指定了每間隔多長時間檢查一下緩存中數據的有效性，默認爲60秒。

9. 對客戶端請求的特殊處理

9.1 忽略不合法的http頭部

語法：ignore_invalid_headers on|off;
默認：ignore_invalid_headers on;
配置塊：http、server

若是將其設置爲off，那麼當客戶端請求中有不合法的header時，就會直接響應400（Bad Request）；若是將其設置爲on，那麼就會忽略此header。

9.2 http頭部是否容許下劃線

語法：underscores_in_headers on|off;
默認：underscores_in_headers off;
配置塊：http、server

該參數指定了http頭部中是否可以帶有下劃線，默認是不容許。

9.3 對If-Modified-Since頭部的處理策略

語法：if_modified_since [off|exact|before];
默認：if_modified_since exact;
配置塊：http、server、location

If-Modified-Since頭部主要是瀏覽器處於性能考慮而做的一個緩存策略，瀏覽器在請求過一份文件以後，會將該文件在本地緩存，並記錄緩存時間，在下次請求時會在If-Modified-Since頭部中帶上上次緩存的時間，服務器在接收到該請求時，會將服務器文件的修改時間與請求中的時間進行比較，若是文件在這以後有過修改，那麼服務器就會正常的返回文件內容以及200狀態碼，若是文件沒有修改過，那麼說明瀏覽器中緩存的文件是最新的，此時就會返回304（Not Modified）狀態碼。
該配置參數有三個選項，其含義分別以下：
- off：表示忽略用戶請求中的If-Modified-Since頭部，在每次請求時都將文件內容返回，此時響應狀態碼爲200；
- exact：將If-Modified-Since頭部包含的時間與將要返回的文件的上次修改時間作精確比較，若是沒有匹配上，則返回200和文件的實際內容，若是匹配上了，則表示文件內容已是最新的，此時就會返回304（Not Modified）狀態碼，瀏覽器收到後會直接讀取本地緩存；
- before：這個是比exact更寬鬆的策略，只要文件的上次修改時間在用戶請求的If-Modified-Since頭部指定的時間以前，那麼就會向客戶端返回304（Not Modified）狀態碼。

9.4 文件未找到時是否返回error日誌

語法：log_not_found on|off;
默認：log_not_found on;
配置塊：http、server、location

該配置的主要做用在於，當用戶請求某個文件時，若是該文件不存在，是否將這條信息記錄在error日誌中，主要用於定位問題。

9.5 merge_slashes

語法：merge_slashes on|off;
默認：merge_slashes on;
配置塊：http、server、location

該配置項表示是否合併相鄰的/，例如//test///a.txt，在配置爲on時，會將其匹配爲location/test/a.txt；若是配置爲off，則不會匹配，URI將仍然是//test///a.txt。

9.6 DNS解析地址

語法：resolver address...;
配置塊：http、server、location

設置DNS名字解析服務器的地址，如：
```
resolver 127.0.0.1 192.0.2.1;
```

9.7 DNS解析的超時時間

語法：resolver_timeout time;
默認：resolver_timeout 30s;
配置塊：http、server、location

次配置項表示DNS解析的超時時間

9.8 返回錯誤頁面時是否在server中註明nginx版本

語法：server_tokens on|off;
默認：server_tokens on;
配置塊：http、server、location

表示在返回錯誤頁面時是否在Server頭部中返回具體的nginx版本，這主要是爲了定位問題方便。

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。