阿里雲企業帳號代開 阿里雲CDN狀態碼502 and 504排查

第一章：先理解502與504在CDN裡代表什麼

在做阿里雲CDN排查時，很多人會先入為主地把502、504當成「網路壞了」。但實際上，兩個狀態碼背後往往是不同的失效型態：它們都可能是回源失敗或超時，也可能是邊緣節點或上游服務異常；差別在於「失敗的階段」和「失敗的時間尺度」。

簡化理解：

502通常更像是「邊緣拿回源的回應失敗」：DNS解析失敗、連不上源站、握手/證書不通、源站直接返回不可用、或中間層返回了非法/非預期內容。你可以把它看成“連上了但沒拿到正確的結果”，或者“連都沒連到”。

504更像是「等待超時」：回源耗時過長、源站慢（CPU飆高、GC頻繁、DB慢）、回源鏈路抖動導致重試、或源站對特定路徑/方法長時間不回應。你可以把它看成“邊緣一直等，但超過了可容忍的等待時間”。

因此，排查應該從「先判定是連不連、快不快」開始，而不是一上來就改配置。當你能把問題定位到“類型”上，後續每一步都會更有方向：是查DNS、查回源地址，還是查源站性能與超時參數。

第二章：建立排查現場的“最小線索”

在進行任何改動前，建議先把關鍵資訊收集齊全。因為502/504通常不是單點問題，可能是某次發版、某個域名解析變更、某條回源規則命中不同源站、或某段時間源站資源枯竭造成的。

你至少需要以下線索：

1）客戶端看到的URL：包含路徑、查詢參數，最好能去掉敏感信息後保留完整結構。CDN策略（快取key、是否回源、是否走HTTPS）可能因參數不同而不同。

2）發生時間範圍：開始時間、持續多久、是否有規律（例如每小時某分鐘突增、整點發版後）。

3）影響範圍：單一國家/地區、單一運營商、單一瀏覽器或所有用戶。若只影響少數地區，可能是節點路由或源站互聯路徑問題；若全局，都可能是源站或配置。

4）狀態碼比例：502多還是504多？是否同一URL同時出現兩者？如果同一批請求先502後504，通常意味著連接逐步變差，可能是源站異常升級或網路退化。

5）CDN日誌或事件：阿里雲CDN通常能查到請求的處理鏈路、命中情況（命中/未命中）、回源耗時、失敗原因等。不要只看“結果是502/504”，要看“結果是在哪一步產生的”。

第三章：用CDN日誌把問題切成兩大類

排查502/504最有效的方法，是在CDN控制台或日誌中找到每次失敗的請求紀錄，然後按“是否回源、回源耗時、回源地址與協議、失敗原因”分層。你會發現很多問題能在幾分鐘內縮小範圍。

小節一：先看是否命中緩存

如果大量請求是“未命中”導致的回源失敗，那502/504與源站健康度高度相關；反之，如果命中率很高卻仍大量502/504，則更可能是CDN邊緣到用戶或邊緣到上游的鏈路/策略問題。

常見例子：

1）你剛更新了快取規則或快取鍵，導致原本可命中的內容變成新的key，結果突然大量回源。

2）源站回應頭部Cache-Control/Expires不符合你的預期，導致CDN不緩存或很短時間失效。

3）清理了大量緩存或刷新策略不當，回源壓力瞬間放大。

小節二：看回源耗時分布

當你看到大量504時，回源耗時往往會接近超時上限。你可以對照CDN回源超時配置、源站實際延遲、以及是否存在重試行為。

如果日誌顯示回源耗時在某個固定值上下波動，通常是超時策略與源站回應時間匹配造成的。若耗時呈現長尾（大多很快，但少數極慢），要更關注源站的慢查、隊列堆積、或GC等“間歇性”瓶頸。

阿里雲企業帳號代開 小節三：看失敗原因字段

