CDN レーダー
測定中…
結果は、いまのネットワークとルーティングルールでの状態です。
Alibaba Cloud はどの拠点が応答したかをウェブページから読めないようにしているため、ここでは遅延だけを測ります。ブラウザから g.alicdn.com の最寄り拠点まで、往復にかかる時間です。
CloudflareCloudflare 中国ネットワークAmazon CloudFrontAkamaiFastlyAzure Front DoorBunny CDNWikimediaGoogleTencent EdgeOneWangsu (CDNetworks)GcoreCDN77
大手 CDN それぞれが、どの拠点からあなたに配信しているか、その距離と遅延がわかります。
CDN は、世界各地のデータセンターにサイトのコピーを置いて配信する仕組みです。このデータセンターを拠点（PoP）と呼びます。つながる拠点が近いほど、その CDN を使うサイトはふつう速く開きます。ただし、いちばん近い拠点につながるとは限りません。
ページはサイトを開くときと同じように、ブラウザから各 CDN の小さなファイルを取得し、どの拠点が応答したかを読み取ります。そのうえで距離と遅延、そしてその距離で出せる理論上の最速値を表示します。
測定の通信はブラウザから各 CDN へ直接届き、このサイトは経由しません。
多くの場合、お使いの機器の問題ではありません。CDN と回線事業者がその経路を選んでいます。
理由：CDN は単純に距離で拠点を決めていません。Cloudflare などはエニーキャストという仕組みで、同じアドレスを世界中の拠点で同時に使っており、どの経路を通るかは回線事業者が決めます。Akamai や CloudFront などは、使っている DNS サーバーの場所をもとに拠点を選びます。中国本土では、Cloudflare の無料・低価格プランのサイトが、多くの回線で米国西海岸など遠い拠点から配信されます。そのほうが回線費用が安いからです。中国本土や香港の拠点から配信されるのは、有料の China Network（JD Cloud と提携）を使うサイトだけです。
影響：拠点が遠いほど、通信の往復に時間がかかります。ページや画像、動画の読み込みが遅くなり、混雑する時間帯には止まりやすくもなります。
できること：プロキシや VPN を使っていると、CDN はプロキシの場所をもとに拠点を選びます。「直接接続だけ・プロキシ経由だけで測る」で比べてみてください。8.8.8.8 のような公開 DNS を使っているなら、プロバイダーの DNS に戻すと、DNS で拠点を選ぶ 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、Alibaba Cloud、Tencent EdgeOne、Wangsu、Gcore、CDN77 は許可していないので、遅延だけを測ります。
距離から計算した遅延の下限です。実際の通信がこれより速くなることはありません。
光ファイバーの中で光は 1 ミリ秒に約 200 km 進みます。往復なので、距離 d の遅延は d ÷ 100 ミリ秒を下回りません。実際の経路は直線距離の 1.5〜2 倍ほどあります。
実際の遅延がこの値の 2 倍に 40 ms を足した値を超えると「遠回り」と表示します。経路が迂回しているか、混雑した区間で待たされています。
その CDN にはもっと近い拠点があるのに、使われていないということです。
全拠点を公開している CDN（Cloudflare、Bunny、Wikimedia）では、あなたにいちばん近い拠点を割り出します。実際に応答した拠点がそれより 1,000 km 以上遠く、しかも 2 倍以上の距離なら表示します。
故障ではなく、CDN か回線事業者が別の経路を選んだ結果です。理由と対策は「なぜ遠くの拠点につながるの？影響は？」をご覧ください。
ドメインを入力すると、そのサイトが使っている CDN、配信している拠点、遅延がわかります。
このサイトの Worker が Cloudflare の DNS で名前を引き（手元の DNS や改ざんされた応答には左右されません）、CNAME の向き先から CDN を見分けます。あわせてサイトの /cdn-cgi/trace で Cloudflare かどうかを確かめ、サイトが許可していれば favicon の応答ヘッダーから拠点を読み取ります。最後にサイトまでの遅延を測ります。
ドメインはこのサイトの Worker と Cloudflare の DNS に送られます。このサイトでは保存しません。
IP アドレスをもとに Cloudflare が推定しています（このサイトは Cloudflare 上で動いています）。たいてい都市までは合っていますが、数百 km ずれることもあります。プロキシを使っている場合は、プロキシの場所になります。
「正確な位置を使う」を押すと、ブラウザの位置情報を使います。使うのはこのページの中だけです。共有するときに位置にチェックを入れた場合だけ、約 10 km 単位に丸めてリンクに入ります。
このサイトは測定結果を保存しません。
測定の通信はブラウザから各 CDN へ直接届きます。CDN には、ふつうのサイトと同じくあなたの IP アドレスが見えます。このサイトが手伝うのは 2 つだけです。IP アドレスからおおよその現在地を出すことと、拠点のコードを都市名に変えることです。
共有リンクには拠点と遅延が入ります。都市、その座標（約 10 km 単位）、回線事業者は、チェックを入れたときだけ含まれます。IP アドレスが含まれることはありません。コードは GitHub で公開しています。
通信を直接つなぐかプロキシ経由にするかは、ウェブページではなく、プロキシクライアントのルーティングルールが決めます。通常の測定は、ふだんの状態そのままです。
どちらか一方だけを測るには、下のルールをクライアントのルール一覧の先頭に追加して、もう一度測ってください。すべて直接接続ならお使いの回線そのもの、すべてプロキシ経由ならプロキシサーバーから各 CDN までを測ります。終わったらルールは削除してください。
中国本土からすべて直接接続にすると、つながらない CDN があるかもしれません。それもひとつの結果です。
すべてブラウザ内で動作します。アカウント不要、テスト結果は収集しません。
© 2026 1ms.dog