プロトコルと回線技術リファレンス

選定ガイド

このページは NZVPN のプロトコルと回線の技術リファレンスです。サブスクリプションプランを選んでいる方、または既に契約していて仕組みを理解したい方を対象としています。チュートリアルページ setup.html の「手順通りにやれば完了する」という流れとは異なり、本ページはより体系的な参照向けです。各章は独立して読むことができ、目次から気になるトピックにジャンプできます。

始める前に、2つの基本的な次元を明確にしておきましょう。プロトコル（Protocol）はデータがどのようにカプセル化、暗号化、転送されるかを決定します。回線トポロジ（Topology）はデータが物理的にどの経路を通るかを決定します。この2つが接続確立速度、転送速度、安定性、モバイル端末のバッテリー消費を決定します。多くのユーザーが「接続できない」「速度が遅い」「4Kでカクつく」という問題に直面しますが、その根本原因はサービス自体ではなく、プロトコルと回線の組み合わせが現在のネットワーク環境に合わせて最適化されていないことにあります。

プロトコル層は「データがどのような形式でネットワークを通過するか」という問題を解決します。従来のTCPプロキシは弱いネットワーク環境ではハンドシェイク再送によって速度が低下しやすいです。一方、UDPベースのプロトコルは高パケットロス環境でもより安定した転送を維持できます。回線層は「データがどの経路を通るか」という問題を解決します。同じシンガポールノードでも、直結、中継、IEPL専用線のどれを使うかで、遅延と安定性が数倍異なることがあります。この2つの層を理解することで、回線一覧を見るときに効果的な判断ができるようになります。

NZVPN のサブスクリプションサービスは120以上の国 / 220以上の回線をカバーしています。Windows、macOS、iOS、Android、Linux の5大プラットフォームに対応し、デバイス台数は無制限です。サブスクリプションは月額 ¥9.9 から（60GBの通信量）の3段階プランで、別途、有効期限が無期限のデータパックも選択できます。30日間の理由不要返金も提供しています。本記事の本サービスに関する記述はすべて上記の事実と一致しており、未確認のデータは一切導入していません。

なお、本ページではネット規制に関する話題は取り扱わず、具体的なノード設定コマンドも提供しません。プロトコルと回線はサービス提供者がバックエンドで設定済みのインフラです。ユーザー側でできる選択は、サブスクリプションプランとクライアント設定に集中しています。しかし、原理を理解することで、なぜ特定のプロトコルが特定のネットワーク環境で速いのか、なぜ専用線回線がより高い月額料金に値するのか、そして接続に問題が発生したときにどの部分を確認すべきかを判断するのに役立ちます。

本ページは「プロトコル → 比較 → トポロジ → シーン」の順で構成されています。最初の5章では6つのプロトコルを順に紹介し、第6章では横断比較表を示し、第7章では回線トポロジを議論し、第8章ではパケットロスと混雑の原因を説明し、第9章では使用シーンに応じた選定提案を示します。最初から最後まで読むことも、気になる章に直接ジャンプすることもできます。

Shadowsocks:軽量プロキシプロトコルのトレードオフ

Shadowsocks（略称SS）は、現在最も広く使われている軽量プロキシプロトコルの1つです。その設計目標は非常に明確です。信頼性の低いネットワーク環境で、可能な限り低いリソースコストで暗号化トンネルを確立することです。SSの暗号化方式はAEAD（認証付き暗号）ストリーム暗号に基づいており、一般的な組み合わせにはAES-256-GCMとChaCha20-Poly1305があります。前者は主流のCPUでハードウェアアクセラレーションが利用でき、後者はモバイル端末のARMプロセッサでより良い性能を発揮します。

SSのトランスポート層はデフォルトでTCPを使用し、データは標準のSOCKS5プロキシトラフィックとしてカプセル化されます。プロトコルレベルで「普通のプロキシに見える」ため、デプロイは非常に軽量で、追加のハンドシェイクや認証のオーバーヘッドが不要です。接続確立時、クライアントとサーバーの間ではTCPハンドシェイク1回と暗号化ハンドシェイク1回だけで済み、プロセス全体は通常数十から数百ミリ秒で完了します。Webブラウジングやインスタントメッセージのような短い接続のシーンでは、SSの応答速度は非常に理想的です。

