traceroute・tracertの使い方｜見方と* * *・!Hの意味を実例で

traceroute は TTL（パケットの寿命）を1から1つずつ増やして送り、TTL が尽きたルーターから返る通知で経路を調べます。

flowchart TD
    A[TTL=1で送る] --> B[ルーター1でTTLが0<br>Time Exceeded→1行目]
    B --> C[TTL=2で送る]
    C --> D[ルーター2でTTLが0<br>Time Exceeded→2行目]
    D --> E[TTL=3で送る]
    E --> F[宛先に届く<br>到着の返事→最終行]

OS ごとの基本の書き方です。

確認環境：Ubuntu 24.04.4・Linux カーネル 6.18・traceroute 2.1.5（Modern traceroute for Linux）・mtr 0.95（mtr-tiny）・tracepath（iputils 20240117）・tcpdump 4.99.4・iptables・iproute2 6.1.0・Python 3.11。Linux の network namespace（1台の中に独立したネットワークを作る仕組み）で「PC → ルーター2台 → サーバー」を組み、ルーターでの ICMP の破棄・遅延・パケット損失・経路の欠落を1つずつ起こして、出力を載せています。遅延と損失は、ルーター間に置いた Python の中継プログラムで加えました。Windows の tracert・pathping・Test-NetConnection は Microsoft Learn、Linux の traceroute・tracepath は man7.org の man ページ、Mac（BSD 系）の traceroute は FreeBSD の traceroute(8) で確かめました（確認日 2026年10月17日）。

traceroute・tracertとは（TTLとICMP Time Exceededの仕組み）

traceroute（Windows では tracert）は、送り先までの経路上にあるルーターの一覧と、それぞれまでの往復時間（RTT）を表示するコマンドです。 「どこまでは届いていて、どこから先で止まるか」「どこから遅くなるか」を調べるときに使います。

仕組みの中心は、IP パケットのヘッダーにある TTL（Time To Live） です。ルーターはパケットを転送するたびに TTL を1減らし、0 になったパケットは捨てて、送信元に ICMP Time Exceeded（種類 11） を返します。traceroute はこの性質を使います。

Linux の traceroute は、既定で UDP のパケットを、使われていないはずのポート（33434 から1つずつ増やす）へ送ります。宛先に届くと「そのポートは閉じている」という ICMP Port Unreachable（種類 3・コード 3）が返り、それを「到着した」合図にします。Windows の tracert は ICMP Echo Request（ping と同じもの）を送ります。

パケットで見る traceroute の動き

検証環境の PC で tcpdump を取りながら traceroute -n -q 1 10.0.23.10 を実行した結果です（行を抜粋）。

192.168.1.10.58329 > 10.0.23.10.33434: UDP, length 32           ← ttl 1 で送信
192.168.1.10.32905 > 10.0.23.10.33435: UDP, length 32           ← ttl 2 で送信
192.168.1.10.59614 > 10.0.23.10.33436: UDP, length 32           ← ttl 3 で送信
192.168.1.1 > 192.168.1.10: ICMP time exceeded in-transit        ← 1台目が返事
10.0.12.2 > 192.168.1.10: ICMP time exceeded in-transit          ← 2台目が返事
10.0.23.10 > 192.168.1.10: ICMP 10.0.23.10 udp port 33436 unreachable  ← 宛先が返事

実際には ttl 1〜16 の16個がほぼ同時に出て、返事が来るたびに次の ttl が送られていました。man ページのとおり、traceroute 2.1.x は既定で16個（-N 16）を同時に送り、待ち時間を短くしています。ttl 4 以上のパケットも宛先に届くので、宛先からは port unreachable が複数返り、traceroute は最初に宛先が答えた ttl で止めます。

表示されるのは「行き」の経路だけです。 返事は相手のルーターが選んだ帰りの経路で戻るので、行きと帰りの経路は同じとは限りません。各行の時間は、その返事が戻るまでの往復の時間です。

