NGINX 模組系統是其效能和安全性的根本,正確的模組組態能顯著提升網站的運作效率。檔案過期模組可控制瀏覽器快取行為,設定 epoch 指令使檔案立即過期,而 max 指令則設定最長過期時間,確保網頁內容的更新頻率符合需求。內容增加模組可在 HTTP 回應的前後插入內容,例如頁首、頁尾或廣告,但需額外編譯才能使用。替換內容模組則可動態修改回應內容,例如隱藏敏感資訊或替換廣告程式碼,提升網站安全性。Gzip 壓縮模組能有效減少資料傳輸量,gzip_static 模組則允許直接提供預先壓縮好的檔案,進一步提升網頁載入速度。設定壓縮等級、緩衝區大小等引數,可針對不同需求微調效能。除了這些核心模組外,NGINX 也提供其他實用模組,例如 Gunzip 模組可解壓縮後端伺服器傳來的 Gzip 壓縮回應,Charset 模組能精確控制回應的字元集,避免編碼問題。Memcached 模組可整合 Memcached 快取系統,降低伺服器負載,Image Filter 模組則提供影像處理功能,方便直接在伺服器端調整圖片。

NGINX 模組組態深度探討

NGINX 作為一個強大的網頁伺服器和反向代理伺服器,其靈活性和功能性來自於其豐富的模組系統。這些模組可以顯著提升伺服器的效能和安全性。以下,玄貓將探討一些常見且實用的 NGINX 模組,並提供詳細的組態。

檔案過期模組

NGINX 的檔案過期模組允許使用者設定檔案的過期時間,從而控制快取行為。這個模組有兩個主要的指令:

  • epoch:檔案的過期時間設定為 1970 年 1 月 1 日,並且 Cache-Control 標頭設定為 no-cache。
  • max:檔案的過期時間設定為 2037 年 12 月 31 日,Cache-Control 標頭設定為 10 年。

這些設定可以幫助使用者根據需要控制快取行為,確保資料的新鮮度或永續性。

增加內容模組

增加內容模組(Addition Module)允許使用者透過簡單的指令在 HTTP 回應的主體前後增加內容。這個模組通常用於新增通用的頁尾、標頭或廣告等。需要注意的是,這個模組並不包含在預設的 NGINX 架構中,因此需要額外編譯。

主要指令包括:

  • add_before_body file_uri;:在回應主體前增加內容。
  • add_after_body file_uri;:在回應主體後增加內容。

NGINX 會觸發子請求以取得指定的 URI。此外,還可以使用 addition_types 指令來定義要增加內容的檔案型別,預設情況下僅適用於 text/html。

addition_types text/html application/json;

內容解密:

  • add_before_body file_uri;:這個指令允許在 HTTP 回應主體之前插入特定的檔案內容。例如,可以插入一段 JavaScript 或 CSS。
  • add_after_body file_uri;:這個指令允許在 HTTP 回應主體之後插入特定的檔案內容。例如,可以插入頁尾資訊或分析碼。
  • addition_types mime_type1 [mime_type2…];:這個指令允許指定哪些 MIME 型別的檔案將受到此模組的影響。預設僅適用於 text/html。

替換內容模組

替換內容模組(Substitution Module)允許使用者直接在 HTTP 回應主體中進行文字搜尋和替換。這對於需要動態修改回應內容的情況非常有用,例如隱藏敏感資訊或替換廣告程式碼。

主要指令包括:

  • sub_filter searched_text replacement_text;:搜尋並替換回應主體中的文字。
  • sub_filter_once on | off;:是否只替換第一次出現的文字,預設值為 on。
  • sub_filter_types mime_type1 [mime_type2...];:指定哪些 MIME 型別的檔案將受到此模組的影響,預設僅適用於 text/html。
sub_filter "old_text" "new_text";
sub_filter_once off;
sub_filter_types text/html application/json;

