tracert は Windows、traceroute は Linux や macOS の経路調査コマンドで、どちらも TTL を1ずつ増やしながら中継点を洗い出す仕組みは同じです。大きな違いは「どの種類のパケットで調べるか」で、tracert は ICMP、traceroute は既定で UDP を使います。この違いのせいで、同じ宛先でも結果が食い違うことがあります。この記事では、両者の違いを整理し、調べたい状況に応じてどちらを、どのオプションで使えばよいかを説明します。
共通する仕組み
どちらのコマンドも、次の流れで経路を調べます。
- TTL（通過できるルーターの数）を 1 にしてパケットを送る
- 最初のルーターで TTL が尽き、そのルーターから「時間超過」の ICMP が返る
- TTL を 2、3 と増やしながら繰り返し、宛先に届いたら終了する
1ホップあたり3回ずつ送るのも、最大ホップ数の既定が 30 なのも共通です。違いは、手順1で送るパケットの種類と、宛先に届いたことの判定方法にあります。
違い1：送るパケットの種類
tracert（Windows）は ICMP Echo
tracert は ping と同じ ICMP Echo Request を、TTL を変えながら送ります。宛先に届くと ICMP Echo Reply が返り、それで到達したと判断します。したがって、宛先が ping に応答しない設定だと、tracert も最後のホップで応答なし（*）になります。
traceroute（Linux / macOS）は既定で UDP
traceroute は既定で、通常使われない高い番号のポート（33434 番から順に）へ UDP パケットを送ります。宛先に届くと、そのポートでは何も待ち受けていないため「ポート到達不能」の ICMP が返り、それで到達を判断します。
この方式では、途中や宛先のファイアウォールが UDP の高いポートを遮断していると、宛先付近から先が * * * になります。
結果が食い違う典型例
- **tracert は最後まで届くが、traceroute は途中から
* * ***: UDP が遮断され、ICMP は許可されている環境です。 - **traceroute は届くが、tracert は最後だけ
***: 宛先が ICMP Echo に応答しない設定です。 - どちらも最後まで届かないのに、Web サイトは表示できる: ICMP も UDP も絞られていて、Web 用の TCP だけが許可されている環境です。
いずれも「経路が壊れている」わけではなく、調べ方とファイアウォールの方針が合っていないだけです。
違い2：選べる調べ方
Linux の traceroute はプロトコルを切り替えられる
Linux で広く使われている traceroute（多くのディストリビューションで traceroute パッケージとして提供）は、オプションで送るパケットを変えられます。
traceroute example.com # 既定：UDP
sudo traceroute -I example.com # ICMP Echo（tracert と同じ方式）
sudo traceroute -T -p 443 example.com # TCP SYN をポート 443 へ-I と -T は root 権限が必要です。-T -p 443 は、実際の HTTPS 通信と同じポートで調べるため、Web サーバーへの経路を見るときに最も実態に近い結果になります。なお、ディストリビューションによっては traceroute が最初から入っておらず、sudo apt install traceroute などで追加する必要があります。
root 権限がない環境では、iputils に含まれる tracepath も使えます。UDP で調べつつ、経路上の MTU（pmtu）も表示してくれます。
macOS の traceroute
macOS の traceroute も既定は UDP で、-I で ICMP に切り替えられます。-P でプロトコルを指定するオプションもありますが、指定できる値は版によって異なるため man traceroute で確認してください。
Windows の tracert は ICMP のみ
tracert には送るパケットの種類を変えるオプションがありません。使える主なオプションは次のとおりです。
tracert -d example.com # 逆引きをしない（速く終わる）
tracert -h 40 example.com # 最大ホップ数を 40 に
tracert -w 1000 example.com # 1回の応答待ちを 1000 ミリ秒に
tracert -4 example.com # IPv4 を指定（-6 で IPv6）-d を付けないと、各ホップの名前を逆引きするため、終わるまでにかなり時間がかかることがあります。まず -d 付きで経路を見て、必要ならホスト名付きで取り直すと効率的です。
Windows で TCP の到達性を確かめたい場合は、PowerShell の Test-NetConnection が使えます。Test-NetConnection example.com -Port 443 で指定ポートへの接続可否を確認でき、-TraceRoute を付けると経路も表示します（経路の調べ方自体は ICMP です）。
違い3：結果の見た目
Linux / macOS の traceroute は、標準ではホップごとに「ホスト名（IP アドレス）」と3回分の往復時間を1行に出します。tracert は先に3回分の往復時間を並べ、その後にホスト名と IP アドレスを出します。表示の順序が違うだけで、読み方は同じです。
どちらも、途中のホップで * や大きな遅延が出ても、その先のホップが正常ならたいていは問題ありません。中継ルーターは自分宛ての問い合わせへの応答を後回しにしたり、回数を制限したりするためです。判断の基準は「最終ホップまで届いているか」「遅延の増加がその先のホップでも続いているか」です。
状況別の選び方
Web サイトにつながらない・遅い
Linux / macOS から sudo traceroute -T -p 443 で調べるのが最も実態に近い方法です。Windows しかない場合は、tracert で経路の概要を見たうえで、Test-NetConnection -Port 443 で TCP の到達性を別に確認します。
社内ネットワークや VPN の経路を確かめたい
ICMP が許可されていることが多い社内環境なら、tracert や traceroute -I で十分です。まず -d（Windows）や -n（Linux / macOS）を付けて逆引きを省き、どのゲートウェイを通っているかを確認します。
断続的なロスや遅延を調べたい
tracert も traceroute も、各ホップに3回ずつ送るだけなので、ときどき起きる問題は捉えにくいです。継続的に測るなら mtr（Windows では pathping）を使います。pathping は各ホップに繰り返し問い合わせてから統計を出すため、完了まで数分かかります。
結果がどうしても食い違う
ICMP・UDP・TCP の3種類で調べ比べると、どの通信が遮断されているかが見えてきます。また、経路上に負荷分散の装置があると、送るパケットによって通る道が変わることもあります。一度の結果だけで断定せず、時間を置いて複数回取ると判断の精度が上がります。
使うときの注意点
- 往きの経路しか分からない: どちらのコマンドも自分から相手への経路を調べるもので、戻りの経路は別のことがあります。可能なら相手側からも調べてもらいます。
- ホスト名から事業者を推測しすぎない: 逆引き名は管理者が付けたもので、古い情報のまま残っていることもあります。目安として扱います。逆引き名の付け方に統一された決まりはありません（2026年10月現在）。
- 共有するときは自分側の情報に注意: 最初の数ホップには社内や自宅のルーターのアドレスが含まれます。
まとめ
- tracert（Windows）は ICMP Echo、traceroute（Linux / macOS）は既定で UDP を使うのが最大の違いです。仕組みや既定の最大 30 ホップ・3回ずつ送る点は共通です。
- 片方だけ途中で止まるのは、多くの場合ファイアウォールが特定のプロトコルを遮断しているためです。
- Linux の traceroute は
-I（ICMP）や-T -p 443（TCP）に切り替えられ、Web サーバーへの経路は TCP で調べるのが実態に近くなります。 - Windows では tracert に
-dを付けて速く終わらせ、TCP の確認はTest-NetConnection -Portで補います。 - 断続的な問題は mtr や pathping で継続的に測ります。