01 · レイヤー
まず問題を4層に戻して考える
同じ「回線が調子悪い」という一言でも、指している場所は4つまったく異なります。それらを分けておけば、後の判断が食い違いません。このページは選定の順序に沿って構成した技術リファレンスです。まず経路、次にプロトコル、最後にデバイスとクライアントを見ます。初めて使う場合は使い方ガイドのメイン手順でクライアントを導入し、接続まで済ませてください。「なぜこの構成を選ぶのか」「なぜ速いときと遅いときがあるのか」と感じたら、またここに戻って参照してください。
4つの層がそれぞれ担うもの
物理・ルーティング層は、データがローカルから出口までどの都市、どの通信事業者を通り、どの相互接続点でつながるかを決めます。レイテンシの下限を決め、夜間ピークにどこで最も渋滞しやすいかも決まります。クライアントやプロトコルを変えても、この層の経路は変わりません。
トランスポート層は TCP か QUIC(UDP)、そしてその背後の輻輳制御です。パケットロス後にどう補うか、ウィンドウをどう増やすか、複数のリクエストが1本の接続をどう共有するかを決めます。体感の「急に速くなったり遅くなったり」の多くはこの層に由来します。
プロキシプロトコル層は Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC といった名前の部分です。認証方式、外側に TLS をかぶせるか、多重化するか、追加ヘッダーがどれだけあるかを決めます。プロトコルは物理経路を変えませんが、ハンドシェイクの回数、再送の方針、CPU コストは変わります。
クライアント・デバイス層には OS のバージョン、権限、Wi-Fi の電波状況、ルーターの NAT テーブル、省電力設定、DNS 設定、MTU が含まれます。この層は最も見落とされがちです。別のデバイスに替えると、前の設定はまったく同じに見えるのに挙動が違うからです。
紛らわしい用語
ノードは接続可能なサーバーまたは入口です。入口はクライアントが最初に接続するアドレス、出口は目的のサイトにアクセスしたときに相手側に見えるアドレス、ランディングは出口の所在する地域を指します。回線は入口から出口までの経路の組み合わせで、直結の場合もあれば中継や専用線を経由する場合もあります。プロトコルはクライアントから入口までの区間の通信方式だけを定めるもので、入口より先がどう進むかは回線が決めます。
| 見えている症状 | 疑わしい層 | まずやること |
|---|---|---|
| すべてのサイトが遅く、夜間ピークに顕著 | 物理・ルーティング層、トランスポート層 | 回線タイプを変えて、時間帯を記録する |
| 特定のサイトだけ遅い、または開けない | 接続先サイト、出口地域 | 出口地域を変える。まずプロトコルは触らない |
| 同じ回線で PC は正常、スマホだけ異常 | クライアント・デバイス層 | 省電力、権限、Wi-Fi、システムプロキシを確認する |
| プロトコルを変えたらすぐ悪化した | プロトコル層、トランスポート層 | 元のプロトコルに戻す。変数は一度に1つだけ |
この表は切り分けの入口であって、実測の代わりにはなりません。変数は一度に1つだけ変えてください。そうしないと、どの項目が効いたのか判断できません。
まず層を決め、次に原因を決めます。すべてのデバイス、すべてのプロトコルが同じ時間帯に遅くなるなら、ローカルネットワークか国際区間の輻輳を先に疑ってください。特定の1台、特定の1アプリだけがおかしいなら、クライアント・デバイス層を先に調べます。「回線」だけを唯一の説明にすると、問題の半分を見落とします。
02 · プロトコル
6つのプロトコルの設計上のトレードオフ
プロトコルはブランドではなく、新しいほど優れているものでもありません。認証、暗号化、転送、多重化に関する取り決めの集まりです。以下では設計上のトレードオフを説明し、設定コードは載せません。クライアントごとにオプション名は異なる場合がありますが、判断の論理は同じです。
軽量フォワード型:Shadowsocks と VLESS
Shadowsocks の核心はシンプルさです。事前共有鍵による AEAD 暗号化で、TCP と UDP のリクエストを出口へ転送します。多重化は内蔵しておらず、ネイティブの TLS 偽装もありませんが、オーバーヘッドが小さく実装も成熟しており、ルーターや古いデバイス、安定した転送だけが必要な場面に向きます。代償として外側の特徴が目立たず、プラグインや中継で補う必要があります。UDP 転送が使えるかどうかは、サーバーとクライアントの実装次第です。
VLESS はどちらかというと軽量な転送キャリアです。自身は暗号化を担わず、セキュリティ境界を外側の TLS や REALITY に委ねます。プロトコルヘッダーが小さく状態も少ないため、XTLS 系のフロー制御と組み合わせると二重暗号化を減らせます。高スループットと低 CPU が利点で、長時間の大容量通信に向きます。ただし前提は外側の設定が正しいことです。外側に信頼できる TLS がなければ、VLESS が自動的に暗号化を提供するわけではありません。
TLS 偽装型:Trojan と VMess
Trojan は認証を TLS 接続の中に入れ込むため、外から見ると普通の HTTPS アクセスに見えます。強度は証明書、TLS バージョン、サーバー設定で決まり、プロトコル名そのものでは決まりません。ドメインと証明書があり、一般サイトと入口を共用したい場面に向きます。設定を誤ると、軽量プロトコルよりハンドシェイク失敗の切り分けが難しくなります。
VMess はユーザー ID とタイムスタンプで認証し、リクエストヘッダーに多くのフィールドを持ち、多重化にも対応します。互換性が高く、古いクライアントでも使えます。代償はヘッダーのオーバーヘッドと実装の複雑さがやや大きく、システム時刻に敏感なことです。デバイスの時刻が大きくずれていると、「設定は合っているのに接続できない」ことが起こります。
QUIC 型:Hysteria2 と TUIC
Hysteria2 は QUIC(UDP)をベースに、輻輳制御をより積極的にしており、パケットロスが多く RTT が高い回線でも帯域を出しやすいのが特徴です。コネクションマイグレーションに対応し、スマホが Wi-Fi からモバイル回線に切り替わっても接続を完全に作り直さずに済みます。代償は UDP の品質に敏感なことです。ローカルネットワークや事業者が UDP を制限していたりロスが多かったりすると、体感は明らかに落ちます。QUIC はユーザー空間で処理するため、CPU とバッテリーの消費は軽量な TCP プロトコルより大きいのが一般的です。
TUIC も QUIC を使い、0-RTT、多重化、コネクションマイグレーションを重視しており、ネットワークを頻繁に切り替える場面や素早い復帰が必要な場面に向きます。比較的新しく、クライアントごとの実装差も大きめです。問題が出たら、まずクライアントのバージョンと UDP の到達性を確認し、そのうえで回線を判断してください。
| プロトコル | ベース | セキュリティ境界 | リソース消費 | 向いている用途 |
|---|---|---|---|---|
| Shadowsocks | TCP / UDP | 事前共有鍵 AEAD | 低 | ルーター、古いデバイス、単純な転送 |
| VMess | TCP | ユーザー ID + タイムスタンプ、TLS をかぶせられる | 中 | 古いクライアントとの互換、多重化が必要 |
| Trojan | TCP + TLS | パスワード認証 + 本物の TLS | 中 | ドメイン証明書があり、サイトと入口を共用 |
| VLESS | TCP、外側 TLS | 外側の TLS / REALITY に依存 | 低 | 高スループット、低 CPU、長時間の大容量通信 |
| Hysteria2 | QUIC(UDP) | TLS 1.3 | やや高 | 弱い回線、パケットロスが多い、モバイル回線の切り替え |
| TUIC | QUIC(UDP) | TLS 1.3 | やや高 | ネットワーク切り替えが多い、素早い復帰 |
選ぶときの3つの誤解
プロトコル名だけを見て、外側を見ない。VLESS は TLS がなければ暗号化されません。Trojan の強度は証明書と TLS 設定で決まります。Shadowsocks はプラグイン次第で外から見え方が変わります。プロトコル名は入口にすぎず、セキュリティ境界は外側にあります。
多重化を万能とみなす。多重化はハンドシェイクを減らしますが、1本の TCP 接続上のヘッドオブラインブロッキングがすべてのストリームに影響します。QUIC の多重化には TCP のヘッドオブラインブロッキングはありませんが、UDP の品質に左右されます。インタラクティブな閲覧と大容量ファイルのダウンロードでは、適した接続戦略が異なります。
クライアント実装を無視する。同じプロトコルでも、クライアントが違えば輻輳制御、バッファ、ログレベル、バッテリー設定が異なります。「同じ回線なのにクライアントを変えたら正常」という場合、問題はプロトコルではなく実装にあることが多いです。
プロトコルはクライアントから入口までの区間だけを担います。入口より先が直結、中継、専用線のどれかは回線が決めます。プロトコルを一通り変えても遅いままなら、回線トポロジーに戻るべきで、プロトコルを変え続けるべきではありません。
03 · ハンドシェイク
接続確立と初回パケットの時間
「ページを開くまで数秒待つ」と「大きなファイルのダウンロードが遅い」は別の問題です。前者はたいてい接続確立で詰まっており、後者で初めてスループットが問題になります。初回パケットまでの時間を分解すれば、どこが遅いのか素早く判断できます。
1回のアクセスで何回ハンドシェイクが起きるか
クライアントはまず DNS でドメインを IP に変換し、入口との TCP 接続を確立して3ウェイハンドシェイクを完了します。外側が TLS なら TLS ハンドシェイクを行い、続いてプロキシプロトコル自身の認証とリクエストヘッダーが続きます。入口はリクエストを出口へ転送し、出口は目的のサイトと改めて DNS、TCP、TLS を行います。ユーザーが見る「初回パケット」は、これらの手順が積み重なった結果です。
このうち、ローカル DNS と入口までの RTT は一般に短く、入口から出口、出口から目的サイトまでの経路のほうが長くなります。つまり初回パケットが遅いのは、自分から入口までが遅いとは限らず、出口から目的サイトの区間が渋滞している可能性もあります。逆に入口が近く、出口も目的サイトの近くにあれば、初回パケットは明らかに短くなります。
接続の再利用と 0-RTT
ブラウザもクライアントも接続を再利用します。HTTP/2 は1本の TCP 上で複数リクエストを、HTTP/3 は1本の QUIC 接続上で複数ストリームを流し、プロキシクライアントも複数リクエストを1本のトンネルに多重化することがあります。再利用はハンドシェイク回数を減らしますが、複数ストリームを同じ接続に縛ります。下位層でパケットロスが起きると、TCP ではすべてのストリームが再送を待ち、QUIC では該当するストリームだけが影響を受けます。
TLS 1.3 と QUIC はセッション再開に対応し、2回目の接続では 0-RTT で先にデータを送れます。往復は確かに1回減りますが、無条件に速くなるわけではありません。サーバーが 0-RTT データを拒否する場合もあり、一部のネットワークはリプレイ保護に慎重です。0-RTT を「必ず速くなる」と考えると誤判断につながります。
時刻、DNS、MTU
時刻同期は VMess のタイムスタンプ認証に影響し、TLS 証明書の有効期限判定にも影響します。デバイスの時刻が大きくずれると、「設定は正しいのにハンドシェイクに失敗する」形で現れます。システムの自動時刻設定をオンにするのが最も手間のかからない確認方法です。
DNS は最初の名前解決にどれだけ待つか、そしてどの入口に解決されるかを決めます。ブラウザ自身の DoH がシステム DNS を迂回し、クライアントとブラウザで違うアドレスを見ていることがあります。切り分けでは、まず誰が名前解決しているかを確認してください。
MTU はカプセル化後も通過できる最大パケット長です。プロキシは元データの外側にヘッダーを足すため、経路 MTU が小さいと大きなパケットが破棄されることがあり、「小さいページは開けるが大きなファイルで止まる」「TLS ハンドシェイクは完了するがデータが動かない」といった形で現れます。こうした問題は回線が遅いと誤判定されがちです。
curl -o /dev/null -s -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first=%{time_starttransfer} total=%{time_total}\n' https://example.com
このコマンドは公開されているサンプルサイトを1つ測るだけで、アカウント情報は一切含みません。dns は名前解決、connect は TCP ハンドシェイク、tls は TLS ハンドシェイク、first は最初のバイト、total は全体の所要時間です。何度か実行して中央値を取ると、1回の結果より参考になります。
初回パケットが遅いことは、帯域が低いことを意味しません。まず上の内訳で DNS、ハンドシェイク、目的サイトの応答のどれかを確認してください。大容量ファイルの転送が持続的に伸びない場合に初めて、スループットと回線の輻輳を見る必要があります。
04 · リソース
リソース消費とモバイル端末のバッテリー
プロトコル比較では「軽量」「高効率」と書かれがちですが、リソース消費は単一の数値ではありません。少なくとも CPU、メモリ、無線の起動回数、バッテリー設定を含みます。同じプロトコルでも、デスクトップ PC と古いスマホでは挙動がまったく違うことがあります。
CPU はどこに使われるか
1つ目は暗号化です。AES のハードウェア命令に対応したデバイスなら AES-GCM のコストは非常に小さく、ハードウェア支援がない場合は ChaCha20 系のストリーム暗号のほうが一般的に軽くなります。2つ目は TLS です。ハンドシェイク、証明書検証、レコード層の暗号化・復号にはいずれも演算が必要です。3つ目は QUIC です。ユーザー空間で実装され、輻輳制御、再送、ストリーム管理を含むため、カーネル内の TCP より CPU コストが大きいのが一般的です。4つ目は多重化とログです。接続が増えるほど、ログが詳細なほどコストは増えます。
したがって「VLESS は Trojan より軽い」は特定の外側と特定のクライアントでしか成り立ちませんし、「Hysteria2 は弱い回線で速い」も、すべてのデバイスで省電力という意味ではありません。判断するときはプロトコル名だけでなく、経路全体を見てください。
バッテリーはどこで消費されるか
モバイル端末のバッテリーは、暗号演算よりも無線モジュールの起動回数に大きく左右されます。ハートビート、再接続、DNS クエリのたびに、セルラーや Wi-Fi のモジュールが低消費電力状態から起きます。ハートビート間隔が短すぎれば頻繁に起き、長すぎれば NAT のタイムアウトで切られ、次のリクエストで接続を作り直すことになります。クライアントの既定値は通常その折衷案なので、「常時接続のため」に極端に攻めた設定にするのはおすすめしません。
ネットワークの切り替えも電力を消費します。スマホが Wi-Fi からセルラーへ、そして Wi-Fi へ戻ると、TCP 接続が切れてクライアントが再接続します。QUIC のコネクションマイグレーションは作り直しを減らせますが、移行自体に暗号状態と経路検証の処理が必要です。省電力設定、バックグラウンド制限、低電力モードは、クライアントがバックグラウンドで接続を維持できるかどうかに影響します。
デバイスと用途別の使い分け
| デバイス / 用途 | 推奨 | 理由 |
|---|---|---|
| 古いスマホ、長時間待機 | 軽量な TCP プロトコルを必要なときだけ | QUIC のユーザー空間コストと無線の起動を抑える |
| ノート PC を電源につないで作業 | 安定優先で多重化を有効に | バッテリーは制約にならず、ハンドシェイク削減が効く |
| スマホでネットワーク切り替えが多い | コネクションマイグレーション対応の QUIC プロトコル | 再接続と再認証を減らす |
| ルーター / 旧デバイス | Shadowsocks または軽量な VLESS | CPU とメモリが限られるため、設定は簡単なほど安定する |
VPNVL の月額プランは台数無制限で、複数のデバイスで同時に使えます。ただしバッテリーと性能はデバイスごとの問題で、互いに代わりにはなりません。
無駄な消費を減らすための習慣
1つ目は用途別の振り分けです。必要なアプリだけをプロキシ経由にし、それ以外は直結にして、不要な暗号化と転送を減らします。2つ目は二重プロキシを避けることです。プロキシの内側にプロキシを重ねると、パケットごとに暗号化と転送が1回ずつ増えます。3つ目は詳細ログをオフにすることです。調査のときだけ有効にし、普段は既定のままにします。4つ目は「常時オン」を唯一の目標にしないことです。電源につないだデバイスは常時オンで構いませんが、バッテリー駆動のデバイスは必要時のみのほうが向いています。5つ目はクライアントを定期的に更新することです。輻輳制御、再接続の方針、バッテリー最適化はバージョンごとに改善されますが、むやみに最新を追わず、安定版を優先してください。
バッテリーは総合的な結果です。プロトコル、クライアント、ネットワーク方式、電波強度、バックグラウンド設定のすべてが影響します。プロトコル名だけで省電力かどうかを判断すると、たいてい間違った結論になります。
05 · トポロジー
回線トポロジー:直結・中継・専用線
回線トポロジーとは「入口から出口までどう進むか」を表します。プロトコル名よりも直接的に、レイテンシ、ジッター、夜間ピークの挙動を決めます。VPNVL のノードページが回線を直結・中継・IEPL 専用線の3種類に分けているのは、まさにこのためです。
直結:経路は最短だが、相互接続の品質に依存する
直結は、クライアントが出口ノードに直接接続する方式で、入口と出口は同じサーバーまたは同じデータセンターです。経路が短く、ハンドシェイクが少なく、実装も単純という利点があります。欠点は、中間区間がローカル事業者と接続先データセンターの相互接続品質に完全に依存することです。相互接続が良ければ直結は非常に素直ですが、悪い場合や夜間ピークに渋滞する場合は直結でも不安定になります。直結は距離が近く、目的サイトと出口地域が合っている場面に向きます。
中継:1ホップ増やして、より安定した中間区間を得る
中継は、クライアントがまず入口に接続し、入口がトラフィックを中継ノードへ転送し、最後に中継ノードから出口へ向かう方式です。直結より1ホップ増えるため、理論上はレイテンシが少し増えます。ただし中継ノードは相互接続の良い場所に置かれることが多く、「ローカル事業者から国際区間」をより制御しやすい経路に置き換えられます。中継の価値は最短であることではなく安定性にあります。直結が夜間ピークに揺れるとき、中継はたいてい滑らかです。
中継にも前提があります。入口がユーザーに近いこと、中継区間に十分な帯域があること、出口が目的サイトの要件を満たすことです。どこか1区間が渋滞すれば、利点は打ち消されます。つまり「中継」は固定の品質ではなく、経路設計の一種です。
専用線:固定チャネルで安定性を優先
IEPL 専用線は、入口と出口の間を比較的固定されたチャネルで通り、他の一般トラフィックと同じ公共相互接続区間を取り合いません。ジッターが小さく夜間ピークでも安定しやすいのが利点で、長時間の会議、海外との業務、切断に敏感な用途に向きます。代償はコストが高いこと、そしてカバーするのは「入口から出口」の区間だけであることです。自宅の Wi-Fi、ローカル事業者、目的サイトは専用線の範囲外です。
したがって専用線は魔法ではありません。自宅の回線がすでに飽和していたり、Wi-Fi の電波が悪かったりすれば、専用線でも最後の区間は救えません。正しい期待値はこうです。専用線は中間区間の不確実性を下げ、問題をローカル側と目的サイト側に収束させ、切り分けをしやすくします。
| 種類 | 経路 | レイテンシの特徴 | ジッターとパケットロス | 向いている用途 |
|---|---|---|---|---|
| 直結 | クライアント → 出口 | 経路が短く、相互接続次第 | 夜間ピークに上がることがある | 近距離、目的地域が一致 |
| 中継 | クライアント → 入口 → 中継 → 出口 | 1ホップ増えるが中間区間は制御しやすい | たいていより滑らか | 海外アクセス、夜間ピークの安定 |
| IEPL 専用線 | クライアント → 入口 → 固定チャネル → 出口 | 最短を目標にしない | ジッターが最小 | 会議、業務、長時間接続 |
同じ回線でも都市によって挙動が違う理由
「ラストワンマイル」が違うからです。事業者、集合住宅、接続方式が違えば、同じ入口までの経路と相互接続品質も変わります。同じ都市でも光回線とモバイル回線で結果が逆になることもあります。ノードページが示すのは回線タイプと対応地域であり、各家庭での保証値ではありません。回線を選ぶときは、まず入口が自分に近いか、次に中間区間が安定しているか、最後に出口が目的サイトの地域要件を満たすかを見てください。
まず入口が近いものを選び、次に中間区間が安定したものを選び、最後に出口が合っているかを確認します。国名だけでノードを選ぶと入口と中間区間を見落としやすく、レイテンシの数値だけで選ぶと一時的な変動に惑わされます。
06 · 輻輳
パケットロスと夜間ピークの輻輳
レイテンシ、ジッター、パケットロス、スループットは4つの異なる指標です。レイテンシはデータが往復する時間、ジッターはレイテンシの変動、パケットロスは届かなかったパケット、スループットは単位時間に送れる量です。夜間ピークで最もよくあるのは「サーバーが壊れた」ことではなく、どこかの区間で渋滞が起き、レイテンシが上がり、ロスが増え、スループットが落ちることです。
パケットロスがなぜすべてを遅くするのか
TCP はパケットロスを輻輳の信号として扱います。ロスを検出すると輻輳ウィンドウを縮め、送信速度を落とし、そこから徐々に戻します。回線の RTT が長いほど回復は遅く、ロスが頻繁なほどウィンドウは増えにくくなります。QUIC も再送しますが、ストリームごとに処理するため、1本のストリームのロスですべてが待たされることはありません。ただし UDP が制限されていたりロスが深刻なネットワークでは、QUIC の利点も打ち消されます。
つまり「1% のパケットロス」でも用途ごとに影響はまったく違います。リアルタイム音声ならたまに途切れる程度、大容量ダウンロードなら明らかな速度低下、インタラクティブな Web なら「クリックしてから待たされる」形で現れます。1回の ping 結果で全体の体感を語るべきではありません。
夜間ピークのよくある原因
1つ目は国際区間の輻輳です。夜間ピークは国際トラフィックが集中し、公共の相互接続で渋滞が起きて、レイテンシとロスが同時に上がります。2つ目は家庭の上り回線の飽和です。家族の動画視聴、バックアップのアップロード、アップデートのダウンロードがルーターのキューを長くします。3つ目は Wi-Fi の干渉です。隣家とのチャネル重複、距離、壁が障害となり、ロスとジッターとして現れます。4つ目はルーターの NAT テーブルやセッション数の逼迫です。古い機器は接続数が増えると遅くなります。5つ目は MTU の不一致です。大きなパケットが捨てられ、小さなパケットは通ります。6つ目は UDP の帯域制限です。QUIC 系プロトコルが一部のネットワークでは TCP に劣ることもあります。
もう1つ見落とされがちなのがバッファブロートです。ルーターのバッファが大きく、渋滞するとレイテンシが上がるのにパケットは落ちないため、速度テストの数値は悪くないのに体感は重くなります。こうした問題はルーター側のキュー管理や帯域制限で緩和するもので、プロトコルを変えても効果は限定的です。
夜間ピークの輻輳かどうかの判断方法
まず時間帯を記録します。19:00 から 23:00 だけ悪化し日中は正常なら、共有回線の輻輳の可能性が高いです。終日悪いなら、ローカルネットワーク、入口の選択、デバイス側の問題の可能性が高いです。次に変数を変えます。同じ時間帯に回線タイプを変え、中継や専用線が明らかに安定するなら中間区間に原因があります。すべての回線が同じなら、まずローカルを調べてください。次に媒体を変えます。有線と Wi-Fi を比較し、無線の干渉を排除します。最後にプロトコルを変えます。TCP と QUIC をそれぞれ試し、UDP が制限されていないか判断します。
切り分けでは、OS 標準のネットワーク診断やルート追跡ツールで経路が変わっていないか観察できますが、1回の ICMP レイテンシを結論にしないでください。ICMP は帯域制限されたり別のキューを通ったりするため、参考程度にとどめるべきです。より重要なのは「同じ時間帯、同じ目的、異なる回線」での比較です。現在の出口アドレスを確認したい場合はネットワーク診断ページで確認できます。
夜間ピークは故障ではなく、容量の問題です。ある回線がピーク時に継続して不安定なら、何度も再接続するより回線タイプを変えるほうが効果的です。すべての回線が同じ時間帯に悪いなら、まず自宅の回線と家庭内ネットワークを見てください。
07 · 選定
用途別にプロトコルと回線を選ぶ
すべての用途に合う設定はありません。選定の順序は、まず回線、次にプロトコル、最後にクライアントの調整です。回線は経路と安定性を、プロトコルはハンドシェイク、コスト、弱い回線での挙動を、クライアントはそれらの能力を引き出せるかを決めます。
AI ツールと長時間接続
ChatGPT、Claude、Gemini といったツールに共通するのは「1本の接続を長時間保ち、ストリーミング応答を受け続ける」という点です。初回パケットに極端に敏感というわけではありませんが、途中での切断や再認証には敏感です。選定では安定性を優先し、中継または専用線 + Trojan/VLESS over TLS で接続の作り直しを減らしてください。会話の途中で頻繁にノードを切り替えないことも重要です。出口地域はサービスの要件に合わせる必要があり、そうでないと地域制限に当たることがあります。詳しくはChatGPT で使う VPN のおすすめをご覧ください。
ストリーミングと 4K
ストリーミングで重要なのは持続的なスループットと出口 IP の信頼性です。直結でも中継でも構いませんが、出口地域が目的のプラットフォームと一致していること、夜間ピークに十分な余裕があることが要点です。Hysteria2 はパケットロスの多い回線でより安定する可能性がありますが、プラットフォームが UDP やデータセンター IP を制限している場合は、TCP 系プロトコルに戻すほうが手間がかかりません。VPNVL の視聴サポートページではプラットフォーム別に対応地域を掲載しています。選ぶ前に照らし合わせてください。
海外との業務と会議
会議はジッターに最も敏感で、絶対的なレイテンシにはそれほど敏感ではありません。IEPL 専用線の価値が最もわかりやすいのはここです。固定チャネルが渋滞を減らし、長時間の接続が切れにくくなります。プロトコルは TCP 系の Trojan または VLESS を選び、クライアントの振り分けで社内ネットワークやローカルサービスをプロキシの対象外にして、不要な転送を減らします。出張の場面では出張向け VPN のおすすめにある使用量の見積もりとチェックリストが参考になります。
モバイルとゲーム
スマホは Wi-Fi とセルラーを頻繁に切り替えるため、コネクションマイグレーションに対応した QUIC プロトコルのほうが扱いやすいです。ただし UDP が制限されているか不明な場合は、TCP の代替を用意しておきましょう。ゲームはレイテンシとジッターが重要なので、自分に近い入口、ゲームサーバーと同じ地域の出口を選び、有線または 5GHz の Wi-Fi を優先してください。バックグラウンドで同時にダウンロードを走らせないことも大切です。
| 用途 | 推奨の回線 | 推奨のプロトコル | 説明 |
|---|---|---|---|
| AI ツール | 中継 / 専用線 | Trojan / VLESS + TLS | 長時間接続の安定を優先し、切り替えは少なく |
| ストリーミング | 直結 / 中継 | VLESS / Trojan | 出口地域が一致し、夜間ピークに余裕があること |
| 海外との業務 | IEPL 専用線 | Trojan / VLESS | 低ジッター、振り分けと併用 |
| モバイル | 中継 | TUIC / Hysteria2 | コネクションマイグレーション、TCP の代替を用意 |
| ゲーム | 直結 / 専用線 | Hysteria2 / TUIC | 入口が近く、同じ地域の出口、有線優先 |
| 大容量ダウンロード | 中継 / 専用線 | VLESS / Shadowsocks | スループット優先、多重化のボトルネックを避ける |
安定重視
中継または専用線 + TLS 系プロトコル
会議、業務、AI との対話に向きます。まず切断しないことを確保し、そのうえでピーク速度を考えます。
弱回線重視
Hysteria2 / TUIC + 中継
パケットロスが多く、ネットワーク切り替えの多いモバイル用途に向きます。まず UDP の到達性を確認してください。
軽量重視
Shadowsocks / VLESS + 直結
ルーター、古いデバイス、単純な転送に向きます。設定は少ないほど安定します。
予算とプランの組み合わせ方
選定はクライアントの中だけで起きるものではなく、購入のときにも起きます。VPNVL の月額プランは開通日を基準に毎月トラフィックがリセットされます。¥9.9/月は 60GB、¥18/月は 250GB、¥28/月は 500GB。トラフィックパッケージは使い切るまで有効で、期限はありません。¥158/300GB、¥358/1000GB、¥658/3000GB です。使用量が安定しているなら月額プラン、上下が大きい場合や余裕を持たせたい場合はトラフィックパッケージを組み合わせてください。予算が限られる場合は、まず10元台で何が買えるかを見てから組み合わせを決めるとよいでしょう。
サービスを乗り換えるべきタイミング
すべての回線、すべてのプロトコル、すべてのデバイスが同じ時間帯に使えないなら、まずローカルネットワークとアカウントの状態を確認してください。特定の1回線だけ長期的に不安定なら回線を変えます。特定の1プロトコルだけ特定のネットワークで使えないならプロトコルを変えます。すべての回線が夜間ピークに長期的に輻輳し、他の時間帯は正常という場合に初めて、サービスの容量を検討する必要があります。「サービスを乗り換える」を第一反応にすると、より簡単な対処を見逃しがちです。
まず回線、次にプロトコル、最後にクライアントの調整。順序を逆にすると、クライアントのパラメータを何度も変えながら、本当に渋滞している区間を一度も変えていない、という状態になります。
08 · 切り分け
レイヤー別切り分けの手順
切り分けの目的は「すべての設定を試すこと」ではなく、最小限の変数で問題を特定することです。以下の5ステップを順に進め、各ステップで記録を残してください。5ステップ後も解決しない場合は、記録を持ってサポートに連絡するほうが、「つながらない」の一言よりはるかに有効です。
- 範囲を絞る。1台だけか、すべてのデバイスか。1つのサイトか、すべてのサイトか。終日か、夜間ピークか。この3つに答えるだけで、問題は半分に絞られます。
- ローカルを確認する。有線と Wi-Fi をそれぞれ試し、システム時刻の自動同期を確認し、2つのプロキシを同時に有効にしていないことを確認し、DNS がブラウザやセキュリティソフトに書き換えられていないことを確認し、ルーターの上り回線が飽和していないことを確認します。
- 変数は1つだけ変える。まず回線、次にプロトコル、次にデバイスです。変えるたびに結果を記録してください。回線、プロトコル、DNS を同時に変えると、どれが効いたのか判断できません。
- ログを見る。クライアントのログにあるハンドシェイク失敗、DNS タイムアウト、TLS エラー、接続リセットは、「開けない」よりはるかに情報量があります。スクリーンショットやログのコピーの前に、購読 URL とトークンは必ず隠してください。
- 情報を添えて相談する。時刻、デバイスと OS、回線名、プロトコル、エラーメッセージ、すでに試した手順。情報が具体的なほど特定は速くなります。
よくある症状と対処
接続はできるがページが開けない。まず DNS を見ます。ブラウザ自身の DoH がクライアントを迂回している可能性があります。次にシステムプロキシが半分だけ有効になっていないかを見ます。最後に MTU、特に小さいページは開けるのに大きいページで止まる場合を確認します。
特定のアプリだけ使えない。振り分けルールでそのアプリが除外されていないか確認してください。証明書ピンニングを使うアプリはプロキシの証明書を受け付けません。UDP しか使わないアプリもあり、現在の回線で UDP が使えない場合は通じません。
頻繁に切断される。スマホの省電力設定、Wi-Fi ローミング、NAT のタイムアウト、ハートビート間隔のいずれも原因になり得ます。まず省電力制限を外し、次にネットワークを変えて比較してください。モバイル回線でのみ切れる場合は、コネクションマイグレーションに強いプロトコルを優先してください。
速度が遅い。まず初回パケットが遅いのか、スループットが低いのかを分けます。次にデバイスの CPU が飽和していないか、Wi-Fi の電波とルーターに問題がないかを見ます。最後に回線タイプを変えます。プロトコル名だけを見つめないでください。
セキュリティとプライバシーの境界
切り分けの際、購読 URL、トークン、完全なログをそのまま公開グループやスクリーンショットに載せないでください。VPNVL はログを記録しませんが、購読 URL 自体がアクセス資格情報です。パスワードと同じように扱ってください。サポートが必要なときは、回線名、プロトコル、エラーの種類、時刻だけを伝え、資格情報は渡さないでください。
よくある質問
同じ回線で PC は速く、スマホは遅い。これは回線の問題ですか?
デバイス・クライアント層の問題である可能性が高いです。まず Wi-Fi とセルラーを比較し、省電力制限とバックグラウンド設定を確認し、別のクライアントで検証してください。スマホが同じ Wi-Fi でも遅い場合は、ルーターと電波を確認します。
プロトコルを変えたら遅くなりました。戻すべきですか?
まず元のプロトコルに戻して差を確認し、そのうえで新しいプロトコルが現在のネットワークで制限されていないか判断してください。QUIC 系プロトコルは UDP に依存するため、一部のネットワークではかえって遅くなります。TCP 系プロトコルもパケットロスが多いと明確に速度が落ちます。同じ時間帯、同じ目的で比較し、1回ページを開いた感触で結論を出さないでください。
夜間ピークには必ず専用線にすべきですか?
そうとは限りません。まず夜間ピークだけ悪化するのかを確認してください。中継ですでに安定しているなら、専用線に上げる必要はありません。専用線が解決するのは中間区間のジッターと渋滞であり、問題が自宅回線や Wi-Fi にあるなら専用線にしても消えません。
UDP が通らない場合はどうすればよいですか?
まず TCP 系プロトコルに変えて、アカウントと回線が正常であることを確認し、そのうえで現在のネットワークが UDP を制限していないか判断してください。QUIC 系プロトコルが必要な場合は、別のネットワークや回線で比較します。同じネットワークで何度も再接続しても、UDP の到達性は変わりません。
月額プランのトラフィックとトラフィックパッケージはどう選びますか?
月額プランは開通日を基準に毎月リセットされます。¥9.9/月は 60GB、¥18/月は 250GB、¥28/月は 500GB。トラフィックパッケージは使い切るまで有効で、期限はありません。¥158/300GB、¥358/1000GB、¥658/3000GB。使用量が安定しているなら月額プラン、変動が大きい場合や余裕を持たせたい場合はトラフィックパッケージを組み合わせてください。
返金はどうなりますか?
初回のお支払いから60日以内であれば、理由を問わず全額返金を申請できます。具体的な手順と着金方法は返金ポリシーのページに従います。申請時に複雑な理由は不要ですが、照合のため注文情報は保管しておいてください。