優化 Cloudflare CDN 快取策略以提升速度

配置一套穩健的 Cloudflare CDN 快取策略，是 2026 年為企業級網站進行速度最佳化時影響最大的工程任務之一。許多 Web 平台之所以延遲很高，是因為每一個使用者請求都必須存取源站資料庫伺服器才能算繪頁面。這種對源站的依賴會拖慢 First Contentful Paint（FCP）和 Largest Contentful Paint（LCP）等速度指標，而將靜態頁面版面與資源元件儲存在全球各地的邊緣節點，則能從最近的邊緣節點提供快速、低延遲的回應。本指南將詳細拆解快取機制、Edge Cache TTL 規則以及動態 cookie 略過配置。

[!TIP] 快取最佳化提示： 避免快取包含已登入使用者資訊的 HTML 頁面。請始終配置 Cache Rules，使其在請求標頭中偵測到特定工作階段 cookie（例如 WordPress cookie 或自訂認證權杖）時略過邊緣快取。

關鍵要點：

• Cloudflare CDN 快取減少了後端伺服器的資料庫查詢，從而降低託管成本。
• Cache Rules 允許開發者根據內容類型和目錄設定自訂 TTL 值。
• 部署 Cache Everything 規則需要配置工作階段 cookie 略過，以防止使用者資料外洩。
• 直接從邊緣節點提供靜態頁面有助於網站在行動裝置上通過 Core Web Vitals。

快取配置：Page Rules 與 Cache Rules

要充分發揮交付管線的效能，您必須選擇合適的儀表板控制模型。根據 Cloudflare Developer Docs 的快取指南，舊版的 Page Rules 正被模組化的 Cache Rules 取代。因此，開發者應實作以下配置：

在預設情況下，CDN 網路只快取媒體格式、樣式表和指令碼。因此，您必須配置三個核心資源選項：

• HTML 快取： 要實現即時頁面載入，您必須指示 CDN 快取 HTML 文件結構。因此，這會停止資料庫查詢。
• Cache-Control 標頭： 配置您的 Symfony 或 PHP 後端伺服器發送自訂的 s-maxage 指令，以指示邊緣伺服器儲存頁面的時長。此外，這還支援自訂 TTL 規則。
• Browser Cache TTL： 設定更短的瀏覽器快取生命週期（例如 4 小時），以確保您修改站台版面時使用者能收到更新。因此，這可以防止版面不匹配的問題。

對於互動式 Web 入口網站，您無法一概而論地快取所有頁面。因此，您必須建立兩條動態略過規則：

• 工作階段略過： 建構規則，指示 CDN 在請求帶有認證或工作階段 cookie 時略過快取，如此一來已登入使用者總是能收到個人化的回應，而匿名訪客仍由邊緣快取提供服務。
• 查詢字串排序： 配置邊緣資料庫快取，使其在評估快取鍵時忽略次要的分析變數（例如 UTM 標籤）。因此，這可以防止快取碎片化。

要安全地部署企業級邊緣快取策略，請完成這一技術驗證流程。採用以下四個最佳化步驟：

1. 稽核 HTTP 標頭： 驗證您的源站伺服器發送乾淨的 Cache-Control 和 Vary 標頭，且不帶認證阻斷。
2. 草擬模組化 Cache Rules： 配置目標 Cache Rules，將靜態分類目錄儲存長達 30 天。
3. 建構認證例外： 建立在偵測到登入 cookie 時略過邊緣快取的規則。
4. 部署 Purge API Webhook： 配置資料庫儲存操作，使其在您更新頁面時觸發自動化的 Purge API 請求。

效能比較：邊緣快取與源站擷取

為了說明速度上的收益，下表詳細列出了實際的載入指標：

前提條件

在您接觸儀表板之前，請確保已準備好以下內容：

• 一個已透過 Cloudflare 代理的網域（橙色雲朵 DNS 設定，而非灰色/僅 DNS）。
• 對您源站配置的存取權限——Nginx、Apache 或應用層——以便您可以設定回應標頭。
• 如果您打算自動化清除快取，需要一個範圍限定為 Zone → Cache Purge 的 API 權杖。在 My Profile → API Tokens 下建立它。
• 一種檢查原始 HTTP 標頭的方法：命令列上的 curl，或 Chrome DevTools 中的 Network 標籤。
• 一個 staging URL 或一條低流量路徑，以便在向全站推出任何內容之前進行試驗。