SSの限界も明らかです。まず、単一ポートでのマルチユーザー対応が弱いことです。初期のSSは1つのポートで1人のユーザーにしかサービスを提供できませんでしたが、後の実装ではマルチユーザーに対応しましたが、サーバー側でユーザーテーブルを維持する必要があり、大規模な同時接続時に管理の複雑さが増します。次に、プロトコル特徴が比較的固定されており、一部のディープパケットインスペクション（DPI）システムはトラフィックの統計的特徴を分析してSSトラフィックを識別できますが、これには一定の計算リソースが必要です。一般ユーザーにとって、SSは依然として最も「スムーズ」な選択肢です。クライアントのエコシステムが成熟し、設定が簡単で、リソース使用量が低いからです。

モバイル端末では、SSのバッテリー性能を個別に説明する価値があります。SSはTCPベースのため、システムは低電力モードに入ることができ、UDPプロトコルのように無線モジュールを頻繁にウェイクアップする必要がありません。iOSとAndroidでは、SSのバックグラウンド維持が比較的容易で、長時間の常駐でもバッテリー消費が大幅に増加することはありません。主にスマートフォンでSNSやWebページを見るユーザーにとって、SSは省電力の優れた選択肢です。

実際の使用では、SSは以下のシーンに適しています。軽度から中程度のクロスボーダーアクセス、モバイル端末での長時間常駐、接続確立速度に敏感なアプリ（インスタントメッセージなど）、そしてネットワーク環境が比較的安定している場合です。ネットワークのパケットロス率が高い場合、SSのTCP再送メカニズムが顕著な速度低下を引き起こすため、後述するQUICベースのプロトコルを推奨します。

NZVPNの回線一覧では、ほとんどの通常回線がデフォルトでSSまたはSS互換の転送方式を採用しています。これらの回線は日常使用に適しており、中継トポロジと組み合わせることで夜間ピーク時も基本的な安定性を維持できます。より極端な速度性能を求める場合は、クライアントで他のプロトコルに切り替えるか、プランページで専用線回線を含むプランを選択できます。

VMess と VLESS:完全プロトコルフレームワークの進化

VMessはV2Rayファミリーの中核プロトコルであり、設計上SSよりも「既知のプロトコルに見えない」ことを重視しています。VMessはアプリケーション層でUUIDをユーザー識別子として導入し、リクエストヘッダーにタイムスタンプを追加し、オプションのリプレイ防止メカニズムと組み合わせることで、同じリクエストがネットワーク上で簡単にリプレイまたは識別されないようにしています。VMessの暗号化もAEADに基づいていますが、メタデータ（宛先アドレス、ポートなど）も暗号化しており、SSのように宛先アドレスを平文ヘッダーに露出しません。

VMessの代償は接続確立速度が比較的遅いことです。接続のたびに「クライアントが開始 → サーバーがUUIDを検証 → 応答を返す」というハンドシェイクプロセスを完了する必要があり、弱いネットワーク環境ではこのプロセスが再送によって長引く可能性があります。さらに、VMessのヘッダーには固定プレフィックスがあり、この特徴はDPIシステムで識別される可能性があります。これを回避するため、後の実装ではmKCP、WebSocket、gRPCなどのトランスポート層バリアントが導入され、VMessトラフィックをWebSocketまたはgRPCトラフィックに偽装しています。

VLESSはVMessの後継であり、中核的な改善点はVMessの冗長な暗号化層を除去したことです。VLESS自体はデータを暗号化せず、メタデータの転送のみを担当し、実際の暗号化はトランスポート層（TLSなど）が行います。これにより接続確立速度が大幅に向上します。アプリケーション層の暗号化ハンドシェイクを先に行う必要がなく、TLSで直接安全なチャネルを確立できます。VLESSはUUIDユーザー識別子とリプレイ防止機能を維持し、XTLSなどの新しい転送機能への対応も追加しています。

リソース使用量の面では、VLESSはVMessより軽量です。アプリケーション層の暗号化を1層省いたため、CPU使用率が低下し、これは低スペック端末やモバイル端末で特に顕著です。VLESSをTLS + WebSocketまたはgRPC転送と組み合わせると、トラフィック特徴が通常のHTTPSサイトアクセスとほぼ区別できず、トラフィック特徴に敏感な環境に適しています。

