架一個 WordPress 站，遲早會在後台或主機商的設定頁看到「Web 伺服器：Apache」或「Web 伺服器：Nginx」這一行，然後開始猶豫：兩個到底差在哪？換一個網站會不會比較快？我自己用得到的 .htaccess 又該怎麼辦？

這篇做的就是 Nginx Apache 比較，但不是丟一堆 benchmark 數字就結束。重點放在跑 WordPress 這個具體情境上：兩者的底層架構怎麼影響你的網站速度、設定難度差在哪、以及那個讓很多人卡住的 .htaccess 問題在 Nginx 上要怎麼處理。看完你會知道自己這個站該選哪一邊，還是其實根本不需要選。

Apache 與 Nginx 在 WordPress 世界各自扮演什麼角色

簡單說，Apache 是「老大哥」，Nginx 是「為了解決 Apache 速度瓶頸而生」的後進者。兩者都是把使用者瀏覽器的請求接下來、找出對應檔案、再回傳網頁的 Web 伺服器，差別在於它們處理請求的方式不同。

Apache（正式名稱 Apache HTTP Server）在 1995 年釋出，由 Robert McCool 開發，之後交給 Apache 軟體基金會維護。它長年是市佔第一的 Web 伺服器，幾乎所有主流 Linux 發行版（CentOS、Ubuntu 等）都預裝它，shared hosting 與 cPanel 環境也大多以它為基礎。對 WordPress 來說，Apache 最大的價值是它原生吃 .htaccess，外掛要改寫網址規則、設快取、做轉址，丟一份 .htaccess 進去就生效，不用碰主設定檔。

Nginx（唸作 engine-x）2004 年由俄羅斯開發者 Igor Sysoev 公開釋出，當初是為了解決所謂的 C10k 問題，也就是單台伺服器要同時撐住一萬條以上連線時的效能瓶頸。它一開始多半擺在 Apache 前面當反向代理與靜態檔伺服器，後來因為架構更省資源，越來越多網站乾脆整套換成 Nginx。WordPress.com 背後的 Automattic 早在 2008 年就把負載平衡器全換成 Nginx，後續整個伺服器堆疊也轉向它。

值得注意的是，這兩者並非二選一的死對頭。很多正式環境是 Nginx 擺前面處理連線、SSL 與靜態檔，後面接 Apache 跑動態內容，各取所長。所以與其問「誰比較好」，不如先搞懂它們的差異會落在你網站的哪個環節。

Nginx 與 Apache 處理請求的架構差在哪

這是整個 Nginx Apache 比較裡最根本的一點，後面的速度、記憶體、並發能力全都從這裡長出來。Apache 用的是程序／執行緒導向，Nginx 用的是事件驅動的非阻塞模型。

Apache 透過 MPM（Multi-Processing Module，多重處理模組）決定怎麼接請求。最老的 prefork 模式每來一條連線就開一個新程序，搭配 mod_php 時，等於每個程序都內嵌一份 PHP 直譯器，連回傳一張 CSS 或圖片都要扛著整套 PHP，相當吃資源。後來的 worker 與 event 兩種 MPM 改用執行緒，緩解了不少問題，但本質上仍是「一條連線對應一個程序或執行緒」。流量一上來，光是不斷建立與銷毀程序就會把成本墊高。

Nginx 走的是另一條路。它通常一個 CPU 核心配一個 worker 程序，而每個 worker 靠一個事件迴圈，就能用非阻塞方式同時照看成千上萬條連線，概念上類似 Node.js 的運作方式。連線不用各自綁一個程序，所以在高並發下，記憶體用量與穩定度明顯佔上風。Cloudflare、Netflix 這類對流量極度敏感的服務會重用 Nginx，原因正在這裡。

底下用一個簡化的對照，把兩種模型放在一起看會更清楚：

對一般中小型 WordPress 站來說，這個架構差異在低流量時感受不大；真正拉開距離是在大量並發、或同一頁面要載入大量靜態檔的時候。