內容解密:

  • sub_filter searched_text replacement_text;:這個指令允許在 HTTP 回應主體中搜尋特定文字並進行替換。例如,可以將某些敏感詞匯替換成星號。
  • sub_filter_once on | off;:這個指令控制是否只替換第一次出現的文字。如果設定為 on,則只替換第一次出現;如果設定為 off,則替換所有出現。
  • sub_filter_types mime_type1 [mime_type2…];:這個指令允許指定哪些 MIME 型別的檔案將受到此模組的影響。預設僅適用於 text/html。

Gzip 壓縮模組

Gzip 壓縮模組允許壓縮 HTTP 回應主體以減少傳輸資料量,從而提高網站載入速度。這對於提升使用者經驗和降低伺服器負載非常重要。

主要組態指令包括:

  • gzip on | off;:啟用或停用 Gzip 壓縮。
  • gzip_buffers amount size;:定義用於儲存壓縮回應的緩衝區數量和大小。
  • gzip_comp_level level;:設定壓縮級別,範圍從 1(低壓縮)到 9(高壓縮)。
  • gzip_disable regex;:停用特定 User-Agent 的 Gzip 壓縮。
  • gzip_http_version version;:啟用特定 HTTP 版本的 Gzip 壓縮。
  • gzip_min_length length;:只有當回應主體長度超過指定值時才進行壓縮。
  • gzip_proxied option;:控制代理回應是否進行 Gzip 壓縮。
  • gzip_types mime_type1 [mime_type2...];:啟用特定 MIME 型別的 Gzip 壓縮。
  • gzip_vary on | off;:新增 Vary: Accept-Encoding 標頭。
  • gzip_window size;:設定 Gzipping 操作的視窗緩衝區大小。
gzip on;
gzip_buffers 4 4k;
gzip_comp_level 6;
gzip_disable "msie6";
gzip_http_version 1.1;
gzip_min_length 256;
gzip_proxied any;
gzip_types text/plain application/json;
gzip_vary on;

內容解密:

  • gzip on | off;:啟用或停用 Gzip 壓縮功能。
  • gzip_buffers amount size;:定義緩衝區數量和大小,用於儲存壓縮後的資料。例如,4 4k 意味著使用四個大小為 4KB 的緩衝區。
  • gzip_comp_level level;:設定壓縮級別,範圍從 1(低壓縮)到 9(高壓縮)。級別越高壓縮率越高但計算量也越大。
  • gzip_disable regex;:停用特定 User-Agent 的 Gzip 壓縮。例如,msie6 意味著停用 IE6 的 Gzip 壓縮。
  • gzip_http_version version;:啟用特定 HTTP 版本的 Gzip 壓縮。例如,1.1 意味著僅對 HTTP/1.1 的請求進行壓縮。
  • gzip_min_length length;:只有當回應主體長度超過指定值時才進行壓縮。例如,256 意味著只有大於 256位元組的回應才會被壓縮。
  • gzip_proxied option;:控制代理回應是否進行 Gzip 壓縮。例如,any 意味著對所有代理回應進行壓縮。
  • gzip_types mime_type1 [mime_type2…];:啟用特定 MIME 型別的 Gzip 壓縮。例如,text/plain application/json 意味著僅對純文字和 JSON 資料進行壓縮。
  • gzip_vary on | off;:新增 Vary: Accept-Encoding 標頭以通知客戶端支援壓縮。

Gzip Static 模組

Gzip Static 模組是對 Gzipping 機制的一個簡單擴充套件。當啟用了 gzipping_static 指令時,NGINX 在提供檔案之前會尋找相應的 .gz 檔案來提供已經預先壓縮好的檔案而不是即時進行壓縮操作。

主要組態指令包括:

gzip_static on | off | always;

