如何排查區域性 CDN 存取故障

區域性 CDN 故障究竟長什麼樣子

區域性的分發故障通常不會表現為整站全面癱瘓。更常見的情況是：一部分使用者會遇到逾時、間歇性連線重置、過期快取物件、TLS 交握錯誤，或上游閘道類報錯，而另一部分使用者卻回報存取一切正常。這種不對稱現象在分散式內容分發系統中其實很正常，因為不同請求會被調度到不同的邊緣位置，而這些邊緣位置又可能依賴不同的遞迴解析器、不同的傳輸路徑，或不同的源站可達條件。因此，分發層完全可能只在某個地理範圍內失效，而其他地區使用者仍可正常取得內容。

• 一個地區出現連線逾時，另一個地區卻回傳 200 OK。
• HTML 能開啟，但 CSS、JavaScript 或圖片資源載入卡住。
• IPv4 正常，而 IPv6 失敗，或者相反。
• HTTPS 僅在某些路徑上失敗，原因可能是交握或上游連線異常。
• 某一家 ISP 或某類解析器後的使用者受影響特別明顯。

從事故回應的角度來看，關鍵判斷其實很簡單：如果源站穩定，而影響範圍呈現明顯的地理性或網路性特徵，那麼故障域通常就位於 DNS 調度、邊緣節點以及邊緣到源站的路徑之間。

先把邊緣層症狀和源站症狀區分開來

在深入 trace 和封包擷取之前，先判斷到底是源站在全球範圍內出現故障，還是只有分發層發生了降級。HTTP 語意在這裡很有幫助。例如閘道或代理回傳逾時，通常表示它沒能及時收到上游回應；而閘道錯誤也可能表示上游行為異常或傳輸失敗。伺服器端狀態碼類別可以提供方向，但僅憑它們並不能直接指出是哪一跳出問題。你需要對比測試。

1. 從多個地區透過分發層測試公開主機名稱。
2. 使用 host override 或臨時直連路徑，直接測試源站。
3. 比較狀態碼、TLS 表現、TTFB，以及物件是否完整。
4. 檢查故障是影響動態頁面、靜態資源，還是兩者同時受影響。

如果直連源站的路徑持續成功，而加速網域名稱只在某些地區存取失敗，那麼幾乎可以確定問題就在區域性的邊緣層。如果兩條路徑在全球範圍內都失敗，那麼根因更可能是上游應用邏輯、源站網路飽和、防火牆策略，或源站端的解析問題。

在變更任何設定之前，先蒐集正確的證據

高品質的排障始於高解析度證據，而不是緊急改設定。工程師應該蒐集足夠的資訊來重現問題，也要蒐集足夠的中繼資料來進行跨系統請求關聯。這意味著你需要時間戳記、來源網路、解析器資訊、傳輸協定族、請求 ID，以及可取得的錯誤回應內容。沒有這些資料，你很容易把一個路由異常誤判為快取損壞事件，或者把源站 DNS 問題誤認成應用程式回歸。

• 精確到 UTC 的故障時間。
• 受影響的國家、州、城市，或 ASN（如已知）。
• 問題是僅瀏覽器發生、僅 API 發生，還是特定物件才發生。
• HTTP 狀態碼、回應標頭，以及交握錯誤資訊。
• 來源 IP、所用解析器，以及目前使用的是 IPv4 還是 IPv6。
• 來自受影響與未受影響路徑的 traceroute 或 MTR 輸出。
• 可與邊緣請求 ID 對齊的源站日誌。

這套證據包之所以重要，是因為分散式故障往往會出現多個並發原因。邊緣節點也許本身可達，卻無法解析源站主機名稱；它也可能能夠正確解析源站，卻在回程路徑上失敗；或者它快取了被污染的物件，而源站本身依舊完全正常。

採用分層診斷流程進行排查

從發現問題到定位根因，最快的方法往往不是東一榔頭西一棒子地追著症狀跑，而是沿著協定堆疊逐層往下排查。對於區域性存取故障，最可靠的順序通常是：用戶端可達性、DNS 調度、邊緣行為、邊緣到源站的連通性，最後才是應用本身的正確性。

1. 驗證故障範圍

最好從至少三個未受影響地區和三個受影響地區發起測試。觀察故障是否穩定聚集在某一類區域內。如果東岸正常、內陸某電信業者異常，那麼真正的分割條件可能不是地理位置本身，而是解析器或傳輸網路問題。

2. 對比 DNS 回傳結果

檢查不同解析器是否回傳了不同的分發端點、不同的 TTL 值，或不同的位址族。同時也要查看用於回源的源站主機名稱，是否能夠在基礎設施端被正確解析。如果分發系統無法可靠解析上游主機名稱，或者源站的權威 DNS 表現緩慢且不一致，邊緣層就可能直接失效。

3. 直接測試源站

透過 host override 和正確的 Host 標頭，暫時繞過分發層。如果源站能夠穩定回傳預期內容且延遲平穩，那麼事故焦點仍應放在邊緣平面上。如果直連測試也暴露出高延遲或隨機連線重置，那麼分發層可能只是把源站本身的脆弱性放大了。

4. 檢查狀態碼和回應標頭

回應類別本身具有重要資訊。閘道類錯誤通常意味著中介層存在問題，503 可能表示暫時不可用，而重新導向迴圈也可能在不同路徑或快取規則不一致時，表現為區域性故障。不要只看狀態列，還要比較回應標頭、快取相關中繼資料、Age 值，以及重新導向目標。

5. 追蹤網路路徑

