海外旅行中にWireGuard VPNが遅くなる理由

更新日：2026年11月2日

はじめに

海外からGL.iNetルーターのWireGuardサーバーに接続すると、自宅の上下対 称のギガビット回線や、海外の滞在先（Airbnbなど）の 同様に高速な回線と比べて、インターネット速度が大幅に低 下することに驚くユーザーは少なくありません。この性能 差には、ISPのルーティングやピアリング、ネットワークの混雑 、ルーターの処理能力、VPNトンネルを介して通信するアプリケ ーションの動作など、複数の要因が関係します。

遅延とは何か、なぜ重要なのか

遅延とは、データがデバイスからVPNサーバーへ到達し、戻ってくるまで にかかる時間です。一般にミリ秒（ms）で測定されます。たとえば、 ベトナムにあるGL.iNetルーターからテキサス州のVPNサーバーに接続する場 合、往復時間（RTT）は容易に250-300 msになります。

遅延が大きいこと自体がWireGuardのパケット転送能力を低下させる わけではありません。TCPとは異なり、WireGuardのUDPベースのデータ転送 では、通常のデータパケットの送信を制御するための確認応 答や輻輳ウィンドウを使用しません。たとえば、利用可能な帯域幅 、パケット損失、処理能力が同程度なら、RTTが300 msのWireGuardトンネル でも、理論上はRTTが3 msの場合と同じパケット転送スループ ットを維持できます。

VPNトンネルを介して通信するアプリケーションは、受信側エンドポイントからのフィ ードバックに依存するTCPやQUICを使用することが多くあります。遠方のVPNサーバー経由で トラフィックを送ると、これらのアプリケーションのRTTが増加する場合があります 。これはアプリケーションの性能に影響しますが、ボトルネックがトランスポートの動 作、ネットワーク経路、ルーターの処理のどれにあるかを特定するものではありません。

アプリケーションの動作も重要です。リモートの共有フォルダーからファイルを開い たり、多数の小さなファイルをコピーしたりする場合、デバイスとサーバー間で 要求と応答が繰り返されることがあります。必要な往復通信のたびに遅延が加わる ため、単一の大きなファイルを高速にダウンロードできる回線でも、こうした 作業は遅く感じられます。TCP受信ウィンドウを大きくしても、アプリケーションレベ ルの待ち時間はなくなりません。

TCPスループットと遅延の関係

遅延の大きい接続でTCPスループットを理解するうえで役立つ関 係の一つが、帯域幅遅延積（BDP）です。

帯域幅遅延積 = スループット x RTT

BDPは、所定のRTTを持つ接続で特定のスループットを維持する ために、転送中（送信済みで未確認）の状態にしておく必要が あるデータ量を表します。ただし、この関係だけでは、実 現可能な最大スループットや、特定のネットワーク接続におけ る制限要因はわかりません。

たとえば、RTTが288 msの場合にTCPスループットを100 Mbpsで維持するには、ネット ワーク経路とエンドポイントがその速度をサポートできることを前提として、 約3.6 MBの未確認データを転送中の状態にする必要があります。

重要な用語をいくつか説明します。

• TCP受信ウィンドウ（rwnd）： 受信デバイスが、受信バ ッファーの空き容量に基づいて、追加で受け取れると通知す るデータ量です。
• TCP輻輳ウィンドウ（cwnd）： 送信側が、輻輳制御ア ルゴリズムとネットワーク状況に基づいて、未確認の状態で 保持できるデータ量です。
• スループット： データが正常に転送され る実効速度です。
• RTT（往復時間）： データがエンドポイント間を移 動し、応答が戻るまでに必要な時間です。

送信側が未確認の状態にできるTCPデータの実効上限は、その他の制 約に加え、受信ウィンドウと輻輳ウィンドウの小さい方によって 決まります。この違いは重要です。受信ウィンドウが十分に大きく ても、輻輳制御やネットワーク経路の制約によって送信側が十分な未 確認データを維持できなければ、高いスループットは保証されませ ん。

パケット損失が起きると、再送が必要になり、送信側が輻輳ウィンドウ を縮小するため、TCPスループットが低下する場合があります。遅延の大 きい接続では、フィードバックや回復に時間がかかるため、大きな受信ウィン ドウだけでは高速な転送を維持できないことがあります。

GL.iNet Subredditメンバーの実例

