CDN：回源排障指南

CDN 節點作為網關無法從來源站點獲得有效響應時會返回 502（Bad Gateway）。回源鏈路中以下任一環節失敗都可能返回 502：

• 來源站點不支援 HTTPS（僅監聽 80 連接埠）但 CDN 配置了 HTTPS 回源；

• 回源連接埠與來源站點實際監聽連接埠不一致；

• 來源站點依賴 SNI 選擇認證但 CDN 未攜帶或攜帶了錯誤的 SNI；

• 來源站點 SSL 憑證到期、無效或與網域名稱不匹配；

• 來源站點使用自我簽署憑證或內部 CA 簽發的認證，回源 TLS 校正失敗。

排查步驟：

• 檢查來源站點是否支援當前回源協議：執行 curl -Iv https://來源站點網域名稱 直接驗證來源站點。若串連被拒絕或逾時，說明來源站點不支援 HTTPS，請將回源協議改為 HTTP；若來源站點支援 HTTPS 且認證有效，可選擇 HTTPS 回源或協議跟隨。

• 檢查回源連接埠是否與來源站點監聽連接埠一致：預設 HTTPS 回源連接埠為 443、HTTP 回源連接埠為 80。如果來源站點使用自訂連接埠（範圍 1~65535），請在回源協議配置中填寫對應連接埠。

• 檢查回源 SNI 配置：當來源站點同一 IP 託管多個 HTTPS 網站時，來源站點依賴 TLS 握手中的 SNI（Server Name Indication）欄位來選擇對應的 SSL 憑證。如果 CDN 回源未攜帶 SNI 或 SNI 值錯誤，來源站點無法匹配正確認證，TLS 握手失敗，返回 502。

  解決步驟：登入 CDN 控制台 → 網域名稱管理 → 選擇目標網域名稱 → 回源配置 → 開啟回源 SNI，填寫來源站點實際提供服務的網域名稱（通常與來源站點認證的 Common Name 一致）。同時將回源 HOST 設定為來源站點網域名稱。

  回源時 CDN 會校正 SNI 與來源站點認證 Common Name 的一致性，若兩者確實無法保持一致（如來源站點使用統一接入層認證），可將認證的 Common Name 加入Common Name白名單。

  說明

  回源 SNI 用於 TLS 握手階段選擇認證，回源 HOST 用於 HTTP 層的虛擬機器主機路由，兩者作用不同，但通常設定為同一個來源站點網域名稱。

• 檢查來源站點 SSL 憑證有效性：確認認證未到期、未被吊銷，且認證中的網域名稱包含來源站點網域名稱。可執行 curl -Iv https://來源站點網域名稱 2>&1 | grep -E "expire|subject|issuer" 查看認證的有效期間、頒發者和綁定網域名稱。認證到期或與網域名稱不匹配時請更新來源站點認證；若來源站點使用自我簽署憑證或內部 CA 簽發的認證，請更換為公有可信 CA 簽發的認證，或將回源協議改為 HTTP。

解決方案：根據來源站點實際情況修改回源協議：來源站點只支援 HTTP → 選擇 HTTP（連接埠預設 80）；來源站點支援 HTTPS 且認證有效 → 選擇 HTTPS（連接埠 443 或自訂）；來源站點兩者均支援且認證維護良好 → 可選擇協議跟隨。詳細操作請參見配置回源協議。

回源協議為“跟隨”時返回 502 如何排查？

回源通訊協定設定為"跟隨"時，CDN 跟隨用戶端的請求協議回源：用戶端使用 HTTP 訪問，CDN 以 HTTP 協議回源；用戶端使用 HTTPS 訪問，CDN 以 HTTPS 協議回源。如果用戶端使用 HTTPS 訪問而來源站點不支援 HTTPS，TLS 握手失敗，回源請求失敗。此問題與"回源返回 502 如何排查"同因，可按同一排查步驟診斷。

解決方案：

• 方式一：將回源協議從"跟隨"改為"HTTP"，CDN 始終以 HTTP 協議回源。

