Nginx核心配置詳解
作為一款高效能的 HTTP 伺服器軟體,Nginx 的核心功能就是應對 HTTP 請求的處理。由於具體硬體、作業系統及應用場景的不同,需要 Nginx 在對 HTTP 請求的處理方法上進行不同的調整,為了應對這些差異,Nginx 提供了多種配置指令,讓使用者可以根據實際的軟硬體及使用場景進行靈活配置。
為了方便理解和使用,可以按照其在程式碼中的分佈,將其分為核心配置指令和模組配置指令兩大類。核心配置指令分為事件核心配置指令和 HTTP 核心配置指令,事件核心配置指令主要是與 Nginx 自身軟體執行管理及 Nginx 事件驅動架構有關的配置指令;HTTP 核心配置指令是對客戶端從發起 HTTP 請求、完成 HTTP 請求處理、返回處理結果,到關閉 HTTP 連線的完整過程中的各個處理方法進行配置的配置指令。模組配置指令是在每個 Nginx 模組中對所在模組的操作方法進行配置的配置指令。
1.Nginx配置檔案詳解
Nginx使用yum安裝後,配置檔案會儲存在/etc/nginx/nginx.conf,在配置檔案目錄下,Nginx 預設的主配置檔案是 nginx.conf,這也是 Nginx 唯一的預設配置入口
1.配置檔案目錄
Nginx 配置檔案在 conf 目錄下,其預設目錄結構如下。
conf/ ├── fastcgi.conf ├── fastcgi.conf.default ├── fastcgi_params ├── fastcgi_params.default ├── koi-utf ├── koi-win ├── mime.types ├── mime.types.default ├── nginx.conf ├── nginx.conf.default ├── scgi_params ├── scgi_params.default ├── uwsgi_params ├── uwsgi_params.default └── win-utf
其中,以“.default”為副檔名的檔案是 Nginx 配置檔案的配置樣例檔案。各配置檔案的說明如下。
-
- fastcgi_params:Nginx 在配置 FastCGI 代理服務時會根據 fastcgi_params 檔案的配置向 FastCGI 伺服器傳遞變數,該配置檔案現已由 fastcgi.conf 代替;
- fastcgi.conf:為了規範配置指令 SCRIPT_FILENAME 的用法,引入 FastCGI 變數傳遞配置;
- mime.types:MIME 型別對映表,Nginx 會根據服務端檔案字尾名在對映關係中獲取所屬檔案型別,將檔案型別新增到 HTTP 訊息頭欄位“Content-Type”中;
- nginx.conf:Nginx 預設的配置入口檔案;
- scgi_params:Nginx 在配置 SCGI 代理服務時會根據 scgi_params 檔案的配置向 SCGI 伺服器傳遞變數;
- uwsgi_params:Nginx 在配置 uWSGI 代理服務時會根據 uwsgi_params 檔案的配置向 uWSGI 伺服器傳遞變數;
- koi-utf、koi-win、win-utf:這 3 個檔案是 KOI8-R 編碼轉換的對映檔案,因為 Nginx 的作者是俄羅斯人,在 Unicode 流行之前,KOI8-R 是使用最為廣泛的俄語編碼。
2.配置檔案結構
為了便於瞭解 Nginx 配置檔案的內部結構,這裡約定幾個名詞的定義。
1) 配置指令
在配置檔案中,由 Nginx 約定的內部固定字串,Nginx 官方文件中的英文單詞為 directive,本教程中則統一稱為配置指令,簡稱指令。指令是 Nginx 中功能配置的最基本元素,Nginx 的每個功能配置都是通過多個不同的指令組合來實現的。
2) 配置指令值
每個配置指令都有對應的內容來表示該指令的控制引數,本教程中約定其對應的內容為配置指令值,簡稱指令值。指令值可以是字串、數字或變數等多種型別。
3) 配置指令語句
指令與指令值組合構成指令語句。一條指令語句可以包含多個配置指令值,在 Nginx 配置檔案中,每條指令語句都要用;作為語句結束的識別符號。
4) 配置指令域
配置指令值有時會是由{ }括起來的指令語句集合,本教程中約定{ }括起來的部分為配置指令域,簡稱指令域。指令域既可以包含多個指令語句,也可以包含多個指令域。
5) 配置全域性域
配置檔案 nginx.conf 中上層沒有其他指令域的區域被稱為配置全域性域,簡稱全域性域。
Nginx 的常見配置指令域如下表所示。
域名稱 |
域型別 |
域說明 |
main |
全域性域 |
Nginx 的根級別指令區域。該區域的配置指令是全域性有效的,該指令名為隱性顯示,nginx.conf 的整個檔案內容都寫在該指令域中 |
events |
指令域 |
Nginx 事件驅動相關的配置指令域 |
http |
指令域 |
Nginx HTTP 核心配置指令域,包含客戶端完整 HTTP 請求過程中每個過程的處理方法的配置指令 |
upstream |
指令域 |
用於定義被代理伺服器組的指令區域,也稱“上游伺服器” |
server |
指令域 |
Nginx 用來定義服務 IP、繫結埠及服務相關的指令區域 |
location |
指令域 |
對使用者 URI 進行訪問路由處理的指令區域 |
stream |
指令域 |
Nginx 對 TCP 協議實現代理的配置指令域 |
types |
指令域 |
定義被請求副檔名與 MIME 型別對映表的指令區域 |
if |
指令域 |
按照選擇條件判斷為真時使用的配置指令域 |
開啟系統預設的 nginx.conf 檔案,可以看到整個檔案的結構如下。
#user nobody; worker_processes 1; # 只啟動一個工作程序 events { worker_connections 1024; # 每個工作程序的最大連線為1024 } http { include mime.types; # 引入MIME型別對映表文件 default_type application/octet-stream; # 全域性預設對映型別為application/octet-stream #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 on; # 啟用零複製機制 keepalive_timeout 65; # 保持連線超時時間為65s server { listen 80; # 監聽80埠的網路連線請求 server_name localhost; # 虛擬主機名為localhost #charset koi8-r; #access_log logs/host.access.log main; location / { root html; index index.html index.htm; } error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } } }
由上述配置檔案可以看出,配置檔案中的指令和指令值是以類似於 key-value 的形式書寫的。寫在配置檔案全域性域的指令是 Nginx 配置檔案的核心指令,主要是對 Nginx 自身軟體執行進行配置的指令。其中,events 和 http 所包含的部分分別為事件指令域和 HTTP 指令域,指令域內的指令則明確約定了該區域內的指令的應用範圍。
server 指令域被包含於 http 指令域中,同時又包含了 location 指令域,各指令域中的共用範圍逐層被上層指令域限定,可見各指令域匹配的順序是由外到內的。Nginx 的配置指令按照內部設定可以同時編寫在不同指令域中,包含在最內層的指令將對外層同名指令進行指令值覆蓋,並以最內層指令配置為最終生效配置。
編寫 Nginx 配置檔案時,為了便於維護,也會把一些指令或指令域寫在外部檔案中,再通過 include 指令引入 nginx.conf 主配置檔案中。例如,配置檔案中把寫有 types 指令域的 mime.types 檔案引用到 http 指令域中。此處使用的是 nginx.conf 檔案的相對路徑。
3.配置檔案中的計量單位
在 Nginx 配置檔案中有很多與容量、時間相關的指令值,Nginx 配置檔案有如下規範。
1) 容量單位可以使用位元組、千位元組、兆位元組或千兆位元組,示例如下。
512
1k或1K
10m或10M
1g或10G
2) 時間的最小單位是毫秒,示例如下。
10ms # 10毫秒 30s # 30秒 2m # 2分鐘 5h # 5小時 1h 30m # 1小時30分 6d # 6天 3w # 3周 5M # 5個月 2y # 2年
4.配置檔案中的雜湊表
Nginx 使用雜湊表加速對 Nginx 配置中常量的處理,如 server 中的主機名、types 中的 MIME 型別對映表、請求頭屬性欄位等資料集合。雜湊表是通過關鍵碼來快速訪問常量對應值的資料儲存結構,在通過雜湊表獲取資料的過程中,其內部實現通過相關函式將常量名轉換為一個關鍵碼來實現對應值的快速定位和讀取。
由於資料的複雜性,會出現不同常量名轉換的關鍵碼是一樣的情況,這就會導致讀取對應值時發生衝突。為了解決這個問題,Nginx 同時引入了雜湊桶機制,就是把相同關鍵碼的雜湊鍵存在一個雜湊桶定義的儲存空間中,然後再進行二次計算來獲取對應的值。
單個雜湊桶的大小等於 CPU 快取行大小的倍數。這樣就可以通過減少記憶體訪問的數量來加速在 CPU 中搜索雜湊關鍵碼的速度。如果雜湊桶的大小等於 CPU 的快取行的大小,在 Nginx 進行雜湊關鍵碼搜尋期間,記憶體的訪問次數最多是兩次,一次是計算雜湊桶的地址,另一次是在雜湊桶內進行雜湊關鍵碼的搜尋。
Linux 系統下檢視 CPU 快取行的指令如下。
cat /proc/cpuinfo |grep cache_alignment
Nginx 在每次啟動或重新載入配置時會選擇合適大小的最小初始化雜湊表。雜湊表的大小會隨雜湊桶數量的增加而不斷調整,直到雜湊桶總的大小達到雜湊表設定的最大值。因此,在 Nginx 提示需要增加雜湊表或雜湊桶的大小時,要先調整雜湊表的大小。
2.Nginx程序配置指令詳解
Nginx 的程序配置指令包含在 Nginx 核心程式碼及事件模組程式碼中,按配置指令設定的功能可分為程序管理、程序調優、程序除錯、事件處理 4 個部分。
1.程序管理
Nginx 本身是一款應用軟體,在其執行時,使用者可對其執行方式、動態載入模組、日誌輸出等使用其內建的基礎配置指令進行配置,指令說明如下表所示。
表:程序管理指令 |
||
指令 |
預設值 |
指令說明 |
daemon |
on |
用於設定 Nginx 程序是否以守護程序的方式在後臺執行,on 為啟用,off 為不啟用 |
pid |
logs/nginx.pid |
設定儲存 Nginx 主程序 ID 的檔案路徑 |
user |
nobody nobody |
用於設定 Nginx 啟動後,主程序喚起的工作程序執行的使用者及使用者組 |
load_module |
-- |
載入動態模組的指令 |
include |
-- |
載入外部配置檔案 |
error_log |
logs/error.log error |
指定錯誤日誌檔案路徑及檔名 |
pcre_jit |
off |
用於設定在配置檔案中的正則表示式是否使用 pcre_jit 技術,off 為不使用,on 為使用 |
ssl_engine |
-- |
指定使用的 OpenSSL 加速引擎名稱 |
其中,pcre_jit 需要 Nginx 在配置編譯時加上 --with-pcre-jit 引數;error_log 的日誌級別可以為如下值:debug、info、notice、warn、error、crit、alert、emerg。
在 Linux 系統中,可用如下命令檢視當前系統支援的 OpenSSL 加速引擎資訊。
openssl engine -t
2.程序調優
Nginx 是按照事件驅動架構設計的。每個外部請求都以事件的形式被工作程序(Worker Process)響應,併發完成各種功能的操作處理。Nginx 工作程序的效能依賴於硬體和作業系統的配置,在實際應用場景中,使用者需要按照硬體、作業系統或應用場景需求的側重點進行相應的配置調整。
Nginx 的程序調優配置指令如下面表格中所示。
表:執行緒池指令 |
|
名 稱 |
執行緒池指令 |
指令 |
thread_pool |
作用域 |
main |
預設值 |
thread_pool default threads=32 max_queue=65536; |
指令說明 |
執行緒池配置指令,允許調整預設執行緒池或建立新的執行緒池,用於讀取和傳送檔案的場景中。線上程池中所有執行緒都繁忙時,新的請求任務將在佇列中等待,預設情況下,等待佇列中的最大任務數是 65536,使用執行緒池機制時,通過配置該指令,可以在因讀取和傳送檔案引發阻塞的場景中提升 Nginx 讀取和傳送檔案的處理效能 |
配置樣例如下:
thread_pool pool_1 threads=16;
具體引數說明如下。
-
- thread_pool 也可以編寫在 http 指令域中;
- threads 引數定義了執行緒池的執行緒數;
- max_queue 引數指定了等待佇列中的最大任務數,線上程池中所有執行緒都處於繁忙狀態時,新任務將進入等待佇列。等待佇列中的最大任務數為 65536;
- 執行緒池指令需要在編譯配置時增加 --with-threads 引數。
表:定時器方案指令 |
|
名 稱 |
定時器方案指令 |
指令 |
timer_resolution |
作用域 |
main |
預設值 |
-- |
指令說明 |
Nginx 中的處理事件超時管理方案有兩種,一種是設定一個定時器,每過一段時間就對所有超時事件進行一次掃描;另一種是先計算出距離當前時間最近的將要發生超時事件的時間,然後等待這個時間之後再去進行一次超時檢測。預設配置下使用第二種超時檢測方案,該方案是依據事件超時時間與當前時間的時間差進行檢測的,所以每次事件返回都需要進行新的檢測時間計算,在 I/O 事件比較多的場景下,這會導致頻繁地呼叫時間函式 gettimeofday 進行計算並更新下次檢測的時間,資源消耗相對較高。而設定一個指定的時間值啟用第一種方案時,Nginx 內建的事件超時檢測定時器會在指定時間週期內進行事件超時檢測,無須呼叫時間函式 gettimeofday 更新時間,資源消耗相對較低 |
配置樣例如下:
timer_resolution 100ms;
在因頻繁呼叫時間函式引發的資源消耗不大的場景中可不設定該指令。
表:工作程序優先順序指令 |
|
名 稱 |
工作程序優先順序指令 |
指令 |
worker_priority |
作用域 |
main |
預設值 |
0 |
指令說明 |
工作程序優先順序設定指令,可以通過該指令設定工作程序在 Linux 系統中的優先順序(nice 值) |
配置樣例如下:
worker_priority -5;
worker_priority 指令值的取值範圍是 -20~19,數值越小,優先順序越高,獲得的 CPU 時間就越多。配置生效後可以通過如下命令檢視,輸出結果如下圖所示。
ps axo command,pid,ni | grep nginx | grep -v grep
表:工作程序數指令 |
|
名 稱 |
工作程序數指令 |
指令 |
worker_processes |
作用域 |
main |
預設值 |
1 |
可配置選項 |
number 或 auto |
指令說明 |
依據 Nginx 架構可知,工作程序數量的最佳配置是小於或等於 CPU 核心的數量。通過該指令可以手動設定工作程序的數量,該指令也支援 auto 指令值,由 Nginx 進行自動分配 |
配置樣例如下:
worker_processes auto;
工作程序數指令的指令值有兩種型別,分別為數字和 auto。指令值為 auto 時,Nginx 會根據 CPU 的核心數生成等數量的工作程序。
表:工作程序 CPU 繫結指令 |
|
名 稱 |
工作程序 CPU 繫結指令 |
指令 |
worker_cpu_affinity |
作用域 |
main |
預設值 |
-- |
可配置選項 |
cpumark 或 auto |
指令說明 |
Nginx 工作程序處於高效的工作狀態是因為充分利用了程序與 CPU 的親緣性,使每個工作程序均可固定在一個 CPU 上執行。該指令可以手動進行工作程序與 CPU 的繫結,當然也可以通過設定指令值 auto 交由 Nginx 自動分配 |
配置樣例如下:
worker_processes 8;
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;
指令值是用 CPU 掩碼來表示的,使用與 CPU 數量相等位數的二進位制值來表示。單個 CPU 用單個二進位制值表示,多個 CPU 組合可用二進位制值相加來表示。如配置樣例所示,CPU 有 8 個核,分別表示綁定了從第 0 核到第 7 核的 CPU。CPU 核數是從 0 開始計數的。
指令值除了可以是 CPU 掩碼外,還可以是 auto。當指令值為 auto 時,Nginx 會自動進行 CPU 繫結。
配置樣例如下:
worker_processes auto;
worker_cpu_affinity auto;
工作程序與 CPU 核數也可以是多種對應組合,指令語句如下:
worker_processes 4; worker_cpu_affinity 01 10 01 10; # 表示把第1、3工作程序繫結在2核CPU的第0核,第2、4工作 # 程序繫結在2核CPU的第1核 worker_processes 2; worker_cpu_affinity 0101 1010; # 表示把第1工作程序繫結在CPU的第0核和第2核,第2工作程序 # 繫結在CPU的第1核和第3核
工作程序 CPU 繫結指令僅適合於 FreeBSD 和 Linux 作業系統。
表:工作程序開檔案數指令 |
|
名 稱 |
工作程序開檔案數指令 |
指令 |
worker_rlimit_nofile |
作用域 |
main |
預設值 |
-- |
指令說明 |
設定 Nginx 所有工作程序同時開啟檔案的最大數量,預設為作業系統的檔案開啟數 |
配置樣例如下:
worker_rlimit_nofile 65535;
表:工作程序關閉等待時間指令 |
|
名 稱 |
工作程序關閉等待時間指令 |
指令 |
worker_shutdown_timeout |
作用域 |
main |
預設值 |
-- |
指令說明 |
設定 Nginx 正常關閉工作程序的超時時間,當超過設定的時間時,Nginx 主程序將強制關閉所有 |
配置樣例如下:
worker_shutdown_timeout 10s;
表:設定互斥鎖檔案指令 |
|
名 稱 |
設定互斥鎖檔案指令 |
指令 |
lock_file |
作用域 |
main |
預設值 |
logs/nginx.lock; |
指令說明 |
設定互斥鎖檔案指令,在開啟 accept mutex 程序排程模式或使用共享記憶體的場景下,需要用到互斥鎖機制。在一些支援原子操作的作業系統中,可使用共享記憶體實現互斥鎖。在不支援原子操作的系統環境下,需要通過該指令指定一個互斥鎖檔案 |
配置樣例如下:
lock_file logs/nginx.lock;
3.程序除錯
Nginx 調整配置或執行發生異常時,為了及時獲知工作程序在事件處理過程中發生的問題,可通過獲取記憶體中各狀態機、變數等資料的內容進行除錯。Nginx 為使用者提供了一些除錯用的配置指令,方便使用者進行程序除錯。配置指令如下面表格中所示。
表:主程序指令 |
|
名 稱 |
主程序指令 |
指令 |
master_process |
作用域 |
main |
預設值 |
on |
可配置選項 |
on 或 off |
指令說明 |
Nginx 預設是以一個主程序管理多個工作程序的工作方式,設定指令值為 off 時,Nginx 將只執行一個主程序來處理所有請求 |
配置樣例如下:
master_process off;
當只由主程序處理請求時,除錯程序會更加方便。
表:除錯點控制指令 |
|
名 稱 |
除錯點控制指令 |
指令 |
debug_points |
作用域 |
main |
預設值 |
-- |
可配置選項 |
stop 或 abort |
指令說明 |
該指令用於進行除錯點的控制,當指令值為 stop 時,Nginx 在執行到內部除錯點時就會發出 SIGSTOP 訊號,方便使用者進行除錯;當指令值為 abort 時則會停止程序並建立 corefile |
配置樣例如下:
debug_points stop;
表:工作目錄指令 |
|
名稱 |
工作目錄指令 |
指令 |
working_directory |
作用域 |
main |
預設值 |
-- |
指令說明 |
在 Linux 作業系統中,當程序執行出錯或收到終止訊號時,作業系統會將執行程序過程中,記憶體中的內容儲存到一個檔案中,該檔案被稱為崩潰檔案(corefile),當 Nginx 程序發生這種狀況時也會生成一個崩潰檔案,該崩潰檔案中包含當時的堆疊及暫存器等資訊,方便使用者排查問題產生的原因。該指令用於設定工作程序儲存崩潰檔案的目錄,在 Nginx 程式崩潰時向該目錄中寫入崩潰檔案,Nginx 程序需要被設定有目錄的寫許可權 |
配置樣例如下:
working_directory logs
可以使用工具 objdump、GDB 進行檔案分析。
表:除錯檔案大小指令 |
|
名稱 |
除錯檔案大小指令 |
指令 |
worker_rlimit_core |
作用域 |
main |
預設值 |
-- |
指令說明 |
該指令是崩潰檔案大小的設定指令。因為崩潰檔案會儲存非常詳細的資訊,資料量很大,很容易把磁碟空間佔滿,因此需要合理限制崩潰檔案的檔案大小 |
配置樣例如下:
worker_rlimit_core 800m;
4.事件處理
Nginx 是採用事件驅動式架構處理外部請求的,這一架構使得 Nginx 在現有硬體架構下可以處理數以萬計的併發請求。通過事件處理指令的配置可以讓 Nginx 與實際執行的硬體及系統進行有效的適配,從而發揮更加高效的併發處理能力。Nginx 的事件處理指令編輯在 events 指令域中,如下面表格中所示。
表:工作程序併發數指令 |
|
名稱 |
工作程序併發數指令 |
指令 |
worker_connections |
作用域 |
events |
預設值 |
512 |
指令說明 |
每個 Nginx 工作程序可處理併發連線的最大數 |
配置樣例如下:
events { worker_connections 65535; }
Linux 系統下,因為每個網路連線都將開啟一個檔案描述符,Nginx 可處理的併發連線數受限於作業系統的最大開啟檔案數,同時所有工作程序的併發數也受 worker_rlimit_nofile 指令值的限制。
表:事件處理機制選擇指令 |
|
名 稱 |
事件處理機制選擇指令 |
指令 |
use |
作用域 |
events |
預設值 |
-- |
指令說明 |
Nginx 內部有多種事件處理機制模型,以下簡稱事件模型。預設情況下,Nginx 會自動選擇一種高效的事件模型,使用者可以通過該指令自行選擇事件模型進行事件處理 |
配置樣例如下:
events {
use epoll;
}
Nginx 支援的事件模型有 select、poll、kqueue、epoll、/dev/poll、eventport。
表:互斥鎖指令 |
|
名稱 |
互斥鎖指令 |
指令 |
accept_mutex |
作用域 |
events |
預設值 |
off |
可配置選項 |
on 或 off |
指令說明 |
設定是否啟用互斥鎖模式的程序排程 |
配置樣例如下:
events {
accept_mutex on;
}
在 Nginx 1.11.3 版本之前,互斥鎖指令是預設開啟的。
表:互斥鎖等待時間指令 |
|
名稱 |
互斥鎖等待時間指令 |
指令 |
accept_mutex_delay |
作用域 |
events |
預設值 |
500ms |
指令說明 |
Nginx 工作程序在互斥鎖模式下需要不斷地爭搶互斥鎖,沒有互斥鎖的工作程序如果爭搶不到互斥鎖,會在等待時間結束後執行下一輪爭搶。通過該指令可以將搶鎖等待時間設定為一個較短的時間,以提高程序爭搶互斥鎖的頻率 |
配置樣例如下:
events {
accept_mutex_delay 300ms;
}
表:多請求支援指令 |
|
名稱 |
多請求支援指令 |
指令 |
multi_accept |
作用域 |
events |
預設值 |
off |
可配置選項 |
on 或 off |
指令說明 |
預設情況下,每個工作程序一次只接收一個新連線。如果開啟該指令,則每個工作程序將接收所有的新連線 |
配置樣例如下:
events {
multi_accept on;
}
表:未完成非同步操作最大數指令 |
|
名稱 |
未完成非同步操作最大數指令 |
指令 |
worker_aio_requests |
作用域 |
events |
預設值 |
32 |
指令說明 |
用於設定當在 epoll 事件模型下使用 AIO 時,單個工作程序未完成非同步 I/O 操作的最大數 |
配置樣例如下:
events { worker_aio_requests 128; }
表:除錯指定連線指令 |
|
名稱 |
除錯指定連線指令 |
指令 |
debug_connection |
作用域 |
events |
預設值 |
off |
可配置選項 |
address 或 CIDR 或 unix: |
指令說明 |
對指定的客戶端連線開啟除錯日誌 |
配置樣例如下:
events { debug_connection 127.0.0.1; debug_connection localhost; debug_connection 192.0.2.0/24; debug_connection ::1; debug_connection 2001:0db8::/32; debug_connection unix:; ... }
該指令需要 Nginx 在編譯時通過--with-debug引數開啟。
5.指令配置樣例
本節指令的配置樣例如下。
daemon on; # 以守護程序的方式執行Nginx pid logs/nginx.pid; # 主程序ID記錄在logs/nginx.pid中 user nobody nobody; # 工作程序執行使用者為nobody load_module "modules/ngx_http_xslt_filter_module.so"; # 載入動態模組ngx_http_xslt_ # filter_module.so error_log logs/error.log debug; # 錯誤日誌輸出級別為debug pcre_jit on; # 啟用pcre_jit技術 thread_pool default threads=32 max_queue=65536; # 執行緒池的執行緒數為32,等待佇列中的最大 # 任務數為65536 timer_resolution 100ms; # 定時器週期為100毫秒 worker_priority -5; # 工作程序系統優先順序為-5 worker_processes auto; # 工作程序數由Nginx自動調整 worker_cpu_affinity auto; # 工作程序的CPU繫結由Nginx自動調整 worker_rlimit_nofile 65535; # 所有工作程序的最大連線數是65535 worker_shutdown_timeout 10s; # 工作程序關閉等待時間是10秒 lock_file logs/nginx.lock; # 互斥鎖檔案的位置是logs/nginx.lock working_directory logs # 工作程序工作目錄是logs debug_points stop; # 除錯點模式為stop worker_rlimit_core 800m; # 崩潰檔案大小為800MB events { worker_connections 65535; # 每個工作程序的最大連線數是65535 use epoll; # 指定事件模型為epoll accept_mutex on; # 啟用互斥鎖模式的程序排程 accept_mutex_delay 300ms; # 互斥鎖模式下程序等待時間為300毫秒 multi_accept on; # 啟用支援多連線 worker_aio_requests 128; # 完成非同步操作最大數為128 debug_connection 192.0.2.0/24; # 除錯指定連線的IP地址和埠是192.0.2.0/24 }
3.Nginx埠監聽(listen指令)
本節主要來介紹 Nginx 中與埠監聽有關的配置指令,下表為埠監聽指令及其相關說明。
名稱 |
埠監聽指令 |
指令 |
listen |
作用域 |
server |
預設值 |
listen*:80 或 *:8000 |
指令說明 |
服務監聽埠、繫結 IP、監聽方式的配置 |
Nginx 服務通過 listen 指令的指令值監聽網路請求,可以是 IP 協議的形式,也可以是 UNIX 域套接字。如果不設定 listen 指令,Nginx 在以超級使用者執行時則監聽 80 埠,以非超級使用者執行時則監聽 8000 埠。
listen 指令的指令值還針對監聽方式提供了豐富的引數,如下表所示。
引數 |
預設值 |
引數說明 |
address |
-- |
若為 IP 協議,該引數值為指定繫結監聽埠的 IP 或主機名;若為 UNIX 域套接字,則該引數值為 sock 檔案路徑 |
port |
80 |
IP 協議監聽的埠 |
bind |
address:port |
指定 IP 及埠 |
ipv6only |
on |
只接收 IPv6 連線或接收 IPv6 和 IPv4 連線 |
default_server |
-- |
當 http 指令域中包含多個虛擬主機時,該引數用於指定哪個虛擬主機是預設服務,預設將第一個順序的 server 設為預設服務。預設服務可以用來處理沒有 server_name 匹配成功的請求 |
http2 |
-- |
HTTP/2 協議支援 |
spdy |
-- |
SDPY 協議支援,與 HTTP/2 協議不能同時存在 |
ssl |
-- |
SSL 支援 |
proxy_protocol |
-- |
在指定監聽埠上啟用 proxy_protocol 協議支援 |
fastopen |
number |
HTTP 處於保持連線(keepalive)狀態時,允許不經過三次握手的 TCP 連線的佇列的最大數 |
deferred |
-- |
新增該引數後,在 TCP 三次握手的過程中,檢測到客戶端有資料時才將 TCP 狀態置為 ESTABLISHED 狀態,沒有資料則直接丟棄 |
reuseport |
-- |
預設情況下,所有的工作程序會共享一個 socket 去監聽同一 IP 和埠的組合。該引數啟用後,允許每個工作程序有獨立的 socket 去監聽同一 IP 和埠的組合,核心會對傳人的連線進行負載均衡。適用於 Linux 3.9+,DragonFly BSD 和 FreeBSD 12+ |
so_keepalive |
off |
配置是否在監聽的埠啟用“TCP keepalive”機制。當設定為 on 時,預設等同於 so_keepalive=30m::10,表示 30 分鐘無資料傳輸時傳送探測包,傳送 10 次,傳送間隔使用系統核心引數 tcp_keepalive_intvl 的設定值 |
backlog |
-1/511 |
當阻塞時,設定掛起連線佇列的最大長度,在 FreeBSD,DragonFly BSD 和 MacOS 作業系統上,預設值為 -1,其他平臺上值為 511 |
rcvbuf |
-- |
socket 接收緩衝的大小,預設為 8k 位元組,在接收資料比較大的場景中可以適當調整 |
sndbuf |
-- |
socket 傳送緩衝的大小,預設為 8k 位元組,在傳送資料較大的場景中可以適當調整 |
setfib |
number |
為監聽套接字設定關聯路由表,僅在 FreeBSD 系統上有效 |
accept_filter |
filter |
為監聽套接字設定過濾器,僅支援 FreeBSD 和 NetBSD 5.0+ 系統 |
配置樣例如下:
http { server { listen 127.0.0.1:8000; # 監聽127.0.0.1的8000埠 listen 127.0.0.1; # 監聽127.0.0.1的預設80埠(root許可權) listen 8000; # 監聽本機所有IP的8000埠 listen *:8000; # 監聽本機所有IP的8000埠 listen localhost:8000; # 監聽locahost的8000埠 listen [::]:8000; # 監聽IPv6的8000埠 listen [::1]; # 監聽IPv6的迴環IP的預設80埠(root許可權) listen unix:/var/run/nginx.sock; # 監聽域套接字檔案 listen *:8000 \ # 監聽本機的8000埠 default_server \ # 當前服務是http指令域的主服務 fastopen=30 \ # 開啟fastopen功能並限定最大佇列數為30 deferred \ # 拒絕空資料連線 reuseport \ # 工作程序共享socket這個監聽埠 backlog=1024 \ # 請求阻塞時掛起佇列數是1024個 so_keepalive=on; # 當socket為保持連線時,開啟狀態檢測功能 } }
4.Nginx server_name:配置主機名稱
Nginx 中的 server_name 指令主要用於配置基於名稱的虛擬主機,其說明如下表所示:
名稱 |
主機名指令 |
指令 |
server_name |
作用域 |
server |
預設值 |
-- |
指令說明 |
設定所在 server 指令域的主機名 |
配置樣例如下所示:
http { server { server_name example.com .example.com; # 泛域名的使用 server_name www.example.; # 多個字尾域名的使用server_name www.example.com ~^www.example.com$; # 正則表示式匹配 # 正則匹配變數的場景 server_name ~^(www\.)?(.+)$; location / { root /sites/$2; } # 正則匹配為變數的場景 server_name ~^(www\.)?(?<domain>.+)$; location / { root /sites/$domain; } } }
當 server_name 指令值中有多個主機名時,第一個主機名為首主機名。
5.Nginx處理HTTP請求
標準的 HTTP 請求從開始到結束包括請求報文和響應報文。
請求報文是客戶端向服務端發起請求時告知服務端請求的方式、相關屬性和請求內容的資料包,由請求行、請求頭、請求體組成,這裡以百度首頁的請求為例,HTTP請求頭結構如下圖所示。
請求行是請求頭內容的第一行,包括請求方法 GET,請求的 URI 地址 https://www.baidu.com,請求的協議及版本號 HTTP/1.1。
請求頭還包含此次請求所設定的若干屬性欄位,屬性欄位由屬性名稱和屬性值組成,如瀏覽器資訊 User-Agent 等。
請求體則是請求資料,該請求是無引數的 GET 方法,請求體中無內容。
常見的請求頭屬性如下表所示。
屬性名稱 |
屬性值樣例 |
屬性說明 |
Host |
www.baidu.com |
記錄使用者請求的目標主機名,常用於服務端虛擬主機的區分,對應 Nginx 的 server_name 指令的配置 |
Accept |
text/html, application/xhtml+xml |
描述客戶端能夠接收服務端返回的資料型別,Nginx 會通過 types 指令域中的內容做匹配 |
Cookie |
BD_HOME=1; sugstore=1 |
客戶端當前連線的所有 cookie |
Referer |
https://www.baidu.com |
表示當前連線的上一個來源 URI |
Cache-Control |
no-cache |
當前客戶端快取機制的控制,可通過更多的屬性值引數進行快取控制 |
Connection |
keep-alive |
表示是否需要啟用保持連線機制,HTTP/1.1 預設啟用保持連線 |
If-None-Match |
W/ "50b1c1d4f775c61:df3" |
與頁面響應頭中 etag 的屬性值配合使用,將 etag 的內容提交給服務端,用以判斷請求內容是否已經被修改,若未被修改,則返回狀態碼 304,客戶端使用本地快取 |
if_modified_since |
-- |
當前請求 URI 頁面本地快取的最後修改時間。伺服器會將實際檔案的修改時間與該引數值進行比較,若一致,則返回 304,客戶端讀取本地快取;若不一致,則返回服務端檔案的內容 |
響應報文是服務端處理客戶端請求後返回客戶端的資料,資料包括響應行、響應頭、響應體 3 個部分,HTTP 響應頭結構如下圖所示。
響應行是響應頭內容的第一行,包含報文協議及版本號 HTTP/1.1、響應狀態碼 200、響應狀態描述 OK。
響應頭則包含服務端處理完請求後響應設定的若干屬性欄位,如 set-cookie 資訊等。
響應體為返回的處理結果,本次請求的響應體是 HTML 頁面資料。
HTTP 響應狀態碼是響應報文中對 HTTP 請求處理結果的重要標識,響應狀態碼是由 RFC 2616 規範定義的,並由網際網路號碼分配局(Internet Assigned Numbers Authority)維護,狀態碼可以分為以下 5 個類別。
-
- 1××(訊息):表示服務端已經接收到請求,正在進行處理;
- 2××(處理成功):表示服務端已經正確處理完客戶端的 HTTP 請求;
- 3××(重定向):服務端接收到 HTTP 請求,並將其 HTTP 請求重定向到客戶本地或其他伺服器進行處理;
- 4××(客戶端請求有誤):客戶端提交的請求不符合規範或未被授權、禁止訪問等;
- 5××(服務端處理出錯):服務端無法正常完成請求操作,如超時等。
常見的響應頭屬性如下表所示。
屬性名稱 |
屬性值樣例 |
屬性說明 |
Content-Type |
text/html; charset=utf-8 |
告知客戶端返回資料的型別 |
Connection |
keep-alive |
告知客戶端是否啟用保持連線機制 |
Cache-Control |
no-cache |
告知客戶端對快取機制的控制 |
ETag |
"50b1c 1d4f775c61:df3" |
當前響應資料的實體標籤值,用於在客戶端與服務端提交相同請求時判斷請求內容是否有修改 |
Location |
https://map.baidu.com/ |
告知客戶端跳轉到指定的 URI |
Set-Cookie |
username=john.wang |
通知客戶端修改本地 cookie 內容 |
當 Nginx 接收 HTTP 請求後,處理相關的配置指令如下表所示。
指令 |
作用域 |
預設值 |
指令值選項 |
指令說明 |
ignore_invalid_headers |
http, server |
on |
on 或 off |
忽略請求頭中的無效屬性欄位,請求頭屬性欄位中,屬性名稱預設由英文字元、數字和連線符組成,不符合此標準的屬性名均為無效屬性名。當指令值為on時,不對無效的屬性名稱進行過濾 |
underscores_in_headers |
http, server |
off |
on 或 off |
請求頭中屬性名稱的定義中“_”是無效連線符,啟用該指令後,“_”將被認為是有效的連線符。如果該指令值為 off,則按照 ignore_invalid_headers 指令的配置進行處理 |
client_header_buffer_size |
http, server |
1k |
-- |
設定存放讀取客戶端請求頭的緩衝區的大小,預設值為1K,當請求頭的資料因cookie過長等其他原因超過所設定的大小時,會按照large-client header buffers的指令配置進行處理 |
large_client_header_buffers |
http, server |
48k |
-- |
當客戶請求頭的大小超過 client_header_buffer_size 指令設定的值時,會將超出的部分轉移到該緩衝區中。在預設配置下,超大請求頭第一次可分配到一個 8KB 的緩衝區塊,請求行的大小不能超過該緩衝區塊的大小,否則將返回 414 錯誤。超出 8KB 的請求頭會被迴圈轉移到新的緩衝區塊中,最多轉移 4 次,當超過該值時,則會返回 400 錯誤 |
client_header_timeout |
http, server |
60s |
-- |
讀取客戶端請求頭的最大超時時間 |
request_pool_size |
http, server |
4k |
-- |
Nginx 開始處理請求時,會為每個請求分配一個 4KB 大小的記憶體池,以減少核心對小塊記憶體的分配次數,HTTP 請求結束後會回收為其分配的記憶體池 |
client_max_body_size |
http, server, Location |
1m |
-- |
HTTP 請求時,請求體的最大值。當請求頭中屬性 Content-Length 的大小超過指令配置時,返回狀態碼 408 |
client_body_buffer_size |
http, server, location |
-- |
-- |
設定讀取客戶請求體的緩衝區大小,當請求體的大小超過該設定值後,會按照 client_body_in_single_buffer 指令的配置選擇部分或全部寫入 client_body_temp_path 指令設定的檔案中。預設配置下,32 位系統下緩衝區的大小是 8KB,64 位系統下緩衝區的大小是 16KB |
client_body_in_file_only |
http, server, location |
off |
off 或 clean 或 on |
預設情況下是優先使用快取,在請求體超出請求體緩衝區的大小時再寫入檔案。啟用該指令後將禁用緩衝區,請求體會被直接寫入 client_body_temp_path 指令設定的檔案中 |
client_body_temp_path |
http, server, location |
client_body_temp_path_client_body_temp |
-- |
請求體被寫入檔案的臨時目錄 |
client_body_timeout |
http, server, location |
60s |
-- |
當 HTTP 請求建立連線後,客戶端在超過設定時間後仍未傳送請求體內容到服務端,則 Nginx 認為請求體超時,將返回響應狀態碼 408 |
if_modified_since |
http, server, location |
exact |
off 或 exact 或 before |
在請求頭中存在屬性if modified since時,關閉或設定客戶端快取檔案修改時間的服務端校驗功能 |
etag |
http, server, location |
on |
on 或 off |
etag(Entity Tag),用於在響應頭中返回檔案實體標籤,與同一檔案的下一次請求頭中 If-None-Match 屬性值組合檢查檔案是否被修改,未修改則返回響應狀態碼 304,否則返回最新的檔案內容 |
max_ranges |
http, server, location |
-- |
-- |
預設為不限制大小,當客戶端以 byte-range 方式獲取資料請求時,該指令限定了允許的最大值。當指令值為 0 時,則關閉以 byte-range 方式獲取資料的功能 |
types |
http, server, location |
-- |
-- |
被請求副檔名與 MIME 型別對映表 |
types_hash_max_size |
http, server, location |
1024 |
-- |
設定 MIME 型別雜湊表的大小 |
types_hash_bucket_size |
http, server, location |
-- |
-- |
設定 MIME 型別雜湊桶的大小,預設值與 CPU 快取行的大小一致,有 32、64、128(單位:位元組)3 個值 |
error_page |
http, server, location |
-- |
-- |
當 HTTP 請求發生錯誤時,可以根據響應狀態碼定義一個返回的頁面或執行跳轉 |
recursive_error_pages |
http, server, location |
off |
off 或 on |
當使用 error_pages 設定多層內部訪問時,仍可處理上一層級返回的響應狀態碼 |
server_tokens |
http, server, location |
on |
on 或 off |
預設在錯誤資訊響應頭中增加屬性欄位“Server”以標識 Nginx 的版本號 |
msie_padding |
http, server, location |
on |
on 或 off |
在響應狀態大於或等於 400 時,會在響應報文中添加註釋,使響應報文大小達到 512 位元組。僅適用於 msie 客戶端 |
配置樣例如下:
http { ignore_invalid_headers off; underscores_in_headers on; client_header_buffer_size 2k; large_client_header_buffers 10 8k; client_header_timeout 180s; request_pool_size 4k; client_max_body_size 100m; client_body_in_file_only on; client_body_temp_path /tmp/nginx/client_temp 1 2; client_body_timeout 120s; if_modified_since before; etag off; max_ranges 1024 ; types_hash_max_size 2048; types_hash_bucket_size 64; error_page 404 /404.html; error_page 500 502 503 504 /50x.html; error_page 404 = @fallback; location @fallback { proxy_pass http://backend; } error_page 404 =200 /empty.gif; location /download/ { types { application/octet-stream yaml; } default_type application/octet-stream; } proxy_intercept_errors on; # 當上遊伺服器返回非200狀態碼時,返回代理伺服器處理 recursive_error_pages on; # 啟用多級錯誤跳轉功能 location / { error_page 404 = @fallback; # 當前URL請求為404時執行內部請求@fallback } location @fallback { proxy_pass http://backend; # 當前所有請求代理到上游伺服器backend error_page 502 = @upfallback; # 當上遊伺服器返回502狀態碼時,執行內部請求@upfallback } location @upfallback { proxy_pass http://newbackend; # 當前的所有請求代理到上游伺服器newbackend } server_tokens off; msie_padding off; }
6.Nginx localhost路由匹配規則
URI 即統一標識資源符,通用的 URI 語法格式如下:
scheme:[//[user[:password]@]host[:port]][/path][?query][#fragment]
格式說明如下:
-
- 在 Nginx 的應用場景中,URL 與 URI 並無明確區別。URI 標準(RFC3986)中約定,URL 是 URI 的一個子集;
- scheme 是 URI 請求時遵守的協議,常見的有 HTTP、HTTPS、FTP;
- host[:port] 是主機名與埠號,HTTP 協議的預設埠是 80,HTTPS 協議的預設埠是 443;
- [/path] 是訪問路徑與訪問檔名;
- [?query] 是訪問引數,訪問引數以“?”開始作標識,由多個以“&”連線的 key=value 形式的字串組成。
1.URI 匹配規則
location 是 Nginx 對 HTTP 請求中的 URI 進行匹配處理的指令,location 的語法形式如下:
location [=|~|~*|^~|@] pattern { ... }
其中,[=|~*|^~|@]
部分稱為 location 修飾語(Modifier),修飾語定義了與 URI 的匹配方式。pattern 為匹配項,可以是字串或正則表示式。
無修飾語:完全匹配 URI 中除訪問引數以外的內容,匹配項的內容只能是字串,不能是正則表示式。
location /images { root /data/web; }
修飾語“=”:完全匹配 URI 中除訪問引數以外的內容,Linux 系統下會區分大小寫,Windows 系統下則不會。
location = /images { root /data/web; }
修飾語“~”:完全匹配 URI 中除訪問引數以外的內容,Linux 系統下會區分大小寫,Windows 系統下則會無效。匹配項的內容必須是正則表示式。
location ~ /images/.*\.(gif|jpg|png)$ { root /data/web; }
修飾語“~*”:完全匹配 URI 中除訪問引數以外的內容,不區分大小寫。匹配項的內容必須是正則表示式。
location ~* \.(gif|jpg|png)$ { root /data/web; }
修飾語“^~”:完全匹配 URI 中除訪問引數以外的內容,匹配項的內容如果不是正則表示式,則不再進行正則表示式測試。
location ^~ /images { root /data/web; }
修飾語“@”:定義一個只能內部訪問的 location 區域,可以被其他內部跳轉指令使用,如 try_files 或 error_page。
location @images { proxy_pass http://images; }
2.匹配順序
1) 先檢測匹配項的內容為非正則表示式修飾語的 location,然後再檢測匹配項的內容為正則表示式修飾語的 location。
2) 匹配項的內容為正則與非正則都匹配的 location,按照匹配項的內容為正則匹配的 location 執行。
3) 所有匹配項的內容均為非正則表示式的 location,按照匹配項的內容完全匹配的內容長短進行匹配,即匹配內容多的 location 被執行。
4) 所有匹配項的內容均為正則表示式的 location,按照書寫的先後順序進行匹配,匹配後就執行,不再做後續檢測。
3.其他事項
當 location 為正則匹配且內部有 proxy_pass 指令時,proxy_pass 的指令值中不能包含無變數的字串。修飾語“^~”不受該規則限制。
location ~ /images { proxy_pass http://127.0.0.1:8080; # 正確的指令值 proxy_pass http://127.0.0.1:8080$request_uri; # 正確的指令值 proxy_pass http://127.0.0.1:8080/image$request_uri; # 正確的指令值 proxy_pass http://127.0.0.1:8080/; # 錯誤的指令值 }
4.訪問路由指令
訪問路由指令如下面表格所示。
表:合併空斜線指令 |
|
名稱 |
合併空斜線指令 |
指令 |
merge_slashes |
作用域 |
http, server, location |
預設值 |
on |
指令值選項 |
off 或 on |
指令說明 |
當指令值為 on,在訪問路徑中相鄰斜線內容為空時進行合併 |
配置樣例如下:
http {
merge_slashes off;
}
表:跳轉主機名指令 |
|
名稱 |
跳轉主機名指令 |
指令 |
server_name_in_redirect |
作用域 |
http, server, location |
預設值 |
off |
指令說明 |
預設情況下,Nginx 重定向時,會用當前 server 指令域中主機的 IP 與 path 拼接成完整的 URL 進行重定向。開啟該引數後,Nginx 會先檢視當前指令域中 server_name 的第一個主機名,如果沒有,則會查詢請求頭中 host 欄位的內容,如果再沒有則會用 IP 與 path 進行拼接 |
配置樣例如下:
http {
server_name_in_redirect on;
}
表:跳轉埠指令 |
|
名稱 |
跳轉埠指令 |
指令 |
port_in_redirect |
作用域 |
http, server, location |
預設值 |
on |
指令說明 |
Nginx 重定向時,會用當前 server 指令域的監聽埠與主機拼接成完整的URL進行重定向。當指令值為 off 時,則預設用 80 埠 |
配置樣例如下:
http {
port_in_redirect on;
}
表:子請求輸出緩衝區大小指令 |
|
名稱 |
子請求輸出緩衝區大小指令 |
指令 |
subrequest_output_buffer_size |
作用域 |
http, server, location |
預設值 |
4k 或 8k |
指令說明 |
設定用於儲存子請求響應報文的緩衝區大小,預設值與作業系統的記憶體頁大小一致 |
配置樣例如下:
http {
subrequest_output_buffer_size 64K;
}
表:絕對跳轉指令 |
|
名稱 |
絕對跳轉指令 |
指令 |
absolute_redirect |
作用域 |
http, server, location |
預設值 |
on |
指令值選項 |
off 或 on |
指令說明 |
Nginx 發起的重定向使用絕對路徑做跳轉,即用主機名和埠及訪問路徑的方式,如果關閉的話,則跳轉為預設相對當前請求的主機名和埠的訪問路徑 |
配置樣例如下:
http {
absolute_redirect off;
}
表:響應重新整理指令 |
|
名稱 |
響應重新整理指令 |
指令 |
msie_refresh |
作用域 |
http, server, location |
預設值 |
on |
指令值選項 |
on 或 off |
指令說明 |
Nginx 處理頁面跳轉或重新整理的方式通常是以向客戶端返回 3xx 狀態碼來實現。該指令是當客戶端為 msie 時,在返回 HTML 頭部新增“<meta http-equiv=\"Refresh\" content=\"0;\" url=*>” |
配置樣例如下:
http {
msie_refresh off;
}
7.Nginx rewrite重定向配置詳解
訪問重寫 rewrite 是 Nginx HTTP 請求處理過程中的一個重要功能,它是以模組的形式存在於程式碼中的,其功能是對使用者請求的 URI 進行 PCRE 正則重寫,然後返回 30× 重定向跳轉或按條件執行相關配置。
rewrite 模組內建了類似指令碼語言的 set、if、break、return 配置指令,通過這些指令,使用者可以在 HTTP 請求處理過程中對 URI 進行更靈活的操作控制。rewrite 模組提供的指令可以分兩類,一類是標準配置指令,這部分指令只是對指定的操作進行相應的操作控制;另一類是指令碼指令,這部分指令可以在 HTTP 指令域內以類似指令碼程式設計的形式進行編寫。
1.標準配置指令
常用的標準配置指令如下面表格所示。
表:rewrite 日誌記錄指令 |
|
名稱 |
rewrite 日誌記錄指令 |
指令 |
rewrite_log |
作用域 |
http, server, location |
預設值 |
off |
指令值選項 |
on 或 off |
指令說明 |
當指令值為 on 時,rewrite 的執行結果會以 notice 級別記錄到 Nginx 的 error 日誌檔案中 |
配置樣例如下:
http {
rewrite_log off;
}
表:未初始化變數告警日誌記錄指令 |
|
名稱 |
未初始化變數告警日誌記錄指令 |
指令 |
uninitialized_variable_warn |
作用域 |
http, server, location |
預設值 |
on |
指令值選項 |
on 或 off |
指令說明 |
指令值為 on 時,會將未初始化的變數告警記錄到日誌中 |
配置樣例如下:
http {
uninitialized_variable_warn off;
}
表:rewrite 指令 |
|
名稱 |
rewrite 指令 |
指令 |
rewrite |
作用域 |
server, location |
預設值 |
on |
指令值選項 |
on 或 off |
指令說明 |
對使用者的 URI 用正則表示式的方式進行重寫,並跳轉到新的 URI |
配置樣例如下:
http { rewrite ^/users/(.*)$ /show?user=$1 last; }
rewrite 訪問重寫是通過 rewrite 指令實現的,rewrite 指令的語法格式如下:
rewrite regex replacement [flag];
1) regex 是 PCRE 語法格式的正則表示式。
2) replacement 是重寫 URI 的改寫規則。當改寫規則以“http://”“https://”或“$scheme”開頭時,Nginx 重寫該語句後將停止執行後續任務,並將改寫後的 URI 跳轉返回客戶端。
3) flag 是執行該條重寫指令後的操作控制符。操作控制符有如下 4 種:
-
- last:執行完當前重寫規則跳轉到新的 URI 後繼續執行後續操作;
- break:執行完當前重寫規則跳轉到新的 URI 後不再執行後續操作。不影響使用者瀏覽器 URI 顯示;
- redirect:返回響應狀態碼 302 的臨時重定向,返回內容是重定向 URI 的內容,但瀏覽器網址仍為請求時的 URI;
- permanent:返回響應狀態碼 301 的永久重定向,返回內容是重定向 URI 的內容,瀏覽器網址變為重定向的 URI。
2.指令碼指令
常見的指令碼指令如下面表格所示。
表:設定變數指令 |
|
名稱 |
設定變數指令 |
指令 |
set |
作用域 |
server, location, if |
指令說明 |
set 指令,可以用來定義變數 |
配置樣例如下:
http { server{ set $test "check"; } } http{ server { listen 8080; location /foo { set $a hello; rewrite ^ /bar; } location /bar { # 如果這個請求來自“/foo”,$a的值是“hello”。如果直接訪問“/bar”,$a的值為空 echo “a = [$a]”; } } }
用 set 指令建立變數後,變數名是 Nginx 配置全域性域可用的,但變數值只在有該變數賦值操作的 HTTP 處理流程中可用。
http{ server { listen 8080; location /foo { set $a hello; rewrite ^ /bar; } location /bar { # 如果這個請求來自“/foo”,$a的值是“hello”。如果直接訪問“/bar”,$a的值為空 if ( $a = “hello” ){ rewrite ^ /newbar; } } } }
當 set 指令後只有變數名時,系統會自動建立該變數,變數值為空。
http {
server{
set $test;
}
}
變數插值如下:
http { server{ set $test "check "; if ( "${test}nginx" = "nginx" ){ #${test}nginx的值為"check nginx" } } }
表:條件判斷指令 |
|
名稱 |
條件判斷指令 |
指令 |
if |
作用域 |
server, location |
指令說明 |
條件判斷指令 |
配置樣例如下:
http { server { if ($http_cookie ~* "id=([^;]+)(?:;|$)") { set $id $1; } } }
1) 當判斷條件為一個變數時,變數值為空或以 0 開頭的字串都被判斷為 false。
2) 變數內容字串比較操作運算子為“=”或“!=”。
3) 進行正則表示式比較時,有以下 4 個操作運算子:
-
- “~”:區分大小寫匹配;
- “~*”:不區分大小寫匹配;
- “!~”:區分大小寫不匹配;
- “!~*”:不區分大小寫不匹配。
4) 進行檔案或目錄比較時,有以下 4 個操作運算子:
-
- “-f”:判斷檔案是否存在,可在運算子前加“!”表示反向判斷。
- “-d”:判斷目錄是否存在,可在運算子前加“!”表示反向判斷。
- “-e”:判斷檔案、目錄或連結符號是否存在,可在運算子前加“!”表示反向判斷。
- “-x”:判斷檔案是否為可執行檔案,可在運算子前加“!”表示反向判斷。
表:終止指令 |
|
名稱 |
終止指令 |
指令 |
break |
作用域 |
server, location, if |
指令說明 |
終止後續指令的執行 |
配置樣例如下:
http { server { if ($slow) { limit_rate 10k; break; } } }
表:跳轉指令 |
|
名稱 |
跳轉指令 |
指令 |
return |
作用域 |
server, location, if |
指令說明 |
向客戶端返回響應狀態碼或執行跳轉 |
配置樣例如下:
http { server { if ($request_method = POST) { return 405; } } }
1) return 的指令值有以下 4 種方式。
-
- return code:向客戶端返回指定 code 的狀態碼,當返回非標準的狀態碼 444 時,Nginx 直接關閉連線,不傳送響應頭資訊。
- return code text:向客戶端傳送帶有指定 code 狀態碼和 text 內容的響應資訊。因要在客戶端顯示 text 內容,所以 code 不能是 30×。
- return code URL:這裡的 URL 可以是內部跳轉或變數 $uri,也可以是有完整 scheme 標識的 URL,將直接返回給客戶端執行跳轉,code 只能是 30×。
- return URL:此時預設 code 為 302,URL 必須是有完整 scheme 標識的 URL。
2) return 也可以用來除錯輸出 Nginx 的變數。
8.Nginx訪問控制簡述
HTTP 核心配置指令中提供了基本的禁止訪問、傳輸限速、內部訪問控制等功能配置。配置指令如下表所示。
表:請求方法排除限制指令 |
|
名稱 |
請求方法排除限制指令 |
指令 |
limit_except |
作用域 |
http, server, location |
預設值 |
-- |
指令說明 |
對指定方法以外的所有請求方法進行限定 |
配置樣例如下:
http{ limit_except GET { allow 192.168.1.0/24; # 允許192.168.1.0/24範圍的IP使用非GET的方法 deny all; # 禁止其他所有來源IP的非GET請求 } }
表:組合授權控制指令 |
|
名稱 |
組合授權控制指令 |
指令 |
satisfy |
作用域 |
http, server, location |
預設值 |
all |
指令值選項 |
all 或 any |
指令說明 |
預設情況下,在響應客戶端請求時,當 ngx_http_access_module、ngx_http_auth_basic_module、ngx_http_auth_request_module、ngx_http_auth_jwt_module 模組被限定的訪問控制條件都符合時,才允許授權訪問。當指令值為 any 時,ngx_http_access_module、ngx_http_auth_basic_module、ngx_http_auth_request_module、ngx_http_auth_jwt_module 模組的訪問控制條件,符合任意一個,則認為可以授權訪問 |
配置樣例如下:
location / { satisfy any; allow 192.168.1.0/32; deny all; auth_basic "closed site"; auth_basic_user_file conf/htpasswd; }
表:內部訪問指令 |
|
名稱 |
內部訪問指令 |
指令 |
internal |
作用域 |
http, server, location |
預設值 |
-- |
指令說明 |
限定 location 的訪問路徑來源為內部訪問請求,否則返回響應狀態碼 404 |
1) Nginx 限定以下幾種型別為內部訪問。
-
- 由 error_page 指令、index 指令、random_index 指令和 try_files 指令發起的重定向請求;
- 響應頭中由屬性 X-Accel-Redirect 發起的重定向請求,等同於 X-sendfile,常用於下載檔案控制的場景中;
- ngx_http_ssi_module 模組的 include virtual 指令、ngx_http_addition_module 模組、auth_request 和 mirror 指令的子請求;
- 用 rewrite 指令對 URL 進行重寫的請求。
2) 內部請求的最大訪問次數是 10 次,以防錯誤配置引發內部迴圈請求,超過限定次數將返回響應狀態碼 500。
配置樣例如下:
error_page 404 /404.html; location = /404.html { internal; }
表:響應限速指令 |
|
名稱 |
響應限速指令 |
指令 |
limit_rate |
作用域 |
http, server, location |
預設值 |
0 |
指令說明 |
服務端響應請求後,被限定傳輸速率的大小。速率是以位元組/秒為單位指定的,0 值表示禁用速率限制 |
配置樣例如下:
server { location /flv/ { flv; limit_rate_after 500k; # 當傳輸速率到500KB/s時執行限速 limit_rate 50k; # 限速速率為50KB/s } }
響應速率也可以在 proxy_pass 的響應頭屬性 X-Accel-Limit-Rate 欄位中設定;可以通過proxy_ignore_headers、fastcgi_ignore_headers、uwsgi_ignore_headers和 scgi_ignore_headers 指令禁用此項功能;在 Nginx 1.17.0 以後的版本中,引數值可以是變數。
map $slow $rate { 1 4k; 2 8k; } limit_rate $rate;
表:響應最大值後限速指令 |
|
名稱 |
響應最大值後限速指令 |
指令 |
limit_rate_after |
作用域 |
http, server, location |
預設值 |
0 |
指令說明 |
服務端響應請求後,當向客戶端的傳輸速率達到指定值時,按照響應限速指令進行限速 |
配置樣例如下:
location /flv/ {
flv;
limit_rate_after 500k;
limit_rate 50k;
}
9.Nginx root指令:根目錄配置
使用者請求的最終結果是要返回資料,當響應檔案在 Nginx 伺服器本地時,需要進行本地檔案位置、讀或寫、返回執行結果的操作。Nginx 中的 root 指令可以設定請求 URL 的本地檔案根目錄,如下表所示。
名稱 |
根目錄指令 |
指令 |
root |
作用域 |
http, server, location |
預設值 |
on |
指令說明 |
設定請求 URL 的本地檔案根目錄 |
配置樣例如下:
location /flv/ { root /data/web; }
當 root 指令在 location 指令域時,root 設定的是 location 匹配訪問路徑的上一層目錄,樣例中被請求檔案的實際本地路徑為 /data/web/flv/。
location 中的路徑是否帶“/”,對本地路徑的訪問無任何影響。
10.Nginx alias指令:虛擬目錄配置
Nginx 中想要配置虛擬目錄可以使用 alias 指令,該指令的介紹如下表所示:
名 稱 |
訪問路徑別名指令 |
指令 |
alias |
作用域 |
location |
預設值 |
-- |
指令說明 |
預設情況下,本地檔案的路徑是 root 指令設定根目錄的相對路徑,通過 alias 指令可以將匹配的訪問路徑重新指定為新定義的檔案路徑。 |
配置樣例如下:
server{ listen 8080; server_name www.nginxtest.org; root /opt/nginx-web/www; location /flv/ { alias /opt/nginx-web/flv/; } location /js { alias /opt/nginx-web/js; } location /img { alias /opt/nginx-web/img/; } }
可以用如下命令進行訪問測試:
curl http://127.0.0.1:8080/flv/ curl -L http://127.0.0.1:8080/js curl http://127.0.0.1:8080/js/ curl -L http://127.0.0.1:8080/img curl http://127.0.0.1:8080/img/
alias 指定的目錄是 location 路徑的實際目錄,其所在 location 的 rewrite 指令不能使用 break 引數。
11.Nginx配置項try_files簡介
try_files 指令是在 Nginx0.7.27 版本中開始加入的,它可以按順序檢查檔案是否存在,並返回第一個找到的檔案,如果未找到任何檔案,則會呼叫最後一個引數進行內部重定向,如下表所示:
名稱 |
檔案判斷指令 |
指令 |
try_files |
作用域 |
server、location |
預設值 |
-- |
指令說明 |
用於順序檢查指定檔案是否存在,如果不存在,則按照最後一個指定 URI 做內部跳轉 |
配置樣例如下:
location /images/ { # $uri存在則執行代理的上游伺服器操作,否則跳轉到default.gif的location try_files $uri /images/default.gif; } location = /images/default.gif { expires 30s; }
跳轉的目標也可以是一個location區域,指令碼如下:
http{ location / { try_files /system/maintenance.html $uri $uri/index.html $uri.html @mongrel; } location @mongrel { proxy_pass http://mongrel; } }
12.Nginx配置項sendfile:零拷貝
Nginx 中的 sendfile 配置項用來在兩個檔案描述符之間直接傳遞資料(完全在核心中操作),從而避免了資料在核心緩衝區和使用者緩衝區之間的拷貝,操作效率很高,被稱之為零拷貝,如下表所示:
名稱 |
零複製指令 |
指令 |
sendfile |
作用域 |
http、server、location |
預設值 |
off |
指令值選項 |
on 或 off |
指令說明 |
啟用零複製(sendfile)。零複製(也稱零拷貝)是讀取本地檔案後向網路介面傳送檔案內容的檔案傳輸機制 |
配置樣例如下:
http {
sendfile on;
}
預設配置下,Nginx 讀取本地檔案後,在進行網路傳輸時會先將硬碟檔案從硬碟中讀取到 Nginx 的檔案緩衝區中,操作流程為硬碟 → 核心檔案緩衝區 → 應用緩衝區。然後將 Nginx 檔案緩衝區的資料寫入網路介面,操作流程:應用緩衝區 → 核心網路緩衝區 → 網路介面。
Nginx 的本地檔案在進行網路傳輸的過程中,經歷了上述兩個操作過程,兩次操作都在核心緩衝區中儲存了相同的資料。為了提高檔案的傳輸效率,核心提供了零複製技術,該技術支援檔案在核心緩衝區內直接交換開啟的檔案控制代碼,無須重複複製檔案內容到緩衝區,則上述兩個操作的流程變為:硬碟 → 核心檔案緩衝區 → 核心網路緩衝區 → 網路介面。
零複製技術減少了檔案的讀寫次數,提升了本地檔案的網路傳輸速度。核心緩衝區的預設大小為 4096B。
13.Nginx日誌記錄配置:log_not_found、log_subrequest
Nginx 中的日誌記錄指令如下面表格所示。
表:不存在檔案日誌指令 |
|
名稱 |
不存在檔案日誌指令 |
指令 |
log_not_found |
作用域 |
http、server、location |
預設值 |
on |
指令值選項 |
on 或 off |
指令說明 |
用於設定如果檔案不存在錯誤是否寫入日誌 |
配置樣例如下:
http {
log_not_found on;
}
表:子請求訪問日誌指令 |
|
名稱 |
子請求訪問日誌指令 |
指令 |
log_subrequest |
作用域 |
http、server、location |
預設值 |
on |
指令值選項 |
on 或 off |
指令說明 |
用於設定子請求的訪問記錄是否寫入日誌 |
配置樣例如下:
http {
log_subrequest on;
}
作者:小家電維修
相見有時,後會無期。