우리 집에서 Gcore의 각 리전은 얼마나 빠를까?

대부분의 '클라우드 속도 측정' 사이트와 각 업체의 Looking Glass는 그들의 서버에서 측정합니다. 데이터센터에 있는 고품질 회선 서버라서, 알 수 있는 건 '데이터센터에서 데이터센터까지'의 속도뿐입니다. 정작 내가 체감하는 부분, 즉 집 인터넷이나 모바일 회선, 통신사 백본, 국제 구간, 오늘 저녁의 혼잡은 잴 수 없습니다.

Me2Cloud는 모든 요청을 내 브라우저에서 보냅니다. Wi‑Fi, 공유기, 통신사, 통신사가 고른 경로, 저녁 피크까지 전부 결과에 들어갑니다.

1. 먼저 워밍업 요청으로 DNS, TCP, TLS를 맺습니다. 이 시간은 보여 주지만 집계에는 넣지 않습니다.
2. 이어서 같은 연결로 같은 호스트에 5, 10, 20번 요청합니다. 한 번에 왕복 한 번과 업체 서버의 처리 시간만 걸립니다.
3. 업체마다 연결을 유지한다고 확인한 방식을 씁니다: AWS, Azure, Google Cloud, Huawei Cloud, DigitalOcean, Scaleway는 GET, Oracle, IBM Cloud, Alibaba Cloud, Tencent Cloud, Volcengine, Baidu AI Cloud, Naver Cloud, Linode, Vultr, OVHcloud, IONOS Cloud, Aruba Cloud, Leaseweb, Gcore, Yandex Cloud는 HEAD(GET은 연결이 끊겨 3배가 됨), Hetzner만 <img>.
4. 결과는 중앙값(가장 대표적인 값), 평균, P90(10번 중 9번은 이 이하), 지터(연속 두 번의 차이 평균), 손실(시간 초과 비율)입니다.
5. 등급은 중앙값으로 정합니다: T0 갓 ≤ 30 ms, T1 최상급 ≤ 80 ms, T2 상위권 ≤ 150 ms, T3 NPC ≤ 250 ms, 그 이상은 T4 망함. 추천에 쓰는 종합 점수는 '중앙값 + 2 × 지터 + 손실 벌점'이라, 안정적인 60 ms가 들쭉날쭉한 45 ms보다 앞섭니다.

• 내 트래픽과 같은 길. 웹, API, 443 포트 터널, 게임 로그인, 다운로드는 모두 TCP입니다. 많은 통신사가 ICMP를 따로 줄 세우거나 제한하거나 다른 경로로 보내서, ping은 좋은데 페이지가 느리거나 그 반대인 경우가 흔합니다.
• 제한에 묻히지 않음. 공유기와 클라우드는 ICMP를 자주 제한·폐기하지만 공개 HTTPS 엔드포인트는 항상 응답합니다.
• 실제 환경이 반영됨. DNS, IPv4/IPv6 선택, 프록시, 가속 서비스가 브라우저 트래픽에도 적용되므로 실제로 얻는 속도를 잽니다.
• 대신: 매번 약간의 일정한 서버 처리 시간이 들어갑니다. 실측으로 AWS는 0–5 ms, Alibaba Cloud는 약 8 ms, Huawei Cloud OBS는 약 20 ms. 100 ms가 넘는 거리에서는 무시해도 되지만, 아주 가까운 리전에서는 ping보다 조금 크게 나옵니다.

• 가정용 회선은 저녁 20:00–23:00에 가장 붐비고, 해외 구간은 더 심합니다. 낮에는 T1 최상급이던 리전이 밤에는 NPC까지 떨어지기도 합니다.
• 낮에 한 번, 피크에 한 번 재 보세요. 저장된 결과에는 '피크 시간' 표시가 붙고, 결과 화면에서 바꿔 가며 비교할 수 있습니다.
• 측정 중에는 큰 다운로드, 동영상, 클라우드 동기화를 멈추세요. 유선이 Wi‑Fi보다 정확하고, Wi‑Fi라면 공유기 가까이에서.
• 모바일 데이터에서는 신호 세기에 따라 결과가 달라집니다. 실제로 쓸 곳에서 재는 게 가장 좋습니다.

• 서버, 게임 서버, CDN 원본을 계약하기 전에 후보 리전을 추릴 때.
• 같은 업체의 리전끼리, 또는 같은 도시의 다른 업체를 비교할 때.
• 게임, 화상 회의, 원격 데스크톱, SSH에 충분히 안정적인지(지터, 손실) 확인할 때.
• 프록시, 가속 서비스, 새 인터넷 요금제가 정말 효과가 있는지 켜고 끄며 비교할 때.
• 사용자 지정 대상으로 내 서버나 CDN을 대형 업체와 나란히 비교할 때.