• 方式二：為來源站點配置 SSL 憑證，確保來源站點支援 HTTPS 訪問。詳細說明請參見配置回源協議。

504 錯誤（Gateway Timeout）表示 CDN 節點在回源時無法在指定時間內從來源站點擷取響應。

常見原因包括：

• 來源站點響應慢或服務不可用。

• 回源請求被中間網路裝置或防火牆丟包（SYN 包被丟棄時表現為連線逾時）。

• 回源協議、連接埠配置錯誤導致串連無法建立（此時通常表現為 502，但若防火牆靜默丟棄而非主動拒絕也可能表現為 504）。

• 回源讀取逾時時間設定過短，不能滿足來源站點實際響應耗時。

回源逾時分為兩個階段，對應不同的排查方向：

• 串連階段逾時：CDN 節點與來源站點建立 TCP 串連的逾時時間為 10 秒。這一階段逾時通常說明來源站點未監聽回源連接埠、防火牆或安全性群組丟棄了 CDN 回源 IP 的 SYN 包，或網路鏈路存在嚴重丟包。

• 讀取階段逾時：串連已建立，但來源站點在回源讀逾時時間（預設 30 秒）內未返回完整響應。這一階段逾時通常說明來源站點處理慢，例如資料庫慢查詢、後端應用阻塞、來源站點負載過高。

排查步驟：

1. 檢查來源站點是否可正常訪問：直接通過 curl -I http(s)://來源站點網域名稱 或瀏覽器訪問來源站點，確認來源站點回應時間和狀態代碼。如果來源站點本身響應慢或無法訪問，需優先修複來源站點效能或可用性問題。

2. 定位耗時集中在哪個階段：執行 ：

   curl -o /dev/null -s -w "time_connect:%{time_connect} time_starttransfer:%{time_starttransfer} time_total:%{time_total}\n" http(s)://來源站點網域名稱/資源路徑

   其中 time_connect 為 TCP 建連耗時，time_starttransfer 為收到首位元組的耗時，time_total 為總耗時。

   • 若 time_connect 就已明顯偏大，按串連階段排查網路與防火牆；

   • 若 time_starttransfer 遠大於 time_connect，說明來源站點業務處理慢，需最佳化來源站點；

   • 若 time_total 遠大於 time_starttransfer，說明響應體過大或來源站點出頻寬不足。

3. 檢查回源協議和連接埠配置：確認 CDN 配置的回源協議、連接埠與來源站點實際監聽一致。如果回源連接埠錯誤或來源站點未監聽該連接埠，CDN 會在逾時後返回 504。

4. 檢查來源站點防火牆或安全性群組：如果來源站點對 CDN 回源 IP 段做了限流或攔截，可能導致部分請求逾時。尤其是靜默丟棄 SYN 包的策略，會直接表現為串連階段逾時。請將 CDN 回源 IP 段加入來源站點白名單（參見CDN回源節點IP地址有哪些）。

5. 檢查 CDN 節點到來源站點的鏈路品質：從 CDN 節點到來源站點之間可能存在網路抖動、丟包或電訊廠商路由問題。可結合 MTR/traceroute 等工具分析（需聯絡阿里雲支援人員從 CDN 節點側發起診斷）。

6. 調大回源讀逾時時間：如果來源站點響應耗時接近預設的 30 秒，可在 CDN 控制台調大回源HTTP請求逾時時間以減少 504。該值最長可配置到 150 秒，但建議不超過 60 秒，且僅作為臨時緩解手段，根本解決方式仍是最佳化來源站點響應效能。

503（Service Temporarily Unavailable）表示來源站點暫時無法處理請求。CDN 回源收到 503 通常由來源站點側原因導致：

• 來源站點 Web 服務程式異常、未啟動或正在重啟；

• 來源站點負載過高（CPU、記憶體、串連數打滿）；

• 來源站點配置了單 IP 訪問頻率限制或並發串連限制；

• 來源站點部署了雲鎖、安全狗、WAF、防火牆等安全性原則攔截了 CDN 回源 IP；