暗示圖示

  graph TD
    A[客戶端請求 /documents/page.html] --> B{檢查 /documents/page.html.gz 是否存在}
    B -- 是 --> C[提供 /documents/page.html.gz]
    B -- 否 --> D[即時壓縮並提供 /documents/page.html]

內容解密:

此圖示展示了 NGINX 在處理客戶端請求時如何選擇提供預先壓縮好的檔案或即時進行壓縮操作。

NGINX 額外模組的探索

Gunzip 模組

Gunzip 模組允許你解壓縮後端伺服器傳來的 Gzip 壓縮回應,以原始形式提供給客戶端。這在某些情況下非常有用,例如當客戶端瀏覽器無法處理 Gzip 檔案時(例如 Microsoft Internet Explorer 6)。你可以在 location 塊中插入 gunzip on; 來啟用這個模組。此外,你還可以使用 gunzip_buffers amount size; 來設定緩衝區的數量和每個緩衝區的大小,其中 amount 是要分配的緩衝區數量,size 是每個緩衝區的大小。

Charset 模組

Charset 模組讓你能夠更精確地控制回應體的字元集。不僅可以指定 Content-Type HTTP 標頭中的 charset 引數值(例如 Content-Type: text/html; charset=utf-8),NGINX 還可以自動重新編碼資料到指定的編碼方法。

指令說明

  • charset:在 http, server, location, if 上下文中新增指定的編碼到回應的 Content-Type 標頭。如果指定的編碼與 source_charset 不同,NGINX 會重新編碼檔案。

    • 語法:charset encoding | off;
    • 預設:off
    • 範例:charset utf-8;
  • source_charset:在 http, server, location, if 上下文中定義回應的初始編碼。如果與 charset 指令中指定的值不同,NGINX 會重新編碼檔案。

    • 語法:source_charset encoding;
  • override_charset:當 NGINX 接收到代理或 FastCGI 閘道器的回應時,這個指令定義是否應檢查並可能覆寫字元編碼。

    • 語法:onoff
    • 預設:off
  • charset_types:在 http, server, location 上下文中定義可重新編碼的 MIME 型別。

    • 語法:charset_types mime_type1 [mime_type2...];
    • 預設:text/html, text/xml, text/plain, text/vnd.wap.wml, application/x-javascript, and application/rss+xml
  • charset_map:在 http 上下文中讓你定義字元重新編碼表。每行表格包含兩個十六進位製程式碼以進行交換。預設的 NGINX 組態資料夾中有一些 koi8-r 字元集的重新編碼表(例如 koi-win 和 koi-utf)。

    • 語法:charset_map src_encoding dest_encoding { ... }

Memcached 模組

Memcached 是一個透過通訊端連線的守護程式應用程式,主要用於提供高效的分散式鍵/值記憶體快取系統。NGINX Memcached 模組提供了指令,讓你能夠組態存取 Memcached 的守護程式。

指令說明

  • memcached_pass:在 location 和 if 上下文中定義 Memcached 的主機名和埠號。

    • 語法:memcached_pass hostname:port;
    • 範例:memcached_pass localhost:11211;
  • memcached_bind:在 http, server 和 location 上下文中強制 NGINX 使用指定的本地 IP 地址來連線 Memcached 伺服器。這對於伺服器有多張網路卡並連線到不同網路時特別有用。

    • 語法:memcached_bind IP_address;
    • 範例:memcached_bind 192.168.1.2;
  • memcached_connect_timeout:在 http, server 和 location 上下文中定義連線超時時間(毫秒)。預設值為 60000 毫秒。

    • 語法:無
    • 預設:60000 毫秒
    • 範例:memcached_connect_timeout 5000;
  • memcached_send_timeout:在 http, server 和 location 上下文中定義寫入資料操作超時時間(毫秒)。預設值為 60000 毫秒。

    • 語法:無
    • 預設:60000 毫秒
    • 範例:memcached_send_timeout 5,000;
  • memcached_read_timeout:在 http, server 和 location 上下文中定義讀取資料操作超時時間(毫秒)。預設值為 60000 毫秒。

    • 語法:無
    • 預設:60000 毫秒
    • 範例:memcached_read_timeout 5,000;
  • memcached_buffer_size:在 http, server 和 location 上下文中定義讀寫緩衝區的大小(位元組)。預設值為頁面大小。

    • 語法:無
    • 預設:頁面大小
    • 範例:memcached_buffer_size 8k;
  • memcached_next_upstream:當 memcached_pass 指令連線到 upstream 塊時,這個指令定義跳轉到下一個 upstream 啟發條件。

    • 語法:
      error timeout,
      invalid_response,
      not_found,
      or off
      
    • 預設:error timeout
    • 範例:
    memcached_next_upstream off;
    
  • memcached_gzip_flag:檢查 Memcached 的回應是否包含指定標誌。如果存在該標誌,NGINX 則會設定 Content-encoding 標頭為 gzip,表示將提供 gzipped 內容。

    Syntax: Numeric flag
    Default: (none)
    Example: memcached_gzip_flag 1;
    