ベトナムにいるGL.iNet subredditのメンバーが、GL.iNet Flint 2ルーター上で稼働するテ キサス州の自宅のWireGuardサーバーに接続した際、次の結果を報告 しました。

• サーバー所在地： 米国テキサス州
  
  • ローカル速度（対称型光回線） 700 Mbps download / 940 Mbps upload
• クライアント所在地： ベトナム
  
  • ローカル速度（VPNなし）： 455 Mbps download / 634 Mbps upload
    
  • ローカル速度（WireGuard VPNクライアント有効時）： 47.3 Mbps download / 12.1 Mbps upload, 288 ms ping

自宅のVPNサーバー経由でダウンロードする場合、ダウンロードの最大スループット は、自宅のインターネット回線のアップロード速度にも左右される点に注意してくだ さい。

これらの測定では、ローカルのインターネット性能と国 際WireGuard接続の性能に大きな差が見られます。ただし、各テストが 同等のネットワーク経路を測定しているとは限りません。ベト ナムでのローカル速度テストでは近隣のテストサーバーに 接続する一方、VPN経由のトラフィックは、まずテキサス州まで の国際接続を通過する必要があります。そのため、経由する ISPのトランジットネットワーク、ピアリング構成、混雑する可 能性のある箇所が異なります。遅延が似ている国際接続で も、経路の品質によって速度は大きく異なります。VPN接続 のRTTは約288 msでしたが、この測定値だけでは、遅延がスルー プット低下の主因とは断定できません。パケット損失、 非効率な国際ルーティング、混雑なども関係した可能性があ ります。

まず、ネットワークのスループットに影響する一般的な要因を確認しましょう。

1. ISPの性能変動と近隣の混雑： スループットは、混雑やネットワーク負荷によって大きく変動します。
2. Wi-Fiの性能： 物理的な環境、他の無線デバ イスからの干渉、クライアントデバイスの能力、Wi-Fi 固有の半二重通信（全二重のEthernetとの違い）によって大き く変動します。
   • 現実的なWi-Fi性能について詳しくは、こちらをお読みください： https://www.wiisfi.com/
3. ISPのルーティングと国際ピアリング： 国境を越えるト ラフィックは、異なる事業者が運用する複数のネットワークを通過する ことがあります。両端のローカル回線が高速でも、ピアリング接続の混 雑、非効率な経路、パケット損失によって、スループットは大幅に低下 します。RTTが似ている国際経路でも、速度は大きく異なる場合があります。

ローカルISPの混雑や国際ルーティングの状況は、通常ユーザーが 直接制御できませんが、別のISPやネットワーク経路をテストすると 性能差を把握できる場合があります。両端のローカル回線が高速なの に長距離経路が遅い場合、国際ルーティングの品質やピアリングの混 雑は、よく疑われる原因です。別のISP（カフェなど）やホット スポットからテストすると、経路上で速度低下が起きているかを確認 する手掛かりになります。可能な限り有線Ethernetを使うことで、Wi-Fiの 制約を軽減できる場合があります。VPNスループットの問題を調べる 際は、ルーターの処理能力の制約やMTU関連の問題も確認する価値が あります。

結局のところ、国際VPN接続が遅い理由を判断するには、ネットワ ーク経路、VPNルーター、トンネルを介して通信するアプリケー ションの制約を区別する必要があります。

パフォーマンスを向上させるTCP Window Scaling

TCPの受信ウィンドウは、当初は約64 KBに制限されていました。ウィンド ウスケーリング（RFC 7323）によって上限は約1 GiBになり、現在のOSはウィ ンドウを自動調整します。たとえば、Microsoftの文書にある自動調整設 定Normalでは、約16.8 MBの受信ウィンドウを表現できます。したがって、現在 のTCP接続が本質的に64 KBに制限されているわけではありません。

出典：duckware.com/blog/how-windows-is-killing-internet-download-speeds

TCPウィンドウの上限とRTTの関係

未確認データ量の上限が固定されたTCP接続では、ウィンドウに起因するおおよそ のスループット上限は次のとおりです。

スループット（ビット/秒） ≈ ウィンドウ上限（バイト） × 8 ÷ RTT（秒）

ウィンドウ上限が一定の場合、RTTが大きいほどウィンドウに 起因する上限は低くなります。次の例はこの関係を示すもので、実際のVPN スループットを予測するものではありません。