なお、VLESS自体はデータを暗号化しないため、TLSと組み合わせて使用する必要があります。NZVPNのクライアントはVLESS回線を設定する際、デフォルトでTLS暗号化を有効にするため、ユーザーが手動で介入する必要はありません。VLESSはCDNとの連携も優れています。VLESSのハンドシェイクプロセスが簡潔なため、CDNのオリジンサーバーへのアクセス時にタイムアウトで切断されにくいからです。

選定の観点から見ると、VMessは互換性の要求が高い古いクライアントや、mKCPなどの特殊な転送が必要なシーンに適しています。VLESSは接続速度とモダンな転送機能を求めるユーザーに適しています。両方ともNZVPNの回線に展開されており、クライアントは回線設定に応じて適切なプロトコルを自動的に選択するため、一般ユーザーが手動で区別する必要はありません。

Trojan:通常のHTTPSトラフィックへの偽装

Trojanの設計思想はSSやVMessとは異なります。中核となる考え方は「トラフィックを通常のHTTPSサイトアクセスと完全に一致して見せる」ことです。TrojanはTLSトンネルの上にカスタムプロトコルを重ね、クライアントとサーバーの間で最初に完全なTLSハンドシェイクを完了し、その後HTTPに似たヘッダーで実際のリクエストを転送します。ネットワークトラフィックの観点では、Trojan接続はブラウザがHTTPSを有効にしたサイトにアクセスするのとほぼ区別できません。

この偽装特性により、Trojanは「普通のアクセスに見える」必要があるシーンで非常に効果的です。接続確立プロセスは通常のHTTPSと同じで、TCPハンドシェイク1回とTLSハンドシェイク1回の後、データ転送が始まります。このプロセスはVMessよりアプリケーション層のハンドシェイクが1つ少ないため、接続確立速度はVLESSと同等ですが、SSよりはやや遅いです（TLSハンドシェイク自体に1〜2 RTTが必要なため）。

Trojanの暗号化は完全にTLSに依存しているため、証明書管理の要求が高くなります。サーバー側は有効なTLS証明書を保持している必要があり、そうでなければ接続はハンドシェイク段階で失敗します。NZVPNのクライアントには証明書検証ロジックが組み込まれており、回線にTrojanプロトコルが設定されている場合、自動的に証明書検証が完了します。ユーザーはサブスクリプションのインポート時に対応する回線を選択するだけで済みます。証明書の有効期限切れやドメイン変更があった場合、クライアントは接続失敗を通知します。その場合はサブスクリプションリンクを再取得して更新できます。

リソース使用量の面では、Trojanのオーバーヘッドは主にTLSの暗号化・復号に起因します。現代のCPUにはAES-NIなどのハードウェアアクセラレーション命令があるため、TLSの暗号化・復号のCPU使用率は高くありません。モバイル端末では、Trojanのバッテリー性能はVLESSに近いです。両方のトランスポート層がTCPであるため、システムは正常に低電力モードに入ることができます。ただし、ネットワークのパケットロスが深刻な場合、TrojanのTCP再送も速度を低下させることに注意が必要です。これはすべてのTCPプロトコルに共通する特性です。

Trojanの適用シーン:複雑なネットワーク環境を安定して通過する必要がある方、トラフィック特徴をできるだけ目立たせたくない方、CDNと連携してドメイン分割を行いたい方です。TrojanとTLS + WebSocketの組み合わせはCDNと良好に互換性があり、トラフィックをCDNノードからオリジンサーバーに転送し、バックエンドの位置をさらに隠すことができます。

NZVPNの回線体系では、Trojanは通常、専用線または高品質な中継回線に展開されています。Trojanの偽装特性は安定したTLS接続を必要とするため、回線自体の品質が悪いと、頻繁なTLS再接続がかえって体験を低下させます。「接続すればすぐ使える、手間がかからない」ことを求めるユーザーにとって、Trojan回線は気楽な選択肢です。

Hysteria2 と TUIC:QUICベースの次世代プロトコル

Hysteria2とTUICはどちらもQUIC（Quick UDP Internet Connections）ベースのプロキシプロトコルです。QUICはGoogleが主導して開発したトランスポート層プロトコルで、基盤にはUDPを使用していますが、TCPの信頼性のある転送、輻輳制御、多重化機能を内蔵しています。TCPと比較して、QUICの最大の利点は接続確立が速いことです。TLSハンドシェイクをトランスポートハンドシェイクに統合しており、通常1つのRTTで暗号化接続を確立できます。