Memcached 組態示例

以下是一個使用 Memcached 組態 NGINX 的示例:

server {
    server_name example.com;
    [...]

    location / {
        set $memcached_key $uri;
        memcached_pass localhost:11211;
        error_page 404 @notcached;
    }

    location @notcached {
        internal;
        # 若檔案未找到,轉發請求至代理伺服器
        proxy_pass http://backend;
    }
}

這樣組態後,當請求 URI 沒有找到時,會從 Memcached 中取得資料;若 Memcached 中沒有資料,則將請求轉發給代理伺服器。

Image Filter 模組

Image Filter 模組透過 GD Graphics Library 提供影像處理功能。請注意,此模組不包含在預設的 NGINX 構建中,需要額外組態。

location ~* \.(png|jpg|gif|webp)$ {
    [...]
}

與其他模組整合

Mermaid圖示

此圖示展示了 NGINX 各模組之間的關係與組態流程:

  flowchart TB
    I[I]
    No[No]
    Yes[Yes]

subgraph "NGINX Configuration"
    direction TB
    A[Gunzip Filter] --> B[Charset Filter]
    B --> C[Memcache]
end

subgraph "Processing Flow"
    direction TB
    D[Client Request] --> E[NGINX Server]
    E --> F[Gunzip Filter]
    F --> G[Charset Filter]
    G --> H[Memcache Lookup]
end

subgraph "Memcache Process"
    direction TB
    H --> I{Data Found?}
    I -- No --> J[Proxy Request]
    I -- Yes --> K[Return Data]
end

style A fill:#f9f,stroke:#333,stroke-width:2px;
style B fill:#bbf,stroke:#333,stroke-width:2px;
style C fill:#ff9,stroke:#333,stroke-width:2px;

與其他模組整合

架構圖示

以下圖示展示了 NGINX 各模組之間如何互相配合:

  flowchart TD
    B[B]
    C[C]
    D[D]
    E[E]
    F[F]
    G[G]
    H[H]
    No[No]
    Yes[Yes]

subgraph "Request Handling"
A[Client Request] --> B{Nginx Server}
B --> C{Gunzip Filter}
C --> D{Charset Filter}
D --> E{Memcache Check}
E -- Yes --> F{Return Data}
E -- No --> G{Proxy Request}
F --> H{Client Response}
G --> H{Client Response}
end

style A fill:#f9f,stroke:#333,stroke-width:2px;
style B fill:#bbf,stroke:#333,stroke-width:2px;
style C fill:#bbf,stroke:#333,stroke-width:2px;
style D fill:#bbf,stroke:#333,stroke-width:2px;
style E fill:#bbf,stroke:#333,stroke-width:2px;
style F fill:#bbf,stroke:#333,stroke-width:2px;
style G fill:#bbf,stroke:#333,stroke-width:2px;