很多平台的日誌會給出類似“DNS解析失敗”“連接超時”“TLS握手失敗”“上游返回錯誤”“回源狀態碼異常”“回源連線被拒絕”等原因。這一步的價值在於：你不必猜測，直接按原因去查對應環節。

若日誌沒有細分原因，也可以用回源地址、協議（http/https）、端口、以及處理鏈路判斷“失敗發生在連線建立還是回應等待”。

第四章：回源側排查——把“502”與“504”各自打回原形

阿里雲CDN的本質是代理與加速，它最終仍要取得源內容。因此當回源失敗時，CDN的狀態碼往往就是源站問題的放大器。下面用“連不上/連上了但失敗/等太久”三種場景來拆。

小節一：源站不可達或DNS問題（常導致502）

若日誌提示回源DNS解析失敗或連接被拒絕，你應該先檢查源站域名/回源IP是否變更。很多事故源自“看似無關”的改動：例如源站換機房、內網域名解析策略變更、或只在某些DNS節點生效。

具體做法：

1）確認CDN回源配置使用的是域名還是IP。若是域名，檢查域名解析是否穩定、TTL是否過短、是否有多套解析導致偶發錯到不存在的IP。

2）從可靠環境對源站域名進行DNS解析對照：確保A/AAAA記錄正確，且端口服務可用。

3）檢查安全組/防火牆。源站可能限制來源IP段，導致CDN節點IP不在白名單。這類問題往往呈現“部分地區可、部分地區不可”。

4）檢查源站是否對特定Host頭或SNI要求嚴格。如果回源協議與Host不匹配，可能出現握手失敗或返回錯誤。

小節二：TLS證書與握手問題（常導致502，並可能伴隨504）

當回源是HTTPS，而源站證書鏈不完整、域名不匹配或TLS版本/加密套件不兼容時，CDN邊緣可能在握手階段失敗，直接回502。少數情況下握手反覆重試，會把部分請求拖到超時邊界，出現504。

排查要點：

1）源站證書是否快到期。證書到期後通常是突然全面失敗，不太像緩慢劣化。

2）證書是否完整鏈（含中間證書）。某些客戶端寬容，CDN邊緣可能更嚴格。

3）源站是否只允許特定TLS版本。若CDN回源使用的協議限制較嚴，可能導致握手失敗。

4）回源是否需要SNI。對基於虛擬主機的源站，SNI/Host不匹配會導致返回404或證書不匹配。

小節三：源站返回異常（也會造成502）

即便連線成功，源站仍可能返回與預期不符的內容或狀態。例如源站應用崩潰、反向代理上游不可用、或對某些路徑返回500/502，CDN會把這些異常映射為自己的502/504（取決於它判定的錯誤類型）。

你應該在源站側同時查看以下：

1）Nginx/Apache/SLB的錯誤日誌：看是否出現連線被拒、上游超時、upstream prematurely closed、或反代超時。

2）應用日誌：定位是否同一時間段有報錯，且與CDN失敗URL對得上。

3）健康檢查：源站是否被健康檢測剔除？如果源站後端池健康度下降，部分請求會被打到故障節點。

小節四：源站慢導致504（慢不是“慢一點”，而是“到超時線了”）

阿里雲企業帳號代開 504的核心通常是回源超時。當源站在某些條件下回應變慢，就會跨越CDN的容忍等待時間。常見原因包括：

1）DB慢：查詢慢、鎖等待、連線池耗盡。

2）應用線程/協程池耗盡：排隊導致延遲飆升。

3）Cache穿透或緩存擊穿：突然大量回源到源站“計算型接口”，直接把後端拖入超時。

4）上游依賴不可用：例如應用在處理請求時需要調用外部服務，而外部服務慢或失敗，導致源站本身一直等待。

建議做一個對照：在504發生的那段時間，源站的p95/p99延遲、錯誤率、以及CPU/內存/GC指標是否同步惡化。若只有少量請求504，通常是“長尾慢”；若大量請求504，則是“整體慢或回源壓力過大”。

