CDN 레이더
측정 중…
출구를 확인하는 중…
Gcore 쪽에서 어느 지점이 응답했는지 페이지가 읽지 못하게 하므로, 여기서는 시간만 잽니다. 브라우저에서 gcore.com의 가장 가까운 엣지까지의 왕복 시간입니다.
CloudflareCloudflare 중국 네트워크Amazon CloudFrontAkamaiFastlyAzure Front DoorBunny CDNWikimediaGoogle알리바바 클라우드Tencent EdgeOneWangsu (CDNetworks)CDN77
대형 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, Alibaba Cloud, Tencent EdgeOne, Wangsu, Gcore, CDN77은 허용하지 않아 시간만 잽니다.
CDN은 거리로 배정하지 않습니다. Cloudflare, Akamai 등은 같은 주소를 여러 곳에서 동시에 알리거나(애니캐스트) DNS 리졸버 위치에 따라 응답하며, 실제 경로는 통신사가 고릅니다.
중국 본토에서는 흔한 일입니다. Cloudflare 무료·저가 요금제 사이트는 많은 통신사에서 미국 서부 등 먼 지점으로 연결됩니다. 그 경로가 더 싸기 때문입니다. 유료 요금제와 China Network(JD Cloud와 운영)는 홍콩이나 중국 본토 지점이 응답합니다.
프록시나 VPN도 지점을 바꿉니다. CDN에는 프록시 주소가 보이고, 그 위치에 맞춰 배정됩니다.
광섬유 안에서 빛은 1밀리초에 약 200 km를 가므로, 거리 d의 왕복은 d ÷ 100밀리초보다 빠를 수 없습니다. 실제 경로는 직선의 1.5~2배입니다. 왕복 시간이 그 두 배에 40 ms를 더한 값보다 훨씬 길면 '돌아서 감'으로 표시합니다. 경로가 우회하거나 혼잡한 구간에서 기다리는 것입니다.
모든 지점을 공개하는 CDN(Cloudflare, Bunny, Wikimedia)은 나와 가장 가까운 지점을 찾습니다. 응답한 지점이 그보다 1,000 km 이상, 그리고 두 배 이상 멀면 표시합니다. 고장이 아니라 CDN이나 통신사가 다른 경로를 고른 것입니다.
도메인을 입력하면 이 사이트의 Worker가 Cloudflare DNS로 조회해(로컬이나 변조된 응답의 영향을 받지 않음) CNAME이 가리키는 곳에서 CDN을 알아냅니다. 사이트의 /cdn-cgi/trace로 Cloudflare인지 확인하고, 사이트가 허용하면 favicon 응답 헤더에서 지점을 읽습니다. 마지막으로 사이트까지의 시간을 잽니다.
도메인은 이 사이트의 Worker와 Cloudflare DNS로 전송되며, 둘 다 저장하지 않습니다.
규칙 기반 프록시 클라이언트(Clash, Surge 등)를 쓰면 어떤 CDN은 내 네트워크에서 바로 나가고(직접 연결, D), 어떤 CDN은 프록시 서버를 거칩니다(프록시, P). 프록시를 거치면 CDN은 프록시 주소로 위치를 고르고 왕복 시간에 프록시까지의 구간이 포함되므로, 둘은 그대로 비교할 수 없습니다.
페이지는 먼저 출구를 찾습니다. 중국 본토 사이트(IPIP)가 보는 주소, 이 사이트가 보는 주소, Cloudflare trace가 보는 주소를 모아 각각의 위치를 확인합니다. 호스팅 업체 네트워크에 있는 출구는 프록시로 봅니다.
그다음 각 CDN의 출구를 판단합니다. Cloudflare trace에는 주소가 적혀 있습니다. 위치를 읽을 수 있는 CDN은 그 위치가 어느 출구에 훨씬 가까운지로 판단합니다. 프록시를 거쳐서는 불가능할 만큼 왕복이 짧으면 직접 연결입니다. 알리바바 클라우드와 텐센트의 테스트 도메인은 일반적인 규칙의 중국 본토 직접 연결 목록에 있어 규칙으로 추정합니다(점선 표시). 판단할 수 없는 것은 '?'로 표시하고, 거리는 참고값으로만 쓰며 결론에 포함하지 않습니다.
직접 연결만 또는 프록시만 측정하려면 '직접 연결만 또는 프록시만 측정'의 규칙을 사용하세요.
IP 주소로 판단합니다. 이 사이트가 보는 주소는 Cloudflare가(이 사이트는 Cloudflare에서 실행됩니다), 다른 출구는 ip.sb가 위치를 추정합니다. 보통 도시 단위까지 맞지만 수백 km 틀릴 수도 있습니다. 프록시 주소는 자주 틀리므로 연결된 Cloudflare 위치를 대신 사용합니다. 모든 트래픽이 프록시를 거치면 '나'의 위치는 프록시의 위치입니다. '정확한 위치 사용'을 누르면 브라우저 위치를 사용하며, 페이지 안에서만 씁니다.
아니요. 요청은 브라우저에서 각 CDN으로 바로 가며, CDN은 다른 사이트처럼 내 IP 주소를 봅니다. 출구를 찾기 위해 페이지는 IPIP(myip.ipip.net)에도 요청하고, 출구의 IP 주소를 ip.sb에 보내 위치를 확인합니다. 이 사이트는 아무것도 저장하지 않습니다. 공유 링크에는 위치, 왕복 시간, 각 행의 출구(D·P 글자만)가 들어갑니다. 도시, 좌표(약 10 km 단위), 통신사는 체크했을 때만 포함되고, IP 주소는 절대 들어가지 않습니다. 코드는 GitHub에 공개되어 있습니다.
직접 연결할지 프록시를 거칠지는 웹페이지가 아니라 프록시 클라이언트가 라우팅 규칙으로 정합니다. 기본 테스트는 평소 상태를 보여 줍니다.
한쪽만 측정하려면 아래 규칙을 클라이언트 규칙 목록 맨 위에 넣고 다시 테스트하세요. 모두 직접 연결이면 내 네트워크를, 모두 프록시면 프록시 서버에서 각 CDN까지를 측정합니다. 측정이 끝나면 규칙을 지우세요.
중국 본토에서 모두 직접 연결하면 응답하지 않는 CDN이 있을 수 있습니다. 그것도 결과입니다.