mtrコマンドでネットワーク経路と品質を確認する方法|pingとtracerouteを統合した障害切り分けも


この記事の監修:宮崎智広(Linux教育歴15年以上・受講者3,100名超)
HOMELinux技術 リナックスマスター.JP(Linuxマスター.JP)Linuxtips, ネットワーク > mtrコマンドでネットワーク経路と品質を確認する方法|pingとtracerouteを統合した障害切り分けも
「サーバーへの接続が時々遅くなるけど、どの経路で詰まっているのか分からない」
「tracerouteで経路は見えるが、パケットロスや遅延までは一目で分からない」
「ping と traceroute を両方打ちながら、どの区間で劣化しているのかを手早く切り分けたい」

この記事では、mtr コマンドを使ってネットワーク経路とパケットロス・遅延を同時に確認する方法を解説します。RHEL 9.4 / Ubuntu 24.04 LTS で動作確認済みです。インストールから対話モード・レポートモード・実務での障害切り分けまで、現場でそのまま使える形で紹介します。

この記事のポイント

・mtr は ping と traceroute を統合したネットワーク診断ツール
・mtr -rwc 10 ホスト名 でレポート形式の出力が得られる
・Loss% と Avg を見て劣化している区間を特定する
・ICMP がフィルタされる経路では -T(TCP)や -u(UDP)に切り替える


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
図解60P/登録10秒/解除も3秒 / 詳細はこちら

なぜ mtr が障害切り分けに向いているのか

ネットワークのトラブルで現場のエンジニアが最初に打つコマンドは、ping と traceroute の2つです。ping は宛先までの到達性と遅延を計測しますが、途中のどのルーターで詰まっているかは分かりません。traceroute は経路を表示しますが、一度だけの計測なので瞬間的なパケットロスの傾向は掴めません。

mtr(My TraceRoute)は、この2つを同時に連続実行するツールです。経路上の各ホップに対してパケットを送り続け、Loss%(パケットロス率)と Avg(平均応答時間)をリアルタイムに更新します。結果、「どの区間で何%のパケットが落ちているか」「どのホップから急に遅延が増えているか」を一目で把握できます。

20年以上サーバーを運用してきた経験から言うと、拠点間のVPNが不安定なとき、クラウドのリージョン間接続で瞬断が起きるとき、mtr は最短で原因区間を絞り込める武器になります。

mtr のインストール

多くのディストリビューションでは標準リポジトリに含まれています。未インストールの場合は以下で導入します。

# RHEL系(Rocky Linux / AlmaLinux / RHEL 9) sudo dnf install -y mtr # Debian / Ubuntu sudo apt install -y mtr-tiny # GUI版も使う場合 sudo apt install -y mtr # バージョン確認 mtr --version

インストール後、バージョン確認で以下のように表示されれば準備完了です。

# 実行例(RHEL 9.4) $ mtr --version mtr 0.95

基本的な使い方

1. 対話モードで経路を確認する

引数に宛先ホストを指定するだけで、経路上の各ホップに対する ping を連続実行し、画面を更新し続けます。

# 対話モードで起動 sudo mtr www.linuxmaster.jp # 名前解決を止めてIPのみ表示(表示が早くなる) sudo mtr -n www.linuxmaster.jp

実行すると以下のような画面が表示されます(マスク済み)。

My traceroute [v0.95] srv-app01 (192.168.xxx.10) -> www.linuxmaster.jp 2026-04-17T10:21:05+0900 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. _gateway 0.0% 30 0.4 0.4 0.3 0.6 0.1 2. xxx.xxx.xxx.1 0.0% 30 2.1 2.3 1.9 3.5 0.3 3. xxx.xxx.xxx.254 0.0% 30 3.2 3.1 2.8 4.1 0.2 4. xxx-xxx.bb.example.ne.jp 0.0% 30 5.1 5.4 4.8 12.3 1.4 5. xxx-xxx.transit.example.net 13.3% 30 18.2 17.9 15.1 33.2 3.8 6. xxx-xxx.edge.example.net 0.0% 30 16.4 16.8 15.5 21.0 1.2 7. www.linuxmaster.jp 0.0% 30 17.1 17.2 16.4 22.1 1.1

上の例ではホップ5で Loss 13.3% が出ています。ここから先のホップはロスなしに戻っているので、このルーター自身が ICMP の応答を意図的に絞っている可能性が高いと読みます。終端(宛先)までロスが連続している場合こそ本物の障害です。
対話モードは q キーで終了します。
関連するネットワーク確認の基礎としては、Linux ポート確認の全コマンドも合わせて押さえておくと、L3(経路)と L4(ポート)の切り分けがスムーズになります。

2. レポートモードで結果をテキスト化する

障害チケットやログに貼り付ける場合は、レポートモード(-r)を使います。-c で計測回数、-w で列幅を広く取ると整形しやすくなります。

# 10回計測してレポート出力 sudo mtr -rwc 10 www.linuxmaster.jp # 名前解決なし + レポート sudo mtr -rwnc 10 www.linuxmaster.jp

