阿里雲企業帳號開通 CDN 加速後圖片無法顯示解決辦法

前言：為什麼 CDN 會讓圖片突然「看不見」

很多網站在上 CDN 之後會變快，但也可能出現一種很刺眼的狀況：頁面速度明明提升了，卻有圖片不顯示、顯示灰框、或只在特定網路環境下失效。這通常不是單一原因造成，而是「加速後的交付鏈路」比你原先想像的更長：URL 解析、重寫規則、快取策略、回源流程、響應頭（MIME、緩存標記、權限）、以及瀏覽器的安全策略都可能在某一步出錯。

解決這類問題，核心思路不是猜測，而是把現象拆成幾個可驗證的問題：圖片到底有沒有被 CDN 命中？CDN 回了什麼？瀏覽器收到的回應頭是否正確？和你源站相比到底差在哪裡？只要你沿著這個順序排查，通常都能在短時間內定位到根因。

第一章：先辨認「錯的是 CDN 還是圖片連結」

圖片不顯示時，第一反應往往是「CDN 壞了」。但其實你更應該先確認：瀏覽器是否連到了正確的 URL。

1. 檢查 HTML/模板中的圖片路徑是否正確

在加 CDN 之前，你可能使用了相對路徑或站內拼接方式，例如 /images/a.png。加速後，如果你把域名換成了 CDN 域名，模板是否同步更新？若你只是把靜態資源交由 CDN，卻沒有統一域名，瀏覽器就可能請求到不存在的主機或路徑。

建議你直接在瀏覽器開發者工具中查看 Network（網路請求）列表，點開失敗的圖片請求，觀察：

• Request URL 是否是 CDN 域名？
• Path 是否與源站一致？
• 是否出現了重複路徑（例如 /cdn/cdn/images/1.png）或多了一段前綴（例如 /static/images/...）？

2. 看瀏覽器控制台與狀態碼：404、403、415、206 都有不同含義

常見狀態碼對應的方向不同：

• 404：URL 在 CDN 或回源端找不到，通常與重寫規則、路徑映射、大小寫有關。
• 403：權限策略擋住了（例如需要簽名、Referer 被限制、源站 ACL 不允許 CDN 取回）。
• 415/不支援的媒體類型（較少見但會發生）：MIME 類型不對或響應頭被攔改。
• 阿里雲企業帳號開通 206 Partial Content：若 Range 請求處理異常，部分圖片（尤其大圖、背景圖）可能顯示不完整或不顯示。

你不用全懂，但要明白：看懂狀態碼，等於把排查範圍縮小一半。

第二章：最常見原因——快取沒更新或指向了錯的內容

CDN 的價值在於「命中快取」。但這也意味著：如果你更新了圖片、改了檔名或替換了資源，而 CDN 仍在提供舊版本甚至錯版本的內容，就會造成「看起來像失效」的結果。

1. 檔案已替換但 CDN 仍返回舊的內容

常見情境是：源站已把 banner.jpg 換成新檔，但 URL 沒變。CDN 若採用長緩存（例如一年），會繼續回舊內容。某些情況下舊內容本身已刪除，導致回源失敗或 CDN 快取到不完整資料。

你可以用兩個手段判斷：

• 在回應頭中查看 Age、X-Cache（不同 CDN 可能有不同欄位），確認是否命中快取。
• 直接把同一張圖的 URL 在無痕/不同網路下測試，或暫時清除快取再測。

2. 需要「清除快取」而不是只改源站

更新圖片後，如果 CDN 允許你發起 Purge/Invalidate，應該在部署流程中把它納入。尤其在你使用內容雜湊檔名的策略之前（例如 image.abc123.png），你得確保「清掉舊資源」或「更換 URL」。

如果你無法全面 purge，也可以採取精準清除：只清掉受影響的路徑，例如 /images/banner.jpg 或某個目錄。

3. 反向：源站內容正確，但 CDN 快取了「錯誤回應」

