プロトコルと回線の選定リファレンス

6 種類のプロトコルの設計判断

プロキシプロトコルが解くべき課題は 3 つに分解できます。トラフィックを通過可能な 1 本のコネクションにカプセル化すること、両端の間で暗号化と完全性検証を完了させること、経路上の中間装置がバイト列から内容を判別できないようにすることです。6 種類の主要プロトコルはこの 3 点でそれぞれ異なるトレードオフを選んでおり、その結果はハンドシェイクの回数、CPU 負荷、パケットロス耐性、モバイルのバッテリー消費にそのまま現れます。この章では設計方針ごとに順に説明します。順位付けはしません。回線を切り離して優劣を語っても意味がないからです。

Shadowsocks:最も薄いカプセル化

Shadowsocks の設計目標はとても控えめです。暗号化された TCP または UDP のコネクションでトラフィックを出口まで運び、追加の偽装層を重ねません。暗号化には AEAD スイートを使い、代表的なのは AES-128-GCM、AES-256-GCM、ChaCha20-Poly1305 です。これらのモードは暗号化と完全性検証を 1 ステップに統合するため、暗号化したうえで別途チェックサムを計算する往復が不要になります。TLS を内蔵しないため、ハンドシェイクのコストは 6 種類の中で最も低い部類に入り、遅延に敏感な用途では直接的な利点になります。代償は、トラフィックの特徴が外側の包み方に完全に依存することです。そのまま流す場合、高エントロピーなバイト列の TCP ストリームになり、経路上でディープパケットインスペクションを行う装置に見つかる可能性があります。実際の運用では、Shadowsocks を TLS トンネルに入れるか、他のトランスポート層と組み合わせるのが一般的です。

VMess:識別子と時刻の検証を伴うカプセル化

VMess はプロトコルのヘッダーにユーザー識別子とタイムスタンプを載せ、サーバー側はこの 2 つで本人確認を行います。ここに落とし穴があります。クライアントとノードの時刻がほぼ一致していないとハンドシェイクがそのまま拒否され、設定を 1 項目ずつ照合しても間違いがないのにつながらない、という症状になります。VMess のヘッダーは複数のバージョンを経ており、AEAD 版ではヘッダーも完全性保護の対象にして、途中でヘッダーフィールドが改ざんされるのを防ぎます。オーバーヘッドは Shadowsocks よりやや大きくなりますが、その代わりにマルチユーザーモデルが明確になり、ヘッダーフィールドも細かく分かれます。1 台のノードで複数の購読者を区別する用途に向いています。

Trojan:トラフィックを標準 TLS に載せる

Trojan の発想は、プロキシのトラフィックを標準の TLS コネクションに載せることです。まず完全に普通に見える TLS ハンドシェイクを済ませ、サーバーはハンドシェイクが終わってからパスワードを検証します。経路上の中間装置から見ると、それはごく普通の HTTPS セッションであり、接続先のドメイン、証明書チェーン、ハンドシェイクの順序は通常のアクセスと変わりません。パスワードが一致しない場合、サーバーはそのコネクションを実在の Web サービスへ転送し、探索してきた相手に正常な Web ページの応答を返せます。互換性の高さが利点で、代償は TLS の層が増えること、ハンドシェイクが 1 往復増えること、CPU が対称暗号の処理をもう 1 回行うことです。

VLESS:重複した層を取り除く

VLESS の方針は、やるべきことだけをやるというものです。プロトコル自体は暗号化せず、暗号化は完全に外側の TLS に任せることで、TLS の中にもう 1 層暗号化を重ねる無駄を避けます。XTLS 系のフロー制御と組み合わせれば、内側と外側で同じ暗号化を二重に実行せずに済み、CPU 負荷がはっきり下がります。VLESS はステートレスなので、サーバーはユーザーごとにセッションテーブルを保持する必要がなく、ノードの水平スケールが容易です。安定した TLS チャネルがすでにあり、スループットと CPU 効率を最大まで引き上げたい場面に向いています。逆に言えば、外側の TLS 設定が不適切な場合、VLESS 自体には追加の暗号化による保険がありません。

Hysteria2:QUIC 上で輻輳制御を変える