• 來源站點進入維護模式或正在部署。

排查步驟：

1. 繫結來源站直接存取複現：通過修改本地 hosts 檔案將加速網域名稱指向來源站點 IP 後訪問，若直連來源站點同樣返回 503，說明問題在來源站點側，可排除 CDN 節點本身的問題。

2. 檢查來源站點 Web 服務是否正常：確認 Nginx、Apache、IIS 等 Web 服務進程正在運行且監聽對應連接埠（80/443 或自訂連接埠）。若服務進程異常或未啟動，請重啟服務並查看服務日誌定位原因。

3. 檢查來源站點負載與限流配置：來源站點 CPU、記憶體、串連數過載，或配置了單 IP 訪問次數限制（如 Nginx 的 limit_req、limit_conn 模組），都可能對 CDN 回源請求返回 503。請結合業務量評估是否需要擴容或調整限流閾值。

   說明

   CDN 回源請求集中來自有限的回源節點 IP，在來源站點按 IP 限流的情境下容易被誤判為單 IP 高頻訪問。建議對 CDN 回源 IP 段設定更高的限流閾值或直接豁免。

4. 檢查安全性原則是否攔截 CDN 回源 IP：來源站點的安全性群組、防火牆、WAF、雲鎖、安全狗等安全性原則可能將 CDN 回源 IP 識別為異常流量並攔截。請在攔截日誌中尋找來自 CDN 節點 IP 的記錄，將 CDN 回源 IP 段加入白名單（擷取方式請參見CDN回源節點IP地址有哪些）。

5. 重新整理 CDN 緩衝：來源站點恢複後若仍訪問到 503，請執行一次 URL 重新整理。對於 500、502、503、504 等狀態代碼，CDN 的緩衝優先順序為：來源站點返回 Set-Cookie 時不緩衝 → 控制台配置了狀態代碼到期時間則按配置緩衝 → 否則按來源站點的 Pragma、Cache-Control、Expires 回應標頭緩衝 → 上述都沒有時預設緩衝 1 秒。因此預設情況下 503 不會造成持續影響，但若控制台曾為 5xx 配置較長的狀態代碼到期時間，異常響應會持續被緩衝到到期，此時需手動重新整理或將 5xx 的緩衝時間改為 0（參見配置狀態代碼到期時間）。

問題現象

來源站點通常通過 Host 要求標頭區分虛擬網站。若 CDN 配置的回源 HOST 與來源站點期望的網域名稱不一致，來源站點可能返回 404、403、500 等錯誤。

排查步驟

1. 檢查回源 HOST 是否與來源站點虛擬機器主機配置匹配

   • Nginx：檢查 server_name 是否包含回源 HOST 配置的網域名稱。

   • Apache：檢查 <VirtualHost> 中的 ServerName / ServerAlias。

   • IIS：在 IIS 管理器中選擇目標網站 > 綁定，檢查"主機名稱"欄位是否與回源 HOST 一致。

2. 重新整理 CDN 緩衝

修改回源 HOST 配置後，執行 URL 重新整理以清除可能緩衝的錯誤響應。

問題現象：網站訪問出現"重新導向次數過多"或"ERR_TOO_MANY_REDIRECTS"錯誤，或部分圖片、CSS、JS 等資源載入失敗。

問題原因：來源站點主動響應了 HTTP→HTTPS 的強制跳轉（常見於寶塔面板、WAF、Nginx 等服務的強制跳轉規則），而 CDN 回源協議配置為 HTTP，請求鏈路形成環路：

用戶端 → CDN → CDN 以 HTTP 回源（連接埠 80）→ 來源站點返回 301 跳轉到 HTTPS → 未配置回源 301/302 跟隨時，CDN 將 301 返回給用戶端 → 瀏覽器跟隨跳轉到 HTTPS → 再次經 CDN 以 HTTP 回源 → 來源站點再次返回 301 → ……瀏覽器反覆重新導向，最終報 ERR_TOO_MANY_REDIRECTS；若開啟了回源 301/302 跟隨，CDN 節點會在回源鏈路上反覆跟隨跳轉，達到跟隨次數上限後將 301 返回給使用者，同樣形成迴圈。關於跟隨功能的說明請參見配置回源301302跟隨。