Nginx 跑 WordPress 真的比較快嗎

直接回答：在靜態檔與高並發場景下，Nginx 通常明顯較快；但若只看 PHP 動態內容，且兩邊都調校得當，差距會縮小到沒有想像中那麼戲劇化。

靜態檔（圖片、CSS、JS）是 Nginx 的主場。多項測試顯示，Nginx 處理靜態檔的每秒請求數可以達到 Apache 的近兩倍。一個 WordPress 頁面往往要載入幾十個靜態資源，這個差距會直接反映在實際載入時間上。

動態內容就是另一回事。WordPress 的頁面要靠 PHP 跑完整套程式邏輯、查資料庫、組好 HTML 才回傳。這部分的速度瓶頸更多落在 PHP 處理方式與資料庫，而不是 Web 伺服器本身。當 Apache 改用 PHP-FPM（而非老式的 mod_php）後，兩者在純動態請求上的差距會收斂到一成出頭的等級。換句話說，把 Apache 從 mod_php 換成 event MPM 加 PHP-FPM，它在現代環境裡仍是有競爭力的選擇。

決定 WordPress 體感速度的，其實是這幾層疊加的結果：

• PHP 處理方式：mod_php 把 PHP 直譯器綁在 Apache 程序裡，連靜態檔請求都被牽連；PHP-FPM 則是獨立的程序池，Web 伺服器只把 PHP 請求轉過去，互不卡住。Nginx 天生只能走 PHP-FPM 這條路，Apache 則兩種都能選。
• 頁面快取：Nginx 內建 FastCGI 快取，能把整頁產好的 HTML 存起來，下次直接吐出，不必再跑一次 PHP。Apache 這邊的 mod_cache 較容易和其他模組打架，實務上常改搭 Varnish 之類的加速器。
• 靜態檔交付：高流量、媒體量大的站，Nginx 的事件模型在這層省下的資源最多。

所以「Nginx 比較快」這句話要加條件：對高流量、靜態檔多的站，差距真實存在；對流量平穩的一般部落格或企業形象站，把快取與 PHP-FPM 設好，兩者的實際差別你大概感覺不出來。

.htaccess 在 Nginx 上要怎麼辦

這是 WordPress 使用者從 Apache 轉到 Nginx 時最常卡住的點：Nginx 沒有 .htaccess，那我那些規則怎麼辦？答案是規則本身都能搬，只是搬的位置與方式不一樣。

.htaccess 是 Apache 獨有的「目錄層級設定檔」。它的好處是不用重啟伺服器、也不用碰主設定檔，在網站目錄樹的任何一層丟一份，就能改寫該層的轉址、URL 重寫、上傳大小上限、快取標頭、目錄密碼保護等規則。對 shared hosting 業者來說這是夢幻功能，因為同一台機器上幾百個使用者各自管自己的 .htaccess，互不干擾，也碰不到全域設定。WordPress 本身、各家外掛也預設靠 .htaccess 來寫固定網址（permalink）的重寫規則。

但這份彈性是有代價的。只要開啟 .htaccess，Apache 每收到一個請求，都得從被請求的檔案那一層往上，逐層走到網站根目錄，檢查每一層有沒有 .htaccess 並載入、重新設定自己。WordPress 的目錄結構又特別碎，wp-content/uploads、各佈景主題、幾十個外掛子目錄都會發出請求。有分析指出，一個常見的 WordPress 設定，單次頁面載入可能觸發 42 次 .htaccess 執行、249 次尋找 .htaccess 檔案的動作。這就是 Apache 在大量小檔請求下會慢下來的一個隱形成本。

Nginx 沒有對應的目錄層級設定檔，所有設定一律集中在伺服器層的設定檔，由管理者統一管理。它把「沒有 .htaccess」當成優點而非缺陷：少了逐層掃描，請求路徑更乾淨。代價則是少了那份「不必重啟、人人可改」的便利。

