온라인 Traceroute
온라인 traceroute로 웹사이트나 IP 주소까지 패킷이 지나는 네트워크 경로를 8개 도시에서 동시에 홉별로 추적하세요. 어느 네트워크가 패킷을 나르는지, 어디에서 시간이 늘어나는지, 손실이 실제인지 알 수 있습니다. 전 세계에서 내 IP까지 오는 경로도 추적할 수 있습니다.
wikipedia.org: 도시 8곳 모두에서 응답합니다. 상파울루에서 1.1 ms, 시드니에서 200 ms.
wikipedia.org·주소 6개·6곳에서·5~19홉·Wikimedia FoundationAS14907·기록된 실행 예시입니다. 추적을 누르면 내 결과를 볼 수 있습니다
wikipedia.org: 도시들을 산호세, 애슈번, 암스테르담, 상파울루, 싱가포르 및 마르세유에 있는 서로 다른 주소 6개로 보냅니다.- 요하네스버그에서 5번 홉의 시간이 158 ms 늘어납니다. Cogent 네트워크가 요하네스버그에서 런던까지(9,100 km) 건너가는 곳이므로 거리 때문이며 문제가 아닙니다.
- 시드니에서 4~8번 홉은 시드니, 퍼스 및 싱가포르에 있는데도 모두 약 98.1 ms에 응답합니다. 패킷이 터널을 지나며, 각 응답은 먼저 터널 끝까지 갔다가 돌아옵니다.
도시 8곳에서
0~250 ms · 모든 도시에 같은 눈금
요하네스버그wikipedia.org
185.15.58.224- 1–4RFC 3927Vultr 네트워크 안의 사설 주소 4개사설 주소0%0.4 ms0.1–11.1
- 5206.249.1.25Cogent
AS174트랜짓손실 0%지터 53.0159 ms158–159
여기서부터 +158 ms: 요하네스버그 → 런던, 9,100 km. 거리 때문이며 문제가 아닙니다. - 6be9736.ccr81.lon01.atlas.cogentco.com154.54.93.42Cogent
AS174트랜짓손실 0%지터 53.7160 ms159–160
- 7ldn-b3-link.ip.twelve99.net62.115.9.28Arelion
AS1299트랜짓손실 0%지터 59.6179 ms179–179
런던 안에서 +14.3 ms: 응답이 패킷이 간 길보다 더 긴 길로 돌아옵니다. - 8ldn-bb2-link.ip.twelve99.net62.115.140.70Arelion
AS1299트랜짓손실 0%지터 61.6185 ms185–185
- 9prs-bb2-link.ip.twelve99.net62.115.133.239Arelion
AS1299트랜짓손실 0%지터 62.8188 ms188–188
- 10mei-b5-link.ip.twelve99.net62.115.124.57Arelion
AS1299트랜짓손실 0%지터 62.8188 ms188–188
- 11wikimedia-ic-370330.ip.twelve99-cust.net62.115.147.133Arelion
AS1299트랜짓손실 0%지터 69.8192 ms188–209
- 12irb-601.asw1-b12-drmrs.wikimedia.org185.15.58.143Wikimedia Foundation
AS14907목적지 네트워크손실 0%지터 61.9182 ms180–184
- 13wikipedia.org185.15.58.224Wikimedia Foundation
AS14907목적지손실 0%지터 58.0174 ms174–174
요하네스버그의 mtr 보고서
요하네스버그 → wikipedia.org Host Loss% Drop Rcv Avg StDev Javg 1. AS??? _gateway (169.254.169.254) 0.0% 0 5 0.3 0.2 0.2 2. AS??? 100.100.100.1 (100.100.100.1) 0.0% 0 5 0.3 0.0 0.1 3. AS??? 10.94.0.97 (10.94.0.97) 0.0% 0 5 3.0 4.0 3.8 4. AS??? 10.94.0.13 (10.94.0.13) 0.0% 0 5 0.4 0.1 0.2 5. AS174 206.249.1.25 (206.249.1.25) 0.0% 0 5 158.6 0.4 53.0 6. AS174 be9736.ccr81.lon01.atlas.cogentco.com (154.54.93.42) 0.0% 0 5 159.6 0.4 53.7 7. AS1299 ldn-b3-link.ip.twelve99.net (62.115.9.28) 0.0% 0 5 178.6 0.1 59.6 8. AS1299 ldn-bb2-link.ip.twelve99.net (62.115.140.70) 0.0% 0 5 184.7 0.1 61.6 9. AS1299 prs-bb2-link.ip.twelve99.net (62.115.133.239) 0.0% 0 5 188.2 0.1 62.8 10. AS1299 mei-b5-link.ip.twelve99.net (62.115.124.57) 0.0% 0 5 188.2 0.1 62.8 11. AS1299 wikimedia-ic-370330.ip.twelve99-cust.net (62.115.147.133) 0.0% 0 5 192.3 8.4 69.8 12. AS14907 irb-601.asw1-b12-drmrs.wikimedia.org (185.15.58.143) 0.0% 0 5 181.7 1.5 61.9 13. AS14907 wikipedia.org (185.15.58.224) 0.0% 0 5 173.9 0.1 58.0
traceroute는 어떻게 작동하나요?
traceroute는 지날 수 있는 라우터 수를 하나씩 늘리며 프로브를 보내고, 프로브가 한도에 다다른 라우터는 응답을 돌려보냅니다. 그 응답으로 라우터의 주소와 시간을 알 수 있고, 역방향 DNS 조회로 라우터 이름을 찾습니다.
이 한도가 패킷의 TTL(Time To Live, IPv6에서는 홉 제한)입니다. 각 라우터는 TTL을 1씩 줄이고 0이 되면 패킷을 버린 뒤 ICMP Time Exceeded 메시지를 돌려보냅니다. 첫 번째 프로브는 첫 라우터에서, 두 번째 프로브는 두 번째 라우터에서 멈추며, 마침내 목적지에 닿은 프로브에는 목적지가 직접 응답합니다.
이 페이지는 모든 프로브를 반복하는 MTR을 실행합니다. 각 도시에서 홉마다 패킷 5개를 보내므로 각 홉에 최저, 평균, 최고 시간과 손실 수치가 나옵니다. 모든 시간은 프로브가 측정한 왕복 시간으로, 갔다가 돌아오는 시간에 라우터가 응답을 만드는 시간이 더해진 값입니다.
TTL마다 프로브 1개, 산호세 → wikipedia.org5회 중 가장 빠른 값 · 2026년 10월 23일
- TTL 1Oracle Cloud0.2 ms
- TTL 2Equinix0.4 ms
- TTL 3Equinix1.8 ms
- TTL 4Wikimedia Foundation2.0 ms
- TTL 5wikipedia.org1.7 ms
- 프로브: 라우터를 지날 때마다 TTL이 1씩 줄어듦
- TTL이 0이 되면 라우터가 프로브를 버림
- 라우터의 응답: ICMP Time Exceeded