• 한 곳의 결과일 뿐입니다. 내 회선이지 사용자 회선이 아닙니다. 사용자 몇 명에게도 재 달라고 하고 내보내서 비교하세요.
• 재는 건 엔드포인트이지, 앞으로 쓸 서버 자체가 아닙니다. 그 리전의 공개 API나 스토리지를 잽니다. 같은 리전의 서버는 보통 같은 네트워크지만 프리미엄 회선(CN2, BGP와 단일 통신사, Lightsail과 EC2 등)은 다를 수 있습니다.
• 대역폭, UDP, 경로는 재지 않습니다. 왕복 시간만 재며 다운로드 속도, UDP 게임 트래픽, 중간 경로는 모릅니다.
• 브라우저의 영향. 확장 기능, 프록시, VPN, 무거운 탭은 잡음이 됩니다. 무거운 탭은 닫고 이 페이지를 앞에 두세요.
• Hetzner는 브라우저에서 연결을 유지할 수 없어 매번 핸드셰이크가 포함됩니다. 일부 나라에서는 닿지 않는 대상도 있습니다.

• 이 페이지는 Cloudflare에 올린 정적 파일뿐입니다. 백엔드도 가입도 분석 도구도 없고, 결과를 업로드하지 않습니다.
• 테스트 요청은 모두 브라우저에서 업체로 바로 갑니다. 위의 요청 기록이나 개발자 도구 Network 탭에서 하나씩 볼 수 있습니다.
• 네트워크 정보는 Cloudflare(speed.cloudflare.com/meta, /cdn-cgi/trace)에서 받고, 선택 사항인 WebRTC 확인은 stun.cloudflare.com에 UDP 출구 주소를 묻습니다. 설정에서 끌 수 있습니다.
• IPv4/IPv6 확인은 Cloudflare 외에 ipify.org와 ident.me에도 함께 물어보므로, 그중 하나가 막혀 있어도 IPv6가 없다고 잘못 판단하지 않습니다.
• 설정, 사용자 지정 대상, 최근 결과는 이 브라우저의 로컬 저장소에만 있고 '테스트 데이터 지우기'로 결과를 지울 수 있습니다.

공개 엔드포인트를 너무 세게 두드리면 업체의 속도 제한이나 WAF에 걸리고 결과도 망가집니다. 그래서 테스트 속도를 일부러 낮췄습니다:

• 호스트마다 동시에 요청 1개, 샘플 사이는 250–370 ms 쉼(호스트당 초당 최대 2–3회).
• 업체마다 동시에 최대 2개 호스트, 전체 최대 8개(기본 4개).
• 한 번 테스트에 호스트당 최대 21번 요청(워밍업 + 20). 연속 모드 없음.
• 3번 연속 실패한 호스트는 포기하고 계속 재시도하지 않습니다.
• 모두 익명, 쿠키와 Referer 없는 '단순 요청': 사전 요청 없음, 응답은 수백 바이트, 가능하면 HEAD, 큰 파일은 받지 않습니다.

전체 트래픽은 평범한 웹 페이지 하나를 여는 것보다 적습니다. 모든 대상이 익명 요청에 정상 응답하는 것을 확인했습니다(200, 403, 404 모두 측정에는 문제없음).

트래픽이 프록시를 거치면 브라우저가 재는 건 '나→프록시'와 '프록시→업체'이지 내 회선이 아닙니다. 네트워크 표시는 출구가 데이터센터인지, 시간대와 출구 국가가 다른지, WARP가 켜졌는지, WebRTC와 HTTPS 출구가 다른지 같은 흔한 징후를 확인합니다.

직접 연결 규칙 받기로 테스트용 호스트만 직접 연결하게 하고(Clash / Mihomo, Surge, Shadowrocket, Quantumult X, Loon, sing-box, Xray, SwitchyOmega, 도메인 목록 지원) 다시 확인하세요. 프록시 자체를 재고 싶다면 그대로 재면 되고, 그게 프록시의 실제 성능입니다.

• 각 행의 막대는 같은 눈금(로그, 2 ms~3초)입니다. 점은 각 샘플, 띠는 샘플의 가운데 절반 범위, 세로선은 중앙값입니다.
• 띠가 좁을수록 안정적이고, 띠가 넓거나 점이 흩어지면 지터가 큽니다. 빨간 ×는 손실 횟수입니다.
• 행을 펼치면 샘플별 추이, 모든 통계, 사용한 대상이 보입니다. ✓는 조건에 맞는 리전입니다.