你打開 Cloudways 後台，清了 Varnish、清了 Breeze、清了 Redis……然後想起來還有 Cloudflare。全部清完，客戶終於看到更新後的內容了。但你心裡知道，這種「亂槍打鳥」的清法遲早會出問題——而且每次都要清全部，等於讓快取的加速效果白費了。
上一篇我們聊了快取的基本觀念和行銷自己能做的排查步驟。這一篇就來把每一層的設定搞定。
為什麼值得花時間配？上一篇提過，Deloitte 和 Google 的聯合研究顯示，網站載入速度每快 0.1 秒，轉換率就提升 8-10%。Cloudflare APO 實測更是讓 TTFB 降低 72%。正確配置五層快取之後，不只是網站變快——行銷發文後快取會自動更新，你每週也能少花幾個小時在「幫我清一下快取」的救火上。
這篇會幫你把 Cloudways + Cloudflare 架構下的五層快取搞清楚：每一層該怎麼配、什麼時候該清哪一層、以及出問題的時候怎麼快速定位。照著配一次，以後行銷來問「為什麼沒更新」，你 30 秒就能判斷問題在哪。
🏗️ 先搞清楚：你的快取堆疊長怎樣
一個跑在 Cloudways + Cloudflare 上的 WordPress 網站，請求從使用者到資料庫會經過五層快取：
使用者 → 瀏覽器快取 → Cloudflare CDN → Varnish → Breeze 頁面快取 → WordPress（Redis）→ MySQL每一層攔截的東西不同，解決的問題也不同：
| 層級 | 快取什麼 | 解決什麼問題 | 清除方式 |
| 瀏覽器 | 靜態資源 + HTML | 減少不必要的網路請求 | 使用者自己操作 |
| Cloudflare CDN | 靜態資源 + HTML（APO） | 全球加速，離使用者最近的節點回應 | Cloudflare Dashboard |
| Varnish | 完整 HTML 頁面 | 攔截重複請求，減輕 PHP 負擔 | Breeze 後台 / Cloudways 後台 |
| Breeze 頁面快取 | 靜態化的 HTML 檔案 | 跳過 PHP 執行，直接回傳 HTML | WordPress 後台 Breeze 選單 |
| Redis | 資料庫查詢結果、WordPress 物件 | 減少資料庫查詢次數 | WP-CLI / 後台 |
重點觀念：越外層的快取，命中時越快、但離資料越遠。 Cloudflare CDN 命中的話，請求根本不會到你的主機；Varnish 命中的話，PHP 完全不用跑。所以配置的邏輯是：讓大多數請求在外層就被攔截，只有真正需要即時資料的請求才進到內層。
⚙️ 逐層配置建議
瀏覽器快取：Cache-Control header
Breeze 已經內建瀏覽器快取的設定，通常不需要另外處理。但如果你想微調，核心邏輯是這樣：
- 靜態資源（JS、CSS、字體、圖片）：`public, max-age=31536000`——快取一整年。WordPress 預設會在 CSS/JS URL 後面加 `?ver=` 參數，檔案更新時 URL 會變，所以不怕拿到舊版。如果你的靜態資源是用 content hash 命名（如 `style.abc123.css`），可以再加上 `immutable` 省掉瀏覽器的重新驗證請求
- HTML 頁面：`public, max-age=3600`——快取 1 小時，保留合理的更新窗口
- 登入 / 個人化頁面：`private, no-store`——絕對不能快取，否則會出大事
一個常見的誤解（其實很多工程師也搞混）：`no-cache` 不等於「不快取」。它的意思是「可以存，但每次用之前要問伺服器確認還能不能用」。真正要完全禁止快取，要用 `no-store`。
Cloudflare CDN + APO
Cloudflare CDN 負責全球加速，而 APO（Automatic Platform Optimization）則是把動態 HTML 也推到邊緣節點快取，效果在前一篇提過——TTFB 降低 72%。設定上只需要安裝 Cloudflare WordPress 外掛並啟用 APO，SSL 模式建議設為 Full (Strict)，然後不要另外設 Cache Rules 去覆蓋 APO 的邏輯就好。
APO 啟用後，行銷在 WordPress 後台發布新文章，Cloudflare 那端的快取約 30 秒內會自動更新，登入使用者也會自動 bypass，不需要手動清。但如果你的網站有涉及個人資料的頁面（會員資訊、表單確認頁等），要確保這些頁面有被正確排除在快取之外。
Varnish（Cloudways 內建）
Varnish 是 Cloudways 伺服器前面的反向代理。當 Cloudflare 的快取過期或 miss，請求會到 Varnish 這層。如果 Varnish 有快取，就直接回應，PHP 完全不用跑。
Breeze 預設整合了 Varnish，在 WordPress 後台就能管理。自動 bypass 的條件包括：登入使用者、`wp-admin` 路徑、POST 請求。這些你不用另外設定，裝好 Breeze 就有囉。
要注意的是：如果同時啟用了 APO，Varnish 主要服務的是「origin 到 CDN」這段，也就是 Cloudflare 來拉新內容時會打到 Varnish。對一般訪客來說，大部分請求已經在 Cloudflare 那層就被攔截了。
Redis（Object Cache）
Redis 快取的不是 HTML 頁面，而是資料庫查詢的結果。WordPress 每載入一個頁面，背後可能跑幾十到幾百個資料庫查詢。Redis 把這些查詢結果存在記憶體裡，下次要同樣的資料直接從記憶體拿，不用再問 MySQL。
為什麼選 Redis 不選 Memcached？兩者效能在 WordPress 場景下幾乎一樣（都能達到 100,000+ 次操作/秒），但 Redis 有兩個關鍵優勢：支援資料持久化（啟用後伺服器重啟快取不會遺失），以及支援更豐富的資料結構。Cloudways 現在預設也是用 Redis。
啟用方式：Cloudways 後台 → Server Management → Manage Services → 確認 Redis 已啟用。WordPress 端則是透過 Object Cache Pro（Cloudways 在 2GB RAM 以上方案免費提供）或 Breeze 內建的 Object Cache 功能來串接。啟用後到 WordPress 後台確認 Redis 狀態是 Connected，命中率維持在 90% 以上就是健康的。
Breeze 頁面快取 + 前端優化
Breeze 是 Cloudways 自家開發的 WordPress 快取外掛，在這個架構裡扮演兩個角色：頁面快取和前端資源優化。
頁面快取的部分很直覺——Breeze 會把 PHP 動態產生的 HTML 存成靜態檔案，下次有人來訪問同一個頁面，直接回傳靜態檔，PHP 完全不用跑。到 WordPress 後台 → Breeze → Basic Options，確認「Purge Cache」相關選項有開啟就好啊。
但真正容易踩坑的是前端優化這一塊。Breeze 的 File Optimization 功能可以壓縮（Minify）和合併 JS、CSS 檔案，理論上能減少 HTTP 請求數和檔案大小。但實務上，開了壓縮之後頁面跑版或功能壞掉是非常常見的事。
為什麼會壞？因為 JS 壓縮會移除空白和換行，某些寫法不嚴謹的 JavaScript（少了分號、變數命名衝突）在壓縮後會出錯。CSS 合併則可能改變載入順序，導致樣式覆蓋的優先序跟原本不同。
我們的建議：
- CSS Minify：可以開，出問題的機率較低
- JS Minify：先在測試環境開，確認沒壞再上正式站
- JS/CSS 合併（Combine）：除非你很確定每個外掛的 JS 都寫得夠乾淨，否則建議不要開
- 出問題的排查法：先全關，然後一個一個開，開到哪個壞了就知道是哪個的問題
Breeze 還有一個「Delay JS」功能，可以延遲載入非關鍵的 JavaScript。這對 PageSpeed 分數有幫助，但如果網站有用到第三方追蹤碼（GA4、Meta Pixel）或即時聊天外掛，延遲載入可能導致這些功能不正常，要特別注意排除清單。
🛒 WooCommerce 的快取地雷
如果你的網站有跑 WooCommerce，快取設定要特別小心。購物車、結帳、帳戶頁面是動態的，絕對不能被快取，否則客戶 A 可能看到客戶 B 的購物車。
必須排除的頁面和 URL：
- `/cart`、`/checkout`、`/my-account/*`
- URL 參數：`?add-to-cart=`、`?wc-api=`
WooCommerce 自 1.4.2 版起會在這些頁面設定 `DONOTCACHEPAGE` 常數，Breeze 和大多數快取外掛都會偵測這個常數並自動 bypass。但你要確認 Breeze 的排除清單裡確實有這些路徑。
Varnish 端也有對應的邏輯：正確配置的 Varnish 會偵測 WooCommerce 的 session cookie 並自動 bypass——需要排除的 cookie 包括 `woocommerce_items_in_cart`、`woocommerce_cart_hash`、以及 `wp_woocommerce_session_*`。但如果你用了自訂結帳流程（像 CartFlows 或 FunnelKit），這些自訂頁面不會被自動排除，你得手動加進 Breeze 和 Varnish 的排除清單。
🔍 出問題了？用這個 SOP 快速定位
行銷說「沒更新」的時候，別急著全部清一輪。打開 Chrome DevTools（F12）→ Network 分頁 → 重新整理頁面 → 點第一個 HTML 文件請求（不是 CSS 或圖片，因為靜態資源和 HTML 的快取策略不同）看 Response Headers。兩個 header 就能告訴你問題在哪一層：
`cf-cache-status`（Cloudflare 那層，常見值）：
- `HIT` = Cloudflare 有快取，內容從邊緣節點回來
- `MISS` = Cloudflare 沒快取，去 origin 拉了新的
- `EXPIRED` = 快取已過期，Cloudflare 重新向 origin 拉了最新版
- `REVALIDATED` = 快取過期後問了 origin，origin 說內容沒變（304），繼續用舊快取
- `BYPASS` = 這個請求被設定為不快取（登入使用者、排除規則等）
- `DYNAMIC` = Cloudflare 認為這是動態內容，不快取
`x-cache`（Varnish 那層）：
- `HIT` = Varnish 有快取
- `MISS` = Varnish 沒快取，交給 PHP 處理
常見狀況對照表：
| 症狀 | cf-cache-status | x-cache | 問題在哪 | 解法 |
| 只有自己看到舊的 | — | — | 瀏覽器快取 | Ctrl+Shift+R |
| 無痕也是舊的 | HIT | — | Cloudflare CDN | 清 Cloudflare 快取 |
| cf 是 MISS 但還是舊的 | MISS | HIT | Varnish | 清 Breeze / Varnish |
| 兩個都 MISS 但還是舊的 | MISS | MISS | Redis 或頁面快取 | 清 Redis + Breeze 頁面快取 |
| 登入後看到別人的內容 | HIT 或 MISS | HIT | bypass 規則錯誤 | 立即停用頁面快取，檢查設定 |
最後一種狀況是最嚴重的——如果登入使用者看到了別人的頁面內容，代表 Varnish 或 Cloudflare 的 bypass 規則沒正確排除登入狀態。這時候要先停用快取止血，再回頭檢查設定。
✅ 上線前快取配置 Checklist
每次上新站或調整快取設定後，跑一次這張清單：
Cloudflare
- APO 已啟用
- SSL 模式設為 Full (Strict)（強烈建議）
- 沒有 Cache Rules 覆蓋 APO 邏輯
- Cloudflare WordPress 外掛已安裝且連線正常
Cloudways
- Varnish 已啟用
- Redis 已啟用，WordPress 端顯示 Connected
- PHP 版本為 8.x
Breeze
- 頁面快取已啟用
- Varnish 整合已啟用
- CSS Minify 已測試確認無樣式異常後開啟，JS Minify 已在測試環境確認無問題
- 排除清單包含 `/cart`、`/checkout`、`/my-account/*`（如有 WooCommerce）
- 自訂結帳頁面已加入排除清單（如有）
- Delay JS 排除清單已加入追蹤碼和即時聊天外掛（如有）
🎯 配好一次，省下每週的救火時間
快取不難配，難的是知道有幾層、每一層的眉角在哪。把這張 checklist 存起來，下次上新站直接照著跑。配好之後，大多數的「更新沒變」問題會自動消失——因為 APO 和 Breeze 都會在 WordPress 發布內容時自動清除對應的快取（大約 30 秒內生效）。
對行銷來說，最大的改變是：以後發文不用再找你清快取了。對你來說，最大的改變是：每週少花幾個小時救火，真的遇到問題也能 30 秒定位到是哪一層。
但如果你不想自己折騰這些設定，或是不確定目前的配置是不是最佳狀態——CTK Pro 可以幫你做一次完整的快取架構健檢。我們會逐層檢查你的 Cloudflare、Varnish、Breeze、Redis 設定，產出一份具體的優化建議報告。有需要的話，歡迎直接聯絡我們聊聊。
- Cloudflare APO for WordPress – Cloudflare Blog, 2020（APO 技術原理與 505 個網站效能測試）
- Cloudflare APO 官方文件 – Cloudflare Developers（APO 設定指南）
- How to Use Breeze Varnish Settings – Cloudways Help Center（Breeze + Varnish 整合設定）
- Memcached vs Redis – Kinsta, 2025（Redis 與 Memcached 架構差異與效能比較）
- Breeze WordPress Cache Plugin – Cloudways（Breeze 功能說明與 Varnish 整合）
- Configuring Caching Plugins for WooCommerce – WooCommerce Developer Docs（動態頁面排除規則）
- HTTP Caching – Jono Alderson（Cache-Control header 深度解析）
- Cache-Control – MDN Web Docs（HTTP 快取標頭完整參考）
註：所有數據與引述均截至 2026 年 3 月