解決方案（二選一）：

• 方案 A：讓 CDN 直接使用 HTTPS 協議回源。前提：來源站點已配置有效 SSL 憑證且 443 連接埠正常監聽。將回源連接埠修改為 443、回源通訊協定設定為 HTTPS；如果來源站點有多網域名稱監聽，同時配置回源 SNI 和回源 HOST 為加速網域名稱或來源站點網域名稱。

• 方案 B：關閉來源站點的強制跳轉，保持 HTTP 互動。登入來源站點伺服器，關閉強制 HTTPS 跳轉規則；保持 CDN 回源協議為 HTTP、連接埠 80 不變。用戶端到 CDN 這一段仍可用 HTTPS 加密，只要 CDN 和來源站點的協議約定一致即可。

輔助操作（無論選哪個方案，都建議執行）：執行 URL 重新整理清除已緩衝的重新導向響應，確保新配置立即生效。配置修改後需要下發到全網節點，通常幾分鐘內完成，期間部分節點可能仍返回舊的重新導向響應。關於 CDN 對各類狀態代碼的預設緩衝策略，請參見配置狀態代碼到期時間。

本條針對僅在配置回源 HOST/SNI 之後才出現重新導向迴圈的情境；若未配置回源 HOST/SNI 就已出現重新導向迴圈，請參見上一條“來源站點配置 HTTP 到 HTTPS 跳轉後出現重新導向迴圈”。其根本原因仍是來源站點開啟了 HTTP 到 HTTPS 的強制跳轉，而 CDN 以 HTTP 協議回源；修改回源 HOST/SNI 後，來源站點匹配到預期網站並使強制跳轉規則開始生效，迴圈隨之出現。請按以下步驟排查：

• 關閉來源站點上的 HTTPS 強制跳轉功能：登入來源站點管理面板（如寶塔面板），找到 HTTPS 設定，關閉"強制HTTPS"或"HTTP到HTTPS跳轉"選項。

• 確認回源 HOST 和回源 SNI 配置一致且正確：在回源配置頁面，確保回源 HOST 和回源 SNI 設定為正確的網域名稱（通常為來源站點網域名稱），且兩者值保持一致，使回源請求符合來源站點的預期。

• 重新整理 CDN 緩衝：調整配置後，重新整理 CDN 緩衝以清除已緩衝的重新導向響應。

該報錯說明 OSS 的 Bucket 存取權限為私人（private），未攜帶簽名的請求無法讀取 Bucket 內的對象。私人 Bucket 可以起到訪問鑒權的作用，避免非授權的請求盜刷流量，因此不建議為了排除此報錯而將 Bucket 改為公用讀取。

解決方案：為加速網域名稱開啟OSS私人Bucket回源功能。開啟後，CDN 會自動使用服務角色 AliyunCDNAccessingPrivateOSSRole 攜帶簽名訪問私人 Bucket，終端使用者通過 CDN 訪問時無需額外簽名。操作路徑：CDN 控制台 > 網域名稱管理 > 目標網域名稱 > 回源配置 > OSS 私人 Bucket 回源。

如果您的 OSS Bucket 中使用了Key Management Service（Key Management Service）進行加密，您需要為 CDN 的回源角色額外授予使用 KMS 密鑰的許可權，否則 CDN 將無法解密和訪問這些檔案，出現 This request is forbidden by kms. 報錯。

解決方案：

1. 登入 RAM控制台，在左側導覽列選擇身份管理 > 角色。

2. 在角色名稱列表下找到 AliyunCDNAccessingPrivateOSSRole 角色，單擊新增授權。

   說明

   如未找到該角色，說明尚未開啟過 OSS 私人 Bucket 回源功能。請先參見OSS私人Bucket回源開啟功能，角色會自動建立，再返回執行此步驟。

3. 在權限原則下選擇系統策略，搜尋並添加 AliyunKMSCryptoUserAccess，單擊確認新增授權。

