このVPN初心者向け用語解説では、まずよくある疑問を整理します。クライアント上で並んで表示される「サブスクリプション、ノード、プロトコル、ルール分岐、グローバルモード」は、実際にはそれぞれ異なる階層の機能です。サブスクリプションは設定を届け、ノードは選択可能な入口または出口、回線はデータの経路、プロトコルはクライアントとサーバーの通信方法、分岐モードはどのリクエストをこの経路に通すかを決めます。
乗り物にたとえると理解しやすくなります。サブスクリプションリンクは更新される路線案内、ノードは停留所、直結・中継・専線は走行経路、プロトコルは車両と道路で使う通信ルール、分岐ルールはどの区間を高速道路にし、どこを一般道にするか決めるナビのようなものです。階層を整理すれば、クライアントの設定項目の多くは難しくありません。
サブスクリプション、設定、ノードの違い
サブスクリプションリンクは更新可能な設定インデックス
サブスクリプションリンクは通常、サービス提供者の管理画面で発行されます。クライアントがリンクにアクセスすると、アドレス、ポート、プロトコル、通信方式、認証情報、ノード名などを含むサーバー設定を取得します。一般的な情報ページではなく、アクセス権限を含む設定への入口なので、フォーラムへの投稿、スクリーンショットの公開、公開文書への掲載は避けてください。
「サブスクリプションを取り込む」と「ノードに接続する」は別の操作です。取り込みはクライアントに利用可能な設定を認識させるだけで、実際にデータを送るには一覧からノードを選び、接続を開始する必要があります。クライアントによっては定期的にサブスクリプションを更新し、手動操作時だけ更新するものもあります。サービス側で入口が変更され、ローカルの一覧に古い内容が残っている場合は、古いノードを何度も切り替えるより、まずサブスクリプションを更新するほうが効果的です。
単一ノードの設定とサブスクリプションは別物
単一ノードリンクは1件の設定だけを記述するもので、一時的な取り込みや詳細な切り分けに向いています。一方、サブスクリプションリンクでは複数のノードをまとめて管理でき、サーバー側の更新後にクライアントが再取得すれば変更を同期できます。「取り込み成功」と表示されたのに新しいノードが見つからない場合は、サブスクリプションのグループを開いているのかローカル設定を開いているのかを確認し、キャッシュが使われていないかも確認しましょう。
ノード名はラベルであり、完全なトポロジーではない
「東京」「シンガポール」「ロサンゼルス」といった名称は、通常、出口や入口の位置、またはサービス提供者が回線を識別するためのラベルです。名前だけで全経路を判断することはできません。東京と表示された中継ノードでも、近い入口に接続してから最適化された経路で東京の出口へ向かう場合があります。直結ノードなら、通常は端末から遠隔サーバーへ直接接続します。
- ✅ 取り込み後はまずサブスクリプションを更新し、ノード一覧に変化があるか確認する。
- ✅ サブスクリプションリンクはアクセス認証情報として扱い、信頼できる端末とクライアントだけに保存する。
- ✅ ノードを切り替えたら、一覧の選択状態だけでなく、クライアントに表示された現在の設定を確認する。
- ❌ 「取り込み成功」と表示されても、ネットワークがすでに切り替わったとは限りません。接続スイッチは別途有効にする必要があります。
- ❌ 都市名のラベルだけで回線の種類を判断せず、サービス提供者の回線説明も確認する。
直結・中継・IEPL専線の違い
回線の種類は「データが端末から出口までどのように届くか」を示します。プロトコルとは並列の概念ですが、同じものではありません。同じプロトコルでも直結回線、中継経路、専線上で動作できます。プロトコルは接続とカプセル化を担い、回線はデータを運ぶ基盤経路を示します。
| 回線の種類 | 基本的な経路 | 主な特徴 | 確認したい指標 |
|---|---|---|---|
| 直結 | 端末から遠隔地の入口または出口へ直接接続 | 構成がシンプルで、実際の品質は地域の通信事業者と国際ネットワーク経路に左右されやすい | ハンドシェイクの安定性、混雑時間帯の変動、パケットロス、ルート変更 |
| 中継 | 近い入口に接続してから、目的の出口へ転送 | 一部の不安定な公衆網区間を避けられる一方、入口と中継経路の両方が結果に影響する | 入口までの距離、転送の安定性、出口の負荷、復路の経路 |
| IEPL専線 | 入口と海外側の間を企業向け専線で接続し、その先で目的のネットワークへ接続 | 主要な国際区間が一般の公衆網経路だけに依存せず、経路の一貫性を重視しやすい | 接続品質、専線の適用範囲、出口側ネットワーク、障害時の切り替え |
直結だから必ず遅いわけでも、中継だから必ず速いわけでもありません。端末のネットワークから遠隔地の入口までの経路が良好なら、直結はシンプルで効率的です。公衆網の国際経路が不安定なら、適切な中継のほうが安定する場合もあります。IEPLは入口間の接続方式を示すもので、端末から最終的なウェブサイトまでの全区間が専線になるわけではありません。入口までの接続や出口から目的のサービスまでの経路には、それぞれ別のネットワークが使われます。
主要なプロトコル名の見方
プロトコルは、クライアントとサーバーがデータを認証、暗号化、カプセル化、転送する方法を定めます。初心者はプロトコル名を速度ランキングとして捉える必要はありません。ネットワークがUDPを許可しているか、システムが対応するカーネルを備えているか、トランスポート層の設定、サーバー負荷、基盤回線によって結果は変わります。以下はクライアントの選択項目を理解するための目安であり、プロトコルに固定的な優劣を付けるものではありません。
Shadowsocks
Shadowsocksは軽量な暗号化プロキシプロトコルで、通常はサーバーアドレス、ポート、暗号化方式、パスワードで構成されます。実装が広く、クライアントとの互換性も高いため、一般的なウェブ閲覧やアプリのルール分岐に向いています。どのドメインを直結するかはプロトコル自体では決まらず、具体的な分岐はクライアントのルールが担います。
VMessとVLESS
VMessには認証と時刻に関する仕組みがあり、端末の時刻ずれによってハンドシェイクに失敗することがあります。VLESSはプロトコル自体をよりシンプルに設計しており、実際の安全性や通信品質は外側のTLS、通信方式、サーバー設定に大きく左右されます。VLESSと表示されている場合も、プロトコル名だけでなく、TLS、WebSocketなどのトランスポート層が組み合わされているか確認しましょう。
Trojan
Trojanは通常TLS上で動作し、一般的な暗号化ウェブ通信に近い形で接続します。証明書、ドメイン、サーバー設定が正しく連携していることが重要です。証明書の期限切れ、システム時刻の誤り、ドメイン解決の異常、中間ネットワークの干渉などでもハンドシェイクに失敗するため、トラブル時にパスワードの変更だけを試すのは不十分です。
Hysteria2とTUIC
Hysteria2とTUICはいずれもQUICとUDPを利用した通信を重視しており、ある程度のパケットロスや揺らぎがあるネットワークでも、スループットと操作感を保てる場合があります。ただし、現在のネットワークがUDPを厳しく制限している場合は接続できなかったり、正常に動作するTCP経路より品質が落ちたりすることがあります。「ウェブ向けプロトコルは使えるのにQUIC系プロトコルは使えない」場合は、ノードの障害と決めつけず、まずUDPへの対応状況を確認しましょう。
| プロトコル | 主な通信特性 | 確認するポイント | 選び方の目安 |
|---|---|---|---|
| Shadowsocks | 軽量な暗号化プロキシで、幅広く実装されている | 暗号化方式、ポート、認証情報、ルール分岐 | クライアント互換性と設定のシンプルさを優先する |
| VMess | 認証と時刻に関する検証を含む | システム時刻、トランスポート層、認証情報 | サーバー側に成熟した設定がある環境に向く |
| VLESS | プロトコル層がシンプルで、TLSと組み合わせることが多い | TLS、ドメイン、通信方式、サーバー側パラメータ | 名称だけでなく、通信設定全体を見て判断する |
| Trojan | 通常はTLSで接続を確立する | 証明書、ドメイン解決、システム時刻、ポート | TLS経路が正常に動作するネットワークに向く |
| Hysteria2 | QUICとUDPを基盤とし、効率的な通信を重視する | UDP到達性、輻輳制御、ローカルネットワークの制限 | UDP環境が良好、またはネットワークに変動がある場面に向く |
| TUIC | QUICとUDPを基盤とし、並行通信に対応する | UDP到達性、証明書、クライアント実装 | プラットフォームの対応状況と現在のネットワーク条件を合わせて選ぶ |
ルール分岐、ルール、グローバルモードと直結モード
モードの切り替えは、トラフィックをどこへ送るかを決めます。初心者は「グローバル」を端末上のすべてのデータがトンネルに入る状態と考えがちですが、実際の範囲はクライアントの取り込み方式によって異なります。システムプロキシだけを使う場合は、システムプロキシ設定に従うアプリだけが対象です。TUNを有効にすると、通常はより多くのシステムレベルの通信を処理できますが、プラットフォームの権限、プロトコルの種類、除外ルールの影響を受けます。
ルールモード
ルールモードでは、ドメイン、IP、アプリ、ルールセットに応じて通信先を振り分けます。海外サイトは選択したノードを経由し、国内サービスは直結のままにし、広告ドメインはルールで拒否することもできます。日常利用に向いていますが、ルールを最新に保つことが重要です。ドメインの所属変更、コンテンツ配信ネットワークの切り替え、アプリの新しいAPI利用などで、誤判定が起きる場合があります。
グローバルモード
グローバルモードでは通常、クライアントが取り込める通信を現在のノードへまとめて送ります。「ルールの誤判定かどうか」を切り分ける際に便利です。ルールモードでは開けないサービスがグローバルモードで使えるなら、原因はルールの一致条件、DNSの結果、またはアプリが正しく取り込まれていないことが多いでしょう。確認後はルールモードへ戻し、国内サービスまで遠隔地の出口を経由しないようにします。
直結モード
直結モードでは遠隔ノードを経由しません。プロキシを一時停止しながらクライアントを動かしたい場合や、問題がローカルネットワークに由来するか確認したい場合に使います。直結でもプロキシでも目的地にアクセスできないなら、問題は回線側とは限りません。ローカルDNS、ブラウザキャッシュ、システムネットワーク、目的のサービス自体の状態が原因の可能性もあります。
システムプロキシとTUN
システムプロキシは主にHTTPまたはSOCKSのプロキシ入口を設定します。ブラウザやシステムプロキシに従うアプリは接続しやすい一方、一部のアプリはこれを迂回します。TUNは仮想ネットワークインターフェースを作成し、システムのネットワーク層でより多くの通信を捕捉するため、プロキシ設定を読み取らないアプリにも有効です。ただし、対応するシステム権限が必要で、ファイアウォール、企業向けネットワークツール、他の仮想ネットワークインターフェースと競合することがあります。
DNSリークと名前解決の経路が重要な理由
ドメインへアクセスする前に、端末は通常DNSで対応するアドレスを問い合わせます。通信が遠隔ノードを経由していても、DNSクエリだけがローカルネットワークのリゾルバーへ送られると、DNSの経路とアクセス経路が一致しないことがあります。これはプライバシー上の問題に限らず、目的のサービスが現在の出口地域に適さないアドレスを返したり、ルール分岐が誤った名前解決結果を受け取ったりする原因にもなります。
クライアントにある「リモートDNS」「ローカルDNS」「暗号化DNS」「スニッフィング」は、それぞれ異なる処理を担います。リモートDNSは通常、プロキシが必要なドメインを遠隔経路で解決します。ローカルDNSはローカルサービスや直結ドメインに使われることが多く、暗号化DNSは端末とリゾルバー間の問い合わせを保護します。ドメインスニッフィングは接続データからドメインを復元し、ルールが経路を判断できるようにします。スニッフィングはDNSの代替ではなく、すべてのアプリの名前解決動作を修正できるわけでもありません。
ブラウザ内蔵のセキュアDNSは、クライアントが指定したシステムリゾルバーを迂回することもあれば、TUNによって正しく取り込まれることもあります。実際の動作はクライアントの実装とルーティング設定によって異なります。同じウェブサイトでもブラウザと他のアプリで結果が違う場合は、ノードを替えるだけでなく、ブラウザのセキュアDNS、システムDNS、クライアントログを個別に確認しましょう。
- ✅ プロキシ対象のドメインと直結ドメインが、ルールの想定どおりの名前解決経路を使っているか確認する。
- ✅ ブラウザで独自のセキュアDNSが有効になっていないか、そのリクエストがクライアントに取り込まれているか確認する。
- ✅ DNS設定を変更したら古いキャッシュを削除し、接続を再確立する。
- ✅ ルールモードとグローバルモードを比較し、異常がドメインの一致条件に由来するか判断する。
- ❌ 出口アドレスが変わったことだけを、DNSが正しく取り込まれた証拠にしない。
プラットフォームによってクライアントの設定が異なる理由
同じサブスクリプションを異なるプラットフォームに取り込んでも、ノード名は同じ場合がありますが、通信の取り込み方式と権限モデルは異なります。WindowsのクライアントはシステムプロキシとTUNを同時に提供することが多く、macOSはシステムネットワーク拡張機能やプロキシ設定に依存します。Androidはシステムが提供するVPNインターフェースで仮想ネットワークを作成し、iOSとiPadOSはシステムが許可するネットワーク拡張機能と構成を使用します。
そのため、「デスクトップでは使えるのにモバイルでは使えない」からといって、サブスクリプションの内容に問題があるとは限りません。モバイルOSではバックグラウンド動作が制限されることがあり、ネットワーク切り替え後にトンネルの再確立が必要になる場合もあります。デスクトップOSでは、ファイアウォール、セキュリティソフト、企業設定、他の仮想ネットワークアダプターの影響を受けやすい傾向があります。アプリの分岐方法にも違いがあり、プロセスやアプリ単位で選べるクライアントもあれば、ドメインとIPのルールだけで処理するクライアントもあります。
クライアントのカーネルバージョンによって、認識できるプロトコルやフィールドも決まります。古いカーネルで新しいHysteria2、TUIC、VLESSの通信設定を取り込むと、取り込みはできても起動できなかったり、未知のフィールドが無視されたりすることがあります。サブスクリプションを更新しても、クライアントのカーネルが自動的に更新されるわけではありません。「設定は存在するのに起動時にエラーが出る」場合は、クライアントのバージョンとプロトコル対応状況を同時に確認しましょう。
取り込みから接続までの手順
- ユーザーパネルからサブスクリプションリンクをコピーします。文字を手動で削除・変更せず、リンクを公開オンライン変換ツールに入力しないでください。
- プラットフォームに合い、目的のプロトコルに対応するクライアントを選びます。サブスクリプションにHysteria2またはTUICが含まれる場合は、クライアントのカーネルが対応設定を実際にサポートしているか確認してください。
- 「URLから取り込む」または「サブスクリプションを追加」を使います。取り込みが完了したら一度更新し、ノード一覧が読み込まれていることを確認します。
- 距離と用途に合ったノードを選びます。1回の遅延測定だけで並べ替えず、直結・中継・IEPL回線の説明も合わせて判断してください。
- 日常利用ではまずルールモードを選びます。特定のアプリが取り込まれない場合は、システムプロキシ、TUNの権限、アプリ分岐を確認してください。
- 接続後は実際の経路を確認します。クライアントに「接続済み」と表示されるだけでなく、出口の位置、DNS解決、目的のアプリが想定どおりか確認しましょう。
- 異常があるときは階層ごとに確認します。サブスクリプションを更新し、ノードを切り替え、ルールモードとグローバルモードを比較した後、プロトコル、DNS、システム権限を確認します。
初心者が特に混同しやすいポイント
ノードが多いからといって、プロトコルが多いとは限りません。複数のノードが同じプロトコルを使うこともあれば、同じ出口に異なるプロトコルの入口が用意されることもあります。ノードは位置を、プロトコルは通信方式を表し、互いの代わりにはなりません。
接続済みでも、すべてのアプリが取り込まれているとは限りません。クライアントのハンドシェイクが成功したことは、端末からサーバーまでの通信路が確立したことを示すだけです。アプリがその経路を使うかどうかは、システムプロキシ、TUN、アプリ自身のプロキシ設定、ルール分岐によって決まります。
グローバルでも、基盤上のすべての通信が無条件にノードへ入るわけではありません。クライアントが取り込めるのは、システムが許可し、クライアント自身が対応している通信に限られます。LANへのアクセス、除外されたアプリ、特殊なプロトコル、他の仮想インターフェースは別の経路を通ることがあります。
専線でも、端末から目的地までの全区間が専用ネットワークになるわけではありません。IEPLは主に入口間の専線接続を示します。端末から入口まで、また出口から目的のサービスまでは、それぞれ別のネットワーク経路を通ります。評価するときは回線ラベルだけでなく、経路全体を確認しましょう。
低遅延でも、継続通信が安定するとは限りません。測定パケットは小さい一方、動画、ダウンロード、会議では回線を継続的に使用します。パケットロス、揺らぎ、輻輳制御、出口の品質のほうが、1回の遅延測定より実際の使用感をよく説明できることがあります。