온라인 Traceroute

온라인 traceroute로 웹사이트나 IP 주소까지 패킷이 지나는 네트워크 경로를 8개 도시에서 동시에 홉별로 추적하세요. 어느 네트워크가 패킷을 나르는지, 어디에서 시간이 늘어나는지, 손실이 실제인지 알 수 있습니다. 전 세계에서 내 IP까지 오는 경로도 추적할 수 있습니다.

Globalping 프로브에서 MTR 실행 · 네트워크 정보는 Team Cymru · 모든 위치를 왕복 시간과 대조
예시MTR · ICMP2026년 10월 23일 기록 · 도시 8곳에서

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· 13홉 · 174 ms
  1. 1–4RFC 3927Vultr 네트워크 안의 사설 주소 4개사설 주소0%0.4 ms0.1–11.1
  2. 5206.249.1.25CogentAS174트랜짓손실 0%지터 53.0159 ms158–159
    여기서부터 +158 ms: 요하네스버그 → 런던, 9,100 km. 거리 때문이며 문제가 아닙니다.
  3. 6be9736.ccr81.lon01.atlas.cogentco.com154.54.93.42CogentAS174트랜짓손실 0%지터 53.7160 ms159–160
  4. 7ldn-b3-link.ip.twelve99.net62.115.9.28ArelionAS1299트랜짓손실 0%지터 59.6179 ms179–179
    런던 안에서 +14.3 ms: 응답이 패킷이 간 길보다 더 긴 길로 돌아옵니다.
  5. 8ldn-bb2-link.ip.twelve99.net62.115.140.70ArelionAS1299트랜짓손실 0%지터 61.6185 ms185–185
  6. 9prs-bb2-link.ip.twelve99.net62.115.133.239ArelionAS1299트랜짓손실 0%지터 62.8188 ms188–188
  7. 10mei-b5-link.ip.twelve99.net62.115.124.57ArelionAS1299트랜짓손실 0%지터 62.8188 ms188–188
  8. 11wikimedia-ic-370330.ip.twelve99-cust.net62.115.147.133ArelionAS1299트랜짓손실 0%지터 69.8192 ms188–209
  9. 12irb-601.asw1-b12-drmrs.wikimedia.org185.15.58.143Wikimedia FoundationAS14907목적지 네트워크손실 0%지터 61.9182 ms180–184
  10. 13wikipedia.org185.15.58.224Wikimedia FoundationAS14907목적지손실 0%지터 58.0174 ms174–174
지금까지의 시간이 홉에서 늘어난 시간라우터 응답이 느림0~200 ms, 이 도시의 눈금
요하네스버그의 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일

프로브산호세1라우터 12라우터 23라우터 34라우터 45목적지TTL 1라우터 1의 Time ExceededOracle Cloud0.2 msTTL 2라우터 2의 Time ExceededEquinix0.4 msTTL 3라우터 3의 Time ExceededEquinix1.8 msTTL 4라우터 4의 Time ExceededWikimedia Foundation2.0 msTTL 5목적지의 Echo Replywikipedia.org1.7 ms
  1. TTL 1Oracle Cloud0.2 ms
  2. TTL 2Equinix0.4 ms
  3. TTL 3Equinix1.8 ms
  4. TTL 4Wikimedia Foundation2.0 ms
  5. TTL 5wikipedia.org1.7 ms
  • 프로브: 라우터를 지날 때마다 TTL이 1씩 줄어듦
  • TTL이 0이 되면 라우터가 프로브를 버림
  • 라우터의 응답: ICMP Time Exceeded
