Cloudflare 救援機制完整實戰：當 Next.js SSR 主機掛掉，訪客為什麼還能看到正常頁面

14 小時。 這是 2025 年 10 月 20 日，AWS 美東 us-east-1 區域因為 DynamoDB DNS race condition 引發的級聯故障，從第一個錯誤訊息冒出來、到最後一個服務恢復的總時長。Vercel 控制台、Build Pipeline、超過 400 萬使用者、1,000 多家科技公司，全部一起陪葬。

但事後 Vercel 官方部落格 寫了一段意味深長的話：「這段期間，使用者請求預生成的靜態頁面仍然能正常被服務。」翻譯：origin 死了，但 CDN 前面有快取的網站，訪客根本沒感覺。

你也想要這種「主機掛了訪客無感」的體驗？這篇講的就是怎麼用 Cloudflare 把它做出來。Always Online、stale-if-error、Cache Reserve，加上一份 Next.js 可以複製貼上的 Cache-Control header——拆完之後你會發現，市面上九成中文教學講的「Cloudflare 自動救你」其實是個美麗的誤會。

2025 年 10 月那 14 小時，靜態頁面為什麼活下來

故事是這樣開始的：那天早上 7:11 UTC，AWS 內部監控系統開始尖叫。一個再簡單不過的 DNS race condition，把 DynamoDB 的服務發現機制弄壞了。 ThousandEyes 的事後分析 顯示，這個錯誤像骨牌一樣推倒了 EC2、Lambda、NLB、ECS/EKS——也就是現代 SaaS 棧最仰賴的那幾根支柱。

IncidentHub 偵測到的數字很驚人：400 多家 SaaS 服務同步故障，其中 197 家事後直接承認源頭就是 AWS。Snapchat、Alexa、Coinbase 全部躺平。

這場災難對企業意味著什麼？ITIC 2024 Hourly Cost of Downtime Survey 統計：90% 以上的中大型企業每小時當機損失超過 30 萬美元，41% 的大企業介於 100 萬到 500 萬美元。14 小時換算下來，光是「沒辦法接訂單」這件事就足以讓財務報表流血。

但同樣 14 小時內，部份 Vercel 客戶的網站使用者「只是覺得後台 deploy 一直卡住」——前台流量繼續跑，購物車繼續轉。為什麼？因為這些網站的 HTML 早就被 CDN 快取了，訪客的 request 從未抵達已經爆炸的 us-east-1。

這是這整篇文章的核心洞見：origin 不應該是訪客的單點故障。 而 Cloudflare 提供了三層武器來實現這件事——只是大多數人連武器名稱都唸錯了。

如果你對「為什麼正式機會無預警掛掉」有興趣，可以順便讀一下我們之前寫的 Node.js V8 heap 高水位完整事故復盤——那是 Cloudflare 救不到的另一面：應用層自己的記憶體洩漏。CDN 救援機制是面對「origin 已經掛掉」的下游解，但根因仍然要回頭修。

Always Online 是個美麗的誤會：90% 的人沒讀完小字

先說結論：如果你以為 Cloudflare 後台「Always Online」開關打開，網站掛了就會自動 serve 快取，那你大概率會在事故當下發現它沒救你。我們直接拆 Cloudflare 官方文件 上的小字。

Always Online 到底是什麼

2022 年 7 月，Cloudflare 把 Always Online 整合進 Internet Archive（也就是 Wayback Machine）。當你的網站完全連不上時，Cloudflare 會直接用 IA 上的歸檔版本回應訪客。Free 方案每 30 天爬一次、Pro 方案每 15 天爬一次——這已經是第一個訊號：你看到的可能是兩三週前的內容。

致命限制：四個小字

讀完這段你會理解，為什麼 Cloudflare 社群充斥著「我網站掛了 Always Online 完全沒生效」的抱怨。

還有一個沒人講的副作用

Cloudflare Revalidation 文件 寫得很清楚：當 Always Online 啟用時，stale-while-revalidate 與 stale-if-error 兩個 directive 會被忽略。 也就是說，你以為自己有「兩道保險」（Always Online + stale-if-error），實際上開了第一道反而把第二道關掉了。這個設計取捨在官方文件裡很容易錯過。

結論：Always Online 是針對「origin 完全失聯」的最後手段，不是日常維運的主力。對 SSR 應用來說，真正能救你的是下一個機制。