更麻煩的一種：某次短暫故障讓源站回了 404/500，但 CDN 把這個錯誤也快取起來。你修好了源站之後，瀏覽器仍拿到 CDN 的錯誤頁面。

解法很直接：查看 CDN 的錯誤快取 TTL（如果有設定），並執行對應的錯誤快取清除。

第三章：HTTPS、重定向與 Mixed Content 的坑

圖片在 HTTPS 頁面中引用 HTTP 時，瀏覽器可能直接阻擋（Mixed Content）。加 CDN 後，URL 結構容易變動，導致部分資源仍沿用 http，或 CDN 的重定向規則不一致。

1. 確認圖片 URL 的協定是 HTTPS

在 Network 裡，如果看到圖片請求是 http://，就要立刻處理。你可以：

• 統一在模板中使用協定無關寫法（例如使用以 // 開頭）或直接改成 https:// CDN 域名。
• 在 CDN/反代層配置 HTTP→HTTPS 301/302。

但注意：重定向的狀態碼與鏈路可能影響快取，尤其是你把圖片經過多層重定向後，CDN 可能無法按預期命中快取。

2. 路徑重寫造成的 301 循環

有些系統會同時在源站和 CDN 都配置重寫或強制結尾斜線。結果可能形成重定向鏈：例如 /img/a.png ↔ /img/a.png/。瀏覽器遇到循環重定向會直接失敗。

阿里雲企業帳號開通 你可以從 Network 裡查看「跳轉鏈」，並在 CDN 端檢查 rewrite 規則是否互相打架。

第四章：MIME 類型錯誤與壓縮策略導致圖片損壞

瀏覽器能不能正確顯示圖片，不只看內容是否存在，還看「它被宣告成什麼」。如果 CDN 對圖片的 Content-Type 判斷錯誤，或者壓縮/轉碼策略損壞了二進位，圖片可能顯示為空白或失敗。

1. Content-Type 必須正確

常見問題包括：

• .jpg 被回成 text/plain
• .png 被回成 application/octet-stream（通常仍可顯示，但某些環境下可能不理想）
• 回源拿到的 header 在 CDN 被覆蓋

在 Network 裡打開該圖片的 Response Headers，確保 Content-Type 與檔案類型一致。若不一致，你需要回到 CDN 的「媒體類型探測」或「header 覆蓋」設定。

2. 不要對圖片做不合適的轉碼

某些 CDN 支援壓縮或轉碼（例如把圖片轉成 WebP/AVIF）。如果你的站點或前端仍請求原格式，但 CDN 的轉碼條件或 Accept 頭處理有問題，就可能回錯格式，導致顯示異常。

排查方法：

• 查看 Response Headers 裡是否有 Content-Encoding（例如 gzip/br）和轉碼標記。
• 比較同一張圖在 CDN 與源站直接直連（繞過 CDN）時 Response Headers 差異。

3. Range 請求與大文件傳輸

圖片在某些情況會使用 Range（例如視頻流旁的預讀、瀏覽器的加載行為）。若 CDN 或源站對 Range 處理異常，可能導致圖片讀取不完整。

如果你看到回應狀態碼是 206，但圖片仍不顯示，應優先檢查：

• 是否允許 Range
• 是否在回源層正確處理 Range
• 是否有錯誤的 Cache 行為導致混亂的分段快取

第五章：權限與安全策略——403 的常見來源

很多網站對圖片採用保護策略，例如只允許特定 Referer、或使用簽名 URL、或源站只允許 CDN IP 回源。加 CDN 後，最容易翻車的就是「CDN 送出的回源請求或使用者請求沒有被允許」。

阿里雲企業帳號開通 1. 檢查 403：是 CDN 層擋了，還是源站層擋了

在狀態碼 403 的 Response 中看是否有 CDN 自己的錯誤頁面或 header 標記。你也可以用日誌確認失敗請求的來源。

