你的 Nginx 還在用預設值？資深工程師的 WordPress 效能調校聖經，榨乾伺服器最後一滴效能！

嗨，我是浪花科技的資深工程師 Eric。在業界打滾這麼多年，看過無數個 WordPress 網站，從個人部落格到一天幾十萬流量的電商平台都有。我發現一個很有趣、但也讓人有點哭笑不得的現象：很多網站明明用了效能絕佳的 Nginx 當作網頁伺服器，但裡面的設定檔（nginx.conf）卻幾乎是「全新未拆封」的預設狀態。

這就像是你買了一台法拉利，卻只用時速 30 公里在市區開，完全浪費了它該有的性能啊！老實說，每次看到這種情況，我內心的工程師小劇場都會忍不住上演：「天啊，這 worker_processes 才開 1，是想讓 CPU 在旁邊泡茶聊天嗎？FastCGI Cache 沒開，每次請求都讓 PHP 跑到天荒地老，這對得起使用者寶貴的時間嗎？」

所以，今天我決定不囉嗦了（好吧，可能還是會有一點），直接端出這篇 Nginx 主機效能最佳化的實戰指南。這篇文章不是要教你複製貼上一堆看不懂的指令，而是要帶你理解每個設定背後的「為什麼」，讓你真正成為 Nginx 的主人，而不是被預設值綁架。準備好了嗎？讓我們一起把你的 WordPress 網站速度催到極致！

Nginx 效能核心：先搞懂 Worker Processes 和 Connections

在我們開始大刀闊斧修改設定前，必須先理解 Nginx 運作的兩個核心概念：worker_processes 和 worker_connections。這兩個參數決定了 Nginx 能同時處理多少「工作」和「連線」，是效能調校的地基，地基沒打好，上面蓋再多高樓大廈都會垮。

到底該開多少工人？談 worker_processes

worker_processes 指的是 Nginx 要啟動多少個工作程序（Worker Process）來處理使用者的請求。你可以把它想像成餐廳裡有多少個服務生。如果服務生太少，客人一多就應付不來；但如果服務生太多，超過了廚房（CPU）的出餐速度，多請的人也只是在旁邊乾瞪眼，浪費資源。

一個最常見、也最安全的設定原則是：將 worker_processes 的數量設定為你伺服器的 CPU 核心數。

你可以用這個指令來查看你的 CPU 有多少核心：

grep processor /proc/cpuinfo | wc -l

假設你的伺服器有 4 個核心，那麼你的 `nginx.conf` 應該這樣設定：

# 通常在 nginx.conf 的最頂部
worker_processes 4;

工程師小囉嗦： 有些人會建議設成 `auto`，讓 Nginx 自動偵測。這在大多數情況下是可行的，但我個人還是偏好明確指定。為什麼？因為 `auto` 在某些虛擬化環境或容器（例如 Docker）中可能會誤判，明確指定數字可以讓你 100% 掌握伺服器的行為，這對我們工程師來說，是一種確定性的安全感！

每個工人能服務多少客人？談 worker_connections

worker_connections 則是定義了每一個 Worker Process 能同時處理的最大連線數。這就像是規定每個服務生手上最多能端幾個盤子。

這個數字不是越大越好，它受限於作業系統的檔案描述符（File Descriptors）限制。你可以用 ulimit -n 來查看這個限制。一般來說，預設的 1024 對於一個有流量的網站是遠遠不夠的。

一個比較合理的起始設定是 4096 或更高：

# 在 events {} 區塊內
events {
    worker_connections 4096;
}

所以，你的 Nginx 伺服器理論上能同時處理的最大連線數就是：worker_processes * worker_connections。以上面的例子就是 `4 * 4096 = 16384`。這個數字涵蓋了所有連線，包括與客戶端的連線、與後端 PHP-FPM 的連線等。

快取治百病？Nginx FastCGI Cache 設定實戰

WordPress 是一個動態網站，每次有人訪問，伺服器都要去執行 PHP、查詢資料庫，然後生成一個 HTML 頁面。這個過程其實很耗資源。如果 1000 個人同時看同一篇文章，伺服器就要重複做 1000 次同樣的事情，這根本是災難！

這就是快取（Cache）派上用場的地方。Nginx 內建的 FastCGI Cache 可以在伺服器層級就把 PHP 生成的結果暫存起來。下一個使用者來訪時，Nginx 直接從快取把存好的 HTML 丟出去，完全不用驚動後面的 WordPress 和資料庫，速度快到飛起！

第一步：定義快取路徑與規則

首先，在 `nginx.conf` 的 `http` 區塊中，我們要定義快存的位置、大小等資訊。

# 在 http {} 區塊內，通常放在 server {} 的外面
fastcgi_cache_path /var/run/nginx-cache levels=1:2 keys_zone=WORDPRESS:100m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";

• /var/run/nginx-cache: 快取檔案存放的路徑，請確保 Nginx 有權限寫入此目錄。
• levels=1:2: 快取目錄的層級結構。
• keys_zone=WORDPRESS:100m: 建立一個名為 WORDPRESS 的共享記憶體區域，大小為 100MB，用來存放快取鍵（Cache Key）。
• inactive=60m: 如果快取檔案在 60 分鐘內沒有被存取，就自動刪除。
• fastcgi_cache_key: 定義如何產生快取的「鑰匙」，也就是用什麼規則來判斷兩個請求是不是同一個頁面。

第二步：在網站設定中啟用快取

接著，到你的網站設定檔（例如 `/etc/nginx/sites-available/yourdomain.com`），在處理 PHP 的 `location` 區塊中啟用它。