ルーターでの TTL と転送の関係は、関連記事「デフォルトゲートウェイとは｜調べ方・設定・決め方をLinuxで実演」で扱っています。IP・ICMP がどの層の仕組みかは、関連記事「OSI参照モデルとは｜7層の早見表とTCP/IP対応・パケット実例」で扱っています。

traceroute・tracertの使い方（Linux・Mac・Windows）

Linux：traceroute のインストールとオプション

Ubuntu などでは最初から入っていないことがあります。Ubuntu のパッケージ名は traceroute です。tracepath は iputils-tracepath、mtr は mtr（画面なし版は mtr-tiny）に入っています。

sudo apt install traceroute
traceroute --version

Modern traceroute for Linux, version 2.1.5
Copyright (c) 2016  Dmitry Butskoy,   License: GPL v2 or any later

一般ユーザーで -I や -T を付けると、次のエラーになりました。既定の UDP は一般ユーザーでも動きます。

$ traceroute -n -I 10.0.23.10
You do not have enough privileges to use this traceroute method.
socket: Operation not permitted

Mac：traceroute

Mac でも同じ traceroute コマンドを使い、オプションは BSD 系の traceroute の形です。FreeBSD の traceroute(8) では、既定は UDP で基準ポートは 33434、-I で ICMP Echo、-P でプロトコル（icmp・tcp など）を選び、-n で名前を引かず、-q の既定は 3、-w の既定は 5 秒です。

traceroute -n example.com
sudo traceroute -I -n example.com

Windows：tracert のオプション

Windows はコマンドプロンプトか PowerShell で tracert を使います。Microsoft Learn の説明では、TTL を1から始めてエコー要求を送り、送るたびに TTL を1ずつ増やし、宛先が応答するか最大ホップ数に達すると終わります。

tracert /d www.microsoft.com
tracert /d /h 15 /w 1000 192.0.2.10

PowerShell では Test-NetConnection 宛先 -TraceRoute でも tracert を実行でき、-Hops で最大ホップ数を指定します。

tracerouteの出力の見方

ここからは、次の検証環境で取った出力です。ルーター2台を経由してサーバーに届く構成です。

flowchart TD
    PC[PC<br>192.168.1.10] --> R1[ルーター1<br>192.168.1.1]
    R1 --> R2[ルーター2<br>10.0.12.2]
    R2 --> SV[サーバー<br>10.0.23.10]

正常なときの出力です。

$ traceroute -n 10.0.23.10
traceroute to 10.0.23.10 (10.0.23.10), 30 hops max, 60 byte packets
 1  192.168.1.1  0.026 ms  0.003 ms  0.002 ms
 2  10.0.12.2  1.169 ms  1.166 ms  1.164 ms
 3  10.0.23.10  1.161 ms  1.160 ms  1.157 ms

Windows の tracert の出力は、Microsoft Learn では次の形です。列の意味（ホップ数・3回分の往復時間・アドレス）は traceroute と同じで、<1 ms は1ミリ秒未満を表します。名前が引けると 名前 [IP] の形で出ます。

Tracing route to <宛先> [IPアドレス]
over a maximum of 30 hops:

  1     1 ms     1 ms    <1 ms  <ホスト名> [IPアドレス]
  ...
Trace complete.

返事が無い回は * になり、すべて返事が無い行は Request timed out.（日本語版では「要求がタイムアウトしました。」）と出ます。

* * * が出るときの読み方

* * * は「その TTL で、待ち時間の間に返事が来なかった」という意味だけで、そこで通信が止まっているとは限りません。 検証環境で、* * * が出る原因を4つ起こしました。

パターン1：途中のルーターが返事をしない

ルーター2で、自分が出す ICMP Time Exceeded だけを捨てる設定にしました（iptables -A OUTPUT -p icmp --icmp-type time-exceeded -j DROP）。

$ traceroute -n 10.0.23.10
traceroute to 10.0.23.10 (10.0.23.10), 30 hops max, 60 byte packets
 1  192.168.1.1  0.025 ms  0.003 ms  0.002 ms
 2  * * *
 3  10.0.23.10  0.531 ms  0.543 ms  0.547 ms