Hysteria2の独自性は、Brutalという輻輳制御アルゴリズムを使用している点にあります。従来のTCP輻輳制御（CUBIC、BBRなど）はパケットロスを検出すると送信レートを積極的に下げるため、パケットロスがあるネットワークでは帯域利用率が低下します。Brutalは逆で、ユーザーが目標レートを設定し、そのレートでデータを送信し続け、パケットロスがあっても後退しません。これは高パケットロス・高遅延のリンクで非常に効果的で、動画ストリーミングや大容量ファイルのダウンロードで安定した速度を維持できます。

TUICの設計はより「シンプル」に傾いています。これもQUICベースですが、サーバー側のユーザーテーブルを廃止し、VLESSに似たUUID識別子を採用しています。TUICの接続確立速度はHysteria2と同等ですが、輻輳制御アルゴリズムは標準QUICのデフォルト実装に近いため、極端に高いパケットロス環境では速度性能がHysteria2ほど積極的ではありません。ただし、TUICのリソース使用量はより低く、低スペック端末でよりスムーズに動作します。

モバイル端末のバッテリーは、QUICプロトコルを選択する際に最も考慮すべき要素です。QUICはUDPベースであり、UDPはモバイルネットワーク下でNATマッピングと接続状態を維持するために無線モジュールをより頻繁にウェイクアップする必要があります。これは、同じ使用時間であれば、QUICプロトコルのバッテリー消費が通常TCPプロトコルより10%〜20%高いことを意味します。ただし、QUICの高速再接続能力は、ネットワーク切り替え時に迅速に復旧できることを意味し、「再接続」による追加のバッテリー消費を減らします。

Hysteria2とTUICは以下のシーンに適しています。モバイルネットワーク（4G/5G）下の高パケットロス環境、4Kストリーミングやビデオ会議が必要な場合、そしてネットワークが頻繁に切り替わる場合（地下鉄、新幹線など）です。パケットロス率が5%を超えるリンクでは、QUICベースのプロトコルはTCPプロトコルより2〜3倍速いことが多いです。

NZVPNのクライアントはHysteria2とTUICを全面的にサポートしています。サブスクリプションのインポート時にQUIC対応の回線を選択した場合、クライアントは対応するポートと転送パラメータを自動的に設定します。注意点として、一部の古いネットワーク機器（企業ファイアウォールなど）がUDPトラフィックを禁止している場合、QUICプロトコルは動作せず、TCPプロトコルにフォールバックする必要があります。

接続確立速度とリソース使用量の横断比較

6つのプロトコルを1つの表にまとめると、設計トレードオフがより直感的に見えてきます。なお、下表のデータは典型的なネットワーク環境（パケットロス率1%〜3%、RTT 40〜80ms）に基づく経験値であり、実際の性能は回線品質、デバイス性能、ネットワーク混雑度によって異なります。

表からいくつかの選定の法則を導き出せます。第一に、ネットワーク環境が安定している場合（家庭用ブロードバンド、オフィスネットワーク）、TCPプロトコル（SS、VLESS、Trojan）で十分です。省電力で互換性も良好です。第二に、モバイルネットワークで頻繁に使用する場合、またはネットワークのパケットロス率が高い場合、QUICベースのプロトコル（特にHysteria2）が速度体験を大幅に向上させます。第三に、トラフィック特徴が気になる場合、TrojanとVLESSがより確実な選択肢です。

リソース使用量の面では、SSとVLESSのCPU使用率が最も低いです。追加の暗号化層を省いているためです。VMessはアプリケーション層の暗号化が1層多いため、CPU使用率がやや高くなります。Hysteria2とTUICのCPU使用率はQUICの実装品質に依存します。TUICのコードはより簡潔で、低スペック端末で有利です。

接続確立速度は多くの人が見落としがちな指標です。短い接続のシーン（Webブラウジング、API呼び出し）は接続確立遅延に非常に敏感で、RTTが1回増えるごとにユーザーが「カクッ」と感じます。QUICプロトコルはTLSハンドシェイクをトランスポートハンドシェイクに統合し、接続確立を1つのRTTに圧縮します。これはモバイル端末の体験における大きな利点です。一方、VMessは追加のアプリケーション層ハンドシェイクが必要なため、弱いネットワーク環境では接続確立が1秒を超える可能性があります。