ウィンドウに起因する理論上の上限（ウィンドウ ÷ RTT）。1 MB = 1,000,000バイトとして計算し ています。関係を説明するための例であり、実際のVPNスループットを予測するものではありません。

実際のスループットは、輻輳制御、パケット損失、利用可能な帯域幅 、処理能力の上限にも左右されます。複数のTCP接続によって合計 スループットが向上する場合もありますが、利用可能な帯域幅を使 い切れなくなる共通のRTTしきい値はありません。

ベトナムとテキサス州の例では、RTTが288 msで未確認データが2 MBに制限 された単一のTCP接続を仮定すると、ウィンドウに起因する上限は約 55.6 Mbpsになります（表の300 msの行は、RTTが大きいため少し低い値です）。 ただし、これだけではユーザーの測定値が47.3 Mbpsだった理由はわかり ません。

テストで使用した接続数、実際のTCPウィンドウ、ネットワーク状況がわからな ければ、ボトルネックがウィンドウ上限、混雑、パケット損失、ISPのルーテ ィング、あるいは別の要因だったのかを判断できません。

TCPウィンドウサイズは何によって決まるのか

TCPウィンドウサイズは個々の接続に属し、データ転送中に変化する 場合があります。そのため、上記の例の値を、デバイス上のすべ ての接続に適用される固定設定として扱うべきではありません。

受信ウィンドウは、受信デバイスのOSが管理します。そのサイズは、受信バ ッファーの空き容量、OSの自動調整や制限、アプリケーションの設定、ア プリケーションが受信データを処理する速さなどによって決まります。ノー トパソコンにファイルをダウンロードする場合、ノートパソコンは送信元サ ーバーに受信ウィンドウを通知します。アップロードの場合は、受信サ ーバーがノートパソコンにウィンドウを通知します。

送信側は別途、輻輳制御アルゴリズムとネットワークからのフィードバ ックに基づいて輻輳ウィンドウを管理します。受信側が大きなウィンドウ を通知していても、これによって未確認状態のデータ量が制限される場合 があります。一般的なルーター間のWireGuard構成では、これらのTCPウィンドウは 通信するコンピューターやサーバーに属するもので、VPNルーター上の単一の ウィンドウサイズ設定ではありません。

実際の接続を確認する方法

パケット解析に慣れている方は、Wiresharkで通知されたTCP受信ウィンド ウを確認できます。ルーター間の構成では、転送を行うコンピュータ ー上でトラフィックをキャプチャします。最初のハンドシェ イクとウィンドウスケーリングのネゴシエーションを記録できる よう、新しいTCP接続を確立する前にキャプチャを開始してください 。ダウンロード中、その転送に対してコンピューターから送信される TCP確認応答を調べ、Transmission Control Protocolセクションを展開して、 Calculated window sizeを 探してください。これは、その時点でコンピューターが通知した受信ウィンドウを示します。Wiresharkがネゴ シエーション済みのスケール係数を認識している場合は、スケーリングが適用されます。

この値は転送中に変化する場合があります。送信側の輻輳ウィンド ウを直接示すものでも、受信ウィンドウが性能を制限している ことを証明するものでもありません。また、OSの自動調整設定を確認 しても、個々の接続が現在通知している実際のウィンドウはわかり ません。

別の実例：pingが変わらなくても速度は向上する

別のサポート事例で、遅いTailscale VPN接続を調査しました。TailscaleはWireGuardの 暗号化を使用しますが、リレーの種類によって暗号化パケットの 転送方法が異なります。DERPリレーはTCPベースの接続を、Tailscale Peer RelayはUDP を使用します。これは、通常は暗号化パケットをUDPで直接送 信する単独のWireGuard接続とは異なります。この事例では両リレー を同じAWS Lightsailインスタンス上でセルフホストしていたため、比 較対象は非公開でホストされた2つのリレー方式であり、Tailscaleの 公開DERPサーバーではありません。

クライアントのインターネット接続はテストで約83 Mbps、VPNサーバ ーのインターネット接続はアップロード速度約40.6 Mbpsでした。観測 されたダウンロード速度は次のとおりです。

SQMはSmart Queue Managementの略で、パケットキューを管理し、負荷時の過剰な遅延を減ら すルーター機能です。この比較では、クライアント側のトラベル ルーターでSQMの有効・無効を切り替えました。