Stale-If-Error 才是真保險絲：藏在 RFC 5861 裡的救援指令

Cloudflare 不是發明這個概念的人。早在 2010 年，IETF RFC 5861 就把兩個 Cache-Control directive 寫進 HTTP 規範：

• stale-while-revalidate=N：快取過期後，CDN 仍可繼續回舊版給訪客 N 秒，背景去 origin 抓新版。訪客體感是「永遠零延遲」。

• stale-if-error=N：origin 回錯誤（5xx）時，CDN 自動 fallback 到舊版快取，最長維持 N 秒。訪客體感是「網站根本沒掛」。

這兩個 directive 是最近 15 年所有 CDN 災難救援設計的基石。Vercel 自己也在 2024 年正式宣告 stale-if-error 對所有 response 生效，Cloudflare 在 2026 年 2 月把 stale-while-revalidate 改成全非同步運作——意思是第一個踩到過期內容的訪客也能直接拿到 cache，不必等背景 revalidation。

實戰場景：origin TTL 60 秒、stale-if-error 一週

最常見也最實用的配方長這樣（後面會給完整 header）：CDN 從 origin 抓到一份頁面後，60 秒內直接 serve cache；60 秒到 1 小時這段「過期但 fresh」期間用 stale-while-revalidate 邊送舊版邊更新；如果 origin 在這個過程中突然掛掉，stale-if-error 讓 CDN 繼續用最後那份快取頂著，最長一整週。

Stale-While-Revalidate 與 Cache Reserve：把過期快取變成資產

把 stale-if-error 想成「保險套」，stale-while-revalidate（簡稱 SWR）就是「省力套」。SWR 真正解決的是日常的「TTL 一到、第一個訪客倒楣等 origin 回應」這個小痛點，「網站掛了」那種極端情境反而是其次。

假設你的部落格文章 TTL 設 60 秒。沒開 SWR 的話，每 60 秒就有那「第一個踩到過期」的訪客要等 origin 重新生成頁面，可能多花 200ms 到 2 秒。開了 SWR 之後，那位訪客直接拿到舊版（毫秒級），origin 同步更新，下一位訪客就拿到新版。

Cloudflare 在 2026 年 2 月之前，SWR 是同步的——也就是訪客要等 revalidation 完成。改成 async 之後，整個體感跟 Vercel ISR 完全一樣，這是過去一年 Cloudflare 維運上最被低估的進步之一。

Cache Reserve：把 cache 變永久

Cloudflare 的標準 edge cache 會被定期淘汰——熱門頁面留得住，冷門頁面可能幾天就被清掉。如果你的網站是長尾型（部落格、商品頁、文件站），這個淘汰機制會讓 stale-if-error 的「最後快取」隨時間消失。

Cache Reserve 把 cache 移到 R2 物件儲存上，幾乎永久保留。意思是：origin 即使掛三天，stale-if-error 還是有東西可以拿。

Next.js SSR 預設救不回的三個原因

講到這裡你可能會想：「這些功能聽起來都不錯，那我直接把 Cloudflare 開上去就好了吧？」 不行。Next.js SSR 有三個預設行為，會讓上面講的所有救援機制全部失效。

原因一：SSR 預設 Cache-Control 是不快取的

Next.js 的 App Router 對純 SSR 路由（沒設 revalidate 也沒用 fetch cache) response 預設不帶 s-maxage。Cloudflare 看到後直接標記為 DYNAMIC，cf-cache-status 會回傳 DYNAMIC、根本不放進 cache。origin 一掛，CDN 沒東西可 serve。

這就是 Cloudflare 社群上「我的 Next.js 為什麼 cf-cache-status 永遠是 DYNAMIC」 這類問題反覆出現的原因。

原因二：Next.js 對 5xx 預設回 1 年的 cache

這個你一定要記住，因為它是反向陷阱。 Next.js 對 500 response 預設帶 Cache-Control: s-maxage=31536000, stale-while-revalidate——意思是「這個錯誤頁面快取一年」。

意思是：你 origin 出錯一次，那個 500 response 就被 Cloudflare 快取整整一年。後續訪客即使 origin 已經修好，依然會看到舊的錯誤頁。這個 vercel/next.js Discussion #49150 已經吵了快兩年，但截至 2026 年 5 月仍未官方修正。

原因三：ISR 與 Cloudflare cache 不同步

