Cloudflare Smart Tiered Cache 認得雲端原站：加一個「區域提示」，快取命中率更高、原站更輕鬆

一句話看懂：如果你的網站原站放在 AWS、GCP、Azure 或 Oracle Cloud，現在可以告訴 Cloudflare 它在哪個區域，快取命中率就會更高、打到原站的請求更少。

先用白話講：分層快取是什麼？

想像一間連鎖早餐店有很多分店，都要跟同一間中央廚房訂貨。如果每間分店遇到沒貨，都各自打電話給中央廚房，廚房電話就會被打爆。

比較聰明的做法是：先指定一間「區域總店」，沒貨的分店都先跟它訂，由它統一向中央廚房叫貨。這就是分層快取（Tiered Cache）：Cloudflare 全球有很多節點，沒命中快取時，先找一個「上層節點」，再由它去問你的原站。

發生什麼事

Cloudflare 在 4 月 17 日公告，Smart Tiered Cache 現在能更好地支援放在公有雲上的原站。

• 以前：官方說，AWS、GCP、Azure、Oracle Cloud 這類雲端常使用 anycast 或區域單播網路，Smart Tiered Cache 沒辦法穩定選出最佳的上層節點，只好退回多個上層節點的做法，結果是命中率較低、更多請求打到原站。
• 現在：替原站設定「雲端區域提示」，Cloudflare 會結合提示與即時延遲資料，挑一個離你雲端區域近的主要上層節點，再加一個不同地點的備援，讓所有沒命中的請求集中從一個靠近原站的位置送出。

怎麼設定？

1. 啟用 Smart Tiered Cache。
2. 替原站 IP 或主機名稱設定雲端區域提示，例如 aws/us-east-1 或 gcp/europe-west1。
3. 設定位置：儀表板的 Caching > Tiered Cache > Origin Configuration，也可以用 API 或 Terraform。

給開發者的技術細節

• 支援的服務商：AWS、GCP、Azure、Oracle Cloud。
• 適用方案：Free、Pro、Business、Enterprise，不另外收費。
• 主要上層節點會依提示與即時延遲選出，另有一個不同地點的備援，提高穩定性。
• 公告沒有提供命中率提升的具體數字，實際效果要看你自己的流量，建議設定前後各觀察一段時間。

我的看法

我接過的網站案子，大多是把前端放在 Cloudflare 後面、原站放在某家雲的小主機上。原站規格不大，一旦快取沒命中的請求變多，網站就會變慢，甚至被流量打到。這個功能對這種架構特別有感：補一個欄位，就可能讓原站輕鬆一些。

不過要提醒自己：官方沒有給具體的提升數字，所以我會先在一個流量中等的網站打開，看快取命中率與原站負載的變化，再決定要不要全面套用。另外，區域提示要填對，填錯反而可能選到離原站比較遠的上層節點。

名詞小辭典

• 原站（Origin）：真正存放網站內容的主機，CDN 沒有快取時會回頭向它拿資料。
• 快取命中（HIT）/ 未命中（MISS）：命中表示 CDN 手上就有內容直接回應；未命中則要回原站拿。
• Anycast：同一個 IP 位址由多個地點同時對外服務，使用者會連到最近的一個。
• Terraform：用程式碼描述並自動建立雲端設定的工具。

資料來源

• Cloudflare Changelog：Smart Tiered Cache optimizes public cloud origins（2026-04-17）