2行目は * * * ですが、3行目で宛先に届いています。 ルーター2はパケットを転送していて、自分への通知を出していないだけです。インターネット上のルーターやクラウドの経路では、この形がよく出ます。その先の行が表示されていれば、* * * の行は無視できます。

パターン2：ICMP の送信数の制限（続けて実行すると出る）

Linux には、ICMP のエラー通知を同じ相手に送る間隔の制限があります（net.ipv4.icmp_ratelimit。カーネルのドキュメントでは既定 1000 ミリ秒で、Time Exceeded と Destination Unreachable が対象）。ルーター2をこの既定値にして、traceroute を3回続けて実行しました。

（1回目・2回目）
 2  10.0.12.2  0.897 ms  0.898 ms  0.896 ms
（3回目）
 1  192.168.1.1  0.017 ms  0.004 ms  0.003 ms
 2  * * *
 3  10.0.23.10  0.502 ms  0.523 ms  0.531 ms

宛先の側で制限がかかると、最後の行の手前に * * * が並んだあと、遅れて宛先が出ることもありました。

 1  192.168.1.1  0.020 ms  0.003 ms  0.004 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * 10.0.23.10  0.176 ms  0.033 ms

宛先は3ホップ目なのに、7行目で表示されています。3〜6行目の TTL のパケットも宛先に届いていましたが、宛先が port unreachable を返す回数を制限していたため、返事が来なかった回が * になりました。宛先の手前に * * * が並んでも、最後に宛先が出ていれば届いています。 時間をおいて実行するか、-N 1（1つずつ送る）で出にくくなります。

パターン3：途中で UDP が捨てられている（最後まで * * *）

ルーター2で、サーバー宛ての UDP を転送せずに捨てました（iptables -A FORWARD -p udp -d 10.0.23.10 -j DROP）。

$ traceroute -n -m 8 10.0.23.10
traceroute to 10.0.23.10 (10.0.23.10), 8 hops max, 60 byte packets
 1  192.168.1.1  0.190 ms  0.136 ms  0.128 ms
 2  10.0.12.2  0.372 ms  0.359 ms  0.354 ms
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *

ある行から最後まで * * * が続くのは、その先へ「traceroute のパケット」が通っていない形です。 ただし通らないのは UDP だけかもしれません。同じ状態で ICMP（-I）と TCP（-T -p 26780、サーバーで待ち受けているポート）を試すと、どちらも宛先まで届きました。

$ sudo traceroute -n -I -m 8 10.0.23.10
 1  192.168.1.1  0.032 ms  0.003 ms  0.002 ms
 2  10.0.12.2  0.406 ms  0.421 ms  0.429 ms
 3  10.0.23.10  0.437 ms  0.444 ms  0.448 ms

$ sudo traceroute -n -T -p 26780 -m 8 10.0.23.10
 1  192.168.1.1  0.019 ms  0.003 ms  0.002 ms
 2  10.0.12.2  0.502 ms  0.882 ms  0.902 ms
 3  10.0.23.10  0.919 ms  0.933 ms  0.939 ms

最後まで * * * になったら、方式を変えて試します。 Web サーバーなら -T -p 443 のように、実際に使うポートで調べると、ファイアウォールを通る経路を見られます。ファイアウォールの設定は、関連記事「ufwとfirewalldの使い方｜コマンド対応表とSSH締め出し対策」で扱っています。

パターン4：返事が遅く、待ち時間を超えた

ルーター2が出す Time Exceeded だけを 150 ミリ秒遅らせました（転送するパケットは遅らせていません）。すると、既定の設定では2行目が * * * になりました。

$ traceroute -n 10.0.23.10
 1  192.168.1.1  0.070 ms  0.006 ms  0.003 ms
 2  * * *
 3  10.0.23.10  1.624 ms  2.206 ms  2.220 ms