Next.js ISR 用 revalidatePath() / revalidateTag() 觸發更新時，只清自己內部的 cache，不會去打 Cloudflare。結果就是 Next.js 那層已經有新版，Cloudflare 邊緣節點還繼續 serve 舊版，HIT 率反而成了詛咒。

解法：每次 ISR 觸發時，呼叫 Cloudflare API 主動 purge 對應路徑。我們在 我們網站的維運實作 裡也踩過這個坑——文章發布後 Cloudflare 還停在舊版，需要 webhook 主動清快取。

Cache-Control 配方：複製貼上即可運作的 header

以下是針對 Next.js App Router 的實戰配方。都假設你用 Cloudflare 當 CDN，origin 是 Vercel / Zeabur / Railway 之類的 PaaS。如果你還在挑 PaaS，可以參考 Vercel、Railway、Render、Zeabur、Fly.io 五大 PaaS 平台完整比較。

配方 A：部落格文章頁（最常見）

// app/blog/[slug]/page.tsx
export async function generateMetadata({ params }) {
  return { /* meta */ }
}

export default async function Page({ params }) {
  const post = await getPost(params.slug)
  return 
}

// 關鍵：用 route segment config 設定 cache
export const revalidate = 60  // ISR 每 60 秒自動更新

// 額外用 middleware 或 response header 加上 SWR + SIE
// app/api/route-handler 範例：
export async function GET() {
  return new Response(html, {
    headers: {
      'Cache-Control':
        'public, s-maxage=60, ' +
        'stale-while-revalidate=3600, ' +
        'stale-if-error=604800'
    }
  })
}

這份配方的意義：

• s-maxage=60：CDN 快取 60 秒，TTL 短才能反映新內容

• stale-while-revalidate=3600：60 秒到 1 小時這段時間，邊送舊版邊更新

• stale-if-error=604800：origin 掛了，最多用一週前的快取頂著

• 瀏覽器 max-age 沒設 → 預設 0：避免訪客本地快取太久看不到最新版

配方 B：列表頁（首頁、分類頁）

// 列表頁更新比較頻繁，TTL 設短一點
export const revalidate = 30

// 對應的 Cache-Control：
// public, s-maxage=30, stale-while-revalidate=600, stale-if-error=86400
// 短 TTL + 一天的 stale-if-error 兜底

配方 C：API 路由與動態內容

// 完全個人化的 API（例如 /api/me）
export const dynamic = 'force-dynamic'
export const fetchCache = 'force-no-store'

// header：
// Cache-Control: private, no-store, must-revalidate
// CDN 完全不要 cache 這類路由

配方 D：5xx 錯誤頁面（必設！）

// app/error.tsx
export default function Error({ error }) {
  return (
    
      
        {/* 透過 Next.js metadata 或 middleware 強制覆寫 */}
      
      ...
    
  )
}

// 更可靠的做法：在 middleware 攔截 response status
// middleware.ts
export async function middleware(req) {
  const res = await fetch(req)
  if (res.status >= 500) {
    res.headers.set(
      'Cache-Control',
      'no-store, no-cache, must-revalidate, max-age=0'
    )
  }
  return res
}

Cloudflare Cache Rules 設定：哪些該快取、哪些絕對不能

有了 Cache-Control header 還不夠，Cloudflare 還有自己的 Cache Rules 引擎可以強制覆寫行為。Dashboard 路徑：你的網域 → Caching → Cache Rules。

規則 1：HTML 全面進 cache（克服 DYNAMIC 預設）

這條規則解決前面講的「Next.js SSR 預設不快取」問題。

規則 2：5xx 永不快取

這條救你免於「500 被快取一年」的災難。

Rule name: Never cache 5xx
Match: (http.response.code ge 500)  ← Cloudflare expression
Cache eligibility: Bypass cache
這條規則的優先順序要高過規則 1，否則沒用。

規則 3：登入後內容繞過 cache

有 Set-Cookie 或 Authorization header 的 response 永遠不要進 cache，否則會把使用者 A 的內容送給使用者 B。

Match:
  (http.cookie contains "session=") or
  (http.request.headers["authorization"][0] ne "")
Cache eligibility: Bypass cache

規則 4：開啟 Cache Reserve（如果需要）

Caching → Cache Reserve → Enable。一旦開啟，符合 cache 條件的 response 會自動 mirror 一份到 R2，等於免費獲得「一年級災難備援」。

