NGINX 模組組態：核心模組與進階應用

NGINX 模組化設計使其具備高度彈性與擴充性，能滿足多樣化的網站需求。Referer 模組可限制來源網域，Real IP 模組則能準確識別客戶端真實 IP，對於反向代理架構尤為重要。SSL 模組是保障網站安全性的根本，正確組態憑證與金鑰是建構 HTTPS 的關鍵。此外，Stub Status 模組提供伺服器狀態監控，讓管理者能快速掌握 NGINX 執行狀況。第三方模組的整合則能進一步擴充 NGINX 功能，例如 Access Key 模組提供類別似 Secure Link 的檔案保護機制，Fancy Indexes 模組則能美化自動目錄列表，而 Headers More 模組則賦予 HTTP 標頭設定更大的彈性。然而，整合第三方模組時需謹慎評估安全性，避免引入潛在漏洞。在與後端應用程式整合方面，NGINX 可透過 FastCGI 技術與 PHP-FPM 協同運作，也能透過反向代理機制與 Python 的 Django 框架整合，實作高效能的 Web 服務。

NGINX 模組組態探索

NGINX 作為一個強大的 Web 伺服器，提供了豐富的模組來滿足不同的需求。這些模組包括處理 HTTP 頁首、SSL 安全性及實際使用者 IP 地址等。以下是對這些模組的探討與技術解說。

參照者模組

參照者模組（Referer Module）允許你根據 HTTP 要求中的 Referer 頁首來限制存取。這在防止熱連結、檢查來源網站等方面非常有用。以下是一些常見的組態選項：

valid_referers none blocked *.website.com *.google.com;
if ($invalid_referer) {
    return 403;
}

內容解密：

這段程式碼定義了有效的參照者並傳回錯誤碼：

valid_referers 指令指定哪些參照者是有效的。none 表示沒有參照者，blocked 表示已阻止的參照者，而 *.website.com 和 *.google.com 則是特定網域名稱下的任何子網域名稱。
if ($invalid_referer) 條件檢查是否有無效的參照者。
return 403; 當檢測到無效的參照者時，傳回 HTTP 403 錯誤碼，表示禁止存取。

然而，需要注意的是，由於 Referer 頁首可以被輕易偽造，因此這種方法不應被視為安全措施。

此外，這個模組還提供了 referer_hash_bucket_size 和 referer_hash_max_size 指令來定義有效參照者雜湊表的桶大小和最大大小。

Real IP 模組

Real IP 模組主要用於替換客戶端 IP 地址，特別是在使用反向代理或後端伺服器的情況下。這個模組允許你從 HTTP 頁首中提取真實的 IP 地址。

real_ip_header X-Forwarded-For;
set_real_ip_from 192.168.0.0/16;
set_real_ip_from 127.0.0.1;
set_real_ip_from unix:; # 信任所有 UNIX 域通訊端

內容解密：

real_ip_header 指令設定使用哪個 HTTP 頁首來替換 IP 地址。這裡使用的是 X-Forwarded-For 頁首。
set_real_ip_from 指令定義信任的 IP 地址或 CIDR 段。這裡設定信任了 192.168.0.0/16、127.0.0.1 和所有 UNIX 域通訊端。

以下是一些 Real IP 模組中其他重要指令的說明：

指令	說明
`set_real_ip_from`	設定信任的地址或 CIDR 段，這些地址允許使用實際 IP 頁首替換客戶端 IP 地址。
`real_ip_header`	設定用於替換 IP 地址的 HTTP 頁首。
`real_ip_recursive`	若設定為 on，則會將替換後的 IP 設定為最後一個非信任的 IP；若設定為 off，則會替換成最後一個 IP，無論是否信任。

SSL 模組

SSL 模組使 NGINX 能夠提供 HTTPS 支援，從而保護網站和存取者之間的資料傳輸。

ssl on;
ssl_certificate /path/to/certificate.crt;
ssl_certificate_key /path/to/private.key;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;

內容解密：

ssl on; 啟用 HTTPS 支援。
ssl_certificate 指令設定憑證檔案路徑。
ssl_certificate_key 指令設定私鑰檔案路徑。
ssl_protocols 指令指定使用哪些 SSL/TLS 傳輸協定。
ssl_ciphers 指令指定使用哪些加密套件。

以下是一些其他重要 SSL 組態指令：

指令	說明
`ssl_client_certificate`	設定客戶端憑證檔案路徑。
`ssl_crl`	載入憑證復原列表 (CRL) 檔案。
`ssl_dhparam`	設定 Diffie-Hellman 引數檔案路徑。
`ssl_verify_client`	啟用客戶端憑證驗證並將結果儲存在 `$ssl_client_verify` 中。
`ssl_verify_depth`	指定客戶端憑證鏈的驗證深度。
`ssl_session_cache`	組態 SSL 工作階段快取。
`ssl_session_timeout`	當啟用 SSL 工作階段時，設定工作階段資料使用超時時間。
`ssl_password_phrase_file`	指定包含秘密金鑰密碼片語的檔案路徑。