待ち時間の既定は5秒なので、150 ミリ秒で * になるのは意外に見えます。原因は -w MAX,HERE,NEAR の既定値 5.0,3,10 です。man ページでは、先のホップからすでに返事が来ていると、その往復時間の NEAR 倍（既定 10 倍）までしか待ちません。この例では3ホップ目が約 2 ミリ秒で答えていたため、2ホップ目は約 20 ミリ秒で打ち切られました。-w 5,0,0（最大時間だけで待つ）か -N 1（1つずつ送る）にすると、表示されました。

$ traceroute -n -w 5,0,0 10.0.23.10
 1  192.168.1.1  0.031 ms  0.003 ms  0.003 ms
 2  10.0.12.2  151.264 ms  151.319 ms  151.323 ms
 3  10.0.23.10  0.668 ms  0.685 ms  0.688 ms

!H・!N・!X など記号の意味

時間の後ろに ! で始まる記号が付いたら、ルーターや宛先から「届けられない」という通知（ICMP Destination Unreachable）が返っています。* * * と違い、はっきり止められた合図です。 記号は Linux の traceroute と FreeBSD の traceroute(8) の man ページで共通のものが多くあります。

検証環境で、!N・!H・!X・!F を起こした出力です。

（ルーター2に 172.16.5.5 への経路が無い）
$ traceroute -n 172.16.5.5
 1  192.168.1.1  0.028 ms  0.002 ms  0.002 ms
 2  10.0.12.2  0.844 ms !N  0.833 ms !N  0.830 ms !N

（サーバー側のネットワークに 10.0.23.99 の機器が無い）
$ traceroute -n 10.0.23.99
 1  192.168.1.1  0.022 ms  0.004 ms  0.007 ms
 2  10.0.12.2  0.694 ms  0.672 ms  0.658 ms
 3  10.0.12.2  3052.303 ms !H  3052.325 ms !H  3052.324 ms !H

（ルーター2で REJECT --reject-with icmp-admin-prohibited）
$ traceroute -n 10.0.23.10
 2  10.0.12.2  0.214 ms  0.185 ms  0.251 ms
 3  10.0.12.2  0.223 ms !X  0.216 ms !X  0.180 ms !X

（サーバー側の MTU を 1400 にして、1500 バイトで分割禁止を付けて送る）
$ traceroute -n -F 10.0.23.10 1500
 2  10.0.12.2  0.831 ms  0.799 ms  0.820 ms
 3  10.0.12.2  0.913 ms !F-1400  0.909 ms !F-1400  0.906 ms !F-1400

• !H の 3052 ミリ秒は、ルーター2が ARP（IP アドレスから機器を探す仕組み）で 10.0.23.99 を約3秒探し、見つからずに諦めた時間です。
• !H・!X の行は、3ホップ目なのにルーター2（10.0.12.2）が表示されます。記号の付いた行のアドレスは「止めた機器」です。
• FreeBSD の traceroute(8) では、時間の後ろに記号の付かない ! だけが出ることがあり、返事の TTL が1以下だったことを表します。

遅延が途中で増えるときの解釈

時間が途中の行から大きくなったとき、「そこが遅い」とは限りません。検証環境で2つの形を作り、並べました。

本当に遅い区間があると、その先の行もすべて遅くなります。 ルーター1と2の間の回線に片道 20 ミリ秒の遅延を足すと、2行目と3行目がそろって約 40 ミリ秒（往復分）増えました。ping も同じ値です。

$ traceroute -n 10.0.23.10
 1  192.168.1.1  0.034 ms  0.003 ms  0.002 ms
 2  10.0.12.2  40.725 ms  40.726 ms  40.722 ms
 3  10.0.23.10  40.718 ms  40.715 ms  40.711 ms

$ ping -c 3 -q 10.0.23.10
rtt min/avg/max/mdev = 40.445/40.516/40.592/0.060 ms

1つの行だけが遅く、その先が速いなら、そのルーターの返事が遅いだけです。 ルーターは転送を優先し、自分で ICMP を作る処理は後回しにすることがあります。前の節のパターン4では2行目だけ 151 ミリ秒で、宛先は 0.7 ミリ秒のままでした。このとき、宛先への ping は 0.155 ミリ秒で、通信そのものは遅くありません。