怎麼知道你的救援機制有效？人為製造一次 origin 掛掉

設好 Cache Rules、改好 Cache-Control header 之後，最危險的事是「以為設好了」。實戰上 Cloudflare 設定一個 typo 整套救援就失靈，必須做演練。

演練一：用 curl 看 cf-cache-status

# 先打一次讓 CDN 抓到 cache
curl -sI https://你的網域.com/blog/some-post | grep -i cf-cache-status
# 預期看到：cf-cache-status: HIT （第二次以後）

# 等 TTL 過期之後再打
curl -sI https://你的網域.com/blog/some-post | grep -i cf-cache-status
# 預期看到：cf-cache-status: EXPIRED 或 STALE 或 REVALIDATED

如果你看到 cf-cache-status 永遠是 DYNAMIC，代表 Cache Rules 完全沒生效，請回去檢查 URI 規則。

演練二：人為把 origin 關機

這是最有效但也最需要膽量的測試。建議在低流量時段（半夜 3 點）操作：

• 步驟 1：先確認你要測試的頁面已經有 cache（curl 一次看 HIT）

• 步驟 2：把 origin 服務關掉（暫停 Vercel deploy / 暫停 Zeabur 服務）

• 步驟 3：用瀏覽器無痕視窗訪問該頁面

• 步驟 4：打開 DevTools Network → 查看 response headers

• 步驟 5：應該看到 cf-cache-status: STALE 或 REVALIDATED，頁面正常顯示

• 步驟 6：恢復 origin 服務，等下次 fetch 取回新版

演練三：檢查 Cache Reserve 命中

# Cache Reserve 命中時 cf-cache-status 會回 cf-cache-reserve-hit
curl -sI https://你的網域.com/blog/some-post -H "Cache-Control: no-cache"
# 強制繞過 edge cache，直接打 reserve / origin

超越基本配置：兩種進階災難模式

如果你的網站對可用性的要求高於一般部落格（電商、預約系統、SaaS Dashboard），下面兩種架構值得一試。

模式一：多 origin 故障轉移（Load Balancing）

Cloudflare Load Balancing 可以設定多個 origin pool，當主 origin 健康檢查失敗時自動切到備援。這比 stale-if-error 更積極——它讓你的網站連 SSR 都繼續運作，不只是 serve stale HTML。成本一個月約 5 美元起，適合規模到一定程度的服務。

模式二：把關鍵頁面做成靜態化（SSG/ISR with long TTL）

最便宜的高可用方案：把首頁、關鍵 landing page、聯絡頁面全部用 export const dynamic = 'force-static' 變成純靜態 HTML，CDN 永久快取。即使整個 origin 宇宙爆炸，這幾個頁面照樣能讓訪客找到你的客服信箱。

規劃哪些頁面需要這種「終極備援」是維運哲學的一部分。如果你想針對「我的系統哪幾條路徑值得做這種強化」做一次全面盤點，可以參考 我們的 AI 維運諮詢服務，或者看看 企業客製化網站開發 的架構規劃流程。

關於 Cloudflare 救援機制，工程師最常問的問題

結語：把可用性建立在第二層快取上

整理一下這篇講的所有東西，你會發現一個共通模式：不要把訪客的體驗綁死在 origin 健康狀態上。 一個夠成熟的網站架構，至少要有兩層保險：origin 是第一層，CDN cache 是第二層。Cloudflare 提供的 Cache Rules + stale-if-error + Cache Reserve，本質上是把 CDN 從「加速層」升級成「可用性層」。

這套機制最適合三種人：經營部落格 / 內容站（讀多寫少）、做 SaaS landing page（首頁宕機 = 不能成交）、做電商商品頁（每分鐘斷線都是錢）。如果你的網站符合任一情境，把上面的 Cache-Control 配方跟 Cache Rules 直接套用，是當天就能做完的維運升級。

但 CDN 救援只是維運的一個面向。應用層自己有沒有 OOM、有沒有資料庫連線洩漏、有沒有設定 graceful shutdown，這些根因問題 Cloudflare 救不到。我們之前寫過 Node.js V8 heap 高水位完整事故復盤 與 CI/CD 完整指南，是這篇的姐妹篇——一篇講「網站從掛掉到復原的應用層該怎麼修」、一篇講「怎麼讓部署過程本身不變成事故源頭」。