NGINX 模組化架構允許開發者依需求調整組態，提升網站效能、安全性和穩定性。本文除了 URL 重寫規則的建立與說明外，也涵蓋了核心模組的組態，例如設定索引頁面、日誌格式、存取控制、連線和請求速率限制，以及驗證和授權機制。透過理解這些模組的運作機制和組態方式，可以根據網站的流量、安全需求和特定需求，選擇合適的模組並進行精細化組態，例如針對 API 端點設定連線限制和請求速率限制，或利用授權模組實作更精細的存取控制策略。此外，NGINX 也提供了豐富的指令來操作 HTTP 頭部，例如設定快取過期時間、新增自訂頭部等，可以進一步提升網站效能和使用者經驗。
NGINX 模組組態與應用實務
NGINX 作為一款廣泛使用的 Web 伺服器和反向代理伺服器，其模組化架構允許開發者根據實際需求靈活組態和擴充功能。本文除了 URL 重寫的應用外，更進一步探討了 NGINX 的核心模組，包含索引設定、日誌記錄、存取控制、連線限制、請求速率控制、驗證授權以及內容與編碼處理等方面。理解這些模組的運作機制以及如何正確組態，對於提升網站的效能、安全性和穩定性至關重要。在實際應用中，我們可以根據網站的流量、安全需求以及其他特定需求，選擇合適的模組並進行精細化組態，例如針對 API 端點設定連線限制和請求速率限制，或是利用授權模組實作更精細的存取控制策略。此外，NGINX 也提供了豐富的指令來操作 HTTP 頭部，例如設定快取過期時間、新增自訂頭部等，這些都可以進一步提升網站的效能和使用者經驗。
NGINX 模組組態探索
NGINX 是一個功能強大且靈活的 Web 伺服器，其模組系統使其能夠根據需求進行擴充和自定義。本文將探討 NGINX 的一些重要模組，並深入分析其組態和應用。
新聞網站 URL 重寫
新聞網站常使用包含文章內容提示的 URL 結構。這種結構通常由文章識別碼、斜槓以及關鍵字列表組成。關鍵字通常可以忽略，重寫後的 URI 只需要包含文章識別碼即可。
- 重寫規則：
rewrite ^/([0-9]+)/.*$ /article.php?id=$1;
location /news {
rewrite ^/([0-9]+)/.*$ /article.php?id=$1 last;
}
內容解密：
這條重寫規則使用正規表示式匹配 URL 中的數字部分，並將其捕捉為 $1。然後將 URL 重寫為 /article.php?id=$1，其中 $1 是捕捉的數字。這樣可以將友好的 URL 結構轉換為伺服器能夠處理的內部請求。
討論區 URL 重寫
現代討論區也採用友好型 URL。這裡展示如何建立一個包含主題識別碼和起始帖子的主題檢視 URL。與新聞網站類別似，關鍵字可以忽略。
- 重寫規則：
rewrite ^/topic-([0-9]+)-([0-9]+)-(.*)\.html$ /viewtopic.php?topic=$1&start=$2;
location /forum {
rewrite ^/topic-([0-9]+)-([0-9]+)-(.*)\.html$ /viewtopic.php?topic=$1&start=$2 last;
}
內容解密：
這條規則匹配以 /topic- 開頭，後面跟著數字、另一個數字和任意字元，並以 .html 結尾的 URL。它將這些捕捉的數字分別指定給 $1 和 $2，然後重寫 URL 為 /viewtopic.php?topic=$1&start=$2，實作了友好 URL 到實際處理指令碼的對映。
NGINX 模組概述
NGINX 的 Rewrite 模組是其最重要的模組之一，但還有許多其他模組可以大幅增強伺服器的功能。這些模組按主題分類別，以下是一些關鍵模組的詳細介紹。
網站存取與記錄
這些模組允許組態訪客如何存取您的網站以及伺服器如何記錄請求。
Index 模組
Index 模組提供了一個簡單的指令 index，用於定義當客戶端請求中沒有指設定檔案名稱時，NGINX 將提供的預設頁面。您可以指定多個檔案名稱；找到的第一個檔案將被提供。
http {
server {
listen 80;
server_name example.com;
index index.php index.html index.htm;
}
}
內容解密：
index 指令定義了當請求的 URI 以 / 結尾時，NGINX 將傳回的預設檔案。這裡指定了多個檔案名稱，NGINX 將按照順序尋找並傳回第一個找到的檔案。
Autoindex 模組
如果 NGINX 無法為請求的目錄提供索引頁面，預設行為是傳回一個 403 Forbidden HTTP 錯誤頁面。使用以下指令可以啟用自動目錄列表：
location /downloads {
autoindex on;
autoindex_exact_size off;
autoindex_localtime on;
}
內容解密：
autoindex on 啟用了自動目錄列表功能。當請求的目錄沒有索引檔案時，NGINX 將生成一個目錄列表。autoindex_exact_size off 使檔案大小以可讀的單位（如 KB、MB）顯示，而不是精確的位元組數。autoindex_localtime on 使檔案修改時間以伺服器的本地時間顯示。
Log 模組
Log 模組控制 NGINX 的存取日誌行為。它包括三個主要指令：access_log、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 /var/log/nginx/access.log main;
}
內容解密：
log_format 指令定義了日誌的格式，命名為 main。access_log 指令指定了日誌檔案的路徑，並使用 main 格式記錄日誌。這樣組態後，NGINX 將按照 main 格式將存取日誌寫入 /var/log/nginx/access.log。
日誌模組組態
日誌模組是 NGINX 中一個關鍵部分，負責記錄伺服器執行時的各種事件和狀態。以下是一些重要的日誌模組指令：
open_log_file_cache：這個指令用於組態日誌檔案描述符的快取。
http {
open_log_file_cache max=1000 inactive=20m valid=1h;
}
內容解密：
open_log_file_cache 指令主要用於提高日誌檔案讀寫效率。它透過快取日誌檔案描述符來減少系統呼叫次數，從而提升效能。引數 max 表示最多快取的日誌檔案描述符數量，inactive 表示快取專案在多長時間內未被使用後會被移除，valid 表示檢查快取專案是否仍然有效的時間間隔。
基本驗證模組
基本驗證模組（auth_basic module）允許我們對特定位置或伺服器進行基本驗證，要求使用者輸入使用者名稱和密碼才能存取。
location /admin {
auth_basic "Admin Area";
auth_basic_user_file /etc/nginx/.htpasswd;
}
內容解密：
auth_basic 指令定義了驗證提示資訊（挑戰資訊）。當使用者嘗試存取受保護的資源時，瀏覽器會彈出一個使用者名稱/密碼框。auth_basic_user_file 指令則定義了包含使用者名稱和密碼的檔案路徑。這個檔案中的每一行都包含了一個使用者名稱和對應的密碼雜湊值。
存取控制模組
NGINX 提供了 allow 和 deny 指令來控制特定 IP 地址或 IP 地址範圍對資源的存取許可權。
location /private {
allow 192.168.1.0/24;
deny all;
}
內容解密：
這些指令根據順序處理規則。如果第一條規則是 deny all，那麼後面所有的 allow 指令都將失效；反之亦然。因此，順序非常重要，需要根據實際需求進行合理組態。
連線限制模組
連線限制模組（limit_conn module）允許我們控制特定區域的最大同時連線數量。這對於防止 DoS 攻擊非常有幫助。
http {
limit_conn_zone $binary_remote_addr zone=addr:10m;
server {
location /download {
limit_conn addr 10;
}
}
}
內容解密：
首先，使用 limit_conn_zone 指令定義了一個區域（zone），並指定了區網域名稱和最大大小。然後，在所需的 location 塊中使用 limit_conn 指令來限制該區域內的同時連線數量。
NGINX 組態模組探討
NGINX 是一款高效能的 Web 伺服器，其強大的模組化設計使其能夠靈活應對各種需求。本文將探討 NGINX 中幾個關鍵的組態模組，包括限制連線、限制請求、授權請求以及內容與編碼相關的模組。這些模組在實際應用中能夠顯著提升伺服器的效能和安全性。
限制連線
在高流量的網站中，控制同時連線數量是確保系統穩定執行的重要手段。NGINX 提供了 limit_conn 模組，讓我們可以根據不同的條件來限制客戶端的連線數量。
實作方法
首先，我們需要定義一個限制區域：
http {
limit_conn_zone $binary_remote_addr zone=conn_limit:10m;
}
接下來，在需要限制連線的位置中使用 limit_conn 指令：
location / {
limit_conn conn_limit 10;
}
內容解密：
這樣設定後，同一個 IP 地址最多隻能同時建立10 個連線。如果超過這個限制，NGINX 會回應一個 503 Service Unavailable 的錯誤碼。
應用案例
假設我們有一個需要限制連線數量的 API 端點：
location /api/v1 {
limit_conn conn_limit 5;
limit_conn_status 429; # 自訂錯誤碼
}
內容解密：
這樣設定後，如果某個客戶端同時發起超過5 個連線，則會收到自訂的 429 Too Many Requests 錯誤碼。
限制請求
除了限制連線數量，NGINX 還可以限制請求速率，這對於防止 DDoS 攻擊特別有效。limit_req 模組可以根據定義的區域來控制請求速率。
實作方法
首先，定義一個請求區域：
http {
limit_req_zone $binary_remote_addr zone=req_limit:10m rate=1r/s;
}
然後在需要限制請求的位置中使用 limit_req 指令：
location / {
limit_req zone=req_limit burst=5 nodelay;
}
內容解密：
這樣設定後，每秒鐘最多允許一個請求，但允許瞬間爆發5 個請求。超過這個爆發值後，NGINX 會延遲回應，以保持整體速率。
應用案例
假設我們有一個需要控制請求速率的登入 API：
location /login {
limit_req zone=req_limit burst=3 nodelay;
limit_req_status 429; # 自訂錯誤碼
}
內容解密：
這樣設定後，如果某個客戶端在短時間內發起過多登入請求，則會收到 429 Too Many Requests 錯誤碼。
授權請求
auth_request 模組允許我們根據子請求的結果來控制資源的存取許可權。這對於需要動態授權的情境非常有用。
實作方法
首先，在需要授權的位置中使用 auth_request 指令：
location /downloads {
auth_request /auth;
error_page 401 = @error401;
}
location /auth {
proxy_pass http://auth_server;
proxy_pass_request_body off;
proxy_set_header Content-Length 0;
proxy_set_header X-Original-URI $request_uri;
}
內容解密：
當客戶端發起對 /downloads/ 的請求時，NGINX 會先傳送一個子請求到 /auth。如果子請求傳回 2xx 狀態碼，則允許存取；否則傳回相應的錯誤碼。
內容與編碼
NGINX 提供了一系列模組來處理內容和編碼問題。例如 empty_gif 模組可以直接從記憶體中提供一張空白 GIF 檔案；而 mp4 模組則允許處理 MP4 媒體檔案中的偏移量引數。
Real-world Example: MP4 媒體檔案處理
假設我們有一個需要提供影片串流服務的網站：
location ~* \.mp4 {
mp4;
mp4_buffer_size 1M;
mp4_max_buffer_size 5M;
}
內容解密：
這樣設定後，當客戶端發起對 MP4 檔案的請求時（例如：video.mp4?start=XXX），NGINX 會解析並處理偏移量引數。如果無法尋找指定位置，則傳回 500 Internal Server Error 錯誤碼。mp4_buffer_size 和 mp4_max_buffer_size 指令用於控制處理 MP4 檔案時的緩衝區大小。
HTTP 頭部
HTTP 頭部是 Web 回應中的重要部分，NGINX 提供了多種指令來操作頭部資訊。
新增頭部
使用 add_header 指令可以新增自訂頭部：
location / {
add_header X-Custom-Header "CustomValue";
add_header X-Another-Header "AnotherValue" always;
}
內容解密：
這樣設定後，所有符合條件的回應都會包含自訂頭部 X-Custom-Header: CustomValue。使用 always 引數可以確保即使在錯誤回應中也包含該頭部。
控制過期時間
使用 expires 指令可以控制資源的過期時間：
location /static {
expires 7d;
add_header Cache-Control "public";
}
內容解密：
這樣設定後，所有靜態資源都會被標記為有效期為7 天，並且透過 Cache-Control 頭部指示快取為公開快取。
flowchart TD
A[開始] --> B[處理請求]
B --> C{檢查快取}
C -->|有快取| D[傳回快取內容]
C -->|無快取| E[查詢資料函式庫]
E --> F[生成回應]
F --> G[傳回回應]
圖表翻譯：
這個流程圖展示了 NGINX 處理請求的基本流程。首先檢查是否有快取，如果有則直接傳回快取內容；如果沒有，則查詢資料函式庫並生成回應，最後傳回給客戶端。
本文深入探討了 NGINX 各項核心模組的組態與應用，涵蓋 URL 重寫、索引設定、日誌記錄、存取控制、連線與請求速率限制、驗證授權以及內容編碼處理等關鍵導向。其價值在於賦予開發者精細化控制的能力，得以根據不同業務場景調校伺服器效能，提升網站安全性和穩定性。例如，針對 API 端點的連線和請求速率限制可有效抵禦 DoS 攻擊；而透過授權模組和 HTTP 頭部操作，則能實作更精細的存取控制和快取策略，進一步最佳化使用者經驗。隨著 Web 技術的持續演進， NGINX 的模組化設計將持續展現其強大的適應性和擴充性，在構建高效能 Web 服務的過程中扮演更重要的角色。建議開發者深入理解 NGINX 模組的運作機制，並結合最佳實務，才能最大程度發揮其效能優勢。