Mermaid 流程圖示

此圖示展示了 NGINX 的基本請求處理流程：

  graph TD
    C[C]
    E[E]
    No[No]
    Yes[Yes]
    A[Client Request] --> B[NGINX Server]
    B --> C{Valid Referer?}
    C -- No --> D[Return 403]
    C -- Yes --> E{Real IP?}
    E -- No --> F[Process Request]
    E -- Yes --> G[Set Real IP]
    G --> F[Process Request]

內容解密：

A：客戶端發起請求。
B：請求到達 NGINX 伺服器。
C：檢查請求中的 Referer 頁首是否有效。
- 若無效（No），傳回 HTTP 403 錯誤碼。
- 若有效（Yes），進一步檢查 Real IP。
E：檢查是否需要設定實際 IP 地址。
- 若不需要（No），直接處理請求。
- 若需要（Yes），設定實際 IP 地址後再處理請求。

透過這些組態選項和指令，NGINX 能夠靈活地滿足不同場景下對於安全性和功能性的需求。希望這些內容能夠幫助你更好地理解和應用 NGINX 的各種模組組態技術！

NGINX SSL 模組與高階功能組態

NGINX 作為一個強大的反向代理伺服器與負載平衡器，其 SSL 模組提供了豐富的組態選項，能夠滿足各種安全需求。本文將探討 NGINX SSL 模組的組態細節，並介紹一些高階功能模組的使用方法。

NGINX SSL 模組的基本組態

在開始組態之前，確保你已經擁有以下檔案：

一個 .key 檔案，使用 openssl genrsa -out secure.website.com.key 2048 生成。
一個 .csr 檔案，使用 openssl req -new -key secure.website.com.key -out secure.website.com.csr 生成。
由認證機構（CA）發出的網站證書檔案，例如 secure.website.com.crt。
由 CA 提供的 CA 證書檔案，例如 gd_bundle.crt（如果從 GoDaddy 購買）。

首先，將你的網站證書和 CA 證書合併：

cat secure.website.com.crt gd_bundle.crt > combined.crt

接著，組態 NGINX 以使用這些證書：

server {
    listen 443;
    server_name secure.website.com;
    ssl on;
    ssl_certificate /path/to/combined.crt;
    ssl_certificate_key /path/to/secure.website.com.key;
    # 其他組態...
}

詳細探討 SSL 模組指令

以下是一些常用的 SSL 模組指令：

`ssl_session_tickets`

這個指令啟用 TLS 會話票證，允許客戶端快速重新連線而不需要重新協商。

ssl_session_tickets on;

語法：on 或 off
預設值：on

`ssl_session_ticket_key`

這個指令設定用於加密和解密 TLS 會話票證的金鑰檔案路徑。預設情況下會生成一個隨機值。

ssl_session_ticket_key /path/to/ticket.key;

語法：Filename
預設值：無

`ssl_trusted_certificate`

這個指令設定受信任證書檔案的路徑（PEM 格式），用於驗證客戶端證書並進行 OCSP 回應的釘接。

ssl_trusted_certificate /path/to/trusted.crt;

語法：Filename
預設值：無

SSL 銷售技術（OCSP Stapling）

SSL 銷售技術（OCSP Stapling）是一種技術，允許客戶端快速連線並還原到 SSL/TLS 伺服器會話，而不需要聯絡 CA。這樣可以減少 SSL 機密協商時間。NGINX 支援 OCSP Stapling，以下是如何啟用它：

啟用 OCSP Stapling：
```
ssl_stapling on;
```
啟用 OCSP 回應驗證：
```
ssl_stapling_verify on;
```

設定受信任證書檔案路徑：

ssl_trusted_certificate /path/to/fullchain.pem;

高階功能模組

除了 SSL 模組外，NGINX 還提供一些高階功能模組來增強其能力。

Stub Status 模組

Stub Status 模組提供伺服器當前狀態的資訊，如活動連線數和處理過的請求數等。要啟用它，請在 location 塊中新增 stub_status 指令：

location = /nginx_status {
    stub_status on;
    allow 127.0.0.1; # 建議保護這些資訊
    deny all;
}

實務案例分析

在實際應用中，這些組態可以顯著提升網站的安全性和效能。例如，使用 ssl_session_tickets 和 OCSP Stapling 可以大幅減少 SSL 機密協商時間，提升使用者經驗。同時，Stub Status 模組可以幫助管理員實時監控伺服器狀態，及時發現並解決問題。

未來趨勢預測

隨著網路安全需求的不斷提升，NGINX 的 SSL 模組和高階功能模組將會變得越來越重要。未來可能會看到更多針對 TLS 和 HTTP/3 的最佳化措施，以及更強大的監控和診斷工具。

總結來說，NGINX 提供了豐富的組態選項和高階功能模組，能夠滿足各種安全需求和效能最佳化需求。透過合理組態這些模組，可以顯著提升網站的安全性和效能。

