tracerouteは、宛先までの経路を調べるために、途中のルーターなどから返る応答を観測するコマンドです。Windowsでは主にtracertを使います。本記事では、Linux・macOS・Windowsの違い、主要オプション、出力の読み方、他の診断ツールとの使い分けを解説します。
重要なのは、途中の「*」や大きな応答時間だけで、そのルーターの故障を断定しないことです。tracerouteの結果は調査の手がかりであり、実際のサービスの動作や宛先までの測定結果と合わせて判断します。本記事の出力・ケーススタディは読み方のための架空例で、実測ログではありません。
tracerouteコマンドとは？
IPv4ではTTL（Time To Live）を小さい値から順に増やした探索パケット（プローブ）を送信します。途中でTTLが尽きたときに返るICMP Time Exceededなどを受信し、応答したIPアドレスと往復時間を表示します。IPv6ではTTLに相当するHop Limitを使います。すべての機器が診断用の応答を返すとは限りません。
表示される時間は、測定元から応答元まで行き、応答が測定元に戻るまでのRTT（往復時間）です。隣接ルーター間だけの遅延、片道時間、帯域幅、アプリケーションの処理時間を直接測った値ではありません。物理スイッチなど、IPホップとして現れない機器もあります。
- 経路上で応答した機器や、到達確認できた範囲を調べる。
- 同じ条件で取得した正常時・問題発生時の結果を比較する。
- 宛先の到達性や実際の通信障害と照合し、追加調査の範囲を絞る。
基本的な使い方：まずOSと実装を確認する
Linuxの説明は、主に「Traceroute for Linux」実装を対象とします。BusyBoxなどの別実装では対応オプションが異なります。macOS標準のtracerouteをLinux版と同一視しないでください。Linuxでコマンドが見つからない場合は、組織の手順に従い、利用できるパッケージや管理者への依頼を確認します。
ステップ1：ヘルプを確認する
WindowsはコマンドプロンプトまたはPowerShell、Linux・macOSはターミナルを開きます。次はヘルプやマニュアルを読むためのコマンドです。
tracert /?man tracerouteTraceroute for Linuxではtraceroute --helpやtraceroute --versionも使えます。macOS標準版で同じ長いオプションが使えるとは限らないため、手元のman tracerouteを基準にしてください。
ステップ2：許可された宛先を選ぶ
自分が管理している機器、または診断を許可された宛先を指定します。以下の192.0.2.10やserver.exampleは文書用の例であり、到達を試す実在のサービスではありません。実行時は許可された実際のIPアドレスやホスト名に置き換えてください。第三者のサービスへ繰り返し送信したり、広い範囲を走査したりする必要はありません。
ステップ3：回数・ホップ数・待ち時間を限定して実行する
まずはIPv4のIPアドレスを使い、逆引きDNSを省略して観測します。以下は最大12ホップ、応答待ち2秒の例です。Linux・macOSでは各TTLにつき3回、プローブ間隔500ミリ秒を指定しています。
Windows：tracert
tracert /4 /d /h 12 /w 2000 192.0.2.10WindowsのtracertはICMP Echo Requestを使います。/w 2000の単位はミリ秒で、2秒を意味します。/dは途中のIPアドレスの逆引きを省略し、/h 12は探索するホップ数の上限を指定します。
Linux：Traceroute for Linux
traceroute -4 -n -m 12 -q 3 -w 2 -N 1 -z 500 192.0.2.10この実装では通常UDPで探索します。-N 1は同時に送るプローブ数を1に制限します。これはmacOS標準版へそのまま移すオプションではありません。
macOS：標準のtraceroute
traceroute -n -m 12 -q 3 -w 2 -z 500 192.0.2.10macOSのこの例も通常はUDPで探索します。IPv6のコマンドや対応オプションは別途確認してください。Linux版の-4・-6などを、そのままmacOS標準版へ移植しないようにします。
上限の12ホップまでに宛先が見つからなくても、宛先が停止しているとは限りません。実際の経路が上限より長い場合や、応答が制限されている場合があります。必要なときだけ上限や待ち時間を調整し、止めたい場合はCtrl+Cで中断します。これらの値はコマンド全体の実行時間を正確に指定するものではありません。
主要オプションとOSごとの違い
最大ホップ数：Linux・macOSは -m、Windowsは /h
-m 12または/h 12で、どこまで探索するかを制限します。Traceroute for LinuxとWindows tracertの既定値は30ホップです。Apple公開のマニュアルはmacOS版の既定値をnet.inet.ip.ttlに基づく値としており、全OS共通で30とは説明できません。比較するときは上限を明示すると条件をそろえやすくなります。
プローブ数：Linux・macOSの -q
-q 3は各TTLで3回送る指定で、この2実装では既定値も3です。-q 1なら送信量を抑えられますが、短時間の変動を判断する材料はさらに少なくなります。Windows tracertには同じ意味の-qはありません。3つの数値が近いだけで、長期間安定していると判断しないでください。
待ち時間：同じ「w」でも単位が違う
- Linux・macOS：
-w 2は1プローブの応答待ちを秒単位で指定する。 - Windows：
/w 2000はミリ秒単位で指定する。既定値は4000ミリ秒。 - macOSのマニュアル上の既定の待ち時間は5秒。Traceroute for Linuxは既定の最大待ち時間が5秒だが、既定動作では受信済みRTTに応じた適応的な短縮も行う。単一の値で
-w 2を指定すると、この実装ではその適応計算を無効にする。
待ち時間を短くすると終了は早くなりますが、遅れて返る応答を見落として「*」が増えることがあります。長くすれば必ず原因が分かるわけでもありません。
名前の逆引きを省略：Linux・macOSは -n、Windowsは /d
途中の応答元をIPアドレスで表示し、ホスト名の逆引き待ちを減らします。ただし、宛先をホスト名で指定した場合の名前解決まで省略する指定ではありません。比較のために同じ宛先IPを使う場合は、CDNや負荷分散で名前に対応するIPが変わる点にも注意します。
ICMPで探索：Linux・macOSの -I
通常UDPを使うLinux・macOSのtracerouteでは、-IでICMP Echo Requestに切り替えられます。Windows tracertはもともとICMPを使うので、Linuxの-Iを付ける必要はありません。
ICMPならファイアウォールの影響を受けにくい、と一律には言えません。UDP・ICMP・TCPのどれを許可するかはネットワークの方針次第です。許可された範囲で方法を比較し、拒否されている診断のためにフィルターを解除しないでください。raw socketなどの権限が必要な実装・実行方法もあります。権限エラー時は管理者に確認し、むやみに権限やセキュリティ設定を変更しません。
TCPで探索：Linuxの -T とmacOSの -P は区別する
Traceroute for Linuxの-TはTCP SYNを使う指定です。macOS標準版で-Tを共通オプションとして案内することはできません。Apple公開版ではTCPを選ぶ指定は-P tcpです。ただしポートの扱いなども異なるので、Linuxのコマンドから文字だけ置き換えないでください。Windows標準のtracertにTCP探索や宛先ポートを指定する機能はありません。
Linuxの-Pはこの実装ではraw IPプロトコル指定であり、macOSの-P tcpと同じTCP SYNモードの代用ではありません。OSと実装名を確認することが大切です。
ポート指定：-p 80だけではHTTPを調べられない
Traceroute for Linuxで通常のUDP探索に-pを付けると、開始ポートを指定し、プローブごとに宛先ポートが増えます。既定の開始値は33434です。traceroute -p 80はTCPの80番ポートでHTTP通信を行う指定ではありません。TCPモードの-T -p 443なら宛先TCPポート443を固定して探索します。
macOSのApple公開版では-pはUDP/TCPの基準ポートを指定し、-eが宛先ポートを固定する指定です。Linuxの-eは別の意味なので混同しないでください。本記事ではTCPポートを指定する実行例をLinux版に限定し、macOSで必要な場合は手元のマニュアルで対応と動作を確認するものとします。
使用例：シンプルなネットワーク診断
最初は同じ測定元・宛先IP・IPバージョン・プローブ方式で1回記録します。問題発生時刻、Wi-Fiか有線か、VPNの利用状況、実行したコマンドも残しておくと、後の比較がしやすくなります。
架空の出力例
以下はLinux形式を参考に作成した説明用の出力です。IPアドレスと数値は架空であり、実行結果や実在するネットワークの構成を示していません。出力の体裁はOS・版・設定で変わります。
traceroute to 192.0.2.10 (192.0.2.10), 12 hops max, 60 byte packets
1 192.168.1.1 1.1 ms 1.2 ms 1.1 ms
2 198.51.100.1 7.2 ms 7.5 ms 7.3 ms
3 * * *
4 203.0.113.1 18.1 ms 18.3 ms 18.2 ms
5 192.0.2.10 20.4 ms 20.1 ms 20.3 ms結果の解釈
- 先頭の数字は探索時のTTL（ホップ番号）。同じTTLの各プローブに、同じ機器が応答するとは限らない。
- 各ms値は個別のプローブのRTT。前の行からの増分でも、累積値を合計するための値でもない。
- ホップ3の「* * *」は、このTTLの3つのプローブについて待ち時間内に対応する応答を受信できなかったという意味。
- 後続のホップ4と宛先から応答があるため、ホップ3で全通信が遮断されたとは判断できない。ただし、これはアプリケーションの全通信が正常という証明でもない。
- 宛先から探索方式に対応する応答が得られたかを確認する。途中で表示が終わったことと、宛先へ到達したことを区別する。
通常のUDP探索では、宛先からのICMP Port Unreachableが到達を示す終端応答になります。ICMP探索ではEcho Reply、LinuxのTCP探索ではSYN/ACKやRSTなどを扱います。どの応答でも、Webページの表示やTLS、認証、アプリケーションの正常動作までは保証しません。
結果の読み方：RTT・「*」・損失を誤解しない
1. 途中の大きなRTTは、その区間だけの遅延ではない
ルーターが通過するデータを転送する処理と、自分宛ての診断応答を生成する処理は異なります。診断応答の優先度やレート制限、測定時の負荷、返信経路などがRTTに影響します。ある行が150msでも、その後が20msに戻っているなら、その行だけを根拠に「150msの転送遅延がある」とは言えません。
逆に、ある地点以降でRTTの増大が宛先まで続き、同じ条件で繰り返しても再現し、実際の通信も遅い場合は追加調査の手がかりになります。それでも、往路・復路・経路変更などを切り分けずに、特定のルーターやリンクを原因と断定しないでください。隣接行のRTTの差を、その2台間の片道遅延として扱うのも不適切です。
2. 「*」は未応答であって、故障や転送損失の確定ではない
- 応答の生成や返信がフィルタリングされている。
- ICMPなどの診断応答にレート制限がある。
- 応答が待ち時間より遅い、または往路・復路のどこかでパケットが失われている。
- 機器がTTL超過などへの応答を返さない、または返信経路に問題がある。
途中のホップだけが未応答でも、後続のホップや宛先が応答することはあります。中継機器の未応答率を、そのまま経由するアプリケーション通信のパケット損失率に置き換えることはできません。3回程度の探索から信頼できる損失率を推定することも避けます。
その地点以降の複数ホップと宛先でも損失の傾向が続くか、同時刻にサービスの失敗があるかを確認します。この組み合わせは調査の根拠を強めますが、ICMP応答の制限や経路の違いが残るため、単独で原因を確定する証拠にはなりません。
3. 一度の結果は固定された唯一の経路図ではない
負荷分散（ECMPなど）や途中の経路変更により、同じTTLで異なるIPアドレスが現れることがあります。複数のプローブから集めた行が、1個のパケットの通った一本の連続した経路を表すとは限りません。プロトコル・送信元・宛先ポートが変わると、選択される経路も変わる可能性があります。
さらに、応答の復路は往路と一致するとは限りません（経路の非対称性）。通常のtracerouteの一覧から、復路全体は分かりません。VPN・トンネルなどで内部の経路が見えない場合もあります。表示されたホスト名だけから物理的な場所や管理者、障害の責任範囲を決めつけないようにします。
応用例：プロトコルと宛先までの挙動を比較する
LinuxでICMPを使う例
traceroute -4 -I -n -m 12 -q 3 -w 2 -N 1 -z 500 192.0.2.10UDPとICMPの通り方の違いを、許可された環境で比較する例です。macOSのICMP探索では基本例に-Iを追加し、Linux専用の-4や-N 1は使いません。Windowsは前述のtracertでICMP探索を行います。
LinuxでTCPポート443を指定する例
traceroute -4 -T -p 443 -n -m 12 -q 3 -w 2 -N 1 -z 500 192.0.2.10Traceroute for LinuxのTCP SYN探索です。対象がそのポートでの診断を許可している場合に使います。UDPやICMPと結果が違っても、TCPの方が常に「正確」とは限りません。選んだ通信方式に対する経路・フィルタリングの違いが観測されている可能性があります。TCPで宛先が表示されても、HTTPSの動作確認には、通常のクライアントで実際のサービスを確認する必要があります。
中継ルーターの発見には、TCP探索でも通常ICMP Time Exceededの返信が必要です。TCPポートが許可されているからといって、途中の全ホップが表示されるわけではありません。診断のためだけにファイアウォール、ルーティング、VPNの設定を変えることは避けます。
架空のケーススタディ：断定せずに調査を進める
ケース1：社内サーバーの途中に「*」がある
次は説明用の架空例です。社内サーバーが遅いという相談で、途中のホップ3は未応答ですが、サーバーからは約21msの応答があるとします。
1 192.168.1.1 1.1 ms 1.2 ms 1.1 ms
2 10.0.0.1 3.4 ms 3.6 ms 3.5 ms
3 * * *
4 10.0.0.50 20.8 ms 20.9 ms 21.0 msこのログだけからホップ3を原因と決めたり、ICMPフィルターの解除で遅延が直ると判断したりはできません。正常時の宛先RTT、同じ時刻のアプリケーション応答、サーバー負荷、許可された範囲の機器統計などを照合します。診断応答が表示されるようになったことと、実際のサービス品質が改善したことも別です。
ケース2：途中は高RTTだが、宛先は低RTT
次も架空例です。ホップ2だけが高RTTで、後続と宛先は低い値に戻っています。
1 192.168.1.1 1.1 ms 1.2 ms 1.1 ms
2 198.51.100.1 150.0 ms 170.0 ms 160.0 ms
3 203.0.113.1 18.0 ms 18.3 ms 18.1 ms
4 192.0.2.10 20.4 ms 20.1 ms 20.3 msこの場合、ホップ2の診断応答処理や復路の影響なども考えられ、ホップ2が実際の通信を150ms遅延させている証拠にはなりません。途中の数字だけで機器交換や設定変更へ進まず、宛先の挙動とユーザーが体験している症状を優先して確認します。
ケース3：ある地点以降と宛先で問題が続く
同じ宛先IP・方式で少数回比較し、ある地点以降のRTT増大や未応答が宛先まで続き、実際のサービスでも失敗が起きているなら、管理者に調査を依頼する材料になります。最後に応答したルーターが原因とは限りません。測定元と宛先、日時とタイムゾーン、コマンド、正常時との違い、アプリケーションのエラーをセットで伝えます。
公開の掲示板などへ結果を貼る前に、社内ホスト名、内部IP、構成が推測できる情報を確認し、必要な範囲だけ共有してください。実在するISPや企業が設定変更で問題を解決した、という実績をこれらの架空例から主張するものではありません。
他の診断ツールとの併用
ping：まず宛先に少数回送る
pingはICMP Echoの応答とRTTを確認する補助です。中間ホップの故障を証明するためではなく、まず許可された宛先に少数回送り、同時刻の結果を比較します。Linux・macOSでは次のように送信回数を限定できます。
ping -c 4 192.0.2.10Windowsでは回数指定が異なります。以下は4回、各応答の待ち時間2000ミリ秒です。
ping /n 4 /w 2000 192.0.2.10pingに応答しない設定でもサービスは動作することがあります。反対にpingが通っても、Webやメールなどのサービスが正常とは限りません。OS間でpingのオプションや待ち時間の単位を使い回さないでください。
nslookup：DNSの結果を別に調べる
nslookup server.example許可された実際のホスト名に置き換え、DNSでどのIPアドレスが返るかを確認する例です。名前解決が成功することと、そのIPへ通信できることは別です。また、nslookupの問い合わせ結果が、アプリケーションのキャッシュや独自のDNS設定を含む名前解決と完全に一致するとは限りません。
mtr：短いレポートで傾向を確認する
mtrが導入・許可されているLinuxなどでは、繰り返したプローブの集計が補助になります。常時動かすのではなく、まずは回数を限定したレポートを使います。対応オプションは導入済みの版で確認してください。
mtr -r -n -c 10 -m 12 -i 1 192.0.2.10これはレポートモード、10サイクル、最大12ホップ、間隔1秒の例です。終了までの時間は応答待ちなどにも左右されます。途中のLoss%だけで転送損失を断定しない点はtracerouteと同じです。宛先の結果とサービスの症状を照合し、10回程度の短い集計を長期的な品質保証として扱わないでください。
netstatなど：ローカルの経路を確認する
経路の選択に疑問がある場合は、OSに合った読み取り専用の経路表表示で、デフォルトルートやVPN経由かどうかを確認します。Linux・macOSでは、利用可能な環境ならnetstat -rnで経路表を表示できます。Linuxではnetstatが未導入の場合もあります。コマンドの有無や表示内容はOSのマニュアルを確認し、調査中に経路の追加・削除は行わないようにします。
Wireshark：必要な場合だけ、許可された範囲で
Wiresharkはパケットの詳細を調べる補助になりますが、通信の取得には組織の許可と適切な範囲設定が必要です。ホスト名や通信内容などが記録されることもあるため、初心者が原因不明のまま全インターフェースで収集する手順は推奨しません。まず通常の診断結果を整理し、必要なら管理者と取得対象・期間・保管先を決めてください。
まとめ
- WindowsのtracertとLinux・macOSのtracerouteは、既定の方式とオプションが異なる。特にTCPの
-TをmacOS共通と考えない。 - Windowsの
/wはミリ秒、ここで扱ったLinux・macOSの-wは秒。実装と単位を確認する。 - RTTは往復時間。「*」は待ち時間内に対応する応答がないこと。どちらも単独ではルーター故障や隣接区間の転送遅延を証明しない。
- 途中だけでなく、後続ホップ・宛先・実際のサービスの症状を照合する。負荷分散や往復の経路差も考慮する。
- 宛先と診断方法の許可を確認し、ホップ数・回数・待ち時間を制限して記録する。設定変更は診断と切り分ける。
参考資料
- Microsoft Learn：tracert（Windowsの方式・オプション・RTT）
- Traceroute for Linux公式プロジェクト、同プロジェクトのマニュアル（man7掲載）（Linux実装のオプションと注意事項）
- Apple公開ソース：traceroute.8（macOS系実装。手元のOSのマニュアルも確認）
- Paris traceroute：About（負荷分散と従来のtracerouteの限界）
- Microsoft Learn：ping、mtr公式マニュアルソース（補助診断の回数制限）
コメント