mtrは traceroute と ping を組み合わせたツールで、宛先までの各中継ルーター（ホップ）ごとのパケットロス率と遅延を継続的に測れます。「サイトが遅い」「ときどきつながらない」という相談で、問題が自分のサーバーなのか途中の経路なのかを切り分けるのに向いています。この記事では、インストールからレポートの取り方、結果の正しい読み方、ICMPが絞られている環境でのTCPモードの使い方までを説明します。
mtrが向いている場面
pingは宛先との往復だけ、tracerouteは経路を1回なぞるだけですが、mtrは同じ経路に何十回もパケットを送り、ホップごとの統計を取ります。そのため、次のような「たまに起きる」問題の調査で役に立ちます。
- 特定の地域や回線からだけWordPressサイトの表示が遅い
- 外部API（決済・メール配信・CDNなど）への接続がときどきタイムアウトする
- サーバー移転後、以前より応答が遅くなった気がする
一方、mtrが示すのはネットワークの経路と遅延だけです。PHPの処理が遅い、データベースが詰まっている、といったサーバー内部の問題は見えません。mtrで経路に問題が無ければ、アプリケーション側の調査に進む、という判断材料として使います。
インストール
主要なLinuxディストリビューションではパッケージで入ります。
# Debian / Ubuntu（GUIなし版。サーバーならこちらで十分）
sudo apt install mtr-tiny
# RHEL / Rocky Linux / AlmaLinux
sudo dnf install mtr
# macOS（Homebrew）
brew install mtrmacOSのHomebrew版は、実行時に sudo が必要になることがあります。WindowsにはmtrのWindows向け移植版（WinMTRなど）があるほか、標準コマンドの pathping でもホップごとのロス率を調べられます。
基本の使い方とレポートの取り方
mtr example.com と打つと画面が更新され続ける対話モードになります（q で終了）。調査結果を共有したり記録したりするなら、一定回数送って結果をまとめて出すレポートモードが便利です。
# 100回送信してレポート表示。ホスト名を省略せず、IPアドレスとAS番号も表示
mtr -r -w -b -z -c 100 example.com
# IPv4 / IPv6 を明示して比べる
mtr -4 -rwc 100 example.com
mtr -6 -rwc 100 example.com主なオプションは次のとおりです。
-r（--report）：レポートモード-c 回数：送信回数。10回程度では偶然のロスに振り回されるため、100回前後を目安にします-w：ホスト名を省略せずに表示-n：名前の逆引きをしない。逆引きが遅い環境で結果が早く出ます-b：ホスト名とIPアドレスを両方表示-z：AS番号（どの事業者のネットワークか）を表示
結果の各列の意味
レポートは次のような形で出力されます（アドレスは説明用の値です）。
HOST: client Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.1.1 0.0% 100 0.9 1.0 0.6 3.2 0.3
2.|-- 198.51.100.1 0.0% 100 4.8 5.1 4.2 9.8 0.8
3.|-- 198.51.100.65 42.0% 100 6.1 6.3 5.5 12.4 1.1
4.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
5.|-- 203.0.113.9 0.0% 100 12.2 12.5 11.8 18.0 0.9
6.|-- 203.0.113.10 0.0% 100 12.6 12.8 12.0 16.3 0.7- Loss%：そのホップで応答が返らなかった割合
- Snt：送信した回数
- Last / Avg / Best / Wrst：直近・平均・最小・最大の往復時間（ミリ秒）
- StDev：ばらつき。大きいほど遅延が不安定です
結果の読み方（誤判定しやすいポイント）
mtrの結果で最も多い誤解は、「途中のホップにロスがある＝そこで障害が起きている」という読み方です。
途中だけのロスは、多くの場合問題ではない
上の例では3番目のホップに42%のロスがありますが、その先の5番・6番（最終の宛先）は0%です。ルーターは自分宛ての診断パケットへの応答を後回しにしたり、回数を制限したりする設定になっていることが多く、転送そのものは正常でも応答だけ返さないことがあります。後続のホップにロスが続いていなければ、通信には影響していないと判断してよいケースがほとんどです。4番目の ??? も同様で、応答を返さない設定のルーターです。
ロスが最後まで続くなら実際の問題
あるホップから先、最終ホップまでロス率が継続して出ている場合は、そのあたりで実際にパケットが落ちている可能性が高くなります。判断の基準は最終ホップのロス率です。
遅延の跳ね上がりも「続くかどうか」で判断する
あるホップで遅延が増え、その後のホップも同じ水準のまま続くなら、その区間が距離か混雑で遅いということです。日本と北米の間のように物理的な距離がある区間では、一気に100ミリ秒以上増えるのは自然な挙動です。逆に、途中の1ホップだけ遅延が大きく、次のホップで元に戻るなら、そのルーターの応答が遅いだけで通信には影響していません。
経路は往きと帰りで違うことがある
mtrが測るのは送信元から宛先への往路だけです。インターネットでは往路と復路が別経路になることが珍しくありません。サーバー側からも利用者側（または近くの拠点）に向けてmtrを実行し、両方向の結果をそろえて比べると、原因の区間を絞り込みやすくなります。
ICMPが絞られている環境ではTCPモードを使う
mtrは既定でICMPを使いますが、宛先のファイアウォールやクラウドのセキュリティ設定でICMPが拒否されていると、最終ホップのロス率が常に最大値になり、届いていないように見えてしまいます。Webサーバーまでの経路を調べるなら、実際の通信と同じTCP 443番で測るほうが実態に近い結果になります。
# TCPのSYNで443番ポートを使って測定
mtr -T -P 443 -rwc 100 example.com
# UDPで測定する場合
mtr -u -rwc 100 example.comTCPモードはファイアウォールの許可状況によって結果が変わるため、ICMPとTCPの両方で取って比較すると判断を誤りにくくなります。なお、送信間隔を1秒未満にする -i の指定は、通常は管理者権限が必要です。
調査を依頼するときに添える情報
レンタルサーバーやVPS事業者、回線事業者に調査を依頼する場合は、次の情報をそろえると話が早く進みます。
mtr -rwbz -c 100のレポート（ICMPとTCPの両方）- 実行した日時と、問題が起きている時間帯
- 送信元の回線・地域と、宛先のホスト名
- 可能であれば、サーバー側から送信元方向へのレポート
問題が時間帯で変わるなら、cronで定期的にレポートを保存しておくと比較材料になります。ただし、大量の連続測定は相手側の負荷や監視の対象になりうるため、回数と間隔は常識的な範囲にとどめてください。オプションの細部はバージョンによって異なることがあるので、手元の mtr --help や man mtr で確認してから使うと安全です（2026年10月現在）。
まとめ
- mtrはホップごとのロス率と遅延を統計で示すツールで、経路の問題か、サーバー内部の問題かを切り分けるのに使います。
- 共有・記録には
mtr -rwbz -c 100 宛先のレポートモードが便利です。 - 途中のホップだけのロスは、多くの場合ルーターが応答を絞っているだけです。最終ホップまでロスや遅延が続くかで判断します。
- ICMPが拒否されている宛先には
-T -P 443のTCPモードで測ります。 - 往路と復路は別経路のことがあるため、可能なら双方向で測定します。