Free 或 Pro 方案足以完成下面的每一個步驟。Cache Rules 在所有方案上都可用，儘管少數快取鍵選項和 Tiered Cache 需要更高的方案等級。

步驟 1：從源站發送正確的 Cache-Control 標頭

只有當您的源站沒有主動禁止時，Cloudflare 才會將回應視為可快取。HTML 從不被快取的最常見原因，就是源站在每個請求上返回 Set-Cookie 標頭或一個限制性的 Cache-Control。

在源站設定明確的指令。在 Nginx 中：

1location ~* \.(css|js|woff2|jpg|png|webp|svg)$ {
2    add_header Cache-Control "public, max-age=31536000, immutable";
3}
4
5location / {
6    # HTML: short browser life, long shared (edge) life
7    add_header Cache-Control "public, max-age=0, s-maxage=86400";
8}

s-maxage 指令針對的是像 Cloudflare 邊緣這樣的共用快取，而 max-age=0 則讓訪客的瀏覽器持續重新驗證，從而使他們在一次部署後絕不會看到過期的 HTML。帶指紋的資源上的 immutable 權杖會告訴瀏覽器完全不必重新驗證它們。

對於由應用驅動的回應（PHP 或 Symfony），請在程式碼中表達相同的意圖：

1$response->setPublic();
2$response->setMaxAge(0);            // browser
3$response->setSharedMaxAge(86400);  // edge / s-maxage

經過認證或個人化的回應必須明確地選擇退出，否則一條過於寬泛的規則可能會把一個使用者的頁面提供給另一個使用者：

1Cache-Control: private, no-store

步驟 2：用 Cache Rule 使 HTML 可被快取

在預設情況下，Cloudflare 將 HTML 標記為 DYNAMIC 並且從不儲存它。要改變這一點，請在 Caching → Cache Rules → Create rule 下建立一條規則。

編寫一個運算式，匹配您想要快取的頁面，同時排除任何動態內容：

1(http.host eq "example.com"
2  and not starts_with(http.request.uri.path, "/wp-admin")
3  and not starts_with(http.request.uri.path, "/cart")
4  and not starts_with(http.request.uri.path, "/checkout")
5  and not starts_with(http.request.uri.path, "/my-account"))

然後設定規則動作：

• Cache eligibility： Eligible for cache——舊版「Cache Everything」行為的現代等價物。
• Edge TTL： Use cache-control header if present，以便您在步驟 1 中設定的 s-maxage 生效；如果該標頭缺失，則回退到一個固定值，例如 1 天。
• Browser TTL： Respect origin。

步驟 3：新增 Cookie 略過，使已登入使用者永遠不被快取

這是大多數指南跳過的步驟，也是它們跳過時會外洩資料的步驟。新增第二條規則，放在資格規則之上，使其在存在真正的工作階段 cookie 時強制略過。Cloudflare 自上而下評估 Cache Rules，因此對於已認證的訪客，較早的略過規則總是勝出。

1http.cookie contains "wordpress_logged_in_"
2or http.cookie contains "wp-postpass_"
3or http.cookie contains "woocommerce_items_in_cart"
4or http.cookie contains "comment_author_"

將動作設定為 Bypass cache。對於非 WordPress 技術堆疊，請將 cookie 名稱替換為您框架的工作階段識別碼——PHPSESSID、laravel_session、connect.sid 等等。請嚴格限定其範圍：在這裡匹配像 _ga 這樣寬泛的分析 cookie，會意外地為每一位匿名訪客也略過快取。

步驟 4：正規化快取鍵

僅因一個追蹤參數而不同的兩個 URL 應當共用同一個快取物件。在資格規則內，開啟 Cache Key → Query String，選擇 Ignore specific query string parameters，並列出分析鍵：

1utm_source, utm_medium, utm_campaign, utm_term, utm_content, fbclid, gclid

這會將 /pricing?utm_source=newsletter 和 /pricing?gclid=123 合併到單一的快取項目上，從而提升您的命中率，而不是將其碎片化到數千個幾乎重複的鍵上。

如何驗證快取 HIT 或 MISS

永遠不要假設一條規則有效——要去測量它。Cloudflare 提供的每個回應都帶有一個 cf-cache-status 標頭。請求同一個 URL 兩次，觀察它的變化：

1curl -sI https://example.com/ | grep -i cf-cache-status
2# First request:  cf-cache-status: MISS
3# Second request: cf-cache-status: HIT

您會遇到的值以及各自的含義：