각 선이 프로브 하나입니다. 첫 프로브는 첫 번째 라우터에서, 다음 프로브는 두 번째 라우터에서 만료되는 식입니다. 프로브를 버린 라우터는 그 사실을 알리고, 그 응답 시간이 홉의 시간이 됩니다. 산호세에서 실행한 실제 MTR(Globalping, 2026년 10월 23일): 5홉, wikipedia.org까지 1.7 ms.
온라인 traceroute 결과: 8개 도시에서 wikipedia.org까지의 경로를 세계 지도에 그리고 홉마다 네트워크와 시간을 보여 주는 화면온라인 traceroute 결과: 8개 도시에서 wikipedia.org까지의 경로를 세계 지도에 그리고 홉마다 네트워크와 시간을 보여 주는 화면결론각 도시가 사이트에 어떻게 도달했는지 가장 빠른 왕복 시간부터 가장 느린 시간까지 한 줄로 보여 줍니다.응답하는 곳목적지를 소유한 네트워크와, 사이트가 몇 개의 주소와 장소에서 응답했는지 보여 줍니다.측정 결과 해석홉에서 읽어 낸 내용입니다. 어디에서 시간이 늘어나는지, 구간의 증가가 단순히 거리 때문인지, 손실이 실제인지 보여 줍니다.패킷이 지나간 곳각 도시의 경로를 세계 지도에 표시하며, 각 라우터는 왕복 시간이 허용하는 곳에만 배치합니다.
8개 도시에서 wikipedia.org까지 홉별로 실행한 traceroute입니다. 번호를 선택하면 각 부분이 무엇을 보여 주는지 확인할 수 있습니다.

traceroute 결과는 어떻게 읽나요?

위에서 아래로 읽습니다. 각 줄은 경로 위의 라우터 하나와 그 응답에 걸린 시간입니다. 중요한 것은 시간이 올라가서 그대로 유지되는 곳과 목적지가 응답하는지입니다.

한 줄만 시간이 높고 다음 줄들은 그렇지 않다면, 그 라우터는 전달이 아니라 응답이 느린 것입니다. 응답을 만드는 일은 라우터 프로세서에게 우선순위가 낮은 작업이기 때문입니다. 한 홉 뒤에 사라지는 손실은 라우터가 응답을 제한하는 것입니다. 체감에 영향을 주는 것은 마지막 줄까지 이어지는 시간과 손실뿐입니다. 각 줄의 주소는 프로브가 도착한 인터페이스이므로, 같은 라우터도 다른 경로에서는 다른 주소로 보일 수 있습니다.

뭄바이 → wikipedia.org, 한 줄씩 읽기MTR, 홉마다 패킷 5개

#홉네트워크손실평균
11140.91.204.30Oracle Cloud0%0.6
2125.17.12.178Airtel20%17.5
3125.17.12.177Airtel0%2.3
4116.119.42.61Airtel0%355.3
5* * *––
6ethernet-1-55-100.asw1-603-eqsin.wikimedia.org4Wikimedia Foundation0%57.4
7wikipedia.orgWikimedia Foundation0%562.6
  1. 1홉 번호TTL입니다. 첫 라우터가 1입니다.
  2. 2네트워크라우터를 운영하는 곳: AS 번호와 브랜드입니다.
  3. 3증가 구간시간이 올라간 뒤 그대로 유지되는 곳으로, 보통 거리 때문입니다.
  4. 4라우터 이름PTR 이름입니다. 이름 속 코드가 도시를 나타내는 경우가 많습니다.
  5. 5목적지마지막 줄: 방문자의 패킷에 실제로 걸리는 시간입니다.
실제 측정입니다(Globalping, 2026년 10월 23일). 중요한 시간은 이후에도 유지되는 시간입니다. 뒤 홉보다 느린 홉은 응답이 느렸을 뿐입니다.

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 hosttraceroutetracert host · traceroute hostMTRmtr hostpathpingpathping host
경로 표시모든 홉모든 홉, 실시간모든 홉
홉별 시간홉마다 프로브 3개평균, 최저, 최고쿼리 100개 후
홉별 손실프로브 몇 개로는 알 수 없음모든 라운드를 집계홉마다 프로브 100개
종단 간 시간과 손실예마지막 줄마지막 줄예
걸리는 시간4초5~30초멈출 때까지 실행홉마다 약 25초
이럴 때 사용숫자 하나만 필요할 때경로를 알고 싶을 때손실이 의심될 때Windows에서 손실을 봐야 할 때
각 도구가 측정하는 것입니다. MTR은 계속 추적하는 traceroute이므로 홉별 손실에 의미가 있습니다. 이 페이지는 모든 도시에서 MTR을 실행합니다. pathping의 시간은 기본값으로 계산한 것으로, 홉마다 250 ms 간격으로 쿼리 100개를 보냅니다.

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직접 선택
traceroute에는 고유한 포트가 없습니다. Linux와 macOS는 33434번부터 위쪽 포트로 UDP를 보내고(IANA는 traceroute용으로 33434번만 등록했습니다), Windows는 ICMP 에코 요청을 보냅니다. 이를 버리는 방화벽도 443번 포트로 가는 TCP는 웹사이트 방문처럼 보이므로 통과시키는 경우가 많습니다.

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는 이름 조회를 건너뛰어 더 빨리 끝납니다.