阿里雲企業帳號代開 第五章：CDN側配置排查——很多問題並不在源站

當你確認回源鏈路基本可用後，應該把視角轉向CDN配置本身。因為CDN是一套策略系統：同一個域名在不同路徑、不同參數、不同HTTP方法可能走不同規則。一些細小配置錯誤會讓你以為是網路故障，實際是策略導致的。

小節一：回源地址與回源協議配置

常見錯誤包括：

阿里雲企業帳號代開 1）回源地址填錯（少了一個子域名、端口寫錯、或誤填了反向代理地址與源站地址，導致循環）。

2）回源協議選錯：源站實際只支持HTTPS，你配成HTTP；或源站支持HTTP但你配HTTPS，而證書不完整。

3）端口不一致：源站TLS服務是443，但你配成8443；或反向代理是80/443轉發，卻配置錯端口導致握手失敗。

排查方式：把CDN日誌中實際回源到的host與端口拿出來，和源站服務端配置對照。

小節二：自定義請求頭與Host轉發

對於基於Host分流的源站，CDN是否會按你的需求轉發Host非常關鍵。若你把回源Host設錯，源站可能返回錯誤頁、導致502，或在某些條件下把請求導向不存在的上游。

尤其在多域名、多租戶場景，如果源站只在特定Host下提供服務，任何Host不一致都會讓一部分URL“看起來偶發”。

小節三：快取策略、回源頻率與命中率突變

阿里雲企業帳號代開 當502/504在短時間內集中出現，很多時候與“命中率突降”高度相關。這通常由以下原因觸發：

1）快取規則變更：例如把原本應該命中的靜態資源改成不緩存。

2）快取key設計不合理：包含了會變的參數（如毫秒時間戳、跟蹤token），導致每次都變成不同key，造成回源爆炸。

3）清理緩存過多：整站刷新導致瞬時回源壓力。

你可以在CDN日誌中觀察同一時間段的“命中率、回源量、回源耗時”。如果回源量陡增而源站未擴容，就會迅速轉成504，甚至502。

小節四：壓縮、範圍請求與特定資源類型

某些狀況下，只有特定類型資源出現502/504，例如大文件下載、Range分段請求、或特定Accept-Encoding組合。若源站對Range支持不完全，或對壓縮輸出耗時過長，就可能在少數場景觸發504。

建議挑選一兩個最典型的URL，復現時同時記錄：請求方法（GET/HEAD）、是否帶Range、響應大小、以及源站端是否有對應日志。

第六章：分步排查流程（可以直接照做）

下面給一個可操作的流程，目的在於讓你快速從“症狀”走到“確因”。你不需要一次做完，按順序排查，遇到能證明的點就停下來。

步驟1：鎖定URL與時間窗

從用戶回報或監控告警中拿到最典型的URL集合（建議至少3個：一個靜態資源、一個動態API、一個大文件或高頻接口），並鎖定開始到結束時間。

步驟2：查CDN日誌，先判定“回源/命中”

對這些URL在時間窗內的失敗請求進行抽樣。統計：命中率、是否回源、回源耗時區間、失敗原因（若有）。

步驟3：區分502與504的失敗位置

若失敗原因偏向“DNS/連接/握手”，優先看回源地址、證書、端口、防火牆白名單。若原因偏向“超時”，優先看源站性能與回源配置是否過緊。

步驟4：源站側對齊同一時間窗

在源站對應節點或反向代理查看錯誤日誌與慢請求。確保能匹配到同一批URL或同一類請求（至少能看到上游超時、連線池耗盡或5xx激增）。

步驟5：驗證回源連通性（必要時用探測替代猜測）

在不改動生產的前提下，用測試方式確認從你能控制的網段到源站服務是否正常（包括DNS解析、HTTP/HTTPS連接、證書鏈、以及特定Host）。如果你無法在相同網段測試，也至少在源站端確認“是否收到來自CDN的請求”。

