CDN 加速有沒有生效？怎麼測試？網站 CDN 速度檢測方法

CDN 接入成功不代表加速一定生效。本文介紹如何透過 DNS 解析、HTTP 回應標頭、快取 HIT/MISS、TTFB 及多地區測速判斷 CDN 是否正常運作，並分析 CDN 加速不明顯、回源慢和部分地區存取慢等常見問題。

2026-09-155 分鐘閱讀

網站接入 CDN 之後，頁面能正常打開，並不代表 CDN 加速已經真正發揮作用。有些網站雖然已經修改了解析，存取請求也確實經過 CDN，但靜態資源始終沒有命中快取，每次仍然需要回源；還有一些網站 CDN 接入本身沒有問題，卻因為節點調度、回源線路或者源站回應慢，實際存取速度並沒有明顯改善。

判斷 CDN 有沒有生效，不能只看「網站能不能存取」，也不能只看一次 Ping 結果。更可靠的方式，是從網域解析、回應 Header、快取狀態、TTFB、多地區存取速度幾個方面一起檢查。

一、如何確認 CDN 加速是否生效？

很多站長配置完 CDN 以後，第一件事就是打開網站看一下。網站能存取，圖片能載入，於是就認為 CDN 已經配置成功。從接入角度來說，這確實可以說明配置沒有出現嚴重錯誤，但如果要判斷「CDN 加速有沒有生效」，還需要再往下看。

一般來說，可以分成三個層面：

判斷層面	需要確認的問題
CDN 接入	使用者請求是否已經經過 CDN 節點
CDN 快取	靜態內容是否能夠直接從邊緣節點返回
實際速度	不同地區存取網站後是否真的變快

也就是說，網站接入 CDN 只是第一步。真正有效的 CDN 加速，應該是使用者存取請求先到距離自己較近的邊緣節點，能夠快取的內容直接從節點返回，減少存取源站的距離和次數。如果請求雖然經過 CDN，但每次都需要回源，那麼 CDN 在快取加速方面發揮的作用就會比較有限。

二、先檢查網站有沒有真正走 CDN

判斷 CDN 是否生效，第一步可以從網域解析開始。

大多數 CDN 在接入時，會要求網站把網域透過 CNAME 或相應的解析方式指向 CDN 平台提供的位址。

例如原本：

www.example.com → 源站 IP

接入 CDN 後可能變成：

www.example.com → CDN 提供的 CNAME → CDN 節點

如果網站網域仍然直接解析到原來的源站 IP，就需要先檢查 CDN 接入配置是否已經完成。

不過，這種方法只能作為第一層判斷。

不同 CDN 的網路架構和接入方式並不完全一樣，一些代理型 CDN、Anycast 網路或者隱藏節點資訊的服務，並不能簡單透過「解析出來的是不是源站 IP」來判斷。

所以 DNS 解析正常以後，還需要繼續檢查實際請求。

三、檢查 HTTP 回應標頭，看請求是否經過 CDN

比單純看 DNS 更直接的方法，是查看網站返回的 HTTP 回應標頭。

可以在 Chrome 中打開目標網站，按下 F12，進入 Network 面板，重新整理頁面後點擊主文件或者某個靜態資源，再查看 Response Headers。

也可以直接使用 curl：

curl -I https://www.example.com/

不同 CDN 返回的回應標頭不同，比較常見的欄位包括：

Age
Via
X-Cache
Cache-Status

一些 CDN 還會加入自己的節點編號、快取狀態或者請求 ID。

如果回應標頭中可以看到明顯的 CDN 節點、代理或者快取資訊，基本可以判斷當前請求已經經過 CDN 網路。

不過也要注意，並不是所有 CDN 都會公開這些資訊。

部分服務商會隱藏節點 Header，因此沒有看到 X-Cache 或 Via，也不能直接說明 CDN 沒有生效。

HTTP Header 更適合當作輔助判斷方式，最好結合後面的快取狀態和多地區測速一起看。

四、判斷 CDN 有沒有真正加速，重點看快取是否命中

這是判斷 CDN 是否真正發揮作用時最關鍵的一步。

因為：請求經過 CDN，不代表內容一定從 CDN 快取中返回。

假設使用者請求一張圖片。

如果這個檔案已經快取在邊緣節點，請求路徑大致是：

使用者 → CDN 節點 → 使用者

CDN 可以直接把檔案返回。

但如果當前節點沒有快取，就需要：

使用者 → CDN 節點 → 源站 → CDN 節點 → 使用者

