宛先までの通信経路とMTUを確認できるネットワーク診断ツール
- tracepath -
ネットワーク経路を調査するコマンドとして「traceroute」が有名ですが、Linuxでは「tracepath」も利用できます。tracepathは宛先までの経路を確認できるだけでなく、経路上のPath MTUを調査できる点も特徴です。
本記事では、tracepathの特徴やtracerouteとの違いを整理したうえで、インストール手順、コマンドの使い方、実行結果の見方、オプションについて解説します。
実際に実行したコマンドと実行結果を掲載しているので、ネットワーク調査に必要なtracepathの基礎を実践的に学べます。
tracepathとは
tracepathは、自分の端末から指定した宛先までの通信経路を確認するコマンドです。宛先までに経由するルーターをホップ単位で表示するため、「どのような経路を通って通信しているのか」「どの区間から応答を確認できなくなったのか」といった調査に利用できます。
加えてtracepathでは、通信経路の探索とともにMTUの変化を検出し、宛先までの通信経路におけるPath MTU(PMTU)を確認することができます。PMTUとは、送信元から宛先までの経路において、分割せずに送信できるデータの最大サイズです。
- 宛先までの経路をホップ単位で表示される
- 各ホップのRTT(往復遅延時間)を確認できる
- 経路上のPath MTU(PMTU)を確認できる
- 一般ユーザー権限で実行可能
- シンプルな操作性
- IPv4とIPv6に対応
Linuxの基本的なネットワークユーティリティを提供するiputilsパッケージに含まれており、多くのディストリビューションで標準的に利用できます。
主な用途
tracepathは、主に通信経路を把握したい場合や、ネットワーク上の問題を切り分けたい場合に使用します。
- 宛先までに経由するルーターを確認する
- 通信がどの区間まで到達しているか確認する
- Path MTU(PMTU)を確認する
- ルーティング設定や回線切替の前後で経路が意図どおりか確認する
- IPv4とIPv6で経路が異なるか確認する
- ネットワーク障害の切り分け
- 各ホップの遅延(RTT)の確認
- tracerouteが使えない(権限不足・インストール不可)場合の代替
Webサーバーなどへアクセスできない場合に、いきなりアプリケーション側の問題と判断するのではなく、tracepathを使って通信経路を確認すると原因を整理しやすくなります。
tracepathでは、経路上の各機器からの応答を確認し、応答が得られなかったホップについてはno replyと表示します。ただし、機器の設定により、ICMP Time Exceededの応答が抑止されている場合もあるため、no replyが表示されたからといって、その機器で通信が停止しているとは限りません。
注意事項
本記事に掲載しているコマンドを学習目的で使用する場合、自身が管理する環境でご使用ください。第三者のシステムやネットワークに対して使用すると、実行頻度や規模によっては、サイバー攻撃とみなされる可能性があります。
tracerouteとtracepathの違い
「traceroute」と「tracepath」は、どちらも送信元から宛先までの通信経路を確認するためのコマンドです。通信経路上に存在するルーターなどをホップ単位で確認できるため、ネットワーク障害の切り分けや、想定した経路で通信しているかを確認するときに利用できます。
両者の主な違いは、機能の豊富さとPath MTU(PMTU)の確認可否です。
| tracepath | traceroute | |
|---|---|---|
| 提供パッケージ | iputils(RHEL系) iputils-tracepath(Debian系) | traceroute |
| 主な用途 | 通信経路とPath MTUの確認 | 詳細な経路調査 |
| プローブ方式 | UDPのみ | UDP(デフォルト) ※オプションで「ICMP Echo」「TCP SYN」を選択可能 |
| Path MTU の測定 | 可能 | 基本的に不可 ※一部の実装ではオプションで指定可能 |
| 1ホップあたりのプローブ数 | 1回 | 3回 ※オプションで変更可能 |
| 実行権限 | 一般ユーザー権限 | 一般ユーザー権限 ※ただし、TCPモード(-Tオプション指定時)はroot権限が必要 |
| オプションの種類 | 少ない | 多い |
tracepathには、通信経路上で利用できる最大のパケットサイズであるPath MTU(PMTU)を確認できる特徴があります。経路を調査しながらMTUの変化も確認できるため、ネットワークの経路確認だけでなく、MTUに起因する通信トラブルを調査するときにも役立ちます。
一方、tracerouteは指定できるオプションが多く、プローブに使用するプロトコルやネットワークインターフェース、送信間隔などを調整しながら経路を調査できます。より細かな条件で通信経路を確認したい場合は、tracerouteが適しています。
tracepathのインストール
Linuxディストリビューションやバージョン、OSイメージなどによって、初期状態のパッケージ構成が異なります。次のコマンドを実行すると、tracepathが導入済みか確認できます。
$ tracepath -Vバージョンが表示されない場合、インストールが必要です。
tracepathは、iputilsプロジェクトに含まれるツールです。ディストリビューションによって提供パッケージが異なるため、環境ごとにインストール手順を押さえておきます。
本セクションでは、Debian系とRHEL系の代表的なLinuxディストリビューションを取り上げ、それぞれ解説します。
- Debian系:Kali Linux 2026.2、Ubuntu 26.04 LTS
- RHEL系:AlmaLinux 10.2
なお、tracepathはLinux向けコマンドのため、Windowsでは使用できません。Windows環境で宛先までの通信経路を確認するには、Windowsに標準搭載されているtracertを使用します。
Kali Linuxの場合
本記事の検証環境のKali Linuxには、tracepathがインストールされていないため、以下の手順でインストールします。
パッケージリストの更新
$ sudo apt updateパッケージ情報の確認
$ apt show iputils-tracepath
Package: iputils-tracepath
Version: 3:20250605-1
Priority: optional
Section: net
Source: iputils
Maintainer: Noah Meyerhans <noahm@debian.org>
Installed-Size: 51.2 kB
Depends: libc6 (>= 2.38)
Suggests: traceroute
Homepage: https://github.com/iputils/iputils/
Tag: admin::monitoring, implemented-in::c, interface::commandline,
network::scanner, protocol::ipv6, role::program, scope::utility
Download-Size: 21.4 kB
APT-Sources: http://http.kali.org/kali kali-rolling/main amd64 Packages
Description: Tools to trace the network path to a remote host
The tracepath utility is similar to the traceroute utility, but also
attempts to discover the MTU of the path. Supports IPv4 and IPv6.Debian系ディストリビューションでは、tracepathはiputils-tracepathという独立したパッケージで提供されています。
tracepathのインストール
$ sudo apt install iputils-tracepathインストール後の確認
# 実行ファイルのパス
$ command -v tracepath
/usr/bin/tracepath
# バージョン情報
$ tracepath -V
tracepath from iputils 20250605
libcap: yes, IDN: yes, NLS: no, error.h: yes, getrandom(): yes, __fpending(): yes正常にバージョン情報が表示されれば、インストール完了です。
Ubuntuの場合
Ubuntuでは、Kali Linuxと同様にiputils-tracepathパッケージでtracepathが提供されています。インストール手順は、前述のKali Linuxと同様です。
本記事の検証用に構築したUbuntuでは、初期状態でtracepathが導入済みでした。ただし、使用するOSイメージやインストール時の構成によっては、インストールされないことがあります。
# 実行ファイルのパス
$ command -v tracepath
/usr/bin/tracepath
# バージョン情報
$ tracepath -V
tracepath from iputils 20250605
libcap: yes, IDN: yes, NLS: no, error.h: yes, getrandom(): yes, __fpending(): yes
# 提供元パッケージ
$ dpkg -S "$(command -v tracepath)"
iputils-tracepath: /usr/bin/tracepathAlmaLinuxの場合
AlmaLinuxをはじめとするRHEL系ディストリビューションでは、tracepathは iputilsパッケージに同梱されています。Debian系のように個別パッケージへ分離されていないため、iputilsが入っていればそのまま使えます。
# パッケージの導入状況
$ dnf list installed iputils
インストール済みパッケージ
iputils.x86_64 20240905-5.el10 @anaconda
# 実行ファイルのパス
$ command -v tracepath
/usr/bin/tracepath
# バージョン情報
$ tracepath -V
tracepath from iputils 20240905
libcap: yes, IDN: yes, NLS: yes, error.h: yes, getrandom(): yes, __fpending(): yes
# 提供元パッケージ
$ rpm -qf "$(command -v tracepath)"
iputils-20240905-5.el10.x86_64iputilsパッケージが初期導入されていない場合、次のコマンドでインストールします。
$ sudo dnf install iputilstracepathコマンドの使い方
コマンド構文
$ tracepath [オプション] <宛先ホスト>宛先ホストには、ホスト名、またはIPアドレスで指定します。
最もシンプルなコマンド
$ tracepath example.com # ホスト名
$ tracepath 192.0.2.1 # IPアドレスtracepathコマンドを実行すると、宛先に向けてUDPパケットを送信し、途中のネットワーク機器から返される情報をもとに経路を表示します。また、経路上で利用可能なPath MTU(PMTU)も検出できます。
実行結果の見方
tracepathコマンドを実行すると、宛先までに通過したネットワーク機器やRTT(往復遅延時間)、Path MTU(PMTU)などが表示されます。
例)本記事の検証環境でtracepathコマンドを実行した結果
$ tracepath 192.168.30.107
1?: [LOCALHOST] pmtu 1500
1: 192.168.10.254 0.507ms
1: 192.168.10.254 0.424ms
2: 192.168.20.253 0.959ms
3: 192.168.30.107 1.209ms reached
Resume: pmtu 1500 hops 3 back 3- 1列目:ホップ数
- 行頭に表示される数字は、送信したパケットのTTL(ホップ数)です。
- 1ホップ目、2ホップ目というように、送信元から何段階目のネットワーク機器であるかを確認できます。
- 2列目:ホスト名またはIPアドレス
- ホップ数の次には、応答したネットワーク機器のホスト名やIPアドレスが表示されます。
- 通常は、経路上に存在するルーターなどのアドレスです。
- 名前解決が行われる環境では、IPアドレスではなくホスト名が表示されます。
- 3列目以降:そのホップに至る経路に関する各種情報
- RTT(往復遅延時間):応答に要した時間。
- pmtu(Path MTU):MTUが変化した場合、その値が出力されます。
- reached:宛先ホストに到達したことを示す。この行が出力されれば、経路の追跡は成功です。
最後に実行結果のサマリが出力されます。
pmtu:検出されたPath MTUhops:宛先までのホップ数back:宛先から送信元までの復路の推定ホップ数
オプション一覧
| オプション | 概要 |
|---|---|
| -4 | IPv4を使用する |
| -6 | IPv6を使用する |
| -n | ホスト名の名前解決(DNS逆引き)を行わず、IPアドレスを表示する |
| -b | ホスト名とIPアドレスの両方を表示する |
| -l <length> | 送信するパケットのサイズ(バイト) |
| -m <hops> | 最大ホップ数(最大TTL)を指定する(デフォルト:30) |
| -p <port> | 宛先UDPポートの開始番号(デフォルト:44444) |
| -V | バージョン情報を表示する |
tracepathには、表示形式やパケットサイズ、最大ホップ数などを調整するためのオプションが用意されています。以下では、本記事の検証環境において、Kali Linuxでtracepathコマンドを実行した結果を掲載しています。(Ubuntu、AlmaLinuxでも同様の結果が得られることを確認済み)
名前解決せず、IPアドレスで表示する
tracepathは通常、経路上の各ホップのIPアドレスに対してDNSの逆引きを行い、取得したホスト名を表示します。(名前解決できない場合は、IPアドレスを表示します。)
-nオプションを指定しない場合
$ tracepath 192.168.30.107
1?: [LOCALHOST] pmtu 1500
1: vyos.labo.test 0.510ms
1: vyos.labo.test 0.358ms
2: linux-router.labo.test 0.791ms
3: debian.labo.test 1.317ms reached
Resume: pmtu 1500 hops 3 back 3-nオプションを指定すると、経路上の各ホップに対する名前解決を行わず、IPアドレスを表示します。
-nオプションを指定する場合
$ tracepath -n 192.168.30.107
1?: [LOCALHOST] pmtu 1500
1: 192.168.10.254 0.390ms
1: 192.168.10.254 0.346ms
2: 192.168.20.253 0.705ms
3: 192.168.30.107 1.021ms reached
Resume: pmtu 1500 hops 3 back 3ホスト名とIPアドレスを表示する
-bオプションを指定すると、経路上の各ホップについてホスト名とIPアドレスの両方を表示します。
$ tracepath -b 192.168.30.107
1?: [LOCALHOST] pmtu 1500
1: vyos.labo.test (192.168.10.254) 0.367ms
1: vyos.labo.test (192.168.10.254) 0.311ms
2: linux-router.labo.test (192.168.20.253) 0.810ms
3: debian.labo.test (192.168.30.107) 0.964ms reached
Resume: pmtu 1500 hops 3 back 3送信するパケットのサイズを指定する
送信するプローブパケットの初期サイズは、-lオプションで指定します。(バイト単位)
- IPv4 : 65,535バイト
- IPv6 : 128,000バイト
$ tracepath -n -l 1400 192.168.30.107
1: 192.168.10.254 0.537ms
2: 192.168.20.253 4.961ms
3: 192.168.30.107 1.349ms reached
Resume: pmtu 1400 hops 3 back 3-lで指定したパケット長が経路上の最小MTUを下回る場合、MTU超過が発生しないため、Path MTU(PMTU)を正確に測定できません。この場合、出力される値は実際のPMTUではなく、-lで指定した値そのものになります。例えば、経路上の最小MTUが1454バイトであっても、-l 1400を指定すると測定結果はpmtu 1400となります。
最大ホップ数(最大TTL)を指定する
調査する最大ホップ数(TTLの上限)は、-mオプションで指定します。(デフォルト:30)
$ tracepath -n -m 2 192.168.30.107
1?: [LOCALHOST] pmtu 1500
1: 192.168.10.254 0.583ms
1: 192.168.10.254 0.458ms
2: 192.168.20.253 0.879ms
Too many hops: pmtu 1500
Resume: pmtu 1500tracepathはTTLを利用しながら、宛先までに経由するネットワーク機器を順番に確認します。-mを指定することで、その調査範囲に上限を設定できます。
近距離のネットワークだけを確認したい場合には、最大ホップ数を小さくすることで結果を簡潔にできます。(例.社内ネットワークから外部ネットワークへ出るまでの経路だけを確認したいケースなど)
指定したホップ数までに宛先へ到達できなかった場合、Too many hops と表示して終了します。
宛先UDPポートの開始番号を指定する
-pオプションでは、tracepathが使用する宛先UDPポートの開始番号を指定できます。(デフォルト:44444)
$ tracepath -n -p 10000 192.168.30.107
1?: [LOCALHOST] pmtu 1500
1: 192.168.10.254 0.553ms
1: 192.168.10.254 0.376ms
2: 192.168.20.253 0.951ms
3: 192.168.30.107 1.250ms reached
Resume: pmtu 1500 hops 3 back 3-p 10000を指定すると、UDPポート10000を起点にプローブを送信します。以降、プローブを送信するたびに、10001、10002、10003・・・のように宛先ポート番号を1ずつ増加させて送信します。
実際に送信されたポート番号を確認する場合、tcpdumpなどのパケットキャプチャツールを使用します。

