iperf3 は2台のホスト間で実際にデータを流し、その区間で出せるスループット（帯域）や再送、UDP のパケットロスを計測するツールです。経路そのものを表示するツールではありませんが、「自宅→VPS」「VPS→バックアップ先」のように区間を分けて測ることで、どの区間が遅いのかを数字で切り分けられます。この記事では、サーバーとクライアントの準備から、TCP・UDP の計測、結果の読み方、JSON 出力を使った記録と比較までを説明します。
経路上のどのルーターを通っているかは mtr や traceroute で確認し、各区間の太さは iperf3 で測る、という組み合わせで使うと効果的です。
iperf3 で分かること・分からないこと
iperf3 で分かるのは「この2点間で、この条件なら、どれだけの速度でデータを運べたか」です。具体的には次の値が得られます。
- TCP のスループットと再送回数（Retr）
- UDP のスループット、ジッター（揺らぎ）、パケットロス率
- 1秒ごとの推移（途中で速度が落ちる、波がある、などの傾向）
一方で、経路上のホップ一覧や、どのルーターで遅延が増えているかは分かりません。また、測定結果は回線だけでなく、両端の CPU、NIC、TCP の設定、仮想化基盤の制限、クラウドの帯域上限にも左右されます。「iperf3 が遅い＝回線が悪い」とは限らない点を前提にしておくと、誤った結論を避けられます。
インストールと準備
主要な Linux ディストリビューションではパッケージで導入できます。Windows や macOS 向けのビルドも配布されています（2026年10月現在）。比較的新しいバージョンでは並列ストリームがスレッドごとに処理されるようになり、高速な回線でも測定側の CPU が頭打ちになりにくくなっていますが、ディストリビューションのパッケージは古いバージョンのことがあります。
# Debian / Ubuntu
sudo apt install iperf3
# RHEL / AlmaLinux / Rocky Linux
sudo dnf install iperf3
# バージョン確認
iperf3 --versioniperf（バージョン2系）と iperf3 は互換性がないため、両端とも iperf3 を使います。また、両端のバージョンが大きく離れていると一部のオプションが使えないことがあるため、できるだけ近いバージョンにそろえます。
iperf3 は既定で TCP/UDP の 5201 番ポートを使います。測定するサーバー側のファイアウォールやクラウドのセキュリティグループで、このポートを測定元の IP からだけ一時的に許可してください。測定が終わったら許可を戻すのを忘れないようにします。
基本の測定手順
1. サーバー側で待ち受ける
# 待ち受け開始（Ctrl+C で終了）
iperf3 -s
# 1回測定したら自動で終了する
iperf3 -s -1常駐させたままにすると第三者に帯域を使われるおそれがあるため、-1 を付けて1回ごとに終了させるか、測定時だけ起動する運用が安全です。
2. クライアント側から測定する
# クライアント→サーバー方向（アップロード）を10秒間
iperf3 -c 203.0.113.10
# サーバー→クライアント方向（ダウンロード）
iperf3 -c 203.0.113.10 -R
# 30秒間、最初の3秒は集計から除外、並列4本
iperf3 -c 203.0.113.10 -t 30 -O 3 -P 4203.0.113.10 はサーバーの IP に置き換えてください。-R は向きを逆にするオプションで、Web サーバーからの配信速度を見たいときはこちらが実態に近くなります。新しめの iperf3 では --bidir で双方向を同時に測ることもできます。
-O は TCP の立ち上がり（スロースタート）の影響を除くためのものです。-P で並列ストリームを増やして速度が大きく伸びる場合は、1本の TCP 接続では遅延やウィンドウサイズが制約になっている可能性があります。
3. UDP で測る
# 目標 50Mbit/s の UDP を送信
iperf3 -c 203.0.113.10 -u -b 50MUDP は既定の送信レートが低く設定されているため、-b で目標レートを指定します。いきなり回線上限を超える値を指定するとロスが大量に出るだけなので、低い値から段階的に上げ、ロス率が増え始めるところを探します。共有回線や本番回線では、他の通信を圧迫しないよう短時間で済ませます。
結果の読み方
TCP の測定では、1秒ごとの行と最後の集計行が表示されます。注目する列は次のとおりです。
- Bitrate：その区間のスループット。最後の
senderとreceiverの行が集計値です。 - Retr：TCP の再送回数。多い場合は経路上のパケットロスや輻輳、バッファ不足が疑われます。
- Cwnd：送信側の輻輳ウィンドウ。小さいまま伸びない場合は、ロスや遅延が影響している可能性があります。
UDP の場合は、Jitter（到着間隔の揺らぎ）と Lost/Total（失われたパケット数と総数）を見ます。音声や映像のようなリアルタイム通信の品質を見たいときに役立ちます。
判断の目安として、次のように切り分けます。
-P 4で速度が大きく伸びる → 1接続あたりの制約（遅延、ウィンドウサイズ）が主因- 再送が多く速度が不安定 → 経路上のロスや混雑。時間帯を変えて再測定する
- 片方向だけ遅い → 上り下りの非対称、または途中の機器やシェーピングの影響
- どの区間でも同じ上限で頭打ち → クライアント側の回線、NIC、VM の帯域上限
区間を分けて「遅い経路」を見つける
経路を可視化するというのは、区間ごとの測定値を並べて、どこで細くなっているかを示すことです。たとえば WordPress サイトの表示や管理画面のアップロードが遅い場合、次のように区間を分けて測ります。
- 自宅や事務所の PC → Web サーバー（VPS）
- 別リージョンや別事業者の VPS → 同じ Web サーバー
- Web サーバー → DB サーバーやバックアップ先
1 だけ遅く 2 が速いなら、手元の回線やプロバイダー側の経路が疑われます。両方遅いなら、Web サーバー側の回線や上限設定を確認します。同時に mtr で経路と各ホップの損失を確認すると、遅い区間の中のどのあたりで問題が起きているかの手がかりになります。
公開されている iperf3 サーバーを使う方法もありますが、混雑していて結果が安定しないことが多いため、自分で管理しているホスト同士で測るのが確かです。
JSON 出力で記録・比較する
一度だけの測定では偶然の混雑に左右されます。時間帯を変えて複数回測り、結果を残しておくと比較しやすくなります。-J を付けると結果を JSON で出力できます。
# 結果を JSON で保存
iperf3 -c 203.0.113.10 -t 20 -J > iperf3_$(date +%Y%m%d_%H%M).json
# 受信側の平均スループットを Mbit/s で取り出す（jq が必要）
jq '.end.sum_received.bits_per_second / 1000000' iperf3_*.json
# 1秒ごとの推移を CSV にする
jq -r '.intervals[] | [.sum.start, (.sum.bits_per_second / 1000000)] | @csv' iperf3_20261022_1000.jsonCSV にした推移を表計算ソフトやグラフツールに読み込めば、速度の波や落ち込みを時系列で確認できます。区間ごと・時間帯ごとにファイル名を分けておくと、後から「夜だけ遅い区間」などを見つけやすくなります。
注意点
- 他人のサーバーに向けて測らない：管理権限のないホストに大量の通信を流すと、迷惑行為や規約違反になるおそれがあります。
- クラウドの転送料金：iperf3 は短時間で大量のデータを流すため、クラウドでは送信データ量に応じた費用がかかることがあります。測定時間は必要最小限にします。
- 本番サーバーの負荷：測定中は回線を占有するため、サイトの応答が遅くなることがあります。アクセスの少ない時間帯に行います。
- ポートを閉じる：測定後は 5201 番の許可を削除し、サーバープロセスも停止します。
まとめ
- iperf3 は2点間のスループット・再送・UDP のロスを測るツールで、経路のホップ自体は表示しません。
- 区間を分けて測り、mtr などの経路確認と組み合わせると、遅い経路を数字で切り分けられます。
-Rで逆方向、-Pで並列、-u -bで UDP、-Oで立ち上がりの除外ができます。-Jの JSON 出力を残し、時間帯ごとに比較すると一時的な混雑と恒常的な問題を区別できます。- 測定は自分の管理するホスト同士で、ポートの開放は一時的に、転送料金と本番負荷に配慮して行います。