注意点として、プロトコルの横断比較は回線品質を切り離して考えることはできません。高品質なIEPL専用線と通常のTCPプロトコルの組み合わせは、低品質な中継回線とQUICプロトコルの組み合わせよりも安定している可能性があります。プロトコルは「データをどう伝えるか」を解決し、回線は「データがどの経路を通るか」を解決します。両方を組み合わせて評価する必要があります。

回線トポロジ:直結、中継と専用線

回線トポロジは、ユーザーデバイスからターゲットサーバーまでの間に何ホップを経由し、どの物理経路を通るかを決定します。一般的なトポロジは3つあります。直結、中継、専用線です。これらの違いを理解することが、回線が「価値があるかどうか」を判断する鍵です。

直結（Direct）

直結は、ユーザーデバイスとターゲットノードの間に中間転送サーバーがなく、データが公衆インターネットのルーティングを介して直接ノードに到達することを意味します。直結の利点は遅延が低いことです。経路が最短で、追加のホップオーバーヘッドがありません。ただし、欠点は安定性が完全に公衆インターネットのルーティング品質に依存することです。夜間ピーク時には公衆インターネットの国際出口帯域が逼迫し、直結回線で顕著なパケットロスとジッターが発生する可能性があります。さらに、直結回線は異なるキャリア間（例えば、移動から聯通の出口にアクセスする場合）でルーティングが迂回することがあり、実際の遅延が理論値よりはるかに高くなることがあります。

中継（Relay）

中継回線は、ユーザーとターゲットノードの間に1台以上の転送サーバーを挿入します。これらの転送サーバーは通常、バックボーンネットワークまたは国際出口の重要な位置に配置され、ルーティング経路を最適化し、混雑区間を回避できます。中継の利点は安定性が良いことです。公衆インターネットの一部で混雑が発生しても、中継サーバーは予備ルートで迂回し、接続を維持できます。代償として遅延が増加します。1ホップごとに約5〜15msの遅延が増加し、具体的な値は物理距離に依存します。

中継はさらに「通常中継」と「スマート中継」に分けられます。通常中継は特定の転送サーバーを固定で使用し、経路は比較的固定されています。スマート中継はリアルタイムのネットワーク状況に応じて最適な経路を動的に選択し、BGPのルーティング選択に似ています。NZVPNの中継回線は広くスマートルーティングを採用しており、夜間ピーク時には自動的に遅延が低い経路に切り替わります。

専用線（IEPL）

IEPL（International Ethernet Private Line）は通信事業者が提供するポイントツーポイントの専用線サービスで、物理的に帯域を専有し、公衆インターネットを経由しません。専用線の遅延は非常に低く（通常、公衆インターネット直結より20〜40%低い）、パケットロスもほぼありません。リンク全体が専有されているため、他のユーザーのトラフィックの影響を受けません。専用線の欠点は価格が高いことであり、そのため通常は少数の人気ノードにのみ展開されます。

3つのトポロジの選択ロジックは次のように要約できます。極限の速度を求めるなら専用線、安定性を求めるなら中継、低遅延でネットワーク環境が良ければ直結です。NZVPNの回線一覧では、各回線にタイプのラベルが付いています。IEPL専用線、中継、直結。クライアントでは、回線タイプでフィルタリングすることもできます。

NZVPNの220以上の回線では、専用線、中継、直結がバランスよく配置され、120以上の国をカバーしています。人気地域（香港、シンガポール、アメリカ）では通常3つのトポロジが同時に提供され、ユーザーは使用シーンに応じて選択できます。例えば、Netflixを見るなら専用線、日常のブラウジングなら中継、ゲームなら直結を推奨します。

パケットロスと夜間ピーク混雑の原因と対策

パケットロスは、クロスボーダーネットワークで最も一般的な性能の敵です。パケットロスの原因を理解することで、回線が長期的に使用する価値があるかどうかを判断できます。パケットロスの原因は大まかに3つに分類できます。物理リンクの損失、ルーターのキューオーバーフロー、ルーティングの迂回です。

物理リンクの損失

海底ケーブルや陸上ケーブルは長距離伝送で信号減衰が発生し、電気信号または光信号がリピーターを通過する際にビットエラーが発生する可能性があります。ビットエラーレートが正常範囲内であれば、リンク層のエラー訂正メカニズムで処理され、上位プロトコルに影響しません。しかし、リンクの老朽化や天候の影響でビットエラーレートが上昇すると、エラー訂正能力を超えたデータパケットは直接破棄されます。この種のパケットロスは通常持続的であり、特定の回線が長期間不安定であるという形で現れます。