뭄바이의 저희 서버 → bbc.co.ukUDP · 홉마다 프로브 1개 · 2026년 10월 23일

$ 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  *
  1. 11번 홉은 서버 자체의 게이트웨이로, 경로의 첫 라우터입니다.
  2. 2* 하나는 응답하지 않은 라우터이며, 추적은 다음 홉으로 계속됩니다.
  3. 38번 홉 다음부터 20홉 한도까지 응답이 없습니다. 목적지 쪽에서 이 UDP 프로브를 버립니다.
저희 서버에서 bbc.co.uk까지 기록한 실행 결과(2026년 10월 23일, UDP, 홉마다 프로브 1개)를 traceroute가 출력하는 그대로 보여 줍니다. 명령어는 모든 언어에서 같습니다.

한 홉에서 지연 시간이 갑자기 늘어나는 이유는?

대개 그 홉에서 경로가 바다나 대륙 같은 먼 거리를 건너기 때문입니다. 광섬유 속 빛은 100 km마다 왕복 약 1 ms를 더하므로, 거리에 맞는 증가는 정상입니다.

케이블은 직선으로 놓이지 않으므로 지도상 거리 1,000 km당 약 12.5 ms를 잡으세요. 거리에 필요한 시간의 약 두 배보다 큰 증가나, 경로가 이동하지 않았는데 나타나는 증가는 우회, 혼잡한 링크 또는 더 긴 복귀 경로를 뜻합니다. 각 응답은 프로브가 간 길과 다른 경로로 돌아올 수 있습니다. MPLS 터널 안에서는 모든 홉이 터널 끝의 시간을 보여 줄 수 있어서, 서로 다른 도시에 있는 여러 홉이 같은 숫자를 보고합니다.

시간이 늘어나는 곳: 요하네스버그 → wikipedia.org느린 응답은 제외

050100150200250123456789101112135번 홉에서 +158 ms요하네스버그 → 런던, 9,100 km홉ms

거리 때문일까? 100 km당 왕복 1 ms증가 구간 1개, 2026년 10월 23일 측정

  • 요하네스버그 → 런던9,100 km · 최소 91 ms+158거리
  • 거리가 허용하는 최솟값(광섬유 속 빛)
  • 측정된 증가
광섬유 속 빛은 1밀리초에 약 200 km를 가므로, 왕복에는 직선거리 100 km당 최소 1 ms가 걸립니다. 케이블은 직선보다 깁니다. 이 최솟값의 약 두 배 이내인 증가는 거리 때문입니다. 각 단계는 그 홉이나 이후 홉의 가장 낮은 시간이므로, 응답만 느린 라우터는 단계를 만들지 않습니다.

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
나Jio · AS55836 · 가정용 회선에서 흔히 그렇듯 내 앞의 마지막 홉들은 응답하지 않습니다203.0.113.7
나에게 오는 경로는 내 traceroute가 밖으로 나가는 경로와 다른 경로입니다. 방향마다 따로 라우팅되기 때문입니다. 가정용 회선까지 기록한 실행 예시이며, 주소는 문서용 주소입니다.

온라인 traceroute 자주 묻는 질문

traceroute는 무엇에 쓰나요?

traceroute는 웹사이트나 IP 주소까지 패킷이 지나는 경로와, 경로 위 각 라우터가 응답하는 데 걸리는 시간을 보여 줍니다. 연결이 느려지거나 끊기는 곳이 통신사 안인지, 장거리 링크인지, 목적지인지 찾는 데 씁니다. 이 온라인 traceroute는 8개 도시에서 동시에 실행하므로 경로를 비교할 수 있습니다.

온라인 traceroute 사용법은?

