traceroute（Windows では tracert）は、目的のホストまでにパケットがどのルーターを経由しているかを1段ずつ表示するコマンドです。「どこで通信が止まっているか」「どこから遅くなっているか」を調べるのに使えますが、出力には誤解しやすい点がいくつもあります。この記事では、OS ごとの使い方、仕組み、* * * や途中の遅延の読み方、ICMP が止められた環境で TCP を使って調べる方法までを説明します。
traceroute の仕組み
IP パケットには TTL（IPv6 では Hop Limit）という値があり、ルーターを1台通るたびに1ずつ減ります。0 になったパケットは捨てられ、捨てたルーターは送信元に ICMP の「Time Exceeded」を返します。
traceroute はこの性質を利用して、TTL=1、2、3…と増やしながらパケットを送ります。TTL=1 なら最初のルーター、TTL=2 なら2台目のルーターがエラーを返すので、返ってきたエラーの送信元を並べると経路の一覧になります。目的のホストに着いた段階で、相手からの応答（ICMP Echo Reply、Port Unreachable、TCP の応答など）が戻って終了します。
送るパケットの種類は実装によって異なります。
- Linux / macOS の traceroute：既定は UDP（高い番号のポート宛て）。
-Iで ICMP、Linux 版では-Tで TCP に切り替えられます。 - Windows の tracert：ICMP Echo Request を使います。
- Linux の tracepath：UDP を使い、root 権限なしで動きます。経路上の MTU も表示します。
この違いは重要です。経路上のファイアウォールが UDP を止めていれば Linux の traceroute は途中で途切れ、ICMP を止めていれば tracert が途切れます。片方の結果だけで判断しないことが、正しく読むための第一歩です。
基本の使い方
Linux ではディストリビューションによって traceroute が入っていないことがあります。Debian / Ubuntu 系なら traceroute パッケージ、RHEL 系でも同名のパッケージで導入できます（パッケージ名は2026年10月現在のもので、ディストリビューションにより異なる場合があります）。
# Debian / Ubuntu
sudo apt install traceroute
# RHEL / AlmaLinux / Rocky Linux
sudo dnf install traceroute
# 基本形（名前解決をしない -n を付けると速く、見やすい）
traceroute -n example.com
# ICMP で調べる（Windows の tracert と同じ方式）
sudo traceroute -I -n example.com
# 最大ホップ数と1ホップあたりの試行回数を指定
traceroute -n -m 20 -q 3 example.com
# root 不要で MTU も分かる
tracepath -n example.comWindows ではコマンドプロンプトや PowerShell で tracert を使います。
rem 名前解決をしない（-d）と結果が早く出る
tracert -d example.com
rem 最大ホップ数 20、各応答の待ち時間 1000 ミリ秒
tracert -d -h 20 -w 1000 example.com既定の最大ホップ数はどちらも 30 です。国内のサーバーなら通常は 10〜20 ホップ程度で到達します。
出力の読み方
Linux の traceroute の出力例です（アドレスは説明用）。
1 192.168.1.1 0.512 ms 0.433 ms 0.401 ms
2 * * *
3 198.51.100.1 6.812 ms 6.705 ms 6.950 ms
4 198.51.100.33 7.320 ms 45.110 ms 7.204 ms
5 203.0.113.5 12.044 ms 11.982 ms 12.101 ms
6 192.0.2.10 12.330 ms 12.210 ms 12.287 ms各行が1ホップで、左から順番、ルーターのアドレス、3回分の往復時間です。1行目は通常、自分のネットワークのデフォルトゲートウェイです。
「* * *」は故障とは限らない
* は「時間内に返事がなかった」という意味です。上の例の2行目は返事がありませんが、3行目以降は応答しています。これは、そのルーターが Time Exceeded を返さない設定になっている、あるいは ICMP の送信数を制限しているだけで、パケット自体は先へ転送されていることを示します。
本当に問題なのは、**ある段から先がすべて * になり、目的地まで一度も応答がない**場合です。その場合、最後に応答したルーターの先で、パケットが捨てられているか、経路が途切れているか、ファイアウォールが調査用のパケットを止めている可能性があります。
途中の遅延は最終地点と合わせて判断する
上の例の4行目には 45 ms という突出した値がありますが、5行目と6行目は 12 ms 前後に戻っています。ルーターにとって、自分宛ての ICMP エラーを作る処理は優先度が低く、転送処理とは別に扱われることが多いため、途中のホップだけが遅く見えることはよくあります。
遅延が本物かどうかは、そのホップ以降のすべてで値が高いまま続くかで判断します。ある段から先がそろって遅くなっていれば、その付近の回線が混雑している可能性があります。
末尾の記号
Linux の traceroute では、時間の代わりに !H（ホスト到達不能）、!N（ネットワーク到達不能）、!X（管理上の理由で通信禁止）などが表示されることがあります。!X はファイアウォールが明示的に拒否しているサインで、経路の故障ではなく設定の問題です。
ICMP や UDP が止められている環境では TCP で調べる
クラウドのセキュリティグループや企業のファイアウォールでは、UDP の高い番号のポートや ICMP が止められていることがあります。その場合、実際に使うポートに TCP で調査パケットを送ると、Web サーバーまでの経路が見えることがあります。
# 443番ポート宛ての TCP SYN で経路を調べる（root 権限が必要）
sudo traceroute -T -p 443 -n example.comWindows の tracert には TCP モードがありません。PowerShell の Test-NetConnection に -TraceRoute を付けると経路を表示できますが、方式は ICMP です。TCP で経路を見たい場合は、Linux のサーバーやWSL から調べるほうが手早いです。
経路調査を役立てるコツ
反対方向からも調べる
インターネットの経路は行きと帰りで異なることがよくあります（非対称経路）。自分 → サーバーの traceroute がきれいでも、サーバー → 自分の帰り道で問題が起きていることがあります。サーバーにログインできるなら、サーバー側からも自分の回線のグローバル IP に向けて traceroute を実行してください。
正常なときの結果を残しておく
経路は日常的に変わります。障害時の結果だけを見ても、どのホップが普段と違うのか判断できません。自分が管理するサーバーへの経路は、正常時の traceroute 結果をテキストで保存しておくと比較に使えます。
継続的に見るなら mtr
traceroute は一瞬の様子しか分かりません。各ホップの損失率と遅延を継続的に集計したい場合は、traceroute と ping を組み合わせた mtr が便利です。
# 100回分を集計してレポート表示
mtr -n -r -c 100 example.commtr でも、途中ホップだけの損失は ICMP の制限によることが多く、読み方の考え方は traceroute と同じです。
問い合わせるときに添える
プロバイダーやホスティング会社に問い合わせる場合は、実行日時、送信元と宛先、使ったコマンドとオプション、正常時と障害時の結果を添えると話が早く進みます。
注意点
- 途中のルーターのアドレスは、その事業者の内部情報です。公開の場に貼る場合は、自分の回線のグローバル IP なども含めて必要に応じて伏せてください。
- 他人のネットワークに対して高頻度で調査を繰り返すのは避けてください。
- オプションの文字や既定値は実装・バージョンで異なります。
man tracerouteやtracert /?で手元の環境を確認してから使ってください。
まとめ
- traceroute は TTL を1ずつ増やして、各ルーターが返すエラーから経路を割り出す
- Linux / macOS は既定で UDP、Windows の tracert は ICMP を使うため、止められているプロトコルによって結果が変わる
- 途中の
* * *や一時的な遅延は、その先が応答していれば問題ではないことが多い - 問題を疑うのは、ある段から先がすべて応答しない、またはすべて遅くなる場合
- ICMP や UDP が止められている環境では
traceroute -T -p 443のように TCP で調べ、反対方向からの調査や mtr も組み合わせる