這時會多出一次回源過程。

常見的快取狀態主要有：

快取狀態	含義
HIT	CDN 節點已有快取，直接返回
MISS	當前節點沒有快取，需要回源
BYPASS	根據規則跳過快取
EXPIRED	快取已經過期，需要重新驗證或取得

對於圖片、CSS、JavaScript 等靜態資源來說，如果連續請求多次仍然一直顯示 MISS，就值得檢查快取配置。

常見原因包括：

Cache-Control 設定不合理
檔案被配置為不快取
請求攜帶特殊 Cookie
URL 查詢參數導致快取鍵變化
CDN 快取規則沒有覆蓋該目錄
快取時間設定過短

正常情況下，一個適合快取的靜態資源第一次存取可能是 MISS，等節點完成回源並快取後，再次存取就可能變成 HIT。

這也是為什麼測試 CDN 時，不建議只存取一次就下結論。

五、CDN 加速前後到底有沒有變快，應該怎麼測試？

確認 CDN 已經接管請求、快取也能正常工作以後，下一步才是真正比較加速效果。

這裡不要只看 Ping。

更有參考價值的指標包括：

TTFB
HTTP 回應時間
靜態資源下載時間
不同地區存取速度
不同電信商存取差異

1. 對比 TTFB

TTFB，也就是 Time to First Byte，表示從開始發起請求，到收到第一個位元組所花費的時間。

對於能夠快取的內容來說，CDN 命中快取後通常可以減少回源等待，因此 TTFB 往往會明顯下降。

例如：

直接存取源站：TTFB 680ms
CDN MISS：TTFB 520ms
CDN HIT：TTFB 110ms

這種差異就比較明顯。

說明真正讓首位元組回應變快的，是 CDN 邊緣快取。

但如果直接存取源站是 180ms，而經過 CDN 以後是 200ms，也不能因為「用了 CDN」就強行認為速度一定提高了。

CDN 最終有沒有有效，還是要用實際測試資料判斷。

2. 對比靜態資源下載時間

除了 TTFB，還可以選擇圖片、JS、CSS 或下載檔案進行測試。

這些資源通常比較適合 CDN 快取，也更容易看出邊緣節點的實際加速效果。

例如一個 5MB 檔案，如果源站部署在美國，而亞洲使用者透過附近 CDN 節點存取，命中快取後下載速度通常會比直接跨境存取源站穩定得多。

特別是源站距離使用者較遠的網站，靜態資源的改善會更加明顯。

六、用 Chahu 做多地區網站測速，看 CDN 調度是否正常

如果只在自己電腦上測試，只能代表當前地區、當前電信商這一條網路。

而 CDN 的實際價值之一，就是讓不同地區的使用者存取距離自己更合適的節點。

因此，判斷 CDN 有沒有真正起作用，還需要看多地區測試結果。

可以使用 Chahu 做網站測速，觀察網站在不同地區、不同電信商網路下的實際存取表現。

測試時不要只盯著最快的一個節點，更應該看整體分布。

例如：

測試現象	可能的問題
全國大部分節點回應都比較快	CDN 整體調度正常
電信快，聯通和移動明顯慢	電信商線路存在差異
南方快、北方慢	節點覆蓋或調度可能不均衡
國內慢、海外快	國內節點或跨境線路需要檢查
所有地區都慢	源站、回源或 CDN 配置可能存在問題

如果只有自己所在地區存取很快，而其他地區普遍較慢，就不能說明 CDN 整體效果好；如果不同地區測速結果都比較穩定，而且比未接入 CDN 時更快，才更能說明節點覆蓋和調度發揮了作用。

七、為什麼用了 CDN，網站速度卻沒有明顯變快？

這種情況其實很常見，CDN 並不是接上以後所有頁面都會自動變快。

1. 測試的是動態頁面

CDN 最容易加速的是圖片、JS、CSS、影片、下載檔案這類靜態資源。

但像登入頁面、購物車、會員中心、即時介面這類動態內容，通常需要即時回源。

如果測試的剛好是動態 HTML，請求仍然需要經過源站處理，那麼加速效果就可能沒有靜態資源那麼明顯。

2. 快取一直沒有命中

如果靜態資源每次請求都是 MISS，CDN 節點就需要不斷向源站取得內容。

這時雖然存取路徑經過了 CDN，但真正的邊緣快取優勢並沒有發揮出來。

遇到這種情況，應該優先檢查快取規則，而不是繼續換測速工具。

3. 使用者本來就離源站很近

