Azure企業帳號開戶 Azure CDN提示源站無法訪問排查

第一章：先搞清楚「無法訪問」到底是哪一段失敗

「Azure CDN 提示源站無法訪問」這句話看似籠統，但它通常指向同一件事：CDN 節點嘗試回源時，沒有拿到源站可用的回應。要有效排查，關鍵不是立刻改一堆設定，而是先把失敗點切分成幾段：CDN 解析到哪個源站、能否建立連線、連上後是否通過安全策略、以及源站回來的狀態碼是否符合 CDN 的預期。

你可以把它想成一次「快遞派送」：CDN 就像分揀中心，源站是倉庫。快遞到不了倉庫，原因可能是地址（DNS/主機名）錯、路線（網路/防火牆）不通、門禁（TLS/憑證/WAF）不放行、或倉庫回來的文件（狀態碼/路徑）不符合流程。只要把原因分層定位，修復就會很快。

1.1 先記錄你看到的錯誤型態

不同訊息會引導不同方向。例如：

• 若是明確的回源失敗、超時類訊息，通常是連線層或網路層問題（路徑、端口、防火牆、NSG、TLS 握手卡住）。
• 若是憑證或 TLS 相關字樣，往往與 HTTPS 回源、憑證鏈、SNI、憑證主體名稱不匹配有關。
• 若是 404/403/502/503 之類狀態碼，可能是源站路由或權限策略造成，但也要注意 CDN 的回源配置（例如回源路徑、查詢字串、標頭轉發）是否一致。

建議你在第一次排查時就保存：客戶端看到的狀態碼、錯誤頁面內容（或錯誤代碼）、發生時間範圍、使用的 CDN 結點類型與域名（自訂網域/預設網域）。這些資訊在後面比猜更省時間。

1.2 確定你是「回源問題」而非「快取問題」

很多人看到錯誤就直接當作源站掛了，但實際上可能是快取策略或內容更新導致「回源觸發」。例如當你剛更新了規則、調整了路徑轉換、或過期被清除後，才突然出現無法訪問。你需要確認錯誤發生時，CDN 是否確實需要回源（命中率下降、或冷啟動）。

如果你能在監控中看到某些 URL 同時失敗，而其他 URL 正常，這就更像路徑或安全策略的「局部錯誤」，而不是整個源站完全不可用。

第二章：回源主機與路徑配置是第一嫌疑犯

Azure CDN 的回源設定包含「回源主機名」「協定（HTTP/HTTPS）」「回源端口」「回源路徑/原始路徑」「查詢字串與標頭如何處理」等。很多「源站無法訪問」都從這裡開始。

2.1 檢查回源主機名：DNS 解析是否正確

Azure企業帳號開戶 先從最容易的做法開始：核對你填的回源主機名是否是你以為的那個。

• 如果你在回源配置的是「域名」，請確認該域名在 CDN 區域節點上能解析到正確的 IP。
• 若你的源站有多個 IP（負載平衡器、CDN 之後再回源、或彈性伸縮），解析結果變動可能導致部分節點連不上。
• 如果你最近改過 DNS 記錄，確認變更已完成並觀察 TTL。

實務上，你可以讓團隊從源站運維端驗證：目前源站域名的 A/AAAA 記錄是否存在、指向的是否是對外可連線的地址、以及是否需要特定路由或私網連線。

2.2 檢查回源協議與端口：HTTP/HTTPS 不一致會很致命

很多錯誤不是「源站真的不能用」，而是 CDN 用了你沒料到的協議方式回去。

• 你在源站只開了 HTTPS，但 CDN 回源設定成 HTTP；或反過來。
• 你源站只允許 443，但 CDN 回源設定了 80。
• 你的源站背後是反向代理，對特定端口才會轉發。

建議把回源協議、端口、以及源站實際開放端口整理成一張表，與 CDN 設定逐項比對。這類問題常常在「看起來差不多」時發生，例如 URL 在瀏覽器可打開，但 CDN 回源路徑導向了不同端點或不同協議。

2.3 回源路徑/路徑重寫：URL 轉換一個斷點就會 404

