Nginx 設定精要：效能、安全、負載平衡全攻略

在現代的 Web 架構中，Nginx 不僅僅是一個輕量級的 Web Server，它更扮演著反向代理（Reverse Proxy）、負載平衡器（Load Balancer）以及 API Gateway 的核心角色。無論你是正在架構微服務的 DevOps 工程師，還是需要優化網站載入速度的前端開發者，掌握 Nginx 的設定精要都是提升系統穩定性與效能的必經之路。

然而，Nginx 的強大往往伴隨著複雜性。一個錯誤的設定，輕則導致網站載入緩慢，重則可能造成服務中斷或嚴重的安全性漏洞。本文將深入探討如何透過精準的 Nginx 設定，從效能優化、安全性強化以及負載平衡策略三個維度，打造一個強韌且高效的伺服器環境。

Nginx 的核心架構與運作邏輯

在深入具體的設定參數之前，我們必須先理解 Nginx 的運作機制。Nginx 採用的是「Master-Worker」模型，這也是它能處理高併發（High Concurrency）請求的關鍵。

Master-Worker 模型與事件驅動機制

Nginx 的主進程（Master Process）負責讀取設定檔、管理 Worker 進態以及處理與作業系統的通訊。而實際處理網路請求的工作，則是由多個 Worker Process 承擔。

這種設計採用了非阻塞（Non-blocking）的事件驅動（Event-driven）機制。當一個請求進來時，Worker Process 並不會為每個請求都建立一個新的 Thread，而是透過 epoll（在 Linux 環境下）來監控大量的連線。這種機制讓 Nginx 在面對成千上萬個同時連線時，依然能保持極低的記憶體佔用與極高的處理效率。

設定檔的層級結構

Nginx 的設定檔（通常是 nginx.conf）具有明顯的層級結構。理解這個結構對於進行複雜的配置管理至關重要：

Main Context: 全域設定，如 user, worker_processes, error_log 等。
Events Context: 處理連線相關的底層設定，如 worker_connections。
HTTP Context: 這是最核心的部分，包含了所有 Web 服務的邏輯，包含 gzip, keepalive, upstream 等。
Server Context: 定義特定的 Virtual Host（虛擬主機），處理特定 Domain 或 IP 的請求。
Location Context: 最細粒度的設定，決定如何處理特定的 URL 路徑（例如 /api 或 /static）。

如果你在修改設定時感到困惑，建議可以先使用 Nginx 設定檢查工具來驗證語法是否正確，避免因語法錯誤導致服務無法啟動。

效能優化精要：讓你的伺服器跑得更快

效能優化並非單純地增加硬體資源，更多時候是透過精細的參數調整，減少 I/O 延遲與降低頻寬消耗。

核心連線與處理參數

首先，必須優化 Worker 程序的分配與連線上限。

worker_processes: 建議設定為 auto。這會讓 Nginx 自動偵測 CPU 核心數並啟動對應數量的 Worker，確保每個 CPU 核心都能被充分利用。
worker_connections: 這決定了單個 Worker 能同時處理的連線數。在高併發場景下，建議將此值調大（例如 1024 或 4096 以上），但需注意系統的 ulimit 限制。
use epoll: 在 Linux 環境下，確保使用 epoll 模組，這是目前最高效的 I/O 多路復用機制。

減少網路傳輸負擔：Gzip 與 Keepalive

網路頻寬往往是 Web 應用的瓶較。透過壓縮技術與長連線機制，可以顯著提升使用者體驗。

Gzip 壓縮: 透過 gzip on; 開啟壓縮。針對 HTML, CSS, JavaScript, JSON 等文字類檔案進行壓縮，能大幅減少傳輸的 Payload 大小。但請注意，不要對圖片（如 JPEG）進行 Gzip，因為圖片本身已壓縮過，再次壓縮只會浪費 CPU 資源。
Keepalive 保持長連線: 透過 keepalive_timeout 設定，讓客戶端與伺服器在完成一個請求後，能在一段時間內保持連線，避免頻繁的 TCP 三向交握（Three-way Handshake）造成的延遲。

快取機制（Caching Strategies）

快取是效能優化的「銀彈」。透過 Nginx 的 proxy_cache 功能，你可以將後端伺服器（如 Node.js, Python, PHP）產生的回應結果暫存起來。

當下一個相同的請求進來時，Nginx 直接從磁碟或記憶體回傳結果，完全不需要經過後端應用程式。這對於讀取頻率高、變動頻常的靜態內容或 API 回應極其有效。

安全防禦強化：打造堅不可摧的防線