결론각 도시가 사이트에 어떻게 도달했는지 가장 빠른 왕복 시간부터 가장 느린 시간까지 한 줄로 보여 줍니다.응답하는 곳목적지를 소유한 네트워크와, 사이트가 몇 개의 주소와 장소에서 응답했는지 보여 줍니다.측정 결과 해석홉에서 읽어 낸 내용입니다. 어디에서 시간이 늘어나는지, 구간의 증가가 단순히 거리 때문인지, 손실이 실제인지 보여 줍니다.패킷이 지나간 곳각 도시의 경로를 세계 지도에 표시하며, 각 라우터는 왕복 시간이 허용하는 곳에만 배치합니다.traceroute 결과는 어떻게 읽나요?
위에서 아래로 읽습니다. 각 줄은 경로 위의 라우터 하나와 그 응답에 걸린 시간입니다. 중요한 것은 시간이 올라가서 그대로 유지되는 곳과 목적지가 응답하는지입니다.
한 줄만 시간이 높고 다음 줄들은 그렇지 않다면, 그 라우터는 전달이 아니라 응답이 느린 것입니다. 응답을 만드는 일은 라우터 프로세서에게 우선순위가 낮은 작업이기 때문입니다. 한 홉 뒤에 사라지는 손실은 라우터가 응답을 제한하는 것입니다. 체감에 영향을 주는 것은 마지막 줄까지 이어지는 시간과 손실뿐입니다. 각 줄의 주소는 프로브가 도착한 인터페이스이므로, 같은 라우터도 다른 경로에서는 다른 주소로 보일 수 있습니다.
뭄바이 → wikipedia.org, 한 줄씩 읽기MTR, 홉마다 패킷 5개
- 1홉 번호TTL입니다. 첫 라우터가 1입니다.
- 2네트워크라우터를 운영하는 곳: AS 번호와 브랜드입니다.
- 3증가 구간시간이 올라간 뒤 그대로 유지되는 곳으로, 보통 거리 때문입니다.
- 4라우터 이름PTR 이름입니다. 이름 속 코드가 도시를 나타내는 경우가 많습니다.
- 5목적지마지막 줄: 방문자의 패킷에 실제로 걸리는 시간입니다.
traceroute에 별표(* * *)가 나오는 이유는?
별표는 제시간에 응답을 받지 못한 프로브입니다. 대개 그 라우터가 프로브에 응답하지 않을 뿐이며, 별표가 끝까지 이어질 때만 문제가 됩니다.
각 도구는 프로브마다 몇 초씩 기다리고(Linux와 macOS는 5초, tracert는 4초) 아무것도 돌아오지 않으면 *를 출력합니다. 라우터는 아예 응답하지 않거나 보내는 응답 수를 제한하도록 설정될 수 있고, 방화벽은 프로브나 응답을 자주 버립니다. 중간 홉에 별표가 있어도 그 뒤에 응답이 있다면 패킷은 통과한 것입니다.
전혀 응답하지 않는 라우터
정상3~6번 홉은 응답하지 않지만 7번 홉과 목적지는 응답합니다. 그 라우터들은 패킷을 전달하면서 응답만 하지 않습니다.
상파울루 → wikipedia.org · 2~8번 홉
일부 프로브에만 응답하는 라우터
정상7번 홉은 프로브 5개 중 2개에 응답했고, 그 뒤 홉은 모두 응답했습니다. 응답을 제한할 뿐 손실은 없습니다.
상파울루 → wikipedia.org · 5~9번 홉
목적지 쪽에서 프로브를 버림
TCP 443 사용8번 홉 다음부터 20홉 한도까지 아무것도 응답하지 않습니다. 목적지의 네트워크나 방화벽이 이 프로브를 버립니다.
뭄바이의 저희 서버 → bbc.co.uk (UDP) · 5~20번 홉
traceroute, 핑, MTR, pathping 비교
핑은 목적지 하나의 시간을 재고, traceroute는 경로 위의 모든 라우터를 보여 줍니다. MTR은 계속 추적하므로 각 홉에 실제 손실과 지터 수치가 나오고, pathping은 같은 아이디어를 Windows에서 더 느리게 구현한 도구입니다.
일반 traceroute는 홉마다 프로브 3개를 보내고 넘어가므로, 프로브 하나를 놓친 홉은 33% 손실처럼 보입니다. MTR은 라운드를 거듭하며 모든 홉을 반복하고, pathping은 홉마다 250 ms 간격으로 쿼리 100개를 보낸 뒤 결과를 알려 줍니다. 경로 하나가 아니라 연결 전체를 테스트하려면 핑 테스트나 패킷 손실 테스트를 사용하세요.
| 경로 표시 | 핑ping host | traceroutetracert host · traceroute host | MTRmtr host | pathpingpathping host |
|---|---|---|---|---|
| 경로 표시 | 모든 홉 | 모든 홉, 실시간 | 모든 홉 | |
| 홉별 시간 | 홉마다 프로브 3개 | 평균, 최저, 최고 | 쿼리 100개 후 | |
| 홉별 손실 | 프로브 몇 개로는 알 수 없음 | 모든 라운드를 집계 | 홉마다 프로브 100개 | |
| 종단 간 시간과 손실 | 예 | 마지막 줄 | 마지막 줄 | 예 |
| 걸리는 시간 | 4초 | 5~30초 | 멈출 때까지 실행 | 홉마다 약 25초 |
| 이럴 때 사용 | 숫자 하나만 필요할 때 | 경로를 알고 싶을 때 | 손실이 의심될 때 | Windows에서 손실을 봐야 할 때 |
traceroute는 어떤 포트를 사용하나요?
고유한 포트는 없습니다. Linux와 macOS의 traceroute는 33434번부터 위쪽 포트로 UDP를 보내고, Windows의 tracert는 ICMP 에코 요청을 보내며, TCP 모드는 지정한 포트로 SYN 패킷을 보냅니다(443번은 대부분의 방화벽을 통과합니다).
UDP 프로브는 아무도 수신 대기하지 않는 포트를 노리므로, 목적지가 “포트에 도달할 수 없음”(port unreachable)을 응답하고 추적은 거기서 끝납니다. 잘 열리는 웹사이트 앞에서 추적이 멈춘다면 여기서 TCP 443으로 바꾸세요. 방화벽은 UDP나 ICMP보다 웹 트래픽을 더 자주 통과시킵니다. 포트 자체를 확인하려면 포트 확인을 사용하세요.
각 도구가 프로브에 담는 것기본값이 먼저
- Linux의 traceroutetraceroute hostIP · TTL 1, 2, 3…UDP목적지 포트 33434부터
- macOS의 traceroutetraceroute hostIP · TTL 1, 2, 3…UDP목적지 포트 33434부터
- Windows의 tracerttracert hostIP · TTL 1, 2, 3…ICMP 에코 요청포트 없음
- ICMP 모드traceroute -I · mtrIP · TTL 1, 2, 3…ICMP 에코 요청포트 없음
- TCP 모드traceroute -T -p 443 · mtr -T -P 443IP · TTL 1, 2, 3…TCP SYN목적지 포트 443
- 이 페이지Globalping MTRIP · TTL 1, 2, 3…ICMP · TCP 443 · UDP직접 선택
Windows, Mac, Linux에서 traceroute 사용법(tracert)
Windows에서는 명령 프롬프트를 열고 tracert 뒤에 주소를 입력하고, macOS와 Linux에서는 터미널을 열고 traceroute를 입력합니다. -d(Windows) 또는 -n을 붙이면 이름 조회를 건너뛰어 더 빨리 끝납니다.
tracert는 ICMP를 보내고 프로브마다 최대 4초를 기다리며, macOS와 Linux는 UDP를 보냅니다. mtr(macOS는 Homebrew, Linux는 패키지 관리자로 설치)을 쓰면 이 페이지가 보여 주는 홉별 손실을 볼 수 있습니다. 내 컴퓨터에서 실행한 추적은 온라인 추적으로는 볼 수 없는 내 네트워크 안의 첫 홉들을 보여 주고, 이 페이지는 세계 각지에서 같은 호스트에 어떻게 도달하는지 보여 줍니다.
- Windows
- macOS
- Linux
- MTR
tracert -d example.com홉마다 프로브 3개, 최대 30홉입니다. -d는 이름 조회를 건너뛰어 더 빨리 끝납니다.
$ traceroute -m 20 -w 2 -q 1 bbc.co.uk 1 103.118.16.254 (103.118.16.254) 3.815 ms 2 195.250.22.6 (195.250.22.6) 0.293 ms 3 delhi-203.197.239-201.vsnl.net.in (203.197.239.201) 0.880 ms 4 49.44.18.38 (49.44.18.38) 1.335 ms 5 10.70.14.97 (10.70.14.97) 2.130 ms 6 * 7 192.168.65.138 (192.168.65.138) 16.185 ms 8 49.44.53.3 (49.44.53.3) 17.261 ms 9 * 10 * 11 * 12 * 13 * 14 * 15 * 16 * 17 * 18 * 19 * 20 *
- 11번 홉은 서버 자체의 게이트웨이로, 경로의 첫 라우터입니다.
- 2* 하나는 응답하지 않은 라우터이며, 추적은 다음 홉으로 계속됩니다.
- 38번 홉 다음부터 20홉 한도까지 응답이 없습니다. 목적지 쪽에서 이 UDP 프로브를 버립니다.
한 홉에서 지연 시간이 갑자기 늘어나는 이유는?
대개 그 홉에서 경로가 바다나 대륙 같은 먼 거리를 건너기 때문입니다. 광섬유 속 빛은 100 km마다 왕복 약 1 ms를 더하므로, 거리에 맞는 증가는 정상입니다.
케이블은 직선으로 놓이지 않으므로 지도상 거리 1,000 km당 약 12.5 ms를 잡으세요. 거리에 필요한 시간의 약 두 배보다 큰 증가나, 경로가 이동하지 않았는데 나타나는 증가는 우회, 혼잡한 링크 또는 더 긴 복귀 경로를 뜻합니다. 각 응답은 프로브가 간 길과 다른 경로로 돌아올 수 있습니다. MPLS 터널 안에서는 모든 홉이 터널 끝의 시간을 보여 줄 수 있어서, 서로 다른 도시에 있는 여러 홉이 같은 숫자를 보고합니다.
시간이 늘어나는 곳: 요하네스버그 → wikipedia.org느린 응답은 제외
거리 때문일까? 100 km당 왕복 1 ms증가 구간 1개, 2026년 10월 23일 측정
- 요하네스버그 → 런던9,100 km · 최소 91 ms+158거리
- 거리가 허용하는 최솟값(광섬유 속 빛)
- 측정된 증가
traceroute가 한 홉에서 멈추거나 “요청 시간이 만료되었습니다”가 나올 때
추적이 멈추는 것은 대개 목적지나 그 앞의 방화벽이 traceroute의 프로브를 무시하기 때문입니다. 사이트가 열린다면 네트워크는 정상입니다. 경로를 의심하기 전에 TCP 443을 사용해 보세요.
한 홉부터 끝까지 별표가 나오지만 사이트는 열림가장 흔한 경우
목적지나 그 앞의 방화벽이 traceroute의 프로브를 버립니다. TCP 443으로 다시 실행하세요. 웹사이트 방문처럼 보이므로 보통 통과합니다. 사이트가 열린다면 접속할 수 있는 것이며, 응답받지 못한 것은 프로브뿐입니다.
모든 홉에서 “요청 시간이 만료되었습니다”1번 홉부터
내 방화벽, VPN 또는 네트워크가 프로브나 응답을 차단합니다. 다른 프로토콜을 사용하거나, 내 네트워크 밖인 이 페이지에서 추적을 실행하세요.
1번이나 2번 홉 바로 뒤에서 멈춤공유기는 응답하지만 그 뒤는 없음
통신사로 가는 연결이 끊겼거나 통신사 네트워크가 프로브를 버립니다. 웹사이트도 열리지 않는다면 공유기를 다시 시작하고, 추적 결과를 가지고 통신사에 문의하세요.
중간에 별표, 이후 홉은 응답응답하지 않는 라우터
그 라우터들은 프로브에 응답하지 않거나 응답을 제한합니다. 패킷은 그 라우터를 통과했으므로 문제가 없습니다.
같은 두 주소가 끝까지 반복됨라우팅 루프
두 라우터가 TTL이 다 될 때까지 패킷을 주고받습니다. 경로 중간에 있는 네트워크의 장애이므로, 그 네트워크를 운영하는 통신사에 추적 결과를 보내세요.
시간 뒤에 !H, !N, !X라우터가 도달할 수 없다고 응답
호스트 도달 불가, 네트워크 도달 불가, 관리상 금지를 뜻합니다. 라우터가 패킷을 전달하지 않거나 전달할 수 없다고 응답한 것입니다. 주소가 틀렸거나 일부러 차단되었을 수 있습니다.
내 IP 주소까지의 경로는 어떻게 추적하나요?
“내 IP까지 추적”을 선택하고 버튼을 누르면 여러 도시의 프로브가 내 공인 IP 주소까지 추적합니다. 인터넷이 내 통신사에 어떻게 도달하는지, 나에게 오는 길의 어디에서 시간이 늘어나는지 볼 수 있습니다.
내 주소 직전의 마지막 홉들은 보통 응답하지 않습니다. 가정용 공유기는 프로브에 응답하지 않기 때문입니다. Globalping은 모든 측정을 공개하므로 내 IP 주소는 공개 결과의 일부가 됩니다. 추적은 버튼을 눌러야 시작되며, 저희는 주소를 보관하지 않습니다.
3곳에서 한 가정용 회선까지 추적(Jio, 인도)MTR · 홉마다 패킷 5개
- 뭄바이Oracle Cloud2번 홉에서 멈춤
- 프랑크푸르트Oracle Cloud211 ms
- 애슈번Oracle Cloud245 ms
온라인 traceroute 자주 묻는 질문
traceroute는 무엇에 쓰나요?
온라인 traceroute 사용법은?
tracert와 traceroute는 같은가요?
traceroute에서 * * *는 무슨 뜻인가요?
traceroute가 웹사이트 앞에서 멈추는 이유는?
한 홉에서만 지연 시간이 높으면 문제인가요?
내 IP 주소로 traceroute를 할 수 있나요?
traceroute와 MTR의 차이는 무엇인가요?
traceroute에서 네트워크 홉 수는 몇 개가 정상인가요?
이 온라인 traceroute는 무료인가요? 저장되는 정보가 있나요?
관련 도구
핑 테스트
핑, 지터, 패킷 손실을 측정하고 34개 클라우드 리전까지의 핑과 11개 도시에서 사이트나 IP로 보내는 핑을 확인합니다
패킷 손실 테스트
가장 가까운 Cloudflare 데이터 센터까지의 실제 UDP 패킷 손실, 지터, 버퍼블로트를 업로드와 다운로드로 나눠 측정합니다
포트 확인
포트 연결 및 서비스 가용성 테스트
IP 조회
IP 주소의 위치 정보, ISP, 네트워크 세부 정보를 즉시 조회
내 ISP 확인
ISP, ASN, 연결 세부 정보 확인
DNS 조회
도메인 자체 네임서버의 모든 DNS 레코드를 Google·Cloudflare 캐시와 나란히 확인