SQMは、VPNの速度低下をあらゆる状況で解決できる機能ではありません。 単一の暗号化されたトンネルフローしか認識できない場合、その内部に隠れた アプリケーションの各接続に個別の優先順位を付けることはできません。共有パケットキューの管理は引き続き可能ですが、 キュー内の待ち時間を短縮できるのは、パケットの過剰な滞留が発生しており、 SQMで対処できる場合に限られます。SQMで有効に制御できる過剰な滞留がない場合は、 必要以上に厳しい帯域幅設定や追加の処理負荷によって、 応答性が改善されないままスループットが低下することがあります。

遅延はほぼ変わらなかったにもかかわらず、UDPベースのリレー では、SQMの有効・無効にかかわらずスループットが大幅に向上しま した。最大の改善は、pingの低下やSQMの無効化ではなく、リレー方式の 変更に伴って生じました。

考えられる要因の一つは、DERPのTCPベースのトランスポートです。各Tailscaleデバ イスはTCPでDERPリレーに接続するため、暗号化パケットはリレーの両側 で別々のTCP接続を通過します。トンネル内の複数のアプリケーション 接続が、これらの外側のTCP接続を共有することがあります。外側のTCP接 続でデータが失われると、その後のデータは再送を待ってからで ないと配信できない場合があり、複数のアプリケーションが同時に 遅延する可能性があります。UDPベースのPeer Relayは、この追加の順序付きTCP転 送層を回避します。ただし、トンネル内のTCPアプリケーションは引き 続き独自の確認応答と輻輳制御を使用します。

両リレーは同じインスタンス上で稼働していたため、リレーホスト と場所は一定でした。このことは、単にリレーをユーザーに近づけた からではなく、リレーのトランスポートや実装が改善に寄与したとい う解釈を補強します。ただし、同じホストを使ってもネットワーク経路 や状況が同一とは限らないため、この比較だけでTCPとUDPの違いを唯一の 原因とは特定できません。

これらは一つのサポート事例での観測結果であり、保証された性能値 ではありません。ただし、遅延だけではVPN速度を予測できない理由 を示しています。

まとめ

本記事が、長距離のWireGuard VPN接続で、ダウンロードやアップロード の速度が両端で利用できるインターネット速度より大幅 に低くなる理由を理解する助けになれば幸いです。最も重 要なのは、WireGuard自体にはRTTに依存するスループット上限がな いという点です。UDPベースのデータ転送では、通常のデー タパケットにTCPのような輻輳ウィンドウ、確認応答、再送を 実装していません。

一方、トンネルを介して通信するTCPやQUICのアプリケーションは、それ ぞれの輻輳制御と信頼性確保の仕組みの影響を受けます。RTTが大きい ほど、所定のスループットを維持するために必要な未確認データ量 が増加します。複数接続によって合計性能が向上する場合もあり ますが、RTTや接続数だけでは実現可能な速度は決まりません。実際 の性能は、パケット損失、ネットワークの混雑、ISPのルーティン グやピアリング、利用可能な帯域幅、MTU設定、VPNルーターの処理能力に も左右されます。

一般的なGL.iNetルーター間のWireGuard構成では、TCP接続は端末と接続先サーバ ーの間で確立されます。VPNルーターは、これらのエンドツーエン ド接続のTCP受信ウィンドウを直接制御せず、パケットを暗号化・復 号・転送します。ルーターのハードウェア制約が暗号化パケ ットのスループットに影響する場合はありますが、TCP受信ウィンド ウの制約とは区別する必要があります。

遅い国際WireGuard接続を調べる場合、まず両地点のインターネット接 続を、可能であれば有線Ethernetでテストしてください。時間帯を変えた り、モバイルホットスポットなど別のインターネット回線を使った りしたときに、VPNの性能が変化するかを確認します。こうした 比較は速度低下の発生箇所を絞り込む手掛かりになりますが、 原因の特定にはさらに詳しいテストが必要な場合があります。 大きな遅延はアプリケーションの性能低下に関係しますが、遅いVPN 接続の唯一の説明と決めつけるべきではありません。

今後は、適切な場所に配置したUDPリレーを使い、別の経路に よって米国とアジア間のWireGuard VPN性能を改善できるか実験したいと考 えています。

WireGuard VPNの設定に関するトラブルシューティングと理解に役立つ詳細やヒン トについては、次のGL.iNetフォーラム投稿をご覧ください： https://forum.gl-inet.com/t/how-to-troubleshoot-wireguard/42502