在公開網路環境中，Nginx 暴露在第一線，因此安全設定是重中之重。

SSL/TLS 加密與現代化配置

現在的 Web 服務必須全面採用 HTTPS。但僅僅安裝證書是不夠的，你必須配置強大的加密套件（Cipher Suites）。

禁用舊版協議: 務必關閉 SSLv3, TLS 1.0, TLS 1.1，僅允許 TLS 1.2 與 TLS 1.3。
HSTS (HTTP Strict Transport Security): 透過 add_header Strict-Transport-Security 強制瀏覽器在未來一段時間內僅透過 HTTPS 與伺服器通訊，防止中間人攻擊（MITM）。

流量限制與防禦 DDoS 攻擊

為了防止惡意爬蟲或 DDoS 攻擊，我們需要實施 Rate Limiting（速率限制）。

limit_req: 透過 limit_req_zone 定義一個基於 IP 的共享記憶體區域，並使用 limit_req 限制每個 IP 每秒的請求數。這能有效緩解暴力破解（Br型攻擊）或單一來源的惡意請求。
隱藏伺服器資訊: 使用 server_tokens off;。預設情況下，Nginx 的錯誤頁面會顯示版本號，這會給攻擊者提供精確的漏洞研究資訊，關閉它可以增加攻擊難度。

除了 SSL，還應加入以下 Header 來增強瀏覽器端的防禦能力： * X-Frame-Options: DENY: 防止點擊劫持（Clickjacking）。 * X-Content-Type-Options: nosniff: 防止 MIME 類型嗅探攻擊。 * Content-Security-Policy (CSP): 定義哪些資源可以被載入，是防止 XSS 攻擊最強大的手段之一。

負載平衡實戰：實現高可用性架構

當單一伺服器無法承擔流量時，負載平衡（Load Balancing）是唯一的出路。Nginx 的 upstream 模組提供了極其靈活的配置方式。

負載平衡演算法比較

根據你的應用場景，選擇合適的演算法至關重要。以下是常見的三種策略比較：

Upstream 配置範例

在 http 區塊中，你可以定義多個 upstream 群組，並在 server 區塊中使用 proxy_pass 來引用它們。

http {
    # 定義後端伺服器群組
    upstream backend_servers {
        least_conn; # 使用最少連線演算法
        server 192.168.1.10:8080 weight=3; # 權重較高的伺服器
        server 192.168.1.11:8080;
        server 192.168.1.12:8080 backup;   # 當其他伺服器失效時才啟動
    }

    server {
        listen 80;
        server_name api.example.com;

        location / {
            proxy_pass http://backend_servers;
            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_connect_timeout 60s;
            proxy_read_timeout 60s;
        }
    }
}

實戰範例：一個完整的 Nginx 設定檔解析

為了方便開發者直接參考，以下提供一個整合了效能優化、安全性與負載平衡的範例配置。你可以將此作為基礎，並根據需求進行微調。

user  nginx;
worker_processes  auto; # 自動偵測 CPU 核心

error_log  /var/log/nginx/error.log warn;
pid        /varrypt/run/nginx.pid;

events {
    worker_connections  1024;
    multi_accept on;
    use epoll;
}

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    # --- 效能優化：Gzip 壓縮 ---
    gzip on;
    gzip_disable "msie6";
    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 6;
    gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

    # --- 效能優化：開啟檔案快取 ---
    open_file_cache max=1000 inactive=20s;
    open_file_cache_valid 30s;
    open_file_cache_min_uses 2;
    open_file_cache_maxima 10000;

    # --- 安全防禦：限制請求速率 (Rate Limiting) ---
    limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

    # --- 負載平衡定義 ---
    upstream my_app_cluster {
        least_conn;
        server 127.0.0.1:8081;
        server 127.0.0.1:8082;
    }

    # --- 主要服務設定 ---
    server {
        listen 443 ssl http2; # 開啟 HTTP/2
        server_name example.com;

        # SSL 設定 (請替換為你的憑證路徑)
        ssl_certificate     /etc/nginx/ssl/example.com.crt;
        ssl_certificate_key /etc/nginx/ssl/example.com.key;
        ssl_protocols       TLSv1.2 TLSv1.3;
        ssl_ciphers         HIGH:!aNULL:!MD5;
        ssl_prefer_server_ciphers on;

        # 安全 Header
        add_header X-Frame-Options "SAMEORIGIN";
        add_header X-Content-Type-Options "nosniff";
        add_header X-XSS-Protection "1; mode=block";
        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
        server_tokens off; # 隱藏版本號

        # 靜態資源處理
        location /static/ {
            root /var/www/html;
            expires 30d; # 設定強制的瀏覽器快取
            add_header Cache-Control "public, no-transform";
        }

        # API 代理與流量限制
        location /api/ {
            limit_req zone=mylimit burst=20 nodelay; # 套用速率限制
            proxy_pass http://my_app_cluster;
            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_buffering on;
            proxy_buffer_size 8k;
            proxy_buffers 8 8k;
        }

        # 錯誤頁面自定義
        error_page 404 /404.html;
        error_page 500 502 503 504 /50x.html;
    }
}

