2026年6月4日
2026年6月4日
iperf3 と tracert の使い分け|「遅い」は iperf3、「どこで詰まる」は tracert で切り分ける
iperf3 は「2台のあいだでどれだけの量を流せるか(スループット)」を測る道具で、tracert は「パケットがどのルーターを通って届くか、どの区間で応答が遅れるか(経路)」を調べる道具です。測っているものがまったく違うので、「転送が遅い」なら iperf3 で数字を取り、「届かない・ある地点から遅い」なら tracert で経路を見る、というのが基本の使い分けです。この記事では、症状ごとにどちらから使うか、両方を組み合わせて原因の区間を絞る手順、それぞれの結果を読み違えやすい点を説明します。
なお、iperf3 そのものの詳しい測り方や、tracert と Linux の traceroute の違いは別の記事で扱っています。ここでは「どちらを、どの順で使うか」に絞ります。
2つの道具が測っているもの
iperf3:両端を自分で用意して帯域を測る
iperf3 は、片方でサーバー(iperf3 -s)を起動し、もう片方からクライアント(iperf3 -c)で接続して、実際にデータを流して転送速度を測ります。既定では TCP の 5201 番ポートを使います。
# 測定先のサーバー側(Linux)
iperf3 -s
# 測定元のクライアント側:10秒間 TCP で送信
iperf3 -c 203.0.113.10
# 逆方向(サーバー → クライアント)を測る
iperf3 -c 203.0.113.10 -R
# UDP で 50Mbit/s を流し、ジッターと損失率を見る
iperf3 -c 203.0.113.10 -u -b 50M
ポイントは「両端に自分が操作できるマシンが要る」ことです。インターネット上の任意のサイトに対しては測れません。また、結果は「その2点間で、そのときに出た値」であり、途中のどの区間が細いのかまでは教えてくれません。
tracert:経路上の各ルーターの応答を見る
tracert(Windows)は、TTL(ホップ数の上限)を1から順に増やしたパケットを送り、TTL が尽きたルーターから返る ICMP の通知を集めて、経路と各ホップまでの往復時間を表示します。Windows の tracert は ICMP Echo を使い、Linux・macOS の traceroute は既定で UDP を使う(-I で ICMP、-T で TCP)という違いがあります。
# Windows:名前解決を省いて速く表示し、最大20ホップまで
tracert -d -h 20 203.0.113.10
# Linux:TCP の 443 番で経路を見る(ICMP や UDP が遮断される環境向け、要 root)
sudo traceroute -T -p 443 203.0.113.10
tracert は相手側に何も用意しなくても使えますが、測っているのは「各ルーターが ICMP に返事をする速さ」であって、データ転送の速さではありません。
症状別:どちらから使うか
| 症状 | 最初に使う道具 | 理由 |
|---|---|---|
| ファイル転送やバックアップが遅い | iperf3 | まず回線として何 Mbit/s 出るかを数字にする |
| 特定の拠点・クラウドにだけつながらない | tracert | どのホップで途切れるかを見る |
| ある時間帯だけ遅い・途切れる | iperf3 を繰り返し実行 + tracert(または mtr) | 時間帯による変化と、その区間を両方記録する |
| 応答は返るが体感が重い | tracert で遅延の出始めを確認 → iperf3 | 遅延(RTT)と帯域は別問題なので両面から見る |
「遅い」という訴えは、帯域が足りないのか、遅延が大きいのか、パケットが落ちているのかで対処が変わります。iperf3 は帯域と(UDP なら)損失を、tracert は遅延がどこで増えるかを見るものだと覚えておくと迷いません。
組み合わせて原因の区間を絞る手順
1. iperf3 で「期待値との差」を確かめる
まず両端で iperf3 を実行し、契約や構成から想定される値と比べます。TCP で低い値しか出ない場合、1本の TCP 接続が遅延の影響で伸びきっていないだけ、ということがあるため、並列ストリーム(-P 4 など)でも測ります。並列にして大きく伸びるなら、回線の容量ではなく、遅延とウィンドウサイズの組み合わせが上限を作っていると考えられます。
# 4本並列で30秒、1秒ごとの値を表示
iperf3 -c 203.0.113.10 -P 4 -t 30 -i 1
逆方向(-R)の値も取ります。上りと下りで大きく差がある場合は、片方向だけの帯域制限や、非対称な経路を疑う材料になります。
2. tracert で遅延と途切れの出始めを見る
iperf3 の値が低かったら、同じ2点間で tracert を実行します。見るのは「あるホップから後ろがすべて遅くなる」地点です。そこより手前は問題が小さく、その区間(たとえば自社の出口からプロバイダーの網に入るところ)に原因がある可能性が高い、と判断できます。
3. 区間を分けて iperf3 を測り直す
tracert で怪しい区間が見えたら、その区間の手前と奥に iperf3 を動かせるマシンがあれば、区間ごとに測り直します。たとえば「拠点の PC → 拠点内のサーバー」「拠点のサーバー → クラウドの VM」と分けると、LAN 側なのか WAN 側なのかがはっきりします。ここまで来ると、プロバイダーやクラウド事業者への問い合わせにも具体的な数字を添えられます。
4. 時間帯の変動は記録を残す
夕方だけ遅い、といった症状は一度の測定では再現しません。iperf3 は --json で結果を JSON 出力できるので、cron などで定期実行してファイルに残し、同じ時刻に tracert(または mtr)の結果も保存しておくと、混雑する時間帯と区間を後から照合できます。
読み違えやすい点
tracert の途中の「* * *」や大きな遅延は、問題とは限らない
多くのルーターは、自分宛ての ICMP への応答を低い優先度で処理したり、回数を絞ったりしています。そのため、途中のホップだけ遅延が大きい、または * になるのに、その先のホップは正常、という表示はよくあります。注目すべきは途中の1ホップではなく、「そのホップ以降がすべて悪化しているか」です。最終的な宛先まで普通に応答しているなら、途中の * は気にしなくてよいことが多いです。
tracert は片道の経路しか見ていない
表示されるのは「行き」の経路です。インターネットでは行きと帰りの経路が違うことが珍しくなく、帰りの経路の混雑は tracert では見えません。可能であれば、相手側からも逆向きに tracert(traceroute)を実行して比べます。
iperf3 の値には端末側の上限も含まれる
iperf3 の結果は回線だけでなく、端末の CPU、NIC、仮想マシンのネットワーク性能の上限、ファイアウォールやVPNの暗号化処理の影響も受けます。クラウドの VM ではインスタンスの種類ごとにネットワーク帯域の上限が決まっていることが多く、回線より先にそこで頭打ちになることがあります。測る端末の性能も条件として記録しておくと、比較がぶれません。
実行環境ごとの注意
- iperf3 は ESnet が開発しているツールで、Linux では多くのディストリビューションのパッケージから入ります。Windows 向けの実行ファイルは公式の配布ではなく第三者のビルドが中心です(2026年10月現在)。入手元の信頼性を確かめてから使ってください。
- iperf3 は iperf(バージョン2系)とは互換性がありません。両端で同じ iperf3 を使います。
- サーバー側では 5201 番ポート(UDP で測るなら UDP も)をファイアウォールで一時的に開ける必要があります。測定が終わったら
iperf3 -sを止め、ポートを閉じます。待ち受けたまま放置すると、第三者に帯域を使われるおそれがあります。
本番環境で測るときの配慮
iperf3 は回線を意図的に使い切るため、本番のサーバーや業務時間中の拠点回線で長時間実行すると、ほかの通信に影響します。短い時間(10秒程度)から始め、影響の少ない時間帯を選びます。UDP の -b で回線容量を大きく超える値を指定すると、ほかの利用者の通信を押し出してしまうので、想定帯域より少し低い値から試します。
クラウドでは、外向きの通信量に課金される場合があります。大量のデータを流す測定を繰り返す前に、利用中のサービスの課金体系を確認してください。また、第三者が公開している iperf3 サーバーを使う場合は、その運営者の利用条件に従い、過度な測定を避けます。
tracert は通信量が少なく、影響はほとんどありませんが、短い間隔で大量に繰り返すと、監視側で不審な通信と扱われることがあります。継続的に見たい場合は、間隔を空けた定期実行か、mtr のような専用の道具を使うほうが向いています。
まとめ
- iperf3 は2点間のスループット(と UDP での損失・ジッター)を、tracert は経路と各ホップまでの遅延を測ります。測る対象が違うので、症状に合わせて選びます。
- 「遅い」はまず iperf3 で期待値との差を数字にし、低ければ tracert で遅延が増え始める区間を探し、その区間を分けて iperf3 で測り直すと原因の場所を絞れます。
- tracert の途中ホップの
*や遅延は ICMP の扱いによることが多く、それ以降のホップがすべて悪化しているかで判断します。経路は片道しか見えない点にも注意します。 - iperf3 は端末やVMの性能上限も含んだ値です。本番では短時間・低負荷から始め、終わったら待ち受けを止めてポートを閉じます。