CDN 雷達
正在測試…
結果是你目前網路和分流規則下的情況。
頁面從 static.figma.com 取一個小檔案，它在 Amazon CloudFront 上。回應的 Server-Timing 裡，Cdn-Pop 一項寫著回應的節點。
CloudflareCloudflare 中國網路AkamaiFastlyAzure Front DoorBunny CDNWikimediaGoogle阿里雲騰訊雲 EdgeOne網宿GcoreCDN77
大型 CDN 有幾百個節點（也叫 POP、機房）。你被分到哪個節點，決定了這家 CDN 上所有網站對你來說有多快，而且不一定是最近的那個。
頁面從你的瀏覽器向每家 CDN 請求一個小檔案，就像開網站一樣，然後讀出是哪個節點回應的。接著顯示這個節點離你多遠、往返時間多少，以及依距離算出的理論最低值。
不會傳任何資料給本站：請求從你的瀏覽器直接送到各家 CDN。
每家 CDN 都會把節點寫進回應裡，寫法各不相同：
Cloudflare：/cdn-cgi/trace 的 colo 欄位（HKG）。
Amazon CloudFront：Server-Timing 的 cdn-pop，或 X-Amz-Cf-Pop（NRT57-P11）。
Akamai：Akamai-Request-BC，直接寫城市（JP_13_TOKYO）。
Fastly：X-Served-By（cache-nrt-…-NRT）。
Azure Front Door：X-Azure-Ref（…C1TYO…）。
Bunny：Server 標頭（BunnyCDN-JP1-…）。
Wikimedia：X-Cache，快取伺服器的編號代表機房。
瀏覽器只有在回應允許時才讀得到這些資訊，所以每家 CDN 都選了一個允許讀取的公開檔案來測。Google、阿里雲、騰訊雲 EdgeOne、網宿、Gcore 和 CDN77 都不允許，所以只測延遲。
CDN 並不按距離分配。Cloudflare、Akamai 等會在許多地方同時宣告同一組位址（Anycast），或依你的 DNS 所在位置回傳位址，最後走哪條路由你的電信業者決定。
在中國大陸這很常見：Cloudflare 免費版和低價方案的網站，在許多電信業者那裡會繞到美國西岸等遠處的節點，因為這些路線較便宜。付費方案和中國網路（與京東雲合作）則由香港或中國大陸的節點回應。
代理和 VPN 也會改變節點：CDN 看到的是代理的位址，依代理所在位置分配。
光在光纖裡每毫秒大約走 200 km，所以距離 d 的往返時間不可能低於 d ÷ 100 毫秒。實際路線比直線長 1.5 到 2 倍。往返時間超過理論值的兩倍再加 40 ms，就標為「繞遠了」：路線繞了路，或是在壅塞的鏈路上排隊。
對於公開全部節點的 CDN（Cloudflare、Bunny、Wikimedia），頁面會找出離你最近的節點。如果實際回應的節點比它遠 1000 km 以上、而且遠一倍以上，就會標出來。這不算故障：是 CDN 或你的電信業者選了另一條路。
輸入一個網域。本站的 Worker 用 Cloudflare 的 DNS 查詢它的解析紀錄（不受本地或被汙染的結果影響），從 CNAME 指向的位址認出 CDN；向網站請求 /cdn-cgi/trace 判斷是不是 Cloudflare；如果網站允許，還會讀出它 favicon 回應標頭裡的節點。最後測一下這個網站的延遲。
網域會送給本站的 Worker 和 Cloudflare 的 DNS，兩者都不保存。
依你的 IP 位址，由 Cloudflare 判斷（本站運行在 Cloudflare 上）。通常能精確到城市，但也可能差幾百公里；用了代理時，得到的是代理的位置。「使用精確位置」會改用瀏覽器的定位，只在頁面裡使用。
不會。請求從你的瀏覽器直接送到各家 CDN，它們和任何網站一樣看得到你的 IP 位址。本站不保存任何東西。分享連結裡有節點和往返時間；你的城市、座標（精確到約 10 公里）和電信業者只有在你勾選後才會加入，IP 位址永遠不會。程式碼在 GitHub 上開源。
網頁沒辦法決定請求走直連還是走代理，這由你的代理客戶端按分流規則決定。預設的測試反映你平時的真實情況。
想只測一種：把下面的規則加到客戶端規則清單的最前面，然後重新測試。全部直連測的是你本地的網路；全部代理測的是代理伺服器到各家 CDN。測完記得刪掉這些規則。
全部直連時，在中國大陸有些 CDN 可能連不上，這本身也是結果。
全部在你的瀏覽器裡執行。無需帳號，不收集測試結果。
© 2026 1ms.dog