Nginx 設定檔不再是天書！WordPress 效能調校實戰：從 Worker 到 PHP-FPM，親手打造火箭級網站

嘿，我是浪花科技的 Eric。又到了我們工程師的囉嗦時間。很多朋友聽說 Nginx 效能猛，就把網站從 Apache 換了過來，以為從此就能一飛沖天，結果網站速度還是跟烏龜爬一樣，甚至更慘。問題到底出在哪？十之八九，就是那個原封不動的 nginx.conf 預設設定檔在搞鬼。

別再相信「只要換了 Nginx 網站就會變快」這種都市傳說了。Nginx 就像一輛 F1 賽車的引擎，潛力無窮，但如果你用開家庭房車的方式去調校它，那它跑起來可能還不如一台小綿羊。今天，我們不只複製貼上，我要帶你徹底搞懂 Nginx 跟它最重要的夥伴 PHP-FPM 這對「歡喜冤家」是如何協同工作的，從根本上為你的 WordPress 網站進行一次心臟級的效能手術。

Nginx 效能的心臟：搞懂 Worker Processes 與 Connections

在我們動手修改任何設定之前，你必須先理解兩個最核心的概念：worker_processes 和 worker_connections。這就像蓋房子要先懂鋼筋水泥一樣，地基打歪了，後面再怎麼裝潢都沒用。別看到指令就想複製，先花五分鐘搞懂它們，你之後的調校之路會順暢百倍。

什麼是 worker_processes？你的伺服器有多少個「工人」？

你可以把 Nginx 想像成一個總指揮官，而 worker_processes 就是它手下能同時開工的「工人數量」。每個工人（worker process）都是一個獨立的進程，負責處理來自使用者的請求。理論上，工人越多，能處理的事情就越多。

但這不代表越多越好！開太多工人，他們之間為了搶資源（CPU 時間）會打架，反而降低效率。一個最經典也最安全的設定，就是讓工人的數量等於你伺服器的 CPU 核心數。

你可以在你的 Linux 伺服器上用這個指令查看核心數：

grep -c processor /proc/cpuinfo

不過，現在的 Nginx 已經很聰明了。與其手動設定，我更推薦直接使用 auto，讓 Nginx 自己去偵測最佳的工人數量。這也是目前官方推薦的最佳實踐。

# /etc/nginx/nginx.conf

user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

什麼是 worker_connections？每個工人能同時處理多少事？

如果 worker_processes 是工人的數量，那 worker_connections 就是「每個工人手上能同時拿著多少工具、處理多少條任務線」。這個數字決定了 Nginx 伺服器整體的最大連線數。

最大連線數 = worker_processes * worker_connections

這個值也不是越大越好。它受到系統層級的「檔案描述符（File Descriptor）」限制。你可以把它想成是作業系統給每個程式的「號碼牌」上限。通常預設值是 1024，對於一個有流量的網站來說，這絕對不夠用。你可以用 ulimit -n 來查看這個限制。

一個比較務實的起始設定是 4096 或 8192。這已經能應付絕大多數中小型網站的需求了。記得，這個設定是在 events 區塊裡。

# /etc/nginx/nginx.conf

events {
    worker_connections 4096;
    # multi_accept on; # 如果流量很大，可以考慮開啟
}

真正的瓶頸：Nginx 與 PHP-FPM 的雙人舞

好了，Nginx 的地基打好了。但殘酷的現實是，對於 WordPress 這種動態網站，Nginx 本身的負擔其實很小。它更像一個超高效的傳令兵，負責接收請求，然後把所有 PHP 相關的請求轉發給幕後大老闆——PHP-FPM（FastCGI Process Manager）。

真正消耗 CPU 和記憶體的，是 PHP-FPM 執行 WordPress 程式碼的過程。Nginx 和 PHP-FPM 就像一對跳雙人舞的舞者，任何一方的節奏沒配合好，整個表演就會搞砸。這也是最多新手、甚至是一些老手會忽略的效能調校關鍵點。

診斷你的 PHP-FPM Pool 設定

PHP-FPM 也有類似 Nginx worker 的概念，我們稱之為「PHP-FPM Pool」。它的設定檔通常在這裡：/etc/php/8.x/fpm/pool.d/www.conf（你的 PHP 版本號可能不同）。

裡面最重要的設定是 pm (Process Manager)，它有三種模式：

• dynamic：動態模式。平時維持一定數量的閒置進程，根據需求增減，直到上限。這是最泛用、最推薦的模式，在效能和資源使用之間取得了很好的平衡。
• ondemand：按需模式。平時不保持任何閒置進程，有請求進來才啟動。適合記憶體極小、流量非常低的伺服器，但缺點是第一個請求會比較慢。
• static：靜態模式。從頭到尾都維持固定數量的進程。適合記憶體非常大、流量穩定且高的伺服器，可以免去動態增減進程的開銷。

對於絕大多數網站，請選擇 pm = dynamic。

關鍵參數調校：計算你的 pm.max_children

在 dynamic 模式下，最重要的參數就是 pm.max_children。它定義了 PHP-FPM Pool 最多可以開多少個子進程來處理 PHP 請求。這個數字如果設太小，Nginx 會因為找不到空閒的 PHP 進程而出現 502 Bad Gateway 錯誤；如果設太大，則會耗盡伺服器的記憶體，導致整個系統崩潰。

這絕對不能憑感覺設定！ 我們需要科學計算。公式是：

pm.max_children = (伺服器總記憶體 – 系統及其他服務保留記憶體) / 每個 PHP-FPM 進程的平均記憶體佔用

