ルーターの Wi-Fi 表記が VPN のスループットを予測しない理由

宣伝されている Wi-Fi 速度と実測した VPN 速度は別の層を表しています。より速いルーターを買う前に、この順序立った確認を済ませてください。

3,000 Mbps の Wi-Fi バッジが付いたルーターでも、暗号化された通信はその数字のほんの一部の速度でしか流せませんし、どちらの数字も不誠実ではありません。無線の評価はチップセットが対応する無線リンクの最良の変調方式を表し、VPN の数字は一台の機器が暗号化パケットをルーターの CPU を通してアクセス回線の外へどれだけ速く押し出せるかを表します。これは別の層であり、別のパケットサイズであり、別の測定方法です。箱に書かれた数字は誰も届かない上限として扱い、トンネル速度の予測とは考えないでください。

ステップ 1: 数字を制限する四つの層を整理する

私が扱ってきた遅いルーターの苦情はほぼすべて四つの段のどれかに落ちます：無線リンク、WAN のアクセス速度、転送経路（NAT、ファイアウォール、コネクション追跡）、そして VPN の暗号処理経路です。これらは積み重なり、最も遅い段が結果を決めます。宣伝されている Wi-Fi 速度は最初の段だけを語り、しかも気前よく語ります。

その数字は、ストリーム数にチャネル幅を掛け、チップセットが交渉できる最も高い変調方式を掛けたものです。5 GHz で 80 MHz、1024-QAM の 2x2 無線は 1,200 Mbps 近くで宣伝されますが、Wi-Fi は共有された半二重の媒体です：クライアントは順番を待ち、再送と管理トラフィックがエアタイムを消費し、TCP が独自のオーバーヘッドを加えます。理想的な条件で最高速度を交渉したクライアントでも、通常はその半分を大きく下回り、近隣のネットワークが現れるとさらに下がります。

SymptomTier to suspect first
Wired clients are slow tooWAN access or forwarding path
Only Wi-Fi clients are slowRadio, airtime, or channel width
One stream is slow, four parallel streams add upPer-connection CPU path, not the link
Every stream is slow and one core sits at 100%Crypto path
Fast to LAN hosts, slow to the internetWAN, not the tunnel

表が無線を指すなら、まず無線側を直してください：バンド、チャネル幅、距離です。無線より下を指すなら、次の四つのステップが重要で、アンテナをどれだけ買っても変わりません。

ステップ 2: 無線に触れる前に有線の基準値を取る

ノート PC を Ethernet につなぎ、まずトンネルなしで経路を測定してください、これが分母になります。スループット測定ツールは反対側、VPN を終端する VPS や自宅サーバーで動かし、クライアントをその公開アドレスに向けて、通信がルーターとアクセス回線を通るようにします。

# on the far host (VPN endpoint)
iperf3 -s

# wired client, direct to the endpoint's public address
iperf3 -c 203.0.113.10 -t 30

# same client, four parallel streams
iperf3 -c 203.0.113.10 -t 30 -P 4

そのブロックの二つの数字は別の問いに答えます。一本のストリームは接続ごとの上限を示し、TCP ウィンドウの挙動と経路上のフロー単位の整形を含みます。四本のストリームは、回線に使い切れていない容量があるかを示します：並列フローは一本では埋められないパイプを埋められるからです。

正直に保ってください：同じホスト、同じ時間帯と長さで、家の中で他に何もストリーミングしていない状態にします。ここでは三十秒の一括転送が正しい単位ですし、RFC 6349（TCP スループット試験の枠組み）もこの考え方に基づいており、短いバーストや小さなリクエストは回線を良く見せるからです。何かを変える前に基準値を書き留めてください。

ステップ 3: 同じ試験をトンネル経由で実行する

今度は終端のトンネルアドレスに対して、同じクライアント、長さ、ストリーム数で繰り返します：トンネルは上げ、他の通信はありません。二つの結果の比は、そのハードウェアで暗号化とカプセル化にどれだけかかるかを示し、絶対値は仕事に足りるかを示します。

転送中はカウンターを監視します。WireGuard では wg show がピアごとの転送バイト数を報告し、OpenVPN では一定間隔で書き出されるステータスファイルが同じ見方を与えます。

watch -n 1 'wg show wg0 transfer'
# OpenVPN: add --status /run/openvpn/server.status 10 to the server config
tail -f /run/openvpn/server.status

トンネルの数字が有線の基準値に近ければ、VPN はボトルネックではなく、責めるのはやめられます。基準値のほんの一部なら、損失はルーターの暗号化と転送の経路の内側で起きており、次のステップがどの部分かを示します。

注意が一つあります：出口 IP が変わると、一部の速度テストサービスは黙って別の測定サーバーを選ぶため、結局は別々の二つの宛先を比べることになります。サーバーのアドレスは自分で固定してください。

ステップ 4: CPU を平均ではなく経路として読む

CPU 全体が 30 パーセントと表示されていても飽和していることがあります：一つのトンネルの処理は一つのコア、一つの割り込みキュー、一つのカーネルスレッドに集中しがちで、平均は上限を隠します。ダッシュボードのゲージではなく、コアごとの数値と softirq を見てください。

mpstat -P ALL 1
top -H -p $(pgrep -f 'openvpn')
grep -o -m1 aes /proc/cpuinfo

その出力では三点が重要です。一つのコアが 100 パーセント近くに張り付き、他が遊んでいるなら、接続あたりの限界を示します。重い %soft や一つの CPU で忙しい ksoftirqd は、キューに分散していない受信側のパケット処理を示します。また aes フラグがなければ CPU に AES 命令がないということで、対称暗号がソフトウェアで動き、パケットあたりのコストがはるかに高くなります。

実装も重要です。従来のユーザー空間の OpenVPN は一つのトンネルのパケットをほぼ一か所で処理するため、高速なマルチコア機でもそのトンネルではシングルコアのように振る舞うことがあります。カーネル内の WireGuard は処理を CPU に分散し、OpenVPN のデータチャネルオフロードもパケット処理をカーネルへ移しますが、対応するビルドとプラットフォームに限られます。マーケティングページのハードウェア高速化の主張は、実行しているコード経路がそれを使っている証拠にはなりません。

ステップ 5: 何を変えるかを、この順序で決める

この一覧を下へたどり、当てはまる最初の行で止めてください：その下を変えても数字は動きません。

1. 有線直結のスループットが支払っている水準を下回るなら、プロバイダーと話してください：アクセス回線が出さない容量をトンネルが作ることはできません。2. 有線直結は問題ないのにトンネル試験で一つのコアが張り付くなら、ルーターの暗号処理経路が限界です。3. CPU は遊んでいるのにトンネルが遅いなら、MTU と断片化を確認し、次に遠隔終端自体の容量を見てください。4. Wi-Fi クライアントだけが遅いなら、バンドかチャネル幅を変え、宣伝された速度が VPN の数字ではなかったことを受け入れてください。

ルーターが本当に限界のとき、正直な選択肢は AES 命令とより速い転送経路を持つ機器、ユーザー空間の代わりに WireGuard のようなカーネル側トンネル、あるいはルーターが暗号化をやめるようクライアントを機器自体へ移すことです。ベンチマークに勝つために認証付き暗号化を切ることは、そのどれでもありません：安全性を数字と引き換えにするだけで、その数字も箱には合いません。

何かを買う前に、新しい機器で同じサーバーと同じ長さでステップ 2 と 3 を再実行し、ピークではなく比率を比べてください。

関連記事