위에 웹사이트나 IP 주소를 입력하고 추적을 누르세요. 산호세, 애슈번, 런던, 상파울루, 뭄바이, 도쿄, 시드니, 요하네스버그의 프로브가 동시에 홉마다 패킷 5개로 MTR을 실행합니다. 각 도시의 경로가 네트워크, 시간, 손실과 함께 홉별로 표시되고 세계 지도에도 나타납니다.

tracert와 traceroute는 같은가요?

목적은 같고 세부는 다릅니다. tracert는 Windows 명령어로, ICMP 에코 요청을 홉마다 3개씩 최대 30홉까지 보냅니다. Linux와 macOS의 traceroute는 기본적으로 UDP 프로브를 보냅니다. 둘 다 TTL을 한 단계씩 올리며 응답하는 라우터를 나열합니다. 이 페이지는 ICMP, TCP, UDP 프로브를 보낼 수 있습니다.

traceroute에서 * * *는 무슨 뜻인가요?

별표 하나는 대기 시간 안에 응답을 받지 못한 프로브 하나입니다. 많은 라우터가 traceroute 프로브에 응답하지 않거나 응답을 제한하므로, 이후 홉이 응답한다면 중간의 별표는 정상입니다. 별표가 끝까지 이어진다면 목적지나 방화벽이 프로브를 버리는 것이니 여기서 TCP 443을 사용해 보세요.

traceroute가 웹사이트 앞에서 멈추는 이유는?

대개 웹사이트의 네트워크나 방화벽이 traceroute의 UDP 또는 ICMP 프로브를 버리기 때문이며, 일반 방문은 그대로 통과합니다. 사이트가 열린다면 네트워크는 정상입니다. 프로토콜을 TCP 443으로 설정하고 다시 추적하세요. 웹 방문처럼 보이므로 목적지에 더 자주 도달합니다.

한 홉에서만 지연 시간이 높으면 문제인가요?

목적지까지 이어질 때만 문제입니다. 프로브에 늦게 응답하는 라우터는 자기 줄에서만 시간이 높고 그 뒤 홉은 더 빠릅니다. 이는 겉보기일 뿐입니다. 끝까지 이어지는 증가는 대개 거리 때문이며, 광섬유 100 km당 왕복 약 1 ms입니다. 이 페이지는 각 증가를 이 기준과 대조합니다.

내 IP 주소로 traceroute를 할 수 있나요?

네, “내 IP까지 추적”을 선택하세요. 버튼을 누르면 여러 도시의 프로브가 내 공인 IP 주소까지 추적해 인터넷이 내 통신사에 어떻게 도달하는지 보여 줍니다. 가정용 공유기는 프로브에 응답하지 않으므로 마지막 홉들은 보통 응답이 없습니다. Globalping은 모든 결과를 공개하므로 내 주소는 공개 측정의 일부가 됩니다.

traceroute와 MTR의 차이는 무엇인가요?

traceroute는 홉마다 프로브 몇 개를 한 번 보내고 끝납니다. MTR은 라운드를 거듭하며 계속 보내므로 각 홉에 많은 패킷에서 얻은 손실, 지터, 최저·평균·최고 시간이 나옵니다. 그래서 홉별 손실에 의미가 생깁니다. 이 페이지는 모든 도시에서 홉마다 패킷 5개로 MTR을 실행합니다.

traceroute에서 네트워크 홉 수는 몇 개가 정상인가요?

정해진 수는 없습니다. 프로브와 목적지 사이에 네트워크와 라우터가 얼마나 있는지에 따라 다릅니다. 가까운 사이트는 4~6홉, 먼 사이트는 15홉 이상일 수 있습니다. 도구에는 최대값이 있어 tracert, Linux traceroute, MTR은 30홉, macOS traceroute는 64홉에서 멈춥니다.

이 온라인 traceroute는 무료인가요? 저장되는 정보가 있나요?

무료이며 가입도 필요 없습니다. 추적은 jsDelivr가 운영하는 무료 프로브 네트워크인 Globalping에서 실행됩니다. 도시마다 내 네트워크에 시간당 주어지는 무료 테스트 250회 중 1회를 쓰며(브라우저가 Globalping에 연결할 수 없으면 dnsrobot.net의 테스트를 씁니다), Globalping은 결과를 공개합니다. 저희는 페이지를 위해 각 홉의 네트워크와 위치를 조회할 뿐, 사용자에 관한 정보는 아무것도 보관하지 않습니다.