如果源站部署在上海，測試使用者也在上海，而且原本存取延遲就已經很低，那麼接入 CDN 後不一定會出現特別明顯的時間差。

CDN 的優勢往往在跨地區、跨電信商或者使用者距離源站較遠時更加明顯。

4. CDN 節點調度不合理

正常情況下，使用者應該被調度到網路品質較好的附近節點。

但如果 CDN 調度異常，把使用者分配到距離更遠、線路品質更差的節點，就可能出現：

接入 CDN 以後反而更慢。

這種問題通常單靠本地測試很難發現，多地區測速會更有參考價值。

5. 源站本身回應太慢

CDN 能縮短使用者與邊緣節點之間的存取距離，但無法自動解決所有源站效能問題。

例如動態頁面每次都需要回源，而源站處理請求本身就要 1.5 秒，那麼 CDN 也只能等待。

這時候真正需要優化的是：伺服器效能、後端程式、資料庫、API、頁面快取這些，而不是單純繼續調整 CDN 節點。

6. 網站真正慢在前端資源

還有一種情況是 CDN 已經正常工作，TTFB 也很低，但頁面打開後依然感覺慢。

例如：

圖片體積過大
JavaScript 執行時間太長
CSS 阻塞渲染
第三方廣告載入慢
字型檔案太大

這些問題不屬於 CDN 是否生效本身。

所以 TTFB 變快，並不代表整個頁面一定會立刻完成載入。

八、測試 CDN 速度時應該重點看哪些指標？

CDN 測速不是只看一個數字，比較有參考價值的指標可以分成下面幾類：

指標	主要用途
DNS 解析時間	判斷 CDN 調度解析是否異常
Ping/RTT	判斷使用者到邊緣節點的基礎網路延遲
TCP 連線時間	判斷建立連線是否順暢
TLS 握手時間	判斷 HTTPS 連線階段是否異常
TTFB	判斷首位元組返回速度
HIT/MISS	判斷快取是否真正生效
檔案下載時間	判斷靜態資源實際分發能力
多地區差異	判斷 CDN 節點覆蓋和調度
多電信商差異	判斷電信、聯通、移動線路表現

其中最容易被誤用的是 Ping，Ping 很低，只能說明當前網路到某個 IP 的往返延遲比較低。它並不能直接證明：網站快取已經命中；HTML 回應很快；圖片下載很快；CDN 回源正常；頁面載入速度已經提升，所以判斷 CDN 加速效果時，Ping 可以看，但不能只看 Ping。

九、判斷 CDN 加速是否生效的排查順序

如果不想一次看太多指標，可以按照一個固定順序排查。

第一步：檢查 DNS

先確認網域已經按照 CDN 要求完成解析，如果還在直接存取源站，後面的測試就沒有意義。

第二步：檢查 HTTP 回應標頭

查看請求是否經過 CDN 節點，以及有沒有對應的快取、代理或節點資訊。

第三步：測試靜態資源快取

選擇圖片、JS、CSS 等適合快取的資源，連續請求幾次。

重點觀察：

MISS → HIT

是否正常出現。

第四步：比較 TTFB

分別觀察快取命中和回源情況下的首位元組時間。

如果 HIT 明顯快於 MISS，說明邊緣快取起到了實際作用。

第五步：做多地區測速

透過不同地區、不同電信商的測試結果，看 CDN 調度是否合理。

不要只看自己本地。

第六步：和源站或接入 CDN 前的資料對比

最後再回答最重要的問題：接入 CDN 以後，使用者存取網站到底有沒有真正變快？只有前後對比以後，才能判斷 CDN 的實際效果，而不是只確認「配置已經完成」。

總結

判斷 CDN 有沒有生效，不能只看網站是否能打開，也不能只看 DNS 是否已經修改。真正有效的 CDN 加速，至少應該滿足幾個條件：請求已經經過 CDN 節點，靜態資源可以正常命中快取，並且不同地區使用者的實際存取速度能夠得到改善。

如果已經接入 CDN，但測速結果變化不明顯，可以繼續從快取 HIT/MISS、TTFB、回源時間和多地區測試結果往下排查：當快取 HIT 很快、MISS 很慢時，重點看源站和回源；只有部分地區慢，就看節點調度和線路；如果 TTFB 已經很低但頁面仍然慢，則應該把注意力轉向圖片、JS、CSS 等前端資源。CDN 是否真正有用，最終還是要看實際資料，而不是只看「CDN 已經開啟」這一項配置。