UDP・ICMP・TCPの違い（-I・-T）

どの方式でも経路の調べ方（TTL を増やす）は同じで、違うのは「送るパケットの種類」です。 ファイアウォールはパケットの種類ごとに通す・捨てるを決めるので、方式によって結果が変わります。

TCP の方式は、閉じたポートでも宛先から RST（接続の拒否）が返るため、宛先まで表示されます。検証環境で、待ち受けていないポート 80 に -T で送っても、3行目にサーバーが表示されました。

mtr・tracepath・pathpingとの違い

mtr：損失がどこから始まるかを見る

mtr は、各ホップへ繰り返し送り、損失率（Loss%）と時間の統計を出します。-r で結果を表にして終わり、-c で回数を決めます。ルーター1と2の間で、パケットを片道 10% ずつ捨てたときの結果です。

$ mtr -r -n -c 50 -i 0.2 10.0.23.10
HOST: vm                          Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.1.1                0.0%    50    0.1   0.1   0.0   0.4   0.1
  2.|-- 10.0.12.2                 20.0%    50    0.2   0.5   0.2   5.6   1.0
  3.|-- 10.0.23.10                20.0%    50    0.2   0.3   0.2   3.8   0.6

2行目から損失が始まり、宛先まで同じ割合で続いています。これが本当の損失の形です。 一方、ルーター2に ICMP の送信数の制限をかけたときは、次のようになりました。

  1.|-- 192.168.1.1                0.0%    20    0.0   0.2   0.0   3.7   0.8
  2.|-- 10.0.12.2                 85.0%    20    0.3   2.3   0.3   5.8   3.1
  3.|-- 10.0.23.10                 0.0%    20    0.4   0.3   0.2   0.4   0.1

2行目は 85% の損失ですが、宛先は 0% です。途中の行だけ損失が高く、宛先が 0% なら、そのルーターが返事を間引いているだけです。 判断は「最後の行の損失率」と「損失が始まって宛先まで続くか」で行います。mtr は既定で ICMP を使い、-u で UDP、-T で TCP、-P でポートを指定できます。

tracepath：MTU も一緒に調べる

$ tracepath -n 10.0.23.10
 1?: [LOCALHOST]                      pmtu 1500
 1:  192.168.1.1                                           0.238ms 
 1:  192.168.1.1                                           0.009ms 
 2:  10.0.12.2                                             0.151ms 
 3:  10.0.12.2                                             0.132ms pmtu 1400
 3:  10.0.23.10                                            0.093ms reached
     Resume: pmtu 1400 hops 3 back 3 

サーバー側の MTU を 1400 にした状態です。pmtu 1400 で、経路の途中で MTU が 1400 に下がることが分かります。reached は宛先に届いた、Resume 行は経路の MTU・ホップ数・帰りのホップ数の推定です。traceroute でも --mtu で同じことを調べられ、3行目に F=1400 と出ました。

pathping：Windows で損失の区間を調べる

Microsoft Learn の説明では、pathping は tracert と同じように経路を調べたあと、各ルーターに一定期間 ping を送り、ルーターごと・区間ごとの損失を集計します。既定は各ホップ 100 回（/q）、0.25 秒おき（/p）なので、5ホップなら統計に約 125 秒かかります。

pathping /n 宛先

結果の「This Node/Link」の列のうち、ルーターの行の損失は「そのルーターが自分宛ての ping を捨てた」もの、ルーターの間の | の行の損失は「その区間で転送中に失われた」ものです。Microsoft Learn の例でも、| の行の 13% が実際の問題で、ルーターの行の 3% は転送に影響しない、と説明されています。

よくあるエラーと直し方

検証環境で出たエラー（コマンドが無いとき以外）と、その原因です。

ループは、ルーター2に「172.16.0.0/16 はルーター1へ」という誤った経路を入れて起こしました。ルーター1はルーター2へ、ルーター2はルーター1へ返すため、2つのアドレスが交互に並び、最大ホップ数まで終わりません。