4. 使用重新整理預熱功能，待重新整理任務完成後，重新訪問資源。

同時滿足以下三個條件時會出現該問題：OSS Bucket 許可權為私人、OSS 開啟了靜態網站託管、CDN 開啟了OSS私人Bucket回源。此時訪問加速網域名稱的根路徑（例如 https://example.com/）會返回 403 Forbidden，回應標頭中包含 x-tengine-error: You are forbidden to list buckets。

問題原因：CDN 的私人 Bucket 回源功能與 OSS 靜態網站託管的預設首頁配置衝突。

解決方案：

• 方案一：如果您不需要 OSS 靜態網站託管功能，關閉該 Bucket 的靜態網站託管配置即可。具體方法，請參見靜態網站託管。

• 方案二：如果您需要保留靜態網站託管功能，請在 CDN 中配置 URI 重寫規則，避免回源訪問根目錄：將待重寫的Path配置為 ^/$，目標Path配置為 /index.html，执行规则選擇 Redirect。配置完成後，用戶端請求根路徑時，CDN 節點將返回 302 讓用戶端重新請求 /index.html。具體步驟，請參見重寫訪問URL。

問題現象：來源站點根據客戶終端類型對請求做 302 跳轉以提供對應介面。接入 CDN 後，第一個使用者訪問時 302 響應被緩衝，其他不同終端裝置的使用者通過同一 URL 訪問時，會命中第一個使用者緩衝的 302 頁面，導致終端適配功能失效。

方案 A（推薦）：對 302 響應設定不緩衝。設定第一個請求的 URL 不緩衝，而對 302 跳轉後的頁面進行緩衝。可在來源站點對初始版面設定不緩衝（來源站點的不緩衝策略對 CDN 具有較高優先順序），只要該頁面的響應中帶有以下任一回應標頭，即可保證該頁面不緩衝：

• Cache-control:no-cache、no-store

• Cache-control:max-age=0

• pragma:no-cache

• Cache-control:private

方案 B：在 CDN 側配置初始 URL 不緩衝。若無法修改來源站點回應標頭，可結合 CDN 對目錄和尾碼名的緩衝配置及優先順序，單獨為初始跳轉 URL 配置緩衝時間為 0，其他 URL 保持正常緩衝。

方案 C：使用自訂 Cache Key 區分終端類型。若希望保留緩衝能力而非每次回源，可配置自訂 Cache Key，將終端類型維度加入緩衝鍵，使 PC、移動端各自擁有獨立的快取複本，配置方法請參見自訂Cache Key。

可能原因是來源站點依賴 URL 參數或特定的 Host 頭進行邏輯判斷，而 CDN 預設行為可能導致參數丟失或 Host 頭不匹配。請按以下步驟排查：

1. 檢查緩衝規則中的 URL 參數配置：若來源站點依賴 URL 參數進行跳轉或邏輯判斷，需注意 CDN 的“忽略參數”功能。忽略參數影響的是緩衝鍵（Cache Key），回源請求仍會攜帶完整的 URL 參數，因此問題不是“參數丟失導致來源站點無法處理”，而是“不同參數的請求命中了同一份緩衝，返回了不屬於當前參數的內容”。建議關閉忽略參數，或將影響商務邏輯的參數設為保留，使不同參數各自獨立緩衝（參見忽略參數）。

2. 將回源 HOST 配置為來源站點期望的網域名稱：確保來源站點能正確識別請求主機頭從而處理跳轉邏輯。

3. 執行目錄或 URL 重新整理：修改配置後，執行目錄重新整理或 URL 重新整理以使新配置生效。

問題現象：大檔案下載中斷、斷點續傳失敗，或視頻拖拽播放返回錯誤、從頭播放。

問題原因：開啟 Range 回源後，CDN 節點會向來源站點發起帶 Range 頭的分區請求。如果來源站點不支援 Range 請求（忽略 Range 頭直接返回 200 和全量內容），或返回的 Content-Range 與請求的範圍不匹配，就可能導致緩衝異常或用戶端請求失敗。