實務上要把 .htaccess 規則搬到 Nginx，做法是把規則翻譯成 Nginx 自己的語法寫進設定檔。最典型的就是 WordPress 固定網址那段：Apache 用 mod_rewrite 在 .htaccess 裡處理，Nginx 則改用一段 try_files 的設定達成同樣效果。多數受管理的 WordPress 主機（managed hosting）已經幫你把這段設好，你在後台改固定網址結構照樣會生效，根本不用手動碰設定檔。會踩到坑的，通常是自己架 VPS、又把 Apache 設定直接照搬到 Nginx 的情況——這時規則沒翻譯過去，固定網址或某些外掛功能就會壞掉。

Nginx 與 Apache 哪個設定起來比較簡單

設定難度沒有絕對答案，要看你站在哪個角色：用 shared hosting 的使用者，跟自己管 VPS 的管理者，感受完全相反。

如果你用的是 shared hosting 或 cPanel 環境，Apache 對你反而更省心。你不必碰伺服器主設定檔，外掛要做什麼改寫，丟 .htaccess 就生效，這也是為什麼入門與共享主機幾乎都站 Apache 這邊。對只想把站架起來、靠外掛搞定一切的人來說，這種「不必重啟、目錄就地改」的模式門檻最低。

但換到 VPS 或自管伺服器的層級，情況就反過來。Nginx 的設定全部集中在一處，結構清楚、好維護，記憶體又省，同一台機器能多塞幾個服務。Apache 的彈性這時反而變成負擔：模組多、設定分散、prefork 模式吃資源。要把 Nginx 加新模組確實比較麻煩（許多模組得在編譯期啟用），但日常營運的設定管理，集中式反而更輕鬆。

把這件事拆成你實際的角色，會更好判斷：

• 用共享主機或 cPanel：主機商通常已經幫你決定好用 Apache，你也幾乎不會去動伺服器設定，照用就好，.htaccess 對你是加分。
• 用受管理的 WordPress 主機：底層多半是 Nginx，但供應商已經把固定網址、快取、SSL 都調好，你在後台操作即可，等於享受 Nginx 的效能卻不用自己寫設定。
• 自己架 VPS：這才是你真的要選邊、也真的要寫設定的場景。追求高並發與省資源就上 Nginx，習慣 Apache 生態或大量依賴既有 .htaccess 規則就留 Apache，或乾脆 Nginx 在前、Apache 在後混用。

換句話說，多數一般使用者其實「沒得選」，也「不用選」——主機商已經幫你決定了底層伺服器，並把 WordPress 該調的地方調好。真正需要做這個決定的，是準備自己掌控整台主機的人。

該選 Nginx 還是 Apache，先看你掌控到哪一層

回到最初的猶豫：要不要為了速度換掉現在的 Web 伺服器？先確認你實際能掌控到哪一層，再決定要不要花力氣。

如果你在共享主機上、後台又跑得順，那這個 Nginx Apache 比較對你的意義主要是「看懂主機商在賣什麼」，而不是真要動手換——你能調的本來就不是這一層，把心力放在快取外掛、圖片最佳化與資料庫上，回報更直接。如果你用受管理的 WordPress 主機，底層大概率已經是 Nginx 配 PHP-FPM 與 FastCGI 快取，效能該有的都有了，同樣不必自己折騰。

真正要做選擇的是自管 VPS 的人。站的流量高、靜態資源多、又想用最少的記憶體撐最多連線，Nginx 是現代環境裡的合理預設；反過來，如果你熟悉 Apache 生態、或有一堆既有的 .htaccess 規則不想重寫，把 Apache 換上 event MPM 加 PHP-FPM、再把頁面快取設好，它在今天依然跑得動 WordPress。

下一步很單純：先打開瀏覽器開發者工具的 Network 面板、重新整理你的站，看 HTTP 回應標頭裡的 Server 欄位，確認自己現在到底跑在哪一個上面。知道起點，再對照上面三種角色，你就會清楚這個決定到底輪不輪得到你做、值不值得做。