出力は対話モードと同じ形式で1回だけ表示され、そのまま標準出力に流れます。リダイレクトで保存すれば、時間帯ごとの比較ができます。

# 日時付きでログ保存 sudo mtr -rwc 30 www.linuxmaster.jp > /var/log/mtr-$(date +%Y%m%d-%H%M).log

3. プロトコルを切り替える

経路の途中で ICMP がフィルタされていると、中間ホップで応答が返らずアスタリスク(*)ばかりになることがあります。その場合は TCP や UDP に切り替えてください。

# TCP SYN(ポート443)で計測 sudo mtr -T -P 443 www.linuxmaster.jp # UDP(tracerouteのデフォルトと同じ) sudo mtr -u www.linuxmaster.jp # ICMP ECHOに固定 sudo mtr -I www.linuxmaster.jp

HTTPS で通信できるのに ICMP が通らないケースは珍しくありません。Webサービスの疎通を実態に近い形で測りたければ -T -P 443 が実務で最もよく使う組み合わせです。

応用・実務Tips

JSONで出力して自動集計する

0.93 以降のバージョンでは --json オプションが使えます。監視スクリプトで Loss% の閾値を超えたらアラートを出す、といった使い方が可能です。

# JSON出力 sudo mtr --json -c 10 www.linuxmaster.jp # jqで終端ホップのLoss%だけ抜く sudo mtr --json -c 10 www.linuxmaster.jp | jq '.report.hubs[-1]."Loss%"'

IPv4 / IPv6 を明示する

デュアルスタック環境で、どちらの経路を計測しているのか曖昧になることがあります。-4 / -6 で明示しましょう。

# IPv4で強制 sudo mtr -4 -rwc 10 www.linuxmaster.jp # IPv6で強制 sudo mtr -6 -rwc 10 www.linuxmaster.jp

名前解決そのものが怪しいと感じたら、dig コマンドで DNS を調べる手順で A / AAAA レコードを先に確認してから mtr を打つと、原因の切り分け順序がぶれません。

結果の読み方のコツ

Loss% が特定ホップで高く、以降で0に戻る:そのルーターが ICMP の応答を間引いているだけで、実害はないケースが多い
Loss% が特定ホップから終端まで連続して続く:そのホップの先で本物の経路障害・輻輳が発生している
Avg が特定ホップで急増する:物理距離やキューイング遅延が原因。ベストとワーストの差(StDev)が大きければジッタも疑う
Snt(送信数)が極端に少ないホップがある:TTL Exceededの応答が間引かれている可能性。計測回数を増やして再確認

「Failure to start mtr-packet」が出た時の対処法

非 root ユーザーで実行したときに以下のエラーが出ることがあります。

# エラー例 $ mtr www.linuxmaster.jp Failure to start mtr-packet: Permission denied

mtr は生のソケットを使うため特権が必要です。sudo を付けて実行するのが基本対処です。監視ユーザーで自動実行したい場合は、mtr-packet バイナリに cap_net_raw を付与します。

# ケーパビリティを付与(sudo不要で実行可能にする) sudo setcap cap_net_raw+ep /usr/sbin/mtr-packet # 付与状況の確認 getcap /usr/sbin/mtr-packet

パスはディストリビューションによって /usr/bin/mtr-packet の場合もあります。which mtr-packet で確認してから実行してください。
また、社内プロキシやクラウド側のセキュリティグループで ICMP・UDP が全面的に遮断されているケースでは、-T -P 443 のように TCP で計測しないと何も応答が返ってきません。経路が真っ黒になったらプロトコル切替を先に試すのが鉄則です。

本記事のまとめ

mtr は ping と traceroute を統合した、ネットワーク障害切り分けの定番ツールです。経路全体のパケットロスと遅延を同時に可視化できるので、どの区間が原因かを最短距離で特定できます。よく使うオプションを以下にまとめておきます。
やりたいこと コマンド
対話モードで経路確認 sudo mtr www.linuxmaster.jp
名前解決なしで高速表示 sudo mtr -n www.linuxmaster.jp
レポート形式で10回計測 sudo mtr -rwc 10 www.linuxmaster.jp
TCP 443ポートで計測 sudo mtr -T -P 443 www.linuxmaster.jp
JSON形式で出力 sudo mtr --json -c 10 www.linuxmaster.jp
IPv4に固定して計測 sudo mtr -4 -rwc 10 www.linuxmaster.jp
sudoなしで実行できるようにする sudo setcap cap_net_raw+ep /usr/sbin/mtr-packet
名前解決の段階から疑う場合はLinux DNS 設定の基本も合わせて確認してください。ネットワーク障害は「DNS → 経路 → ポート」の順で切り分けるのがもっとも効率的です。

「どの区間でパケットが落ちているか」を即答できますか?

拠点間が遅い、クラウドへの接続が瞬断する、こうしたネットワーク障害で原因区間を特定できず右往左往するエンジニアは少なくありません。mtrや経路診断の使い方をネットの切れ端で拾うだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル(図解60P)』を完全無料でプレゼントしています。

「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。


無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

登録10秒/合わなければ解除3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録

宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として15年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。