把網站接上內容傳遞網路（CDN）這件事，Cloudflare 免費方案幾乎是台灣站長的預設選項。費用是零，設定介面是中文，只要把網域的 DNS 改指向 Cloudflare，理論上就算接好了。
問題是，「接好」和「真的有用」是兩件事。許多站長完成 DNS 遷移之後，實際量測首字節時間（TTFB）發現數字沒有顯著改善，原因多半出在三個地方：DNS 的代理狀態沒有啟用、快取規則的寫法讓後台也一起被快取、或 SSL 模式與主機設定不一致導致跳轉迴圈。本文就針對這三個痛點，把設定順序和判斷邏輯交代清楚。
文章範圍設定在 Cloudflare 免費方案搭配 WordPress，不涵蓋付費方案的進階功能，例如 Argo 智慧路由、Workers。設定截圖與邏輯以 2026 年的儀表板介面為準。
橘雲（代理）要開對位置，才算真正接上 CDN
Cloudflare 的 DNS 管理介面有一個常讓新手困惑的設計：每筆 DNS 紀錄右側有一個雲朵圖示，可以在橘色（代理）和灰色（僅 DNS）之間切換。這兩個狀態的差異遠比外觀重要。灰雲只是把 DNS 指向功能給你用，流量仍然直通主機；橘雲才是讓流量經過 Cloudflare 節點，CDN 快取、防火牆、SSL 終止，全部都要在橘雲啟用後才能生效。
WordPress 站台的最低要求，是讓根網域（@）和 www 子網域都設為橘雲代理。如果站台有獨立的靜態資源子網域（例如 static.example.com），同樣建議開橘雲，讓靜態檔案也走節點回應。
有幾類 DNS 紀錄應刻意維持灰雲狀態。收發信的 MX 紀錄本來就不需要走 HTTP 代理，設成橘雲也不會有效果，保持灰雲即可。另外，若主機商有提供 FTP 登入專用的 A 紀錄（例如 ftp.example.com），也應保持灰雲——FTP 協定不支援 Cloudflare 代理，強制開橘雲反而會讓連線中斷。
快取規則（Cache Rules）取代頁面規則後，這樣設才有效
Cloudflare 在 2024 年中起陸續停止讓新帳號建立頁面規則（Page Rules），2025 年 1 月起全面鎖定，現有帳號的舊規則暫時保留，但新建設定一律要改走儀表板左欄的「規則（Rules）」區段，展開後找「快取規則（Cache Rules）」。這個改動讓很多照舊教學操作的站長發現找不到入口，實際上只是換了位置，邏輯反而更靈活。
什麼都不設，Cloudflare 預設快取哪些東西
預設狀態下，Cloudflare 只快取靜態副檔名，例如圖片（JPG、PNG、WebP、SVG）、樣式表（CSS）、JavaScript 檔、字型檔等。HTML 文件，也就是 WordPress 產生的頁面本體，預設不快取，每次請求都會穿透到主機。對許多小型 WordPress 站來說，這代表 CDN 的加速效果只出現在靜態資源上，頁面載入本身不會有顯著改善。
要讓 HTML 也被快取，有兩條路徑。一是啟用 Cloudflare 官方外掛提供的「自動平台優化（APO, Automatic Platform Optimization）」，屬付費功能，每月 5 美元，可以讓整頁 HTML 快取在邊緣節點，更新文章後 30 秒內自動清除。二是手動建立快取規則，設定「快取資格（Eligible for Cache）」，自訂要快取的路徑條件，免費方案也可以使用。
手動快取規則的兩條必設邏輯
免費方案手動設定快取規則時，最常見的做法是建立兩條規則，順序很重要。Cloudflare 按規則優先序由上往下比對，第一條符合就套用，不再往下看。
第一條：後台與已登入狀態排除快取。 設定條件為「URI 路徑包含 /wp-admin/」或「Cookie 包含 wordpress_logged_in」，動作設為「繞過快取（Bypass Cache）」。這條規則確保後台操作和已登入的會員頁面不會被快取後錯誤回應給其他訪客——WooCommerce 購物車頁面尤其要注意，被快取之後可能讓不同使用者看到彼此的購物資訊。
第二條：前台頁面啟用快取。 條件設為全域（或指定根網域），動作設為「快取資格」，快取層級選「覆蓋-快取所有內容（Override – Cache Everything）」。這條規則讓 HTML 也進入快取，訪客的第二次請求就能從邊緣節點直接回應，不再打到主機。
兩條規則設定後，在清單裡確認「排除後台」那條排在「快取所有內容」前面，否則順序倒置，後台也會被快取。
快取外掛與 Cloudflare 快取層同時開，衝突點在哪裡
許多 WordPress 站台在接 Cloudflare 之前，本機端已經安裝了 WP Rocket、LiteSpeed Cache、W3 Total Cache 之類的快取外掛。這兩層快取並存時，流量的路徑是這樣的：訪客請求 → Cloudflare 邊緣節點 → 主機快取外掛 → 若未命中則 PHP 動態產生。Cloudflare 和快取外掛理論上分工不重疊，但有幾個配置組合會產生實際問題。
下表列出最常見的衝突場景與對應處理方式，適合在完成快取規則設定後逐項核對。
| 衝突場景 | 根本原因 | 處理方式 |
|---|---|---|
| 更新文章後舊版頁面繼續被回應 | Cloudflare 邊緣快取未清除，外掛只清了主機端快取 | 安裝 Cloudflare 官方外掛並啟用自動快取管理；更新後快取會同步清除 |
| 已登入管理員看到前台頁面版本異常 | 快取規則未排除 wordpress_logged_in Cookie |
在快取規則新增繞過條件，確認排除邏輯覆蓋所有已登入 Cookie 名稱 |
| WooCommerce 購物車顯示其他使用者資料 | 快取規則覆蓋了動態頁面路徑 | 在排除規則中加入購物車路徑（/cart/、/checkout/）；LiteSpeed Cache 或 WP Rocket 通常有專屬的「不快取」路徑清單 |
| 啟用 APO 後與 WP Rocket 快取衝突 | APO 已接管 HTML 快取，WP Rocket 的快取層重複處理 | 在 WP Rocket 設定關閉頁面快取（Page Cache），保留其他最佳化功能（JS 合併、延遲載入等） |
| 開發模式（Development Mode）關閉後問題複現 | 測試期間繞過了 Cloudflare 快取，關閉後恢復快取才顯現規則錯誤 | 在正式環境確認規則邏輯，不要把開發模式當常態解法 |
衝突排查的起點，通常是在瀏覽器開發者工具查看回應標頭（Response Headers），找 cf-cache-status 欄位。回傳 HIT 代表由邊緣快取回應，MISS 代表穿透到主機，BYPASS 代表快取被刻意繞過。確認這個值是否符合預期，通常可以直接定位問題在哪一層。
SSL 模式四選一，選錯會拖慢速度也會產生資安風險
Cloudflare 的 SSL/TLS 加密模式分為四個等級，設定位置在儀表板的「SSL/TLS」區段。選項影響的是 Cloudflare 邊緣節點與主機原始伺服器之間的連線方式，不影響訪客到 Cloudflare 這段，那段永遠是 HTTPS。
| SSL 模式 | 邊緣到主機連線 | 主機需要有效憑證 | 適用情境 |
|---|---|---|---|
| 關閉（Off） | HTTP 明文 | 否 | 不建議，訪客看到未加密警告 |
| 彈性（Flexible） | HTTP 明文 | 否 | 主機無 SSL 且短期過渡用；易產生重新導向迴圈 |
| 完整（Full） | HTTPS，但不驗證憑證 | 需要（可自簽） | 主機有自簽憑證時的暫時方案 |
| 完整（嚴格）（Full Strict） | HTTPS，且驗證憑證有效性 | 需要（需由 CA 簽發或使用 Cloudflare 原始憑證） | 正式站台的建議選項 |
對大多數台灣的主機方案來說，主控台都有提供免費的 Let’s Encrypt 憑證或 Cloudflare 原始伺服器憑證（Origin Certificate）可以一鍵安裝，安裝完成後直接選「完整（嚴格）」即可。
「彈性」模式是最容易造成問題的選項。訪客到 Cloudflare 這段是 HTTPS，Cloudflare 到主機這段是 HTTP。WordPress 在這個狀態下會同時偵測到 HTTP 和 HTTPS 兩種協定，部分外掛（特別是強制 HTTPS 的安全類外掛）會反覆觸發重新導向，頁面永遠在跳轉，無法載入。如果在設定完 Cloudflare 後遇到「重新導向次數過多」錯誤，絕大多數情況是 SSL 模式選了「彈性」所致。
速度方面，「完整（嚴格）」模式多了一次傳輸層安全性協定（TLS）握手驗證，但現代主機的憑證驗證耗時通常在毫秒等級，對整體載入速度的影響可以忽略。Cloudflare 啟用了 HTTP/3 和 TLS 1.3，這兩個協定讓握手來回次數減少，速度的淨效果是正的，而非負的。真正影響速度的是前面提到的快取命中率，SSL 模式本身反而不是瓶頸。
接好之後，用 cf-cache-status 標頭確認快取命中，再用 PageSpeed Insights 量一次修改前後的首字節時間，數字說話比直覺可靠。