Skip to content
所有文章 ‹ Part 14 of 18 · Cache 不是方塊,是一條鏈
工程 · 2 min read

Bypass header 只在有規則的地方有效

X-Cache-Bypass 不是 HTTP 標準。只有寫了規則去讀它的 cache 才會讓路,而 proxy 路線上的 LB cache 根本沒有這條規則。

X-Cache-Bypass 不是 HTTP 標準。只有寫了規則去讀它的 cache,才會讓路。

上一篇的數字指向路線(症狀:HTML、CSS、JS 一直跑回 origin)。我回頭看兩條路線上的 LB cache,發現它們的規則不一樣。

BUCKET 路線(圖片、影片)PROXY 路線(html、css、素材 JS) AkamaiAkamai LB cache有規則:「有 header?不用我的副本」 LB cache沒有規則,根本不讀 header:「我有副本(age: 77),給你」 bucket 回真正的檔案 直接回給 Akamaiproxybucketproxy 和 bucket 都沒收到 request
兩條路線帶的是同一個 bypass header,但只有 bucket 路線的 LB cache 有規則去讀它。
bucket 後端的 LB cache(有 bypass 規則):
  If request.header has X-Cache-Bypass → 直接去 storage 拿
  else → 有副本就回副本,沒有才去 storage 拿

proxy 後端的 LB cache(沒有 bypass 規則):
  不看 header → 有副本就回副本,沒有才去 proxy 拿

我怎麼證實

  • 我帶著 X-Cache-Bypass: yes 直接打 load balancer。
  • Proxy 路線回 age: 77,表示它用了自己存的副本。
  • Bucket 路線回 x-cache: uncacheable,表示它沒用副本。

我讀設定檔時,以為 bypass 對每個 request 都有效(兩層 cache:我原本以為的樣子)。實際上它只對 bucket 路線有效。圖片有 97.9% 的 request 不離開 edge,因為圖片實際上只有一層 cache。

Header 不會自己生效。生效的是讀它的那條規則。

延伸閱讀:Load balancer:一個入口,依規則分給很多後端、Cache header:誰設定,誰讀取、兩層 cache:我原本以為的樣子、症狀:HTML、CSS、JS 一直跑回 origin、Stale-while-revalidate:先回舊檔,背景再刷新。或回到系列總覽。

↑↓ 移動 ↵ 開啟 esc 關閉