CDN 常需要把對客戶端暴露的路徑轉換成源站實際資源路徑。只要轉換邏輯有偏差，CDN 就會回源成功但拿到 404/403，最後被包裝成「無法訪問」。

你要特別注意：

• Azure企業帳號開戶 是否有前導斜線缺失或多出。
• 是否包含了不該轉發的查詢字串或不該保留的路徑段。
• 是否區分大小寫；某些後端或儲存服務對大小寫敏感。

最有效的方式是選一個「你確定會錯」的 URL，對照 CDN 的規則，推算 CDN 送往源站的實際回源 URL，再到源站端人工驗證該回源 URL 是否存在。

第三章：HTTPS 回源與憑證問題：常見但容易被忽略

如果你回源使用 HTTPS，那你的排查重點就要往 TLS 與憑證靠近。很多情況下你自己用瀏覽器可以連上，但 CDN 節點因為 SNI、憑證鏈或中介憑證不同而失敗。

3.1 憑證鏈不完整：瀏覽器常常會「容忍」

瀏覽器有時會透過系統信任庫或額外機制容忍鏈不完整，但 CDN 節點的驗證可能更嚴格。你需要確認源站的憑證：

• 中介憑證是否完整上傳（不是只上 leaf 憑證）。
• 憑證是否在到期日前、且未被吊銷。
• 憑證是否符合回源主機名。

如果你最近換過憑證或更新過負載平衡器，這是最值得優先查的時間點。

Azure企業帳號開戶 3.2 SNI 主機名不一致：一樣的 IP，不一樣的憑證

當源站背後是多站點共用（同一台機器不同域名）時，TLS SNI 用來告訴伺服器「該回哪張憑證」。如果 CDN 回源使用的主機名與你後端配置不一致，伺服器可能回錯憑證，導致驗證失敗。

你可以把問題表述成一句話：CDN 回源時送出的「主機名」是不是你在源站用來綁定憑證的那個名字？如果不是，就要修正 CDN 的回源主機或憑證綁定。

3.3 TLS/加密套件：老系統更容易踩坑

如果你的源站是較舊的服務或反向代理設定，可能不支援 CDN 節點可用的最低 TLS 版本或加密套件。這類問題通常表現為握手失敗或超時。

建議你對源站升級到至少 TLS 1.2，並確保沒有「只允許特定舊套件」的硬性限制。

第四章：安全策略與網路連線：防火牆、WAF、NSG 與存取限制

即使 DNS 與憑證都正確，只要源站把 CDN 節點擋在門外，就會得到「源站無法訪問」。這一章是排查中最容易讓人忽略、但也最常見。

4.1 只允許特定來源 IP：CDN 節點可能沒有在白名單

許多團隊會在源站加上「只允許某些 IP」的規則，特別是當他們希望防止非預期流量。Azure CDN 的節點 IP 不是單一固定值，通常會因部署區域而變動。

如果你使用的是「把 CDN 的節點 IP 全寫死」這種方式，改動很容易漏網。更穩妥的做法是使用 Azure 官方建議的方式來識別合法來源（例如利用特定標頭或使用對應的驗證機制）。

排查時，你可以先暫時放寬規則（在測試環境或縮小範圍）確認是否為白名單問題，再回到正式環境做正確的範圍設計。

4.2 NSG/防火牆：私網源站是否被連上了

Azure企業帳號開戶 如果你的源站不是公網可達，而是部署在私網（例如內部 VM、內部負載平衡器），CDN 不能直接連私網，除非你使用了特定方案（例如透過 Private Link、或把源站暴露在可回源的通道）。

你需要確認：

• 回源端點是否真的對 CDN 可達（路由與防火牆策略）。
• 是否有應用層限制（例如要求特定 Header 才放行）。
• 如果你用 Private Endpoint，對應的回源方式是否符合 CDN 支援。

4.3 WAF/應用層防護：阻擋了 CDN 節點的特徵

WAF 常根據規則封鎖疑似攻擊流量。CDN 回源請求的標頭、User-Agent、來源 IP 與一般瀏覽器不同，可能觸發誤封。

建議你在 WAF 日誌或防火牆事件中找「相同時間段、相同回源主機」的阻擋紀錄。你要找的是「被拒絕的原因」而不是只看是否有事件。