経路上で問題が発生した場合の実行結果
tracepathは、正常時の通信確認だけでなく、障害発生時のトラブルシューティングで特に有効なコマンドです。出力内容を確認することで、通信経路上のどの箇所で問題が発生しているかを切り分ける際に活用できます。
ここでは、実務および学習環境で遭遇しやすい3つのパターンを取り上げ、それぞれの実行結果を解説します。
経路途中のルーターのMTUが小さい場合
中継ルーター(192.168.20.253)のMTU値を1300に変更する。
$ sudo ip link set dev enp0s8 mtu 1300通信経路上にMTU値の小さいネットワーク機器が存在する場合、tracepathではPath MTUの変化が検出され、実行結果にpmtuとして表示されます。
例)送信元側ではMTU 1500を使用できるものの、経路途中からMTU 1300までしか使用できない場合
$ tracepath -n 192.168.30.107
1?: [LOCALHOST] pmtu 1500
1: 192.168.10.254 0.546ms
1: 192.168.10.254 0.357ms
2: 192.168.20.253 0.892ms
3: 192.168.20.253 0.747ms pmtu 1300
3: 192.168.30.107 0.782ms reached
Resume: pmtu 1300 hops 3 back 3192.168.20.253の行末にpmtu 1300が表示されています。これは、当該ルーターからICMP Fragmentation Neededが返却され、tracepathがそれに従って送信サイズを引き下げたことを示します。
最後のResumeにも、検出したPath MTU(pmtu 1300)が表示されます。
経路途中のルーターが応答を返さない場合
中継ルーター(192.168.20.253)に搭載されているファイアウォール管理コマンドにて、ICMPパケットの送信を破棄する。
次は、中継ルーターがICMP Time Exceededを返さないケースです。経路途中のルーターから必要な応答を受信できなかった場合、no replyと表示されます。
例)中継ルーター(192.168.20.253)でICMPパケットの送信を破棄した場合
$ tracepath -n 192.168.30.107
1?: [LOCALHOST] pmtu 1500
1: 192.168.10.254 0.434ms
1: 192.168.10.254 0.401ms
2: no reply
3: 192.168.30.107 1.583ms reached
Resume: pmtu 1500 hops 3 back 3この例では、2ホップ目がno replyとなっています。しかし、その後の3ホップ目(宛先ホスト)からは応答を取得できています。したがって、この結果だけを見て「2ホップ目のルーターで通信が停止している」と判断するのは適切ではありません。
- 経路上のネットワーク機器が必要な応答を返さない
- ICMPメッセージに対して制限が掛かっている
- 応答パケットが途中で失われている
- 一時的な混雑や遅延によって応答がタイムアウトした
重要なのは、no replyより後のホップが表示されているかです。後続のホップが正常に表示され、最終的にreachedとなっている場合、対象ホップがtracepathに応答していないだけで、実際のパケット転送は継続している可能性があります。
宛先ホストに到達できない場合
中継ルーター(192.168.20.253)に搭載されているファイアウォール管理コマンドにて、ICMPパケットの送信、および転送を破棄する。
最後は、宛先まで到達できないケースです。
$ tracepath -n 192.168.30.107
1?: [LOCALHOST] pmtu 1500
1: 192.168.10.254 0.522ms
1: 192.168.10.254 0.471ms
2: no reply
3: no reply
4: no reply
5: no reply
6: no reply
7: no reply
8: no reply
9: no reply
10: no reply
11: no reply
12: no reply
13: no reply
14: no reply
15: no reply
16: no reply
17: no reply
18: no reply
19: no reply
20: no reply
21: no reply
22: no reply
23: no reply
24: no reply
25: no reply
26: no reply
27: no reply
28: no reply
29: no reply
30: no reply
Too many hops: pmtu 1500
Resume: pmtu 1500前項との決定的な違いは、reachedが表示されないままToo many hopsで終了していることです。最大TTL(既定では30)まで探索したものの、宛先からの応答が得られなかったことを示します。
この時点で確定できるのは、「192.168.10.254までは正常に転送されている」という事実のみ。それ以降で何が起きているかは、この出力だけでは断定できません。
他のツールと併用することで、「プロトコル単位で遮断されているのか、経路自体が不通なのか」を切り分けられます。例えば、papingコマンドを使用すると、TCPベースで疎通を確認できます。
# 2ホップ目の中継ルーターに疎通確認
$ paping -p 22 -c 3 192.168.20.253
Paping-NG v1.0.3 - Copyright (c) 2026 Oliver (arch3r.eu)
Connecting to 192.168.20.253 on TCP port 22:
Connected to 192.168.20.253: time=0.87ms protocol=TCP port=22
Connected to 192.168.20.253: time=1.18ms protocol=TCP port=22
Connected to 192.168.20.253: time=1.24ms protocol=TCP port=22
Connection statistics:
Probed = 3, Connected = 3, Failed = 0 (0.00%)
Approximate connection times:
Minimum = 0.87ms, Maximum = 1.24ms, Average = 1.10ms
# 3ホップ目の宛先ホストに疎通確認
$ paping -p 22 -c 3 192.168.30.107
Paping-NG v1.0.3 - Copyright (c) 2026 Oliver (arch3r.eu)
Connecting to 192.168.30.107 on TCP port 22:
Connected to 192.168.30.107: time=1.41ms protocol=TCP port=22
Connected to 192.168.30.107: time=1.72ms protocol=TCP port=22
Connected to 192.168.30.107: time=1.66ms protocol=TCP port=22
Connection statistics:
Probed = 3, Connected = 3, Failed = 0 (0.00%)
Approximate connection times:
Minimum = 1.41ms, Maximum = 1.72ms, Average = 1.60msTCPベースの疎通確認に対して正常な応答が得られていることから、対象機器およびネットワーク経路は正常に稼働していると判断できます。このことから、特定のプロトコルに対してアクセス制御が設定されている可能性が高いと考えられます。