Hysteria2 は QUIC 上で動作し、つまり UDP を使います。最も実用的な違いは輻輳制御にあります。BBR 系のアルゴリズムを選べるため、パケットロス率が高い回線でも高いスループットを維持できます。従来の TCP 輻輳制御のように、ロスが出た途端にウィンドウを大きく縮めることはありません。代償もはっきりしています。UDP のトラフィックは一部のネットワークで速度制限や優先度低下の対象になります。QUIC はユーザー空間の実装なので、パケットごとにユーザー空間へのコピーとタイマー処理が発生し、CPU 負荷はカーネル TCP より高くなります。モバイルで長時間使うとバッテリー消費も増えます。

TUIC:QUIC 上の多重化と 0-RTT

TUIC も QUIC をベースにしており、多重化と高速な復帰に重点を置いています。1 本の QUIC コネクション上で複数の論理ストリームを並行して運べ、セッションを確立したことのあるクライアントは再接続時に 0-RTT を使えるため、1 往復を省略できます。トレードオフは Hysteria2 に近く、UDP の経路が使えるかどうかが体験の上限を直接決めます。UDP がスムーズなネットワークでは TUIC の初回パケット時間は非常に優秀です。逆に UDP が制限されているネットワークでは、安定した TCP 回線に劣ります。

結論はシンプルです。回線品質が良くオーバーヘッドを抑えたいなら Shadowsocks と VLESS が適しています。互換性と偽装が必要なら Trojan が安定します。回線のパケットロスが深刻なら、Hysteria2 と TUIC の輻輳制御がスループットを取り戻します。モバイルで長時間つなぎっぱなしにするなら、カーネル空間で動く TCP 系プロトコルのほうがバッテリーに優しいです。VPNLW の 230+ 回線には地域ごとに利用可能なプロトコルが表示されており、サブスクリプションを読み込めばクライアントが回線に応じたプロトコルの組み合わせを適用します。設定を手作業で組み立てる必要はありません。

クリックから初回パケットまで:ハンドシェイクでは何が起きるか

ユーザーが体感する速さは 2 つの異なる量で決まります。1 つは初回パケット時間、つまりリンクを開いてから最初の 1 バイトを受け取るまでの間隔です。もう 1 つは持続スループット、つまり転送が始まってからの速度です。初回パケット時間は往復の回数で決まり、スループットは帯域と輻輳制御で決まります。この 2 つはよく混同され、そのせいで切り分けの方向を誤ります。ハンドシェイクが遅いだけなのに、大容量の回線に替え続けてしまうわけです。

1 回のリクエストに何回のラウンドトリップが必要か

Web ページへの 1 回のリクエストを分解すると、おおむね次の手順になります。1 つ目は名前解決です。ローカルキャッシュに記録がなければ、DNS に問い合わせるために 1 回以上の往復が必要になります。プロキシモードでは解決をリモート側に任せる場合があり、その場合はローカルからノードまでの区間にネゴシエーションが 1 回増えます。2 つ目はノードまでのトランスポートハンドシェイクで、TCP は 1 往復を要します。3 つ目は TLS ハンドシェイクです。TLS 1.3 はフルハンドシェイクで 1 往復、セッション復元なら 0-RTT が可能です。4 つ目はプロキシプロトコル自身のネゴシエーションです。VLESS と Trojan は追加の往復がほぼなく、VMess は識別子と時刻の検証が必要で、QUIC 系は 1 往復または 0-RTT です。5 つ目はノードから目的サイトまでで、この区間は収容先のデータセンターから目標までの物理距離と経路品質に左右されます。6 つ目でようやくデータが戻ってきます。

これらの区間を足し合わせると、よくある現象の説明がつきます。あるサイトを初めて開くと明らかに遅く、2 回目は速い、というものです。理由は回線が良くなったからではなく、コネクションプールと TLS セッションチケットが再利用され、2 回目以降はハンドシェイクが省略されるからです。

0-RTT が省くもの、その代償はどこにあるか

TLS 1.3 のセッション復元では、クライアントは最初のフライトにアプリケーションデータを載せられます。これが 0-RTT です。QUIC もこの仕組みを引き継いでいます。省略できるのは 1 往復分で、大洋をまたぐ回線では初回パケット時間をまとめて削れることになります。代償はリプレイのリスクです。経路上の攻撃者がこの 0-RTT データを傍受して再送できるため、プロトコル仕様は冪等なリクエストに限って使うことを推奨しています。クライアントが実際に 0-RTT を使うかどうかは実装とローカルキャッシュの状態次第で、必ず起きることではありません。「なぜ速いときと遅いときがあるのか」を調べるときに、覚えておく価値のある点です。