$ traceroute -n -m 8 172.16.5.5
 1  192.168.1.1  0.029 ms  0.002 ms  0.002 ms
 2  10.0.12.2  0.553 ms  0.558 ms  0.555 ms
 3  192.168.1.1  0.555 ms  0.554 ms  0.553 ms
 4  10.0.12.2  0.952 ms  0.965 ms  0.962 ms
 5  192.168.1.1  0.960 ms  0.959 ms  0.958 ms
 ...

名前が引けないときの切り分けは、関連記事「nslookupの使い方｜逆引き・DNS指定・MX・エラーの意味を実例で」で扱っています。

tracerouteでの切り分けの手順

ネットワークの確認に使うほかのコマンド（ip・ss・nc）は、関連記事「Linuxネットワークコマンド一覧｜ip/ss/ncで障害切り分け」で扱っています。

よくある質問

Q. traceroute と tracert の違いは？ A. どちらも TTL を増やして経路を調べるコマンドで、Linux・Mac は traceroute、Windows は tracert です。既定で送るパケットが違い、traceroute は UDP、tracert は ICMP Echo です。traceroute -I で tracert と同じ方式になります。

Q. traceroute の見方は？ A. 先頭の数字がホップ数、次が返事をしたルーターのアドレス、続く3つの時間が3回分の往復時間です。最後の行が宛先なら届いています。「tracerouteの出力の見方」の節に、列ごとの意味をまとめています。

Q. traceroute で * * * が出るのはなぜ？ A. その TTL で返事が来なかったという意味で、ルーターが返事をしない設定、ICMP の送信数の制限、待ち時間切れでも出ます。その先の行が表示されていれば問題ではありません。最後まで続くときは -I・-T で試します。

Q. tracert の使い方は？ A. コマンドプロンプトで tracert /d 宛先 と入力します。/d で名前を引かずに速く終わり、/h で最大ホップ数、/w で待ち時間（既定 4000 ミリ秒）を変えられます。

Q. traceroute の !H・!N の意味は？ A. !H はホストに、!N はネットワークに到達できないという通知です。!X は管理上の禁止（ファイアウォール）を表します。記号の付いた行のアドレスが、止めた機器です。

まとめ

• traceroute・tracert は、TTL を1から増やし、TTL が尽きたルーターから返る ICMP Time Exceeded で経路を調べる。
• Linux・Mac の traceroute は既定が UDP、Windows の tracert は ICMP Echo。-I（ICMP）・-T（TCP）で方式を変えられる。
• 途中の * * * は、その先が表示されていれば問題ではない。最後まで続くなら方式を変えて試す。
• !N・!H・!X・!F は「届けられない」というはっきりした通知で、その行のアドレスが止めた機器。
• 1行だけ遅いのはそのルーターの返事が遅いだけ。本当の遅延や損失は、その先の行もすべて悪くなる。
• 損失や遅延の統計は mtr（Linux・Mac）・pathping（Windows）、MTU は tracepath で調べる。

参考・出典

確認日はいずれも 2026年10月17日です。

• Microsoft Learn「tracert」：https://learn.microsoft.com/ja-jp/windows-server/administration/windows-commands/tracert
• Microsoft Learn「pathping」：https://learn.microsoft.com/ja-jp/windows-server/administration/windows-commands/pathping
• Microsoft Learn「Test-NetConnection」：https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection
• Linux man-pages「traceroute(8)」：https://man7.org/linux/man-pages/man8/traceroute.8.html
• Linux man-pages「tracepath(8)」：https://man7.org/linux/man-pages/man8/tracepath.8.html
• FreeBSD Manual Pages「traceroute(8)」：https://man.freebsd.org/cgi/man.cgi?query=traceroute&sektion=8
• mtr（公式サイト）：https://www.bitwizard.nl/mtr/
• The Linux Kernel documentation「IP Sysctl」：https://docs.kernel.org/networking/ip-sysctl.html
• RFC 792「Internet Control Message Protocol」：https://www.rfc-editor.org/rfc/rfc792

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。