操作步驟如下：

1. 計算平均進程記憶體： 找個網站流量不高不低的時候，執行以下指令，它會列出所有 PHP-FPM 進程的記憶體使用情況（單位 KB），然後取一個平均值。

ps --no-headers -o 'rss,cmd' -C php-fpm8.2 | awk '{ sum+=$1 } END { printf("Avg: %d KB\n", sum/NR) }'

假設我們算出來平均一個進程大約佔用 30MB (30720 KB)。

2. 計算可用記憶體： 假設你的伺服器有 4GB RAM，你可能需要為系統、MySQL、Redis 等保留 1GB，剩下 3GB (約 3072MB) 給 PHP-FPM 使用。
3. 計算 max_children： 3072MB / 30MB ≈ 102。我們可以取一個保守一點的數字，比如 90。

搞懂這個計算方法，你就贏過了 80% 的人了。這才是真正專業的 Nginx 主機效能最佳化，而不是盲目地複製貼上網路上的設定檔。

加速傳輸：快取與壓縮的煉金術

搞定了伺服器內部的協調問題，接下來我們要優化「傳輸」的過程。目標很簡單：讓傳輸的資料量變小、讓不變的資料不用每次都跟伺服器要。

讓瀏覽器記住你的網站：expires 標頭

網站上的圖片、CSS、JavaScript 這些靜態檔案，通常不會頻繁變動。我們可以告訴使用者的瀏覽器：「嘿，這些檔案你下載一次後，接下來 30 天內都不用再問我了，直接用你電腦裡的就好。」這就是瀏覽器快取。

在 Nginx 中，我們透過設定 expires 標頭來實現。這能大幅減少 HTTP 請求，對於回訪使用者來說，網站載入速度會有飛躍性的提升。

# 在你的 server block 中加入

location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|webp|woff|woff2|ttf|eot)$ {
    expires 30d;
    add_header Cache-Control "public, no-transform";
    access_log off;
    log_not_found off;
}

Gzip 還是 Brotli？幫你的網站資料瘦身

壓縮是另一個必殺技。它可以在資料從伺服器傳送到瀏覽器之前，先把它「打包」變小，瀏覽器收到後再「解包」。這能有效減少傳輸時間，尤其是在使用者網路速度不快的情況下。

• Gzip: 老牌、穩定、幾乎所有瀏覽器都支援，是基本盤。
• Brotli: Google 推出的新一代壓縮演算法，壓縮率比 Gzip 更高（尤其對文字檔）。現在主流瀏覽器都已支援。但需要你的 Nginx 有編譯對應的模組。

一般來說，我們會優先啟用 Brotli，如果客戶端不支援，再降級到 Gzip。下面是一個兼容並蓄的設定範例，可以直接使用。

# /etc/nginx/nginx.conf 的 http block 中

# Gzip 壓縮
gzip on;
gzip_disable "msie6";
gzip_vary on;
gzip_proxied any;
gzip_comp_level 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 壓縮 (如果你的 Nginx 支援)
brotli on;
brotli_comp_level 6;
brotli_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript image/svg+xml;

現代化與安全：HTTP/2 與基本防護

效能優化不僅僅是速度，還包含使用體驗和安全性。啟用 HTTP/2 是現代網站的標配。

啟用 HTTP/2，享受多路複用快感

相較於老舊的 HTTP/1.1，HTTP/2 最大的優勢是「多路複用（Multiplexing）」，它允許在一個 TCP 連線中同時傳輸多個請求和回應，解決了所謂的「隊頭阻塞」問題。簡單來說，就是載入資源的效率更高了。

啟用它非常簡單，只要你的網站在跑 HTTPS（這年頭沒跑 HTTPS 也不行了吧），在 listen 指令後面加上 http2 即可。

# 在你的 server block 中

listen 443 ssl http2;
listen [::]:443 ssl http2;

順手加點料：基本安全標頭

效能固然重要，安全也不能忘。都已經在改設定檔了，順手加上幾個基本的安全標頭，可以幫助你抵禦一些常見的網頁攻擊，如點擊劫持（Clickjacking）。

# 在你的 server block 中

add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "no-referrer-when-downgrade" always;
add_header Content-Security-Policy "frame-ancestors 'self'" always;

好了，經過這一連串的手術，你的 Nginx 引擎才算是真正被喚醒了。記住，效能調校是一個持續的過程，沒有一勞永逸的設定檔。你需要根據你的伺服器規格、網站流量和應用程式特性不斷微調。但今天分享的這些觀念和設定，絕對能為你的 WordPress 網站打下一個堅如磐石的高效能基礎。

如果你覺得這些設定太過複雜，或者你的問題不僅僅是 Nginx 層面的效能瓶頸，可能還牽涉到資料庫優化、後端程式碼、甚至是整體網站架構，那也別擔心。這正是我們浪花科技的專業所在。我們專注於為企業打造高效、穩定且可擴展的 WordPress 解決方案。

覺得網站效能還有提升空間，或是想為你的商業網站做一次全面的技術健檢嗎？歡迎點擊這裡，填寫表單與我們聯繫，讓我們的專業團隊為你量身打造最佳解決方案！

延伸閱讀

• 網站心臟手術：Apache vs. LiteSpeed 終極對決，你的 WordPress 該換哪顆引擎？
• 網站慢到捶心肝？別再只會裝快取外掛！資深工程師揭秘 WordPress 效能雙核心：Page Cache vs. Object Cache 終極對決
• Cloudflare 不是裝了就好！資深工程師的 WordPress 終極調校聖經：從快取、防火牆到 APO 設定全攻略