第五章：利用監控與日誌，把「猜測」變成「證據」

排查的核心不是你改了多少設定，而是你能否用證據證明某一段成功或失敗。Azure 的監控資源通常包括 CDN 的日誌/計量、以及源站端的存取日誌、錯誤日誌、TLS 事件或防火牆事件。

5.1 先對齊時間：以分鐘為單位，而不是以「大概」為單位

很多人排查時沒有對齊時間，導致你在源站找不到對應的錯誤。正確做法是：

• 記下 CDN 報錯開始與結束的時間。
• 源站端也用同樣的時間窗查看存取失敗、TLS 錯誤或拒絕事件。
• 若有多區服務（多台/多域名），要確保你的日誌聚合設定能覆蓋到同一時間窗。

5.2 看源站是否「真的收到了回源請求」

這一步能快速縮小範圍：

• 如果源站完全沒有收到任何回源請求：多半是 DNS/網路/防火牆拒絕或路由問題。
• 如果源站收到了請求但回了錯誤碼：多半是路徑轉換、權限、應用邏輯或 WAF 規則。

你可以從源站的訪問日誌中搜尋該 URL 或請求方法（GET/HEAD）、以及是否存在與 CDN 相關的標頭。若你的系統有記錄來自 CDN 的辨識資訊，更能快速判斷。

5.3 利用錯誤碼反推失敗層級

常見情形可以這樣理解：

• 回源超時：多半是網路連線、端口通不通、或 TLS 握手卡住。
• TLS/憑證錯誤：是回源協議或 SNI/憑證鏈。
• 403：多半是 WAF、應用層授權、或要求特定標頭。
• 404：多半是回源路徑或重寫規則問題。
• 502/503：可能是源站本身回應不穩、或反向代理超時、或負載均衡後端不健康。

不要把所有狀況都歸因「源站掛了」。如果源站端日誌顯示有請求但回 404/403，那你要調的是 CDN 回源映射或安全策略，而不是去重啟服務。

第六章：設定類問題的典型坑位（你很可能踩過其中一個）

除了純網路與憑證，還有一些「看似小設定」會造成回源失敗。這些問題通常發生在上線變更、規則調整、或把多個服務混搭後。

6.1 回源主機名與 Host Header：後端依賴 Host 的就會出事

許多後端應用根據 Host Header 路由到不同租戶或不同站點。如果 CDN 回源時沒有轉發正確的 Host，後端就可能回 404 或導向錯誤位置。

你需要確認 CDN 的設定中，回源請求使用的 Host Header 是否符合你的應用期待。排查時，你可以在後端日誌中看實際收到的 Host。

6.2 查詢字串/標頭不一致：簽名驗證與快取規則打架

若你的源站有簽名驗證（例如依賴特定查詢參數或標頭），CDN 若沒有保留或正確轉發這些資訊，就會讓源站拒絕回源。

此外，某些快取規則可能導致 CDN 把「錯誤版本」快取住，造成你修好了源站但仍舊持續錯誤。你需要檢查是否有錯誤回應被快取、以及清除快取的行為是否已完成。

Azure企業帳號開戶 6.3 區域與地理限制：規則層造成的表面錯誤

你可能看到「源站無法訪問」是因為 CDN 在邏輯上先判斷規則不允許，然後導致回源行為與預期不同。這通常需要你檢查 CDN 的路徑規則、地理限制、以及自訂錯誤處理。

做法是：選擇一個錯誤的 URL，檢查它在 CDN 的規則評估中會落在哪條規則（通常是多條規則優先順序的結果）。確認回源規則沒有被覆蓋。

第七章：一個可直接照做的排查流程

下面給你一套更像「值班手冊」的流程。目標是讓你在 30 到 90 分鐘內鎖定大方向，再進入精修。

7.1 第一步：選定一個失敗 URL，先驗證它的回源映射

挑一個明確出錯的 URL（不要用首頁這種可能被重寫的）。記錄客戶端看到的錯誤狀態碼與時間。