ルーターのキューオーバーフロー

これは夜間ピーク時のパケットロスの最も主要な原因です。インターネット上のルーターにはバッファ（キュー）があり、特定の方向のトラフィックがリンク帯域を超えると、データパケットはキューで待機して転送されます。キューが満杯になると、新しく到着したデータパケットは破棄されます。夜間ピーク時には国際出口帯域が多くのユーザーで共有されるため、キューオーバーフローの確率が大幅に上昇し、パケットロス率が通常時の0.1%から3%〜10%に急上昇します。

輻輳制御アルゴリズムの役割は、送信側にネットワーク混雑を認識させ、送信レートを積極的に下げて継続的なパケットロスを回避することです。TCPのCUBICアルゴリズムはパケットロス後に輻輳ウィンドウを半分に減らします。これにより混雑は緩和されますが、スループットが急激に低下します。BBRアルゴリズムはボトルネック帯域と最小RTTを測定して動的に速度を調整し、パケットロス環境でより高いスループットを維持できます。QUICはデフォルトでBBRに似た輻輳制御を採用しているため、高パケットロス環境でより良い性能を発揮します。

ルーティングの迂回

ルーティングの迂回はパケットロスそのものではありませんが、間接的にパケットロスを引き起こす可能性があります。公衆インターネットのルーティングが障害や混雑によりより長い経路に切り替わると、RTTが大幅に増加し、データパケットがキューに留まる時間が長くなり、タイムアウト再送が発生しやすくなります。タイムアウト再送はさらに混雑を悪化させ、悪循環を形成します。中継回線の中核的な価値の1つは迂回を回避することです。バックボーンネットワーク上の転送ノードを介して経路を「まっすぐに」し、不要なホップを減らします。

夜間ピークの混雑に対処するために、ユーザー側でできる選択肢は限られていますが、いくつかの効果的な戦略があります。第一に、IEPL専用線回線を優先的に選択することです。専用線は帯域を専有し、公衆インターネットの混雑の影響を受けません。第二に、クライアントでQUICベースのプロトコル（Hysteria2/TUIC）を有効にすることです。これらはパケットロスに対する許容度が高いです。第三に、最も混雑する時間帯（通常は現地時間の20:00〜23:00）を避けるか、負荷が低いノードに切り替えることです。

NZVPNの回線一覧は、各回線の遅延と帯域をリアルタイムで表示します。特定の回線で夜間ピーク時に継続的に高遅延または低帯域が発生する場合は、同じ地域の他の回線に切り替えてみてください。クライアントに内蔵された自動回線選択機能も、接続品質が低下したときにユーザーに切り替えを促します。

使用シーンに応じたプロトコルと回線の選び方

最後に、プロトコルとトポロジの議論を具体的なシーンに落とし込みます。用途によってネットワーク特性の重視点が異なるため、選定時には最も中核的なニーズを優先的に満たすべきです。

上記の表の推奨は絶対ではありません。実際の使用では、具体的な回線のリアルタイム状態を組み合わせる必要があります。例えば、直結回線が夜間ピーク時に中継回線より遅い場合があります。その場合は一時的に中継回線に切り替えるべきです。NZVPNクライアントはプロトコルと回線タイプによるフィルタリングに対応しており、ユーザーはその時のネットワーク状況に応じて柔軟に調整できます。

ほとんどのユーザーにとって、実用的な戦略は、デフォルトでVLESS + 中継回線を使用することです。この組み合わせは安定性と速度の間で良いバランスを取れています。特定の回線で夜間ピーク時に速度が顕著に低下する場合は、Hysteria2または専用線回線に切り替えてください。デバイスのバッテリー残量が心配な場合は、Shadowsocksに切り替えて電力を節約してください。

サブスクリプションプランについて、頻繁に4Kストリーミングを見る場合やAIツールを使用する場合は、250GBまたは500GBの月額プランを選択することをお勧めします。通信量がより豊富です。日常のブラウジングだけなら、60GBのベーシックプランで十分です。データパックは使用量の変動が大きいユーザーに適しており、購入後は無期限で、必要に応じて追加できます。

最後に、どのプロトコルと回線を選択しても、30日間の理由不要返金が試行錯誤の余地を提供します。まず1か月契約して、実際のネットワーク環境でさまざまな回線の性能をテストし、その後どのプランを長期的に使用するかを決定できます。