コネクション再利用とヘッドオブラインブロッキング

多重化は複数のリクエストを 1 本のコネクションに詰め込み、ハンドシェイクの繰り返しを省きます。TCP では 1 本のコネクション内のデータ順序が厳密に保たれるため、前のパケットが 1 つ失われると後続のすべてのストリームがその再送を待ちます。これがヘッドオブラインブロッキングです。QUIC はトランスポート層でストリームを分離しているので、1 本のストリームのロスが他のストリームに影響しません。代償は、ストリームごとに状態を保持する必要があり、メモリとスケジューリングの負荷が高くなることです。多重化を有効にするかは用途次第です。リクエストが集中し、コネクション数が制限される場面では効果がはっきり出ます。単一の大容量転送では、他のストリームとウィンドウを奪い合わないぶん、無効にしたほうが安定します。

初回パケット時間を自分で測る方法

ブラウザの開発者ツールのネットワークパネルでは、各リクエストのキュー待ち、DNS、接続、TLS、初回バイトといった段階ごとの所要時間をそのまま確認できます。コマンドラインでは curl の段階別タイミングを使います。

curl -o /dev/null -s -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer}\n' https://example.com/

このコマンドを接続確立の前後で 1 回ずつ実行すれば、その差分がハンドシェイクのコストです。例示したドメインは書き方の説明用です。実際のサブスクリプション URL をオンラインツールや公開されるスクリーンショットに貼らないでください。

この表を理解すると、「回線が遅い」という判断がずっと精密になります。初回だけ遅いなら問題はハンドシェイクと名前解決にあります。毎回開くたびに遅いなら往復回数の問題です。初回パケットは速いのに転送が遅いなら、帯域と輻輳制御の問題です。3 つのケースでは対処法がまったく異なります。

CPU、メモリとモバイルのバッテリー

プロトコルの選択は、デスクトップでは主に速度に影響し、モバイルでは電池持ちにも影響します。バッテリーは抽象的な指標ではなく、CPU の起床回数、無線モジュールの稼働時間、メモリの確保と解放の頻度によって決まります。同じサブスクリプションでも、ノート PC では差が分からず、スマートフォンでは 1 時間と 3 時間ほどの違いになることがあります。

暗号スイートのハードウェアアクセラレーション

AES-GCM は、AES-NI に対応した x86 プロセッサや ARMv8 の暗号拡張を備えたモバイルチップではハードウェア命令として実行され、1 バイトあたりのコストはごくわずかです。ChaCha20-Poly1305 はソフトウェア実装で速くなる方式で、ハードウェア支援のない古い端末ではむしろ有利になります。多くのクライアントは CPU の能力に応じて自動で選びますが、手動指定が必要なものもあります。古い Android 端末で暗号スイートを AES から ChaCha20 に変えると、発熱とバッテリーの減りがはっきり改善することがあります。コストの低いわりに見落とされがちな調整です。

ユーザー空間とカーネル空間の違い

TCP は OS のカーネルが処理するため、パケットはネットワークカードからアプリまで必要最小限のコピーしか通りません。QUIC はユーザー空間の実装なので、パケットごとにシステムコール、ユーザー空間へのコピー、タイマー確認が 1 回ずつ発生します。デスクトップのプロセッサでは無視できる負荷ですが、モバイルのプロセッサではそのままバッテリー消費と発熱に変わります。Hysteria2 と TUIC をスマートフォンで長時間使うと、電池持ちが TCP 系プロトコルに劣りがちなのはこのためです。QUIC 系が劣っているのではなく、利点がパケットロスのある回線にあり、代償がバッテリーにあるということで、用途に応じて天秤にかける必要があります。

ハートビートとキープアライブ

