CDN 레이더
측정 중…
지금 쓰는 네트워크와 라우팅 규칙 기준의 결과예요.
페이지가 res-1.cdn.office.net에서 작은 파일 하나를 받아요. 이 파일은 Akamai에 있고, 다른 사이트에서도 응답을 읽을 수 있어요. 응답 헤더 Akamai-Request-Bc에 응답한 데이터센터가 적혀 있어요.
1ms.dog는 도쿄에 서버를 두고, 이 페이지와 같은 방법으로 10분마다 Akamai을(를) 측정해요. 변하지 않는 기준점이에요. 도쿄에서도 데이터센터가 바뀌었다면 Akamai 쪽 변경이고, 내 쪽만 바뀌었다면 네트워크나 DNS 때문일 가능성이 높아요.
CloudflareCloudflare 중국 네트워크Amazon CloudFrontFastlyAzure Front DoorBunny CDNWikimediaGoogle알리바바 클라우드Tencent EdgeOneWangsu (CDNetworks)GcoreCDN77
주요 CDN이 각각 어느 데이터센터에서 나에게 연결되는지, 그 거리와 지연 시간을 보여 줘요.
CDN은 세계 곳곳의 데이터센터에 웹사이트 사본을 두고 전송하는 서비스예요. 이 데이터센터를 PoP 또는 엣지라고도 불러요. 연결되는 데이터센터가 가까울수록 그 CDN을 쓰는 사이트는 보통 더 빨리 열려요. 하지만 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 주소를 볼 수 있어요. 이 사이트가 돕는 건 세 가지뿐이에요. IP 주소로 대략적인 위치를 알려 주는 것, 데이터센터 코드를 도시 이름으로 바꾸는 것, 그리고 측정할 때 DNS 조회를 한 번 더 해서 이 사이트의 DNS 서버로 내가 어떤 DNS 서버를 쓰는지, 내 주소 대역을 보내는지 확인하는 것이에요(메모리에 2분만 두고, 공유 링크와 카드에는 넣지 않아요).
공유 링크에는 데이터센터와 지연 시간이 들어가요. 도시, 그 좌표(약 10 km 단위), 통신사는 체크했을 때만 들어가고, IP 주소는 절대 들어가지 않아요. 코드는 GitHub에 공개돼 있어요.
요청을 직접 보낼지 프록시로 보낼지는 웹페이지가 정할 수 없어요. 프록시 클라이언트가 라우팅 규칙에 따라 정해요. 기본 측정은 평소 인터넷을 쓰는 그대로의 상태를 보여 줘요.
한쪽만 측정하려면 아래 규칙을 클라이언트 규칙 목록 맨 위에 넣고 다시 측정하세요. 모두 직접 연결이면 내 네트워크를, 모두 프록시면 프록시 서버에서 각 CDN까지를 측정해요. 다 끝나면 규칙을 지우세요.
중국 본토에서 모두 직접 연결하면 일부 CDN은 연결되지 않을 수 있어요. 그것도 하나의 결과예요.
테스트는 브라우저에서 시작돼요. 계정이 필요 없고, 결과는 수집하지 않아요.
© 2026 1ms.dog