若是源站擋：

• 把 CDN 的回源 IP 加入 allowlist
• 檢查源站安全群組/防火牆是否阻擋 CDN
• 確認簽名策略是否同樣適用於 CDN 發出的請求

若是 CDN 層擋：

• 檢查是否啟用 Referer 校驗導致跨域或不同來源被拒
• 檢查是否需要簽名 token，且 token 的生成與有效期是否正確

2. 使用「授權後再快取」的誤區

阿里雲企業帳號開通 有些團隊在 CDN 上設置「對需要權限的資源也快取」但沒有把授權因子納入快取 key。結果可能出現：某次有權限的用戶先命中，下一位無權限用戶也拿到快取（或反過來）。圖片就會在不同用戶間呈現隨機失效。

解法通常是：

• 讓快取 key 包含授權相關參數（例如 token、header、query）
• 或對受保護資源改為不快取/短快取，避免授權混雜

第六章：跨域、CORS 與前端讀取方式造成的「看似不顯示」

很多人看到圖片不顯示就以為是資源不存在，其實是前端使用方式導致。

1. 如果是 標籤，CORS 通常不是主因

純粹用 <img src='...'> 顯示圖片時，瀏覽器通常不需要 CORS header。真正需要 CORS 的多半是你用 canvas.drawImage、或用 JavaScript 讀取圖片再處理。

2. 如果是 canvas/背景圖/動態處理，CORS 就可能是根因

阿里雲企業帳號開通 當前端把圖片載入到 canvas 再導出，或使用某些庫做裁切、拼接，若 CDN 回應沒有允許跨域（Access-Control-Allow-Origin），瀏覽器可能報錯並阻止像素讀取，進而造成最終顯示或轉檔失敗。

排查方法：

• 控制台是否有 CORS 相關錯誤
• Response Headers 是否包含 Access-Control-Allow-Origin

第七章：重寫規則、路徑映射與大小寫問題

CDN 介入後，常見還有「重寫規則」或「路徑映射」。一個小小的規則偏差，就可能讓部分圖片失效，而其他圖片沒事，形成難以定位的狀況。

1. 對象存儲的路徑前綴不同

例如你源站對外是 /images/a.png，但實際回源到物件存儲是 prod/images/a.png 或 bucket/images/a.png。若 CDN 對回源路徑的拼接規則不完整，有些路徑會成功，有些不會。

排查：

• 核對 CDN 配置中的 origin path（回源前綴）是否正確
• 抽取失敗圖片的實際回源請求路徑（在 CDN 日誌或源站日誌查看）

2. 大小寫敏感（尤其在某些系統/存儲上）

Linux/某些物件存儲對檔名是大小寫敏感。若你的源站本來容忍（例如透過某種層做了不敏感映射），CDN 直連後就會暴露問題。

例如實際檔名是 Logo.PNG，但你引用 logo.png。在某些環境下可能仍工作，在其他環境就會 404。

第八章：建立一個實用的排查流程（從 10 分鐘到定位）

你可以照下面的步驟做，基本能在短時間內收斂到根因。

步驟一：找到一張「必失敗」的圖片

選擇一張在所有環境都不顯示的圖片（或至少大多數環境失敗），不要同時處理多張，避免你把多個問題混在一起。

步驟二：抓取 Network 詳情並記錄三件事

• Request URL（是否是 CDN 域名、是否有錯路徑、是否 http/https）
• Status Code（404/403/200 但不顯示）
• Response Headers（Content-Type、Cache/Age、是否有重定向、是否 gzip/brotli、是否有 CORS）

阿里雲企業帳號開通 步驟三：對比源站直連結果

用源站域名（繞過 CDN）直接請求同一張圖（如果你有權限）。對比 response headers 和實際內容大小。