如果你在配置過程中遇到任何困難，可以參考 Nginx 範例庫來尋找更多針對不同情境（如 Docker、Lua 模組等）的進階設定參考。

Nginx 設定常見錯誤與排查技巧

在維運過程中，最怕的就是「改了設定卻沒發現出錯，導致服務掛掉」。

1. 語法檢查 (Syntax Check)

在每次修改完 nginx.conf 後，絕對不要直接執行 systemctl restart nginx。請務必先執行：

nginx -t

這個指令會檢查設定檔的語法是否正確，以及檔案路徑是否存在。如果顯示 syntax is ok 與 test is successful，才進行重新載入。

2. 溫和重新載入 (Graceful Reload)

如果你需要套用新設定，請使用 reload 而不是 restart。

nginx -s reload
# 或者
systemctl reload nginx

reload 會啟動新的 Worker 進程來處理新請求，並在舊的 Worker 進程處理完現有的連線後才將其關閉，這能確保服務不中斷。

3. 日誌分析 (Log Analysis)

當服務出現異常時，error_log 是你唯一的救星。 * 檢查 Error Log: tail -f /var/log/nginx/error.log。 * 檢查 Access Log: 用於分析流量模式、檢查是否有異常的 User-Agent 或過大的請求。

FAQ：常見問題解答

Q1: Nginx 的 proxy_pass 與 root 有什麼差別？ A: root 是用來尋找伺服器本地磁碟上的檔案路徑；而 proxy_pass 是將請求轉發到另一個伺服器（如後端 App Server）。

Q2: 如何處理 Nginx 上傳大檔案失敗的問題？ A: Nginx 預設的 client_max_body_size 通常很小（例如 1MB）。如果需要上傳大檔案，請在 http 或 server 區塊中調大此數值，例如 client_max_body_size 100M;。

Q3: 為什麼我的 Nginx 設定了 ip_hash 但還是會導致 Session 丟失？ A: ip_hash 僅能保證同一 IP 的請求導向同一伺服器。如果客戶端使用了代理伺服器或 VPN，其 IP 會變動。此外，如果後端伺服器發生重啟，Hash 值重新計算也會導致分配變動。建議使用 Redis 進行 Session 集中管理。

Q4: 開啟 Gzip 會增加 CPU 負擔嗎？ A: 是的，壓縮過程需要消耗 CPU 運算資源。因此，建議只針對文字類型的檔案進行壓縮，並避免對已經壓縮過的格式（如 JPG, PNG, WebP）進行二次壓縮。

Q5: 如何判斷 Nginx 是否成功啟動了 HTTP/2？ A: 你可以使用瀏覽器的開發者工具（F12）查看「Network」分頁，在「Protocol」欄位中，如果顯示 h2，則代表正在使用 HTTP/2。

Q6: Nginx 的 worker_connections 設定太小會有什麼後果？ A: 當連線數達到上限時，Nginx 會拒絕新的連線請求，使用者的瀏覽器會顯示「連線被拒絕」或「無法連上伺服器」，這會直接導致服務中斷。

結論

Nginx 的設定是一門平衡的藝術。過度追求效能優化可能會導致記憶體耗盡或 CPU 負載過高；過度強化安全性則可能增加維護成本與延遲。

一個優秀的 Nginx 配置應該具備以下三個特質： 1. 高效能：透過正確的緩存、壓縮與連線管理，減少伺服器與客戶端的負擔。 2. 高安全性：透過嚴謹的 SSL/TLS 配置與流量限制，抵禦常見的網路攻擊。 3. 高可用性：透過合理的負載平衡策略與健康檢查，確保服務在任何情況下都能穩定運行。

建議開發者在進行任何生產環境的變更前，務必先在測試環境進行驗證，並養成使用 nginx -t 檢查語法的良好習慣。透過持續的監控與優化，你的 Nginx 才能成為支撐大規模流量的最強後盾。

Nginx 設定精要：效能、安全、負載平衡