步驟6：核對CDN配置變更歷史

回看最近的配置修改：快取規則、回源地址、HTTPS/證書設定、Host轉發、自定義頭、以及路徑分發規則。很多事故並不是“壞了”，而是“改了之後立刻失效”。

步驟7：給出修復方案並做驗證回歸

修復後不要只看指標“恢復了”，還要抽查：失敗URL是否不再出現502/504、命中率是否符合預期、回源耗時是否回到合理區間、以及是否引入新的問題（例如返回內容不對或快取策略錯誤）。

第七章：常見“坑”總結（看完能少走很多彎路）

在大量排查經驗裡，502/504最常見的根源通常集中在下面幾類。你可以把它當作檢查清單。

小節一：回源DNS解析偶發錯誤

源站域名解析存在多結果，且其中一部分IP不提供服務，CDN回源時可能命中不可用IP。表面看像偶發502/504，實則是DNS輪詢與健康度不匹配。

小節二：防火牆白名單未覆蓋全部CDN節點來源

某些地區可用、某些地區不可用，往往與來源IP或地區路由相關。你需要確保CDN回源所需的網段在源站安全策略中是允許的。

小節三：證書鏈不完整或到期

證書到期常見於低頻域名或二級子域名，監控不完善時很容易錯過。證書鏈不完整則可能在某些環境下“能連”，在CDN邊緣就“連不上”。

小節四：快取策略變動導致回源瞬間爆量

尤其在發版後版本號上升或快取key設計變更，回源量瞬間放大，源站還沒來得及承接，504就會像洪水一樣來。

小節五：源站慢是因為上游依賴，非源站本體

很多人以為是源站CPU不夠，但實際是應用依賴的外部服務慢，導致源站等待。你應該看應用的依賴調用鏈路，對應到錯誤與超時統計。

第八章：修復後的驗證與預防（讓問題不再重演）

排查最容易止步於“恢復”。但如果沒有驗證與預防，下一次同類事故仍可能再發。

小節一：驗證指標要“同向”

修復後建議至少看三類指標同向改善：

1）CDN側：502/504比例下降、回源耗時分布回落、回源量是否符合預期（命中率提升或保持）。

阿里雲企業帳號代開 2）源站側：錯誤率下降、慢請求數量下降、關鍵依賴的超時率下降。

3）用戶側：首包時間/下載完成時間改善，且沒有“內容不對”的新症狀。

小節二：做“演練式”復現

你可以在低峰期對典型URL做一次重放或壓測（幅度可控），確認回源鏈路穩定。尤其對大文件或Range請求，復現一次就能避免下次只看404/500卻忽略了504。

小節三：建立預警與回溯材料

預防不是“盡量別出問題”，而是“出問題時能快速定位”。建議把以下納入團隊流程：

1）配置變更必留可追溯記錄：時間、變更內容、影響路徑。

阿里雲企業帳號代開 2）源站慢查監控：p95/p99延遲、上游依賴超時、連線池耗盡告警。

3）CDN回源量與回源耗時告警：當回源量突然上升或回源耗時接近超時線時提前通知。

4）證書到期提醒：對所有涉及回源/客戶端HTTPS的域名建立到期提醒。

結語：把排查變成“可重複的流程”，而不是靠運氣

阿里雲CDN的502與504看似複雜，實則遵循一條邏輯：先判定失敗發生在“回源前、連接中、等待回應”哪個階段；再用日誌把範圍縮到源站連通、TLS握手、應用回應速度或配置策略。當你能把每次事故都落回同一套流程，排查時間會明顯縮短，修復也會更有把握。

你不必猜測網路到底壞在哪裡。把手伸向數據：CDN日誌告訴你回源是否發生、耗時是否接近超時、以及失敗原因落在何處；源站日志告訴你上游是否慢或不可用。當兩邊對齊，你就能從“現象”走到“因果”，讓502/504不再是令人焦慮的黑盒。