接著根據你目前 CDN 設定，推導回源時會呼叫的源站 URL（包含協議、主機、路徑、以及查詢）。如果你無法推導，就直接在源站日誌中搜尋類似路徑（或使用源站端的應用追蹤）。

7.2 第二步：在源站端直接測「同一個 URL」是否可用

從一台能連到源站的機器（最好與 CDN 所在網段接近，或使用同一 VNet/同一出站策略）直接呼叫回源 URL。

• 若源站端都回 404/403：直接修源站路由或權限，不要把時間浪費在 CDN。
• 若源站端可回成功但 CDN 失敗：再回到 DNS、TLS、或安全策略。

7.3 第三步：檢查回源端點的可達性與端口

Azure企業帳號開戶 針對回源協議與端口做連通性驗證。重點是端口是否開放、是否被防火牆或 NSG 阻擋。

如果你看到源站完全沒收到請求，通常連線階段就已被拒絕。

7.4 第四步：針對 HTTPS 做憑證與 SNI 檢查

確認憑證鏈完整、域名匹配、SNI 與回源主機名一致。若源站在你本機可用，仍要考慮 CDN 節點的驗證差異。

7.5 第五步：檢查 WAF/存取控制與拒絕紀錄

在與錯誤時間窗對齊的狀況下，查看防火牆與 WAF 日誌，找出被拒絕的原因碼。只要能定位到「拒絕類型」，修復就會具體：

• 是 IP 白名單：更新識別策略或放寬對應範圍。
• 是缺少標頭或簽名：檢查 CDN 的標頭/查詢轉發設定。
• 是速率限制或規則命中：調整 WAF 規則優先順序或例外條件。

7.6 第六步：修復後做「清除快取 + 驗證」

很多錯誤在修復前後仍會持續一段時間，原因是快取。你需要確認是否有錯誤快取、是否需要清除特定路徑或整體快取，再用不同 URL 測試命中/回源行為。

驗證時，不要只測一個 URL。至少測三種：

• 確定存在的資源（應回源成功）。
• 不存在的資源（應回 404/正確錯誤頁，但不要再出現「源站無法訪問」）。
• 帶查詢參數或簽名的資源（確認轉發與權限流程不被破壞）。

第八章：修好之後如何避免再發生

「源站無法訪問」通常不會憑空發生，它多半與近期變更相關。要降低再次踩坑的機率，你需要在流程上做幾個預防動作。

8.1 變更前後要有對照：回源設定與源站可用性基線

每次調整 CDN 回源協議、憑證、路徑轉換規則、或安全策略，最好留存一份基線紀錄。例如：

• 回源主機名、協議、端口
• 是否使用 HTTPS 回源、憑證到期日
• WAF/防火牆例外條件
• Azure企業帳號開戶 快取規則與錯誤快取 TTL

這能讓你一旦出現問題，快速回到「變更點」而不是從零猜。

8.2 監控不要只看流量：要看回源錯誤率與失敗類型

Azure企業帳號開戶 若你只監控總流量，很可能問題開始但你注意不到。更好的做法是把監控聚焦在回源失敗率、常見錯誤碼分佈（timeout、TLS、403、404），以及源站端的拒絕/錯誤事件。

8.3 讓源站端日誌能回答兩個問題

最實用的日誌粒度是能回答：

• CDN 的回源請求到底有沒有到？（有的話在哪台/哪個服務）
• 到達後為什麼拒絕或失敗？（TLS、WAF、路由、權限、後端健康狀態）

當你能回答這兩個問題，排查就會變得非常有把握。

結語：把問題拆開，你就能修得快

Azure CDN 提示源站無法訪問，本質上是一個「回源鏈路在某個環節斷掉」的提醒。你不需要依賴運氣，也不需要一次性推翻設定。只要按順序處理：回源主機與路徑→協議與端口→HTTPS 憑證與 SNI→網路連線與安全策略→用日誌確認請求是否到達與失敗原因，通常就能在短時間內定位到根因。

如果你願意，把你目前的回源設定（主機名、協議、端口、是否自訂網域）、錯誤出現時間、以及源站端是否有相應回源請求的證據整理出來，我也能幫你把下一步排查目標再縮小到最可能的兩三個項目。