如果您始終只看到 DYNAMIC，說明資格規則未被觸發。請確認運算式中的主機名稱，然後檢查源站沒有在 HTML 文件上發送 Cache-Control: private 或 Set-Cookie。

常見陷阱與疑難排解

• 每個回應上的 Set-Cookie。 Cloudflare 不會快取設定了 cookie 的回應。分析外掛、CSRF 權杖和 A/B 測試工具經常會給 HTML 文件附加一個。請將該邏輯移到非同步請求中，或在可快取路徑上剝離該標頭。
• 匿名訪客上的 BYPASS。 幾乎總是由於 cookie 略過規則過於寬泛——一個像 _ga 這樣的通用 cookie 匹配了您的運算式。請將略過限制為僅針對真正的工作階段 cookie。
• 部署後的過期頁面。 Edge TTL 正在履行其職責；您只是忘記了清除快取。請在發布時觸發一次有針對性的清除，而不是把 TTL 縮短到幾秒鐘。
• Vary 標頭被忽略。 Cloudflare 只按 Accept-Encoding 來變化其快取；它不會為任意的 Vary: User-Agent 或 Vary: Cookie 保留單獨的副本。請透過響應式 CSS 或一個 Worker 來提供針對裝置的標記，而不是依賴 Vary。
• Development Mode 一直開著。 它會略過快取三個小時，並悄悄地使每個回應看起來不可快取。在測試之前請確認它已關閉。

生產環境考量與自動化清除

一旦單條路徑表現正確，就在低流量時段將規則擴展到整個站台，並在 Caching → Overview 中觀察您的命中率——一個健康的靜態站台會穩穩地保持在 90% 以上。

將您的 CMS 接通，使其只清除發生變化的內容，而非整個 zone。按 URL 進行的有針對性清除能讓相鄰頁面在快取中保持溫熱：

1curl -X POST \
2  "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/purge_cache" \
3  -H "Authorization: Bearer ${CF_API_TOKEN}" \
4  -H "Content-Type: application/json" \
5  --data '{"files":["https://example.com/pricing"]}'

從您的發布掛鉤中呼叫它，這樣編輯者的更新會在幾秒鐘內上線，而其他一切都保持快取。對於大型目錄，將相關的 URL 歸入一個 Cache Tag（Enterprise）之下，或按前綴清除，並啟用 Tiered Cache，透過在未命中到達您的源站之前將其路由經過一個區域父節點，來提升全域命中率。

與一家經過審核的英國 Cloudflare 顧問公司合作

正確地做出這些快取決策可以保護您的源站伺服器，並為每一位訪客加速頁面交付。Mecanik 提供專業的技術 SEO 稽核 服務，並透過我們的網站開發 頁面提供基礎設施擴展。我們專注於 Symfony 邊緣整合、自訂 Cloudflare Cache Rules 以及邊緣原生部署。今天就聯絡我們，安排您的技術範圍界定工作坊。

常見問題（FAQ）

什麼是 cloudflare cdn 快取？ Cloudflare cdn 快取是將您網站的頁面、圖像和指令碼檔案的靜態副本儲存在遍布世界各地的邊緣伺服器上的過程。這種配置允許使用者請求由最近的實體伺服器來提供，從而減少網站的載入時間。

如何在不外洩使用者資料的情況下快取 HTML 頁面？ 要安全地快取 HTML，請配置一條帶有「Bypass Cache」動作的 Cache Rule，使其在請求標頭中存在工作階段或管理員 cookie 時觸發。這一設定可確保已登入的入口網站使用者始終從源站資料庫擷取動態內容。

Edge TTL 和 Browser TTL 有什麼區別？ Edge TTL（Time-To-Live）規定 Cloudflare CDN 伺服器在向您的源站伺服器請求新副本之前，將您的內容儲存多長時間。相反，Browser TTL 決定訪客的本機瀏覽器快取保留檔案的時長。

為什麼查詢字串快取會影響網站效能？ 如果查詢字串（例如 UTM 追蹤標籤）未被正規化，CDN 會將每個變體視為唯一的 URL，從而向您的源站伺服器產生重複請求。配置快取鍵正規化可以防止這種爬取重複。

邊緣快取能改善我的 Core Web Vitals 分數嗎？ 可以，直接從邊緣伺服器提供您的 HTML 和媒體資源，能夠最小化 Time-to-First-Byte（TTFB）和 Largest Contentful Paint（LCP）的時間。因此，這一快取策略直接改善您的行動端頁面速度排名。