traceroute / mtr 入門 - 経路をたどって遅延区間を特定する

2026-06-05 読了時間: 約9分 難易度: 中級

この記事で解決できること

• traceroute で 宛先までの経路（どのルータを通るか） を可視化できる
• mtr で 各ホップのパケットロスと遅延を継続測定 し、どの区間が原因かを切り分けられる
• 出力の * * * や「途中ホップのロス」を 誤読せず正しく解釈 できる

traceroute は何をしているのか？

結論: TTL を 1 から順に増やしてパケットを送り、各ルータが返す ICMP Time Exceeded から経路を 1 ホップずつ復元している。

IP パケットには TTL（Time To Live） という「あと何台のルータを通過できるか」のカウンタがある。ルータは転送のたびに TTL を 1 減らし、0 になったパケットは破棄して送信元へ ICMP Time Exceeded を返す。

traceroute はこれを逆手に取る。

1. TTL=1 のパケットを送る → 1 台目のルータで TTL が 0 になり、そのルータが応答 → 1 ホップ目が判明
2. TTL=2 を送る → 2 台目が応答 → 2 ホップ目が判明
3. 宛先に届くまで TTL を増やし続ける

各ホップで既定 3 回プローブを送るため、出力には 3 つの往復時間（RTT）が並ぶ。

$ traceroute example.com

traceroute to example.com (93.184.216.34), 30 hops max, 60 byte packets
 1  _gateway (192.168.1.1)  0.512 ms  0.498 ms  0.471 ms
 2  10.0.0.1 (10.0.0.1)  4.231 ms  4.118 ms  4.090 ms
 3  * * *
 4  93.184.216.34 (93.184.216.34)  12.043 ms  11.998 ms  12.110 ms

traceroute の * * * は障害なのか？

結論: 多くの場合は障害ではない。途中ルータが ICMP/UDP 応答を返さない設定なだけで、その先まで到達できていれば経路は正常。

* * * は「3 回のプローブすべてに応答がなかった」という意味で、原因は主に次のいずれか。

• そのルータが TTL 超過への応答を抑制している（ファイアウォール / ポリシー）
• UDP プローブを遮断している（Linux traceroute の既定は UDP）
• 応答のレート制限にかかった

UDP が遮断されている疑いがあるなら、プローブ方式を変える。

# ICMP Echo（ping と同じパケット種別）で試す
$ sudo traceroute -I example.com

# TCP SYN を 443 番に送る（HTTPS が通る経路なら最も実態に近い）
$ sudo traceroute -T -p 443 example.com

traceroute のよく使うオプションは？

結論: 実務でまず覚えるのは -n（DNS 解決を省いて高速化）、-T -p（TCP で確認）、-m（最大ホップ数）の 3 つ。

# 数値表示・最大 20 ホップ・各ホップ 1 プローブで素早く
$ traceroute -n -m 20 -q 1 example.com

DNS の逆引きで待たされて遅く感じるときは、まず -n を付ける。

mtr は traceroute と何が違うのか？

結論: traceroute が「経路の一回スナップショット」なのに対し、mtr は経路上の全ホップへ ping を撃ち続け、ロス率と遅延統計をリアルタイム更新する。

ネットワークの不調は瞬間的に出たり消えたりする。traceroute の一度きりの結果では「たまたま」を拾えない。mtr は traceroute（経路探索）と ping（継続測定）を合体させ、各ホップを連続監視する。

$ mtr example.com

                             Packets               Pings
 Host                       Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. _gateway                 0.0%    20    0.5   0.6   0.4   1.2   0.2
 2. 10.0.0.1                 0.0%    20    4.2   4.3   4.0   6.1   0.5
 3. 203.0.113.1             10.0%    20   18.0  19.4  17.2  41.0   5.1
 4. 93.184.216.34            0.0%    20   12.0  12.1  11.9  12.4   0.1

各列の意味は次のとおり。

• Loss%: そのホップで応答が返らなかった割合
• Snt: 送ったプローブ数
• Last / Avg / Best / Wrst: 直近 / 平均 / 最小 / 最大の RTT（ms）
• StDev: RTT のばらつき（大きいほど不安定）

mtr のロスはどう読むのか？

結論: 中間ホップだけにロスが出て最終ホップで 0% に戻るなら、それは ICMP レート制限による偽のロス。最終ホップまで続くロスだけが本物の障害。

これが mtr 最大の落とし穴であり、最重要ポイント。上の出力例ではホップ 3 が 10.0% のロスを示すが、最終ホップ 4 は 0.0% に戻っている。

ルータは「自分宛ての TTL 超過応答」を低優先度で処理・抑制することがある。つまりホップ 3 の 10.0% は「ホップ 3 のルータが応答を間引いただけ」で、通信そのものは素通りしている。

つまり「ロスがどのホップから始まり、最後まで続くか」を見る。途中で消えるロスは捨てる。

遅延区間はどう特定するのか？

結論: Avg が大きく跳ね上がり、その値が以降のホップでも維持されていれば、跳ねた区間が遅延の発生源。一瞬跳ねて戻るのは応答処理の遅れで実害なし。

遅延もロスと同じ読み方をする。

• あるホップで Avg が急増し、それ以降のホップでも高いまま → その区間（直前ホップ→当該ホップ間）が真の遅延源
• あるホップだけ Wrst だけが突出して Avg は低い → そのルータが応答を後回しにしただけ。実通信の遅延ではない

# レポートモード: 10 サイクル送って結果を確定出力（ログ共有・チケット添付向け）
$ mtr -rwzbc 10 example.com

オプションの意味:

• -r / --report: 対話画面ではなく集計結果を 1 回出力
• -w: ワイド表示（ホスト名を省略しない）
• -z: 各ホップの AS 番号を表示（どの事業者の網かが分かる）
• -b: ホスト名と IP の両方を表示
• -c N: 送信サイクル数（既定 10）
• -n: 名前解決しない（速い）

traceroute と mtr の使い分けまとめ

結論: 経路を一度確認するだけなら traceroute、どの区間でロス・遅延が起きているかを継続的に切り分けるなら mtr。報告には mtr のレポート出力を添える。