只要使用得當，traceroute 和 MTR 仍然非常有用。它們可以幫助發現延遲飆升、丟包模式，或者從某一跳開始不可達的位置。某些網路會降低 ICMP 優先級，因此單一靜默 hop 並不能直接證明故障，但健康路徑和異常路徑之間的明顯差異，往往能指出真正出問題的鏈路區段。

6. 關聯邊緣日誌與源站日誌

對齊請求時間戳記，並比較受影響地區的失敗請求是否真的到達了源站。如果源站從未看到這些請求，表示問題發生在源站接收之前；如果源站看到了請求，但回應緩慢或行為不一致，就應繼續排查應用延遲、連線池或防火牆邏輯。

區域性分發故障背後的常見根因

同一種現象背後可能對應不同的技術原因，因此分類非常關鍵。下面這些類別，是工程師在排查局部存取失敗時最常遇到的根因。

• 邊緣節點本身不穩定：某個區域節點過載、程序崩潰、路由表過舊，或者快取損壞。大型分散式網路本身就是為了吸收故障而設計的，但局部邊緣異常依然會在現實中發生。
• 源站 DNS 解析失敗：分發平面無法穩定解析上游主機名稱，原因可能是逾時、NXDOMAIN，或權威 DNS 回傳不一致。
• 邊緣到源站路徑退化：邊緣可以接收請求，但無法足夠快地回源，最終表現為 502 或 504。
• TLS 不匹配：憑證鏈、SNI、協定版本，或交握行為在部分節點中不一致，或者僅在某一位址族上表現異常。
• 設定漂移：重新導向規則、快取規則、壓縮、請求標頭正規化，或物件失效設定沒有在所有節點完全收斂。
• 解析器或傳輸網路異常：表面上看起來像是區域性故障，但實際上可能只和某個遞迴解析器叢集，或某個傳輸提供者有關，而非真正的地理問題。

事故處理中如何快速止損

在故障仍持續時，時間比架構潔癖更重要。首要目標是先恢復可達性，再談最佳化。事故緩解措施應當是可回滾、低風險、便於觀察效果的。

1. 對受影響物件做定向清理，減少錯誤快取條目的影響。
2. 如果源站容量允許，將關鍵路徑暫時切回源站直連分發。
3. 如果需要調整調度策略，可暫時縮短 DNS TTL。
4. 放寬對合法邊緣回源請求過於嚴格的防火牆或限速規則。
5. 關閉受影響路徑中的問題重新導向邏輯或特定傳輸特性。
6. 分別驗證靜態資源、API 介面和媒體內容的回退行為。

但也要警惕大範圍粗暴改動。一次恐慌式的全量快取清理，或者整條路徑全面繞過分發層，也許能修復一個區域的問題，卻可能在全球範圍內給源站帶來新的壓力。尤其是在美國伺服器租用環境下，如果業務流量本就呈現突發性成長，從快取分發突然切到純源站服務，很可能只是把瓶頸從邊緣平面轉移到了源站。

預防：依賴可觀測性，而不是僥倖

應對區域性分發事故的最佳防線，不是更厚的操作手冊，而是更好的可觀測性。因為這類區域性故障很難透過辦公室裡的一條網路連線發現，所以監控平面本身也必須是分散式的。工程師應當把邊緣可見性視為一項一等公民能力，而不是一個可有可無的儀表板。

• 從多個地理區域、多個網路部署合成探測。
• 分別追蹤源站直連健康度與加速主機名稱健康度。
• 盡可能記錄請求 ID、快取狀態以及上游耗時欄位。
• 保留一個可用於緊急驗證的源站直測通道。
• 定期稽核 DNS TTL、權威解析健康狀況與雙堆疊一致性。
• 在變更上線前測試快取失效、重新導向行為與 TLS 設定。

如果你的環境同時包含伺服器租用和伺服器託管資源，那麼請盡量將兩者的可觀測性標準統一起來。不同上游策略和路由域可能製造出截然不同、甚至具有誤導性的現象；只有在同一基線下比對日誌、延遲直方圖和解析測試，才能避免誤判。

一份實用的工程師排查清單

對於希望從告警到證據蒐集走最短路徑的團隊來說，下面這份清單通常已經足夠將故障域縮小到明確範圍：

1. 確認影響範圍：地區、網路以及位址族。
2. 從多個解析器對比 DNS 回傳結果。
3. 分別測試公開主機名稱與源站直連路徑。
4. 檢查閘道錯誤、重新導向與快取相關回應標頭。
5. 從正常和異常觀測點分別執行 traceroute 或 MTR。
6. 確認失敗請求是否真的到達了源站。
7. 檢查源站 DNS 健康狀況與權威回應時間。
8. 只清理可疑物件或路徑，不要一鍵全清。
9. 套用可回滾的緩解措施，並觀察系統是否收斂。
10. 記錄精確的故障模式，為下一次事故準備樣本。

這套順序之所以有效，是因為它能快速收縮問題空間，同時避免一種經典反模式：把每一個 504 都當成應用問題，或者把每一個逾時都歸咎於使用者端網路故障。瀏覽器、邊緣節點與源站之間的鏈路足夠長，因此有紀律的隔離法幾乎總是比直覺更可靠。

結論

在現代美國伺服器租用基礎設施中，區域性網站故障是最具迷惑性的維運問題之一，因為源站表面上可能完全正常，但仍有一部分使用者事實上被擋在站點之外。最可靠的思路，是把 CDN 節點故障 視為一個分層除錯問題：先驗證範圍，再比較 DNS 回傳結果，繞過邊緣層，檢查閘道回應，追蹤網路路徑，並關聯日誌，直到真正出問題的那一跳被明確識別出來。對工程師來說，真正的收益不僅是解決這一次事故，更是建立足夠完備的遙測體系，讓下一次同類事件從漫長爭論變成一次簡短調查。