排查步驟：

1. 驗證來源站點是否支援 Range 請求：執行 curl -I -H "Range: bytes=0-1023" http(s)://來源站點網域名稱/資源路徑。若返回 206 Partial Content 且包含正確的 Content-Range 頭，說明來源站點支援 Range；若返回 200 OK 並攜帶完整檔案，說明來源站點忽略了 Range 請求。

2. 根據來源站點能力調整 Range 回源配置：若來源站點不支援 Range，請先改造來源站點使其能正確響應 206 分區，或先關閉 CDN 的 Range 回源功能，避免 CDN 發起來源站點無法處理的分區請求。配置路徑：CDN 控制台 > 網域名稱管理 > 目標網域名稱 > 視頻相關 > Range 回源，該開關預設未開啟，詳見配置Range回源。

3. 檢查來源站點回應標頭是否穩定：Range 回源要求來源站點對同一資源返回穩定的 Content-Length 和 ETag、Last-Modified，以便 CDN 判斷各分區屬於同一版本的檔案。如果來源站點動態產生內容、無法提供這些回應標頭，Range 回源將不可靠。

4. 確認分區緩衝是否被清理：採用 Range 方式回源時，CDN 節點如果收到來源站點響應的非 206 狀態代碼，會刪除已緩衝的分區檔案（回源逾時不會刪除）。因此來源站點間歇性返回 5xx 會反覆清空已緩衝的分區，表現為下載反覆中斷、回源量異常升高，詳見配置狀態代碼到期時間。

問題現象

通過 CDN 訪問時頁面出現亂碼，或瀏覽器提示解碼失敗（ERR_CONTENT_DECODING_FAILED）。

問題原因

• 來源站點返回了壓縮內容（gzip/br）但未設定 Content-Encoding 回應標頭，CDN 將已壓縮的內容再次壓縮後返回，用戶端解碼異常。

• 來源站點 Content-Encoding 聲明與實際編碼不一致。

排查步驟

1. 對比來源站點與 CDN 的回應標頭

# 直連來源站點
curl -I -H "Accept-Encoding: gzip" https://<來源站點網域名稱>/<資源路徑>

# 經 CDN 訪問
curl -I -H "Accept-Encoding: gzip" https://<加速網域名稱>/<資源路徑>

對比兩側的 Content-Encoding、Content-Length、Content-Type 是否一致。

2. 檢查 CDN 智能壓縮配置

若來源站點已返回壓縮內容（回應標頭含 Content-Encoding: gzip），CDN 不應再次壓縮。若出現雙重壓縮，檢查 CDN 控制台"智能壓縮"是否開啟，或關閉 CDN 側壓縮讓來源站點全權處理。

3. 修複來源站點回應標頭

確保來源站點返回壓縮內容時必須同時設定正確的 Content-Encoding 頭，否則 CDN 無法識別內容已壓縮。

問題現象

不同使用者訪問同一頁面時獲得了其他使用者的會話資訊（如登入態串號），或登入後立即失效。

問題原因

來源站點在動態網頁面響應中返回了 Set-Cookie 頭，若該響應被 CDN 緩衝，其他使用者命中緩衝後會收到不屬於自己的 Cookie，導致會話資訊混亂。

解決方案

1. 來源站點對含 Set-Cookie 的響應設定不緩衝

在來源站點側對動態網頁面添加 Cache-Control: no-store 或 Cache-Control: private，防止 CDN 緩衝包含使用者私人資訊的響應。

2. CDN 側配置緩衝規則

在 CDN 控制台為動態網頁面（如 .php、.jsp、/api/ 路徑）配置"不緩衝"規則，確保這些請求始終回源。

3. 使用 CDN 的修改入站回應標頭功能去除回應標頭

若確認 Set-Cookie 對 CDN 緩衝情境無意義（如統計 Cookie），可在 CDN 側配置修改入站回應標頭功能，去除 Set-Cookie 回應標頭後再緩衝。但需確保不會影響商務邏輯。