使用 NGINX 模組來增強伺服器組態

在本文中，玄貓將探討如何使用 NGINX 模組來增強伺服器的組態，並展示一些實際案例。這些模組不僅能提升伺服器的效能，還能提供更多的功能和靈活性。讓我們從一些基本的模組開始，逐步探討其應用和優勢。

使用 Stub 狀態頁面來監控 NGINX

Stub 狀態頁面是一個簡單但有效的工具，可以幫助你監控 NGINX 的執行狀態。這個模組並不在 NGINX 的預設構建中，因此需要手動新增。以下是如何啟用並使用 Stub 狀態頁面的步驟。

組態 Stub 狀態頁面

首先，你需要在 NGINX 的組態檔案中新增相關設定。以下是一個簡單的範例：

server {
    listen 80;
    server_name example.com;

    location /stub_status {
        stub_status;
        allow 127.0.0.1; # 只允許本地存取
        deny all;        # 拒絕其他所有存取
    }
}

在這個範例中，我們設定了一個位於 /stub_status 的位置，只有來自本地的請求才能存取。這樣可以確保這個頁面不會被公開暴露。

檢視 Stub 狀態頁面

當你存取 /stub_status 時，你會看到類別似以下的結果：

Active connections: 1
server accepts handled requests
10 10 23
Reading: 0 Writing: 1 Waiting: 0

這些資料表示了當前活躍的連線、接受的請求數、處理的請求數、讀取中的連線數、寫入中的連線數以及等待中的連線數。

第三方監控解決方案

有一些第三方監控解決方案，如 Netdata，可以透過定期呼叫 Stub 狀態頁面來取得統計資料。這些工具可以幫助你更好地瞭解伺服器的執行狀況，並及時發現潛在問題。

HTTP 滲透模組

HTTP 滲透模組可以組態伺服器在記憶體不足時傳回錯誤頁面。這個模組透過定義一個記憶體閾值來觸發滲透檢查。

組態 HTTP 滲透模組

以下是如何組態 HTTP 滲透模組的範例：

http {
    degradation sbrk=500m; # 在 http 塊級插入記憶體閾值

    server {
        listen 80;
        server_name example.com;

        location / {
            degrade 204; # 在位置塊中指定錯誤碼（204 或 444）
        }
    }
}

在這個範例中，我們設定了一個記憶體閾值為 500M，當記憶體使用量達到這個閾值時，伺服器會傳回 204 錯誤碼。

整合第三方模組

NGINX 有許多由第三方開發者編寫的模組，這些模組可以從官方 Wiki 網站下載。然而，玄貓建議在整合這些第三方模組時要謹慎，因為它們可能會引入安全漏洞。

常見第三方模組

以下是一些常見的第三方模組及其功能：

Access Key 模組：類別似於 Secure Link，用於保護檔案。
Fancy Indexes 模組：改進自動目錄列表。
Headers More 模組：增強 HTTP 標頭的靈活性。

整合第三方模組步驟

整合第三方模組到你的 NGINX 構建中需要三個簡單步驟：

下載 .tar.gz 檔案。
提取檔案：
```
tar xzf module.tar.gz
```

組態 NGINX 構建：

./configure --add-module=/module/source/path [...]

完成這些步驟後，模組就可以像普通 NGINX 模組一樣使用了。

PHP 和 Python 與 NGINX

FastCGI 技術簡介

FastCGI 是 Common Gateway Interface (CGI) 的改進版本。CGI 是一種早期的技術，用於讓網頁伺服器與應用程式進行通訊。FastCGI 提高了效能和效率。

CGI 原理

原始的 CGI 機制是這樣工作的：客戶端傳送請求給網頁伺服器，網頁伺服器將請求轉發給第三方應用程式（如 PHP 或 Python），應用程式處理後將結果傳回給網頁伺服器，網頁伺服器再將結果傳回給客戶端。

組態 NGINX 與 PHP-FPM

PHP-FPM 是 PHP FastCGI Process Manager 的縮寫。以下是如何組態 NGINX 與 PHP-FPM 的步驟。

安裝 PHP-FPM

首先，安裝 PHP-FPM：

sudo apt-get install php-fpm

組態 NGINX

然後，組態 NGINX 與 PHP-FPM：

server {
    listen 80;
    server_name example.com;

    location / {
        root /var/www/html;
        index index.php index.html index.htm;

        location ~ \.php$ {
            include snippets/fastcgi-php.conf;
            fastcgi_pass unix:/var/run/php/php7.4-fpm.sock; # 調整版本號
        }
    }
}

組態 NGINX 與 Python 和 Django

Django 是一個流行的 Python Web 框架。以下是如何組態 NGINX 與 Django 的步驟。

安裝 Django 和 Gunicorn

首先，安裝 Django 和 Gunicorn：

pip install django gunicorn

組態 Gunicorn

然後，組態 Gunicorn：

gunicorn myproject.wsgi:application --bind 127.0.0.1:8000

組態 NGINX

最後，組態 NGINX：

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。