• 阿里雲企業帳號開通 源站 200、CDN 404：多半是回源路徑/重寫/大小寫問題
• 源站 200、CDN 403：多半是權限或回源 IP/簽名限制
• 兩邊都 200，但 Content-Type 或 Encoding 不一致：多半是 MIME/轉碼/壓縮問題

步驟四：檢查 CDN 快取是否命中錯誤內容

查看回應頭中的快取標記與 Age。若狀態碼不是期望的，或大小明顯異常，嘗試 purge 該資源，觀察恢復是否立刻發生。

步驟五：看 CDN/源站日誌的對應請求

如果你能查日誌，就不要只看瀏覽器。日誌能告訴你：

• CDN 是否命中
• 是否回源成功，回源用了什麼路徑
• 源站回的是什麼狀態碼

第九章：針對不同根因的解決方案清單

下面整理一份「對應關係」，讓你更快落地。

1）路徑或 URL 錯配（404）

解決：

• 統一圖片引用的域名與協議（https）
• 檢查 CDN 的重寫/轉發規則是否正確映射到回源路徑
• 修正前端模板的拼接邏輯，避免多餘前綴
• 核對檔名大小寫

2）權限或安全策略（403）

解決：

• 將 CDN 回源 IP 加入源站 allowlist
• 調整 Referer/簽名 token 策略或快取 key
• 確保 CDN 對受保護資源的授權流程一致

3）快取未更新或快取了錯誤（持續不恢復）

解決：

• 阿里雲企業帳號開通 對目標路徑 purge/invalidate
• 檢查錯誤回應是否被快取，降低錯誤 TTL 或排除
• 部署流程加入資源發布後的快取清除

4）MIME/壓縮/轉碼（200 但顯示失敗或內容損壞）

解決：

• 校正 CDN 的 Content-Type/媒體類型探測
• 暫時關閉特定圖片類型的轉碼或壓縮，確認是否恢復
• 檢查 Range 支援與分段快取策略

5）CORS（前端 canvas/讀取失敗）

解決：

• 在 CDN/源站回應加上合適的 Access-Control-Allow-Origin
• 若只允許特定來源，精確配置允許列表

第十章：如何避免再發生——把 CDN 變成可控系統

CDN 的運維不只是「開起來就好」。尤其圖片屬於高頻、且一旦失敗體感很強的資源，應當納入更嚴謹的發布與監控。

1. 部署時把「資源發布」與「快取處理」綁在一起

最好做法是：資源 URL 使用版本號或檔名雜湊，讓新舊資源天然分離；同時仍保留 purge 機制做補救。這能大幅降低「忘了清快取」造成的事故。

2. 配置灰度與回滾，而不是一口氣切全站

你可以先對部分流量、部分路徑或部分圖片類型啟用 CDN 規則；一旦發現圖片異常，立即回滾到穩定配置。灰度的價值在於：縮小影響範圍，讓你能用更少的時間定位問題。

3. 監控「圖片可用率」而不只是整體性能

很多團隊只看網站延遲、吞吐或錯誤率，卻不針對圖片做監控。你可以建立：

• 關鍵圖片的定時探測（例如固定幾張 banner/thumb）
• 失敗率告警（404/403/非預期 Content-Type）
• 內容大小異常偵測（例如 PNG 回應大小突然變成很小）

結語：解決問題其實是在「看清整條鏈路」

CDN 加速後圖片無法顯示，通常不是一個玄學事件。你看到的是結果，但根因藏在鏈路的細節：URL 是否正確、快取是否正確、回源是否被允許、響應頭是否正確、以及轉碼/壓縮是否破壞內容。只要你沿著「狀態碼與回應頭 → 源站對比 → 快取與日誌驗證」這條路走，就能從混亂中抽絲剝繭。

阿里雲企業帳號開通 把排查做成流程，把部署做成可回滾，把監控做成能直接反映圖片可用率，你就不會每次出現問題都憑經驗硬猜。下一次圖片再失效，你需要的不是運氣，而是可重複的判斷方法。