location ~ \.php$ {
    # ... 其他 fastcgi 設定 ...

    # 啟用快取
    fastcgi_cache WORDPRESS;
    # 快取有效的 HTTP 狀態碼，預設只有 200
    fastcgi_cache_valid 200 301 302 10m;
    # 設定在什麼情況下「不要」使用快取
    fastcgi_cache_bypass $skip_cache;
    fastcgi_no_cache $skip_cache;

    # ... 其他設定 ...
}

你會看到一個神秘的變數 $skip_cache。我們需要定義在什麼情況下要跳過快取，例如：使用者已經登入、正在逛後台、或是 WooCommerce 的購物車頁面。這通常會寫在 `server` 區塊的頂部。

# 設定一個變數，預設為 0 (不跳過快取)
set $skip_cache 0;

# 如果是 POST 請求，不快取
if ($request_method = POST) {
    set $skip_cache 1;
}

# 如果 URL 含有查詢字串，不快取 (可自行斟酌)
if ($query_string != "") {
    set $skip_cache 1;
}

# 針對 WordPress 後台及特定頁面，不快取
if ($request_uri ~* "/wp-admin/|/xmlrpc.php|wp-.*.php|/feed/|index.php|sitemap(_index)?.xml") {
    set $skip_cache 1;
}

# 針對已登入的使用者 (檢查 cookie)，不快取
if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") {
    set $skip_cache 1;
}

流量不是無限的！善用 Gzip 與 Brotli 壓縮

網頁上的文字、CSS、JavaScript 檔案在傳輸前，其實可以像壓縮檔一樣先「打包」一下，讓檔案變小，傳輸速度自然就變快了。這就是 Gzip 和 Brotli 在做的事。

在 `nginx.conf` 的 `http` 區塊中加入以下設定，就能啟用 Gzip 壓縮：

# 在 http {} 區塊內
gzip on;
gzip_disable "msie6"; # 放過老舊的 IE6
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6; # 壓縮等級，1-9，6是個平衡點
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript image/svg+xml;

Brotli 是 Google 開發的更新、更強的壓縮演算法，壓縮率比 Gzip 更高。如果你的 Nginx 有安裝 Brotli 模組，強烈建議啟用它，並讓它優先於 Gzip。

迎接未來：啟用 HTTP/2 與優化緩衝區 (Buffers)

HTTP/2 是新一代的 HTTP 協定，它透過多路複用（Multiplexing）等技術，大幅改善了網頁載入速度，特別是在資源檔案很多的時候。在 Nginx 啟用它非常簡單，只需要在 `listen` 指令後面加上 `http2` 即可。

# 在你的 server {} 區塊內
server {
    # ...
    listen 443 ssl http2;
    # ...
}

請注意： HTTP/2 強制要求使用 HTTPS，所以你必須先設定好 SSL 憑證。

另外，關於緩衝區（Buffers），client_max_body_size 是一個你可能需要調整的參數。它決定了使用者能上傳多大的檔案。如果你發現 WordPress 後台無法上傳大一點的媒體檔案，通常就是這個值設太小了。可以把它加到 `http` 或 `server` 區塊：

# 允許上傳最大 64MB 的檔案
client_max_body_size 64M;

別讓 PHP-FPM 拖後腿：Nginx 與 PHP-FPM 的協同作戰

最後，也是最重要的一點：Nginx 主機效能最佳化從來都不是 Nginx 一個人的事。Nginx 只是個傳令兵，真正處理 WordPress 邏輯的是 PHP-FPM。如果 PHP-FPM 的效能跟不上，Nginx 再快也沒用。

你需要檢查你的 PHP-FPM 設定檔（通常在 `/etc/php/[version]/fpm/pool.d/www.conf`），特別是以下幾個參數：

• pm: 建議設定為 dynamic，讓它動態調整子程序數量。
• pm.max_children: 允許的最大子程序數。這是最重要的參數，它直接決定了你的網站能同時處理多少個 PHP 請求。如果太小，高併發時請求就會排隊等待；如果太大，會耗盡伺服器記憶體。你需要根據你的伺服器記憶體來計算，一個 PHP-FPM 程序大約會吃掉 20-30MB 記憶體。
• pm.start_servers, pm.min_spare_servers, pm.max_spare_servers: 這些是 `dynamic` 模式下的輔助參數，用來控制備用的閒置程序數量。

調校 PHP-FPM 是另一門大學問，但請記住一個原則：Nginx 的總連線能力應該要能應付 PHP-FPM 的最大處理能力，兩者必須協調合作，才能發揮最大綜效。

結論：調校是一條永無止盡的道路

我們今天從 Nginx 的核心參數、伺服器層級快取、傳輸壓縮，一路談到與 PHP-FPM 的協同作戰。完成這些設定後，你的 WordPress 網站效能肯定會有質的飛躍。但記住，效能調校不是一次性的工作，它是一個需要根據網站流量、使用者行為不斷監控和微調的過程。

希望這篇文章能幫助你解開 Nginx 的封印，釋放它真正的力量。當然，如果你覺得這些設定太過複雜，或者你的業務更需要專注在核心發展上，而不想為伺服器維運分心，浪花科技的團隊非常樂意提供專業的協助。

延伸閱讀

• 網站狂飆不是夢！Apache vs. LiteSpeed 終極對決，資深工程師帶你挑選 WordPress 的最強心臟
• 網站慢到想哭？解鎖 WordPress 終極加速密技：Redis 物件快取實戰教學
• 網站跑分不及格？Google Core Web Vitals 終極指南：LCP/CLS/FID 調教實戰，讓你的 WordPress 速度原地起飛！

覺得伺服器調校太燒腦，想找專家幫你搞定？歡迎點擊這裡，立即與浪花科技的技術顧問聊聊，讓我們為你的網站打造一個堅實又高效的底層架構！