NAT 装置はアイドル状態のマッピングを回収するため、クライアントは経路を維持するために定期的なハートビートを送る必要があります。ハートビートの間隔が短いほど切断の確率は下がりますが、無線モジュールが起きる回数は増えます。モバイルでは間隔を長めにして OS 側のキープアライブと組み合わせるのが合理的で、デスクトップでは短めに保って復帰の速さを取るのがよいでしょう。「画面ロックから戻るたびに再接続になる」場合は、慌ててノードを変える前にハートビート間隔を確認してください。

バックグラウンド維持と省電力ポリシー

iOS はバックグラウンドのネットワーク権限に厳しく、アプリはバックグラウンドに入ってしばらくすると停止され、プロキシも切れます。Android の省電力ポリシーはバックグラウンドアプリのネットワークアクセスを制限し、画面ロックから数分でメッセージが届かなくなる、といった症状がよく起きます。対処はクライアントを OS の省電力ホワイトリストに追加し、バックグラウンド動作を許可することです。これは任意の手順ではなく、モバイルで長く使うための前提条件です。具体的な操作手順は Android 関連のチュートリアル記事で画面ごとに説明しています。

アプリ別プロキシが最も直接的なバッテリー最適化

必要なアプリだけをプロキシ経由にすると、3 つのものを同時に減らせます。総通信量、暗号化と復号の回数、無線モジュールの稼働時間です。OS のアップデート、アプリストアのダウンロード、LAN 内のバックアップといった通信は、海外ノードを経由する必要がまったくありません。多くのクライアントはアプリ単位のチェックに対応しており、一度設定すれば長く効果が続きます。通信量に上限のあるプランなら、これだけでかなりの量を節約できます。

これらの項目を調整すると、モバイルでの体感改善は回線を替えるより大きいことがよくあります。上限を決めるのは回線で、実際の消費を決めるのは設定です。

直結・中継と専用線

1 本の回線は 3 つの区間に分けられます。ユーザーから入口までのアクセス区間、入口から収容先までの越境区間、収容先から目的までのラストワン区間です。このうちサービス提供者が主体的に最適化できるのは越境区間だけで、回線タイプの違いも主にこの区間に現れます。これを理解すれば、同じ都市にある 2 本の回線で遅延はほぼ同じなのに、夜間ピークの挙動はまったく違う、という理由も分かります。

直結:経路は最短だが品質は最も読めない

直結とは、ノードのデータセンターが海外にそのまま置かれ、ユーザーのトラフィックが国際出口から直接データセンターへ向かう方式です。経路が短く余分なホップがないため、回線品質が良ければ遅延は最小になります。欠点もはっきりしています。越境区間を同じ出口を使うすべてのユーザーと共有するため、夜間ピークの混雑は避けられません。直結回線は予備として、あるいは遅延に極端に敏感で変動も許容できる用途に向いています。直結だけを選ぶのは、体験を他人の出口帯域に預けるのと同じです。

中継:制御できない区間を制御できる区間に置き換える

中継はユーザーに近い場所、たとえば香港や日本に入口を置き、ユーザーはいったん入口に接続し、そこから最適化された経路で収容先へ転送されます。中継の価値は物理距離を縮めることではなく、全員で国際出口に殺到する状況を、スケジューリングされたバックボーン経路に置き換えることにあります。入口ノードは一元的な制御もできます。ある収容回線が混雑したら、トラフィックを別の回線へ切り替えられます。代償はホップが 1 つ増えることで、基礎遅延は直結よりやや高くなりますが、ジッターはたいてい小さく、夜間ピークの落ち込みも緩やかです。

専用線:コストで確実性を買う

IEPL のような専用線は通信事業者が提供し、帯域と経路について明確なサービスレベル契約があり、公衆網のトラフィックと同じキューを奪い合いません。その結果、遅延は安定し、パケットロスは少なく、夜間ピークの影響も目立ちません。コストは 3 つの中で最も高いため、通常は一部の回線にのみ用意されます。ある回線が専用線かどうかは、名称の表記で判断できますし、traceroute で越境区間のホップ数と経由するネットワークを観察する方法もあります。ホップが少なく経路が安定し、越境区間が少数のネットワークにまとまっていれば、最適化された経路である可能性が高いです。

遅延とジッターは別の指標

平均遅延が低いことは、体験が良いことを意味しません。ビデオ会議で怖いのはジッター、つまり遅延の変動です。大容量ファイルの転送で怖いのはパケットロスで、ロスが起きると輻輳制御がウィンドウを縮めます。専用線がこの 2 つの指標で発揮する優位性は、平均遅延の優位性よりはっきりしています。「専用線に変えても数値はほとんど下がらなかったのに、会議が固まらなくなった」という声の多くは、ジッターの話です。

選び方は単純です。日常の閲覧と動画は中継で十分です。会議やリアルタイム共同作業など、途切れが一切許されない用途は専用線を使います。直結は予備と軽い用途に残しておきます。VPNLW の回線一覧には地域ごとに回線タイプが表示されているので、ノードページで地域を絞り込んで 1 本ずつ照合できます。

遅延、パケットロスと夜間ピーク

この章では、もっともよく起きる 3 つのことを説明します。遅延が高くなる理由、パケットロスが起きる理由、夜だけ極端に遅くなる理由です。原因を理解すれば、「回線が壊れたのか」という疑問のほとんどは自分で判断でき、毎回サポートに連絡する必要はなくなります。

遅延は 4 つの要素で構成される

1 つ目は伝搬遅延で、信号が媒体を伝わる時間であり、物理距離で決まり最適化できません。2 つ目は伝送遅延で、データをリンクに押し出す時間であり、帯域とパケットサイズで決まります。3 つ目は待ち行列遅延で、データがルーターのキューで待つ時間であり、混雑時には急激に増えます。4 つ目は処理遅延で、機器の転送、暗号化と復号、プロトコルスタックの処理にかかる時間です。4 つのうち最適化の余地があるのは待ち行列遅延と処理遅延だけです。物理距離が決める下限は突破できません。だからこそ遠回りのほうが速いことがあります。混雑したノードを避ける経路なら、直線経路より合計時間が短くなり得るからです。

パケットロスはどこから来るのか

パケットロスの主な発生源は 4 種類あります。1 つ目はキューの溢れで、経路上のどこか 1 ホップのバッファが埋まると、後から来たパケットはそのまま捨てられます。2 つ目は無線の干渉で、Wi-Fi やモバイル回線は干渉の多い環境でランダムなロスが発生します。3 つ目は機器側の速度制限とポリシーで、特定の種類のトラフィックを制限し、超過分を捨てるネットワークがあります。4 つ目は MTU の不一致で、転送時にパケットが分割され、分割片が失われるとパケット全体の再送になります。4 つの対処はそれぞれ異なります。キューの溢れは回線を変える、無線の干渉は接続方法を変える、速度制限はポートかプロトコルを変える、MTU の問題はクライアントの MTU 設定を調整する、という具合です。

輻輳制御がパケットロスのコストを決める

従来の TCP 輻輳制御はパケットロスを混雑の信号とみなし、ロスを検出すると輻輳ウィンドウを大きく縮め、スループットが落ち込みます。BBR は発想を変えました。回線の帯域と最小ラウンドトリップ時間を継続的に推定し、その推定値に従って送信するため、ロスが必ずしも速度低下につながりません。Hysteria2 がパケットロスのある回線で良い結果を出す根本的な理由はここにあります。速いからではなく、ロスへの反応が違うのです。これを理解すれば、「同じノードなのにプロトコルを変えるとここまで速度が違うのはなぜか」で悩むことはなくなります。

夜のピーク時間帯に遅くなる理由

国際出口の帯域は共有資源です。夜間は利用のピークで、出口リンクが埋まるとキューが長くなり、待ち行列遅延が増え、やがてキューがあふれてパケットロスが始まります。症状は、遅延が平常時より上がる、ロス率が上がる、スループットが下がる、しかも同じ時間帯の中でも変動が大きい、というものです。専用線と最適化された中継の価値が最もはっきり出るのはこの時間帯です。それらは同じ出口の公衆網トラフィックと同じキューを奪い合いません。夜だけ遅く昼は正常なら、ローカルネットワークやクライアントではなく、共有出口の混雑だとほぼ判断できます。

自己計測の限界

ping は ICMP を使い、TCP と同じキューを通るとは限らないため、ping の値が低くてもプロキシが速いとは言えません。速度測定ツールが測るのは瞬間的なスループットで、安定性を見るには連続してサンプリングする必要があります。妥当な観察方法は、同じ時間帯に複数回サンプリングしてジッターとロス率を見ることで、単発のピーク値に注目しないことです。測定先の帯域自体がボトルネックになることもあるので、収容先に近い測定ターゲットを選んでこそ結果に参考価値が出ます。

この 5 つの状況を覚えておけば、ほとんどの問題はサポートに連絡する前にどの層の問題か特定できます。

用途別のプロトコル選定

選定には決まった判断順序があります。まず回線、次にプロトコル、最後にクライアントの設定です。回線が物理的な上限を決め、プロトコルが同じ回線での効率を決め、クライアント設定が細かな体験を決めます。順序を逆にすると、プロトコルを何度も変えても改善しないループにはまります。ボトルネックがプロトコル側にないからです。

判断の順序

まず、その用途がジッターに敏感かどうかを考えます。会議、リアルタイム共同作業、ゲームがこれに当たり、専用線を優先します。次に回線のパケットロス状況を見ます。ランダムなロスが常態化しているなら、QUIC 系プロトコルの輻輳制御がスループットを取り戻せます。3 つ目に端末の種類とバッテリーの制約を見ます。スマートフォンで長時間つなぎっぱなしにするなら TCP 系を優先します。4 つ目に UDP 転送が必要かどうかを見ます。UDP に依存するアプリもあり、その場合はクライアントと回線の両方が対応している必要があります。

4K ストリーミング

4K ストリーミングは持続帯域の要求が 1080p より明らかに高く、ビットレートは通常 2 桁の Mbps に達し、しかも安定性が求められます。バッファが枯渇すれば即座に読み込み表示になります。選定の要点はピーク値ではなく、持続スループットと回線の安定性です。TCP 系プロトコルと中継または専用線の組み合わせは、UDP 上でピークを狙うより安定するのが普通です。利用しているネットワークが UDP を制限している場合、QUIC 系プロトコルはかえって足を引っ張ります。地域ごとの配信ライブラリと出口地域の関係については、ストリーミング特集の記事でより具体的に対照を示しています。

ビデオ会議

会議は遅延とジッターに敏感で、帯域の要求は高くありません。専用線か最適化された中継を第一候補にし、プロトコルは TCP 系で十分です。会議中にノードを切り替えないでください。切り替えは数秒の中断を生み、会議ではその数秒で発言が途切れてしまいます。会議アプリ自体が UDP を使う場合は、クライアントが UDP のトラフィックを捨てていないか確認してください。捨てていると、音声は聞こえるのに画面共有が見えない、という状態になります。

大容量ファイルとバックアップ

帯域が広く遅延の大きい回線では、輻輳制御の影響が増幅されます。BBR 系のアルゴリズムはパイプを埋め尽くせるため、Hysteria2 はこうした場面で優位に立ちます。注意したいのは通信量の消費です。完全バックアップ 1 回で月額プランの枠の大半を使うこともあります。こうした突発的な使用には通信量パックが向いており、使い切るまで有効で期限はありません。1 か月のピークのために月額プランを上位に上げる必要はありません。

モバイルで長時間つなぎっぱなしにする場合

バッテリーを優先します。TCP 系プロトコルを選び、ハートビート間隔を長めにし、アプリ別プロキシを有効にします。スマートフォンで QUIC 系プロトコルを長時間動かして大容量ダウンロードをするのは避けてください。発熱と消費電力がはっきり増えます。メッセージの受信や Web 閲覧だけなら、プロトコルの違いはほとんど体感できません。最も省電力な組み合わせを選べば十分です。

AI ツールと長いコネクション

AI ツールの応答はストリーミングで、1 回の会話で数十秒のコネクションが維持されることがあります。こうした用途は帯域の要求が低い代わりに安定性が重要で、接続が切れると回答全体が無駄になります。低遅延を狙うより、安定した回線と TCP 系プロトコルを選ぶほうが現実的です。回答が途中で止まる頻度が高い場合は、プロトコルを変える前に回線のジッターを疑ってください。関連する切り分けの考え方はヘルプセンターに細かい項目があります。

リアルタイム対戦ゲーム

物理距離は動かせない制約で、プロトコルでできる最適化には限りがあります。UDP 転送が必要で、回線のジッターも小さい必要があります。大陸をまたぐ対戦の遅延の下限は光速で決まり、どのプロトコルでも突破できません。期待値を正しい位置に置くほうが、ノードを何度も変えるより役に立ちます。

プランと用途の対応にも触れておきます。月額プラン ¥9.9 は 60GB 付きで、軽い閲覧やメッセージ中心の利用に向いています。¥18 は 250GB 付きで、日常のストリーミングと仕事をカバーします。¥28 は 500GB 付きで、長時間の視聴や複数端末の同時利用に適しています。通信量は開通日を基準に毎月リセットされ、途中でアップグレードした場合は差額が残り日数で按分されます。突発的な大容量には通信量パックが割安です。¥158 が 300GB、¥358 が 1000GB、¥658 が 3000GB に対応し、使い切るまで有効で期限はありません。

プラットフォーム対応とサブスク導入

プロトコルと回線を決めたら、最後の区間はクライアント側です。同じサブスクリプションでもプラットフォームによって挙動が変わることがあり、その差は主にカーネルが対応しているプロトコルの範囲、バックグラウンド維持の方式、プロキシの引き継ぎ方から来ています。この 3 点の違いを押さえておけば、「同じノードが PC では問題ないのにスマートフォンではだめ」という混乱の多くを避けられます。

5 つのプラットフォームの違い

Windows にはシステムプロキシと TUN の 2 つのモードがあり、システムプロキシは OS の設定に従うアプリにしか効きませんが、TUN はシステムプロキシに従わないプログラムも引き継げます。macOS の権限モデルはより厳格で、初めて TUN を有効にするには承認とネットワーク拡張のインストールが必要です。iOS はバックグラウンドの制限が最も厳しく、手順に従って構成を追加する必要があり、アプリ別プロキシの機能は限られます。Android はアプリ別プロキシに対応しますが、省電力ポリシーは手動で許可する必要があります。Linux にはコマンドラインのクライアントと GUI のクライアントの両方があり、ルーター層でプロキシを動かして LAN 全体で 1 つの出口を共有する使い方に向いています。

サブスクリプション読み込みの 4 ステップ

まずユーザーパネルにログインし、サブスクリプションのページを開きます。次にサブスクリプションのリンクをコピーします。続いてクライアントでクリップボードから読み込むか、リンクを直接貼り付けます。初回の読み込み後に手動で 1 回更新し、ノード一覧が更新されたことを確認します。4 つの手順が終わったら回線を 1 本選んで接続し、出口アドレスを表示する任意のページで、出口の地域が選んだ回線と一致していることを確認してください。

https://example.com/sub?token=YOUR_TOKEN

上に示したのは形式の例で、実際のリンクはログイン後のパネルで取得します。サブスクリプションのリンクは認証情報と同じで、入手した人はあなたの通信量の枠を使えます。公開フォーラムやスクリーンショットに貼らないでください。漏えいが疑われる場合は、パネルでサブスクリプションをリセットすれば古いリンクは無効になります。

サブスクリプションを更新するタイミング

ノードの調整、プロトコルの変更、プランの更新のあとは、クライアント側でサブスクリプションを手動で 1 回更新してください。一部のクライアントは定期的な自動更新に対応しており、間隔は数時間程度がおすすめです。頻繁すぎる取得は意味がなく、切り替え時にノード一覧が一時的に使えなくなることもあります。

台数無制限と帯域の分け合い

VPNLW のサブスクリプションは台数の制限がなく、同じアカウントを Windows、macOS、iOS、Android、Linux で同時に使えます。注意したいのは、1 本の回線の帯域は共有だという点です。同時に複数の端末で大容量の通信をすると、1 台あたりの実効帯域は下がります。家庭で使う場合は、ダウンロードをピーク時間帯以外に置くと体験が良くなります。「台数無制限」と「帯域無制限」が別物である理由でもあります。前者はライセンスで、後者は物理的な資源です。

クライアントの入手口はユーザーパネルの中にあり、ログイン後にプラットフォーム別にダウンロードできます。サブスクリプションもクライアントもパネル内にまとめてあり、紹介ページに固定のインストーラーは置いていません。こうすることでバージョンとアカウントの状態を一致させています。

段階的な切り分けと検証

切り分けで最も避けたいのは、いきなりノードを変えることです。接続は層を積み上げて確立されるため、どの層で問題が起きても「つながらない」という同じ見え方になります。層ごとに潰していくほうが、試行錯誤を繰り返すよりずっと速いです。この章では、そのまま実行できる手順と、各段階の検証コマンドを示します。

6 層モデル

1 層目は接続層です。端末がネットワークにつながっているか、Wi-Fi は正常か、キャプティブポータルに遮られていないかを見ます。2 層目は名前解決です。ドメインが正しいアドレスに解決されるか、ローカル DNS で書き換えられていないかを見ます。3 層目はトランスポートハンドシェイクです。ノードと TCP または UDP のコネクションを確立できるかを見ます。4 層目はプロトコルのネゴシエーションです。本人確認が通るか、時刻が同期しているかを見ます。5 層目は振り分けルールです。その通信がルールで許可されているかを見ます。6 層目はアプリケーション層です。目的のサービス自体が利用可能かを見ます。

各層の検証方法

接続層は ping でゲートウェイを叩いてローカル経路を確認します。名前解決は nslookup で公共のリゾルバを指定して比較します。トランスポートハンドシェイクは curl の詳細出力で、接続が確立したか、TLS が完了したかを見ます。プロトコルのネゴシエーションはクライアントのログでハンドシェイクの結果を確認します。失敗時は通常、明確なエラーコードが出ます。振り分けルールはグローバルモードと比較します。アプリケーション層は別の目的サイトで試し、目的サービス側の障害を除外します。

ping -c 4 192.168.1.1
nslookup example.com 1.1.1.1
curl -v --max-time 10 https://example.com/
traceroute example.com

この 4 つのコマンドで最初の 3 層をカバーできます。例示したアドレスは一般的な書き方なので、ゲートウェイは自分のネットワークの実際のアドレスに置き換えてください。

振り分けルールによる見かけの故障

ルールモードでは、一部のドメインは直結、一部はプロキシ経由になります。あるアプリだけ開けず他は正常な場合、まずグローバルモードに切り替えて比較します。グローバルで正常ならルールの問題、グローバルでも同じなら回線かプロトコルの問題です。この比較だけで調査範囲が一度に半分になり、最も時間を節約できる手順です。ルールの問題は、自作ルールの書き間違い、ドメイン接尾辞のマッチが広すぎる、ルールセットが更新されていない、といった原因が一般的です。

時刻同期が重要な理由

VMess などのプロトコルはタイムスタンプを検証に使うため、システム時刻のずれが大きいとハンドシェイクが拒否されます。症状は、設定は正しく、ノードも稼働しているのに、つながらないというものです。端末の自動時刻同期が有効か確認してください。長時間スリープしていたノート PC や古い端末で最も起きやすい問題です。

サポートに連絡すべきタイミング

層ごとに検証しても特定できない場合に、サポートへ連絡してください。その際は、プラットフォームとクライアント、使用した回線、問題が起きた時間帯、実施済みの検証手順とその結果を書き添えます。情報が揃った依頼は処理が明らかに速くなります。基本情報の確認でやり取りが発生しないからです。特定の時間帯だけ問題が出る場合は、具体的な時刻を書いておくと回線側の記録と照合しやすくなります。

用語とパラメータ早見表

この章では、ここまでに登場した用語をまとめて一覧にし、あわせてサービス自体の仕様も掲載します。用語は五十音順とアルファベット順を混ぜて並べており、厳密な分類はしていません。

用語一覧

プランと通信量パック

サービス仕様

カバレッジ:120+ か国 / 230+ 回線。デバイス:台数無制限。対応プラットフォーム:Windows / macOS / iOS / Android / Linux。支払い方法:Alipay / WeChat Pay / USDT。返金:7 日間返金保証。登録:メールアドレス不要、ユーザー名とパスワードだけで登録できます。暗号化は軍事グレードの暗号化を採用。

続きを読む

手順どおりに最初の設定を済ませたい場合はクイックスタートガイド、プランと通信量パックを比べたい場合はプランと料金、地域別に回線を選びたい場合は世界の回線一覧、よくある質問はヘルプセンターにまとまっています。続けて読める関連記事は 3 本です。初心者向け用語早見表、地域別ライブラリと 4K 帯域の実測比較、Android のバックグラウンド維持とアプリ別プロキシです。