VPN初心者向け用語集：サブスクリプション、ノード、回線、プロトコル、ルーティング、グローバル・ルールモード

VPNやプロキシクライアントを初めて使うと、サブスクリプション、ノード、回線、プロトコル、ルーティング、グローバルモード、ルールモードが混同されがちです。実際には異なる階層にあります。サブスクリプションは設定を配布し、ノードは接続可能なサーバー設定のまとまり、回線はノードまでの経路、プロトコルはクライアントとサーバーの通信方法、ルーティングモードはどのリクエストをプロキシ経由にするかを決めます。

これらの用語を理解するために、ネットワークの原理を最初からすべて覚える必要はありません。実際の接続順に見ると分かりやすくなります。クライアントがサブスクリプションを読み込み、ノード一覧を取得します。ノードを選ぶと、対応するプロトコルで接続を確立します。その後、通信をプロキシ経由にするか直結にするかを、グローバルモードまたはルールモードが判断します。階層を分けて考えれば、多くの設定画面を理解しやすくなります。

まずサブスクリプション、ノード、サーバーを区別する

サブスクリプションURLは更新可能な設定の入口

サブスクリプションURLは通常、サービス側で発行されます。クライアントがアクセスすると、ノード名、サーバーアドレス、ポート、プロトコルのパラメータ、必要な認証情報を取得します。特定のノードそのものではなく、リモート設定一覧に近いものです。サービス側で回線が調整された場合も、クライアントで「サブスクリプションを更新」や「設定を更新」を実行すれば、項目を一つずつ入力し直す必要はありません。

サブスクリプションURLは、エンコードされたテキストや、Clash、sing-boxなどが読み取れる設定形式を返す場合があります。ブラウザーで直接開いて長い文字列が表示されても、リンクが壊れているとは限りません。通常はURL全体をコピーし、クライアントのサブスクリプション読み込み欄に貼り付けます。

ノードはクライアントで選択できる接続設定

ノードには通常、接続先サーバー、ポート、プロトコル、認証パラメータ、通信設定が含まれます。クライアント一覧の「東京」「シンガポール」「アメリカ」などは、多くの場合、識別しやすくするためのラベルです。同じノード名でも、実際のサーバーや入口、ネットワーク経路が完全に同じとは限りません。名前が異なっていても、一部の基盤を共有している場合があります。

「サーバー」は物理または仮想の計算資源を指し、「ノード」はユーザーが接続できる設定項目を指します。一つのサーバーで異なるプロトコルやポートを使えば、複数のノード設定を構成できます。反対に、外部に表示される一つのノードが負荷分散によって複数のバックエンドへ接続されることもあります。ノードを選ぶときは名前だけで判断せず、実際の接続状況と用途を基準にしてください。

• ✅ サブスクリプション更新後は、既存ノードが置き換えられたり名前変更されたりしていないか確認する。
• ✅ 複数のサブスクリプションを読み込むときは、提供元ごとに分かりやすいグループ名を付ける。
• ✅ ノードが使えないときは、まずサブスクリプションを更新し、その後クライアントの時刻とネットワーク権限を確認する。
• ❌ サブスクリプションURLを単一ノードのアドレスと考えて手動で分解しない。
• ❌ 地域名だけで回線品質や具体的な経路を推測しない。

IEPL専用線・中継・直結の違い

回線の種類は、ローカルネットワークから遠隔ノードへ到達する方法を表します。ShadowsocksやTrojanなどのプロトコルとは別のものです。同じプロトコルを使うノードでも異なる回線を利用でき、同じ種類の回線で異なるプロトコルを運ぶこともできます。「回線」と「プロトコル」を混同するのは、初心者が回線を選ぶ際によくある誤解です。

直結だから必ず速いとは限らない

直結は中継を挟まない一方、ネットワーク経路が最短とは限りません。通信事業者間や地域間、国際出口が混雑すると、データが迂回することがあります。反対に、位置の適切な中継入口を使えば、ローカルから入口までを比較的安定した経路に収め、その後段で国際転送を行えます。したがって、経由するサーバー数だけで速度を判断することはできません。

中継はノードの所在地を意味しない

ノードに「日本」と表示されている場合、通常は出口が日本にある、または日本出口を主な用途としていることを示します。一方、中継入口は別の地域にある可能性があります。Webサイトから見える出口IPと、クライアントが最初に接続する入口は、必ずしも同じ場所ではありません。問題を切り分ける際は、「入口への接続失敗」と「出口サービスの異常」を区別してください。

IEPLは回線リソースであり、暗号化プロトコルではない

IEPLは、国際イーサネット専用線による接続を表すために使われます。解決するのはネットワークの一部の伝送経路であり、クライアントの認証、暗号化、通信のカプセル化方式を定義するものではありません。クライアントは引き続き、具体的なプロトコルでサーバーに接続する必要があります。「IEPLノード」と表示されていたら、そのノードの一部の伝送経路で専用線リソースが使われていると理解してください。IEPLというクライアントプロトコルが存在するという意味ではありません。

主要なプロトコル名の意味

プロトコルは、クライアントとサーバーがデータを認証、カプセル化、転送する方法を決めます。クライアントがノードで使われているプロトコルと通信パラメータに対応していなければ、サーバーアドレスとポートが正しくても接続できません。以下の名称はサブスクリプション設定でよく見かけますが、設計上の重点はそれぞれ異なります。

Shadowsocksは設定が比較的コンパクトで、対応クライアントも多い一方、暗号化方式をサーバー側と一致させる必要があります。VMessとVLESSは、WebSocket、gRPC、TCP、TLS、REALITYなどの通信層・セキュリティ層と組み合わせて使われることが多くあります。サブスクリプション読み込みの利点は、関連するパラメータを一つの完全な設定としてクライアントに渡し、手入力の漏れを減らせることです。

TrojanはTLSやドメイン証明書の検証と組み合わせて使われることが多くあります。端末の時刻が大きくずれていたり、ドメインの入力が一致しなかったり、証明書検証に失敗したりすると、接続を確立できない場合があります。証明書エラーが出たら、システム時刻とサブスクリプション設定を確認し、証明書検証をすぐに無効にしないでください。

Hysteria2とTUICはいずれもQUICに依存し、主にUDP上で動作します。高遅延やパケットロスのある一部のネットワークでは、良好な通信性能を示す場合があります。ただし、ローカルネットワークが該当するUDP通信を許可していることが前提です。会社、学校、ホテル、公共ネットワークなどでUDPが制限されていると、これらのノードは接続に失敗する可能性があります。その場合は、TCPベースの利用可能なノードに切り替えて比較してください。

サブスクリプションURLをクライアントに読み込む方法

クライアントによってボタン名は異なりますが、読み込みの流れはほぼ同じです。信頼できるサービス画面からサブスクリプションURLをコピーし、クライアントでリモート設定またはサブスクリプションを追加します。解析が完了したらノードを選択します。各項目の用途を明確に理解している場合を除き、サブスクリプションの内容を1行ずつ手動設定に書き換えないでください。

1. URL全体をコピー：先頭、パラメータ、末尾の文字が欠けていないことを確認します。一部のチャットアプリでは長いURLが途中で切れることがあるため、コピー後に文字列全体を確認してください。
2. サブスクリプション管理を開く：クライアントで「サブスクリプション」「設定」「リモート設定」「URLから読み込む」などの入口を探します。
3. 貼り付けて保存：サブスクリプションを識別しやすい名前を付けてから更新します。クライアントで設定形式の選択を求められた場合は、サービスの案内に従ってください。
4. ノードを選択：プロキシグループまたはノード一覧から目的の地域を選び、出口が指定されていない空の設定のままにしないでください。
5. 実行モードを選択：日常利用ではまずルールモードを使い、プロキシ経路全体を確認するときだけ一時的にグローバルモードへ切り替えます。
6. 接続を確認：ネットワーク確認ページを開き、出口IP、DNS、想定した結果が一致することを確認してから、実際に使うWebサイトやアプリをテストします。

サブスクリプションを更新すると、通常はそのサブスクリプションから生成されたノードが上書きされます。サブスクリプション内のノードパラメータを直接変更しても、次回更新時に元へ戻る可能性があります。長期的に使うカスタムルールは、リモートノードを直接変更せず、クライアントが対応する上書き設定、拡張設定、ローカルルールファイルに保存するのが適しています。

サブスクリプションURL
  → クライアントがリモート設定を取得
  → ノードとプロキシグループを解析
  → ノードを選択
  → プロトコル接続を確立
  → ルーティングルールがリクエストの行き先を判断
  → プロキシまたは直結

• ✅ 読み込み後は、「追加完了」と表示されたかだけでなく、ノード一覧が正常に表示されているか確認する。
• ✅ クライアント内蔵のサブスクリプション更新機能を定期的に使い、設定の変更を取得する。
• ✅ クライアントを変更する前に、新しいクライアントがサブスクリプション内のプロトコルと通信方式に対応しているか確認する。
• ❌ 出所の不明なWebサイトで、認証情報を含むサブスクリプションURLを変換しない。
• ❌ システムネットワークを制御するクライアントを複数同時に有効にして、問題を切り分けない。

グローバル・ルール・直結モードの選び方

実行モードは、クライアントに入った通信をどのように処理するかを決めます。ノード自体を変更したり、直結回線を中継回線に変えたりするものではありません。初心者は「グローバル」を速度が速くなる設定と考えがちですが、実際にはより多くのリクエストを現在のプロキシノードへ渡すことを意味します。

グローバルモード：多くの通信を一律にプロキシ経由にする

グローバルモードは、ルール漏れを一時的に切り分けたり、特定のWebサイトがプロキシ経路でアクセスできるか確認したりするのに適しています。一方、ローカルサイト、LANサービス、プロキシ不要のアプリまで迂回する可能性があり、余計な遅延が発生します。プリンター、ルーター管理画面、ローカル開発サービスに影響することもあります。

ルールモード：ドメイン、IP、アプリごとに分類

ルールモードは、ルールセットに基づいてリクエストを判定します。一般的には、LANアドレスを直結し、ローカルでよく使うWebサイトを直結し、国際回線が必要なドメインをプロキシへ送り、広告や悪意のあるドメインをルールでブロックします。ルールはドメインの末尾、完全なドメイン名、IP範囲、プロセス名、ルールセットなどを基準にできますが、具体的な機能はクライアントとOSに依存します。

ルールの照合には通常、順序があります。具体性の高いルールを広いルールより前に置き、最後に一致しなかった通信はフォールバックルールで処理します。たとえば、あるドメインが先にある直結ルールに一致すると、後ろのプロキシルールは適用されません。「特定のWebサイトが想定したノードを通らない」ときは、ノードを何度も切り替えるのではなく、接続ログで一致したルールを確認してください。

直結モード：プロキシノードを経由しない

直結モードは、プロキシを一時停止したり、ローカルネットワークの状態を比較したり、LAN機器へアクセスしたりする際に使います。一部のクライアントでは、「システムプロキシを無効化」しても、システムプロキシに従うアプリを制御しなくなるだけで、すでに有効なTUNモードは通信を処理し続ける場合があります。接続を一時停止するときは、システムプロキシのスイッチだけでなく、クライアントの状態も確認してください。

システムプロキシ、TUN、アプリ別ルーティングの違い

システムプロキシは、OSがアプリに提供するプロキシ設定です。ブラウザーや一部のデスクトップソフトはこれに従いますが、ゲーム、コマンドラインツール、独自にネットワーク接続を行うアプリは無視する場合があります。そのため、ブラウザーでは有効なのに、他のアプリは直結のままということがあります。

TUNモードは仮想ネットワークインターフェースを通じて、より広い範囲のIP通信を取り込み、クライアントにプロキシか直結かを判断させます。システムプロキシ設定を読み取らないアプリにも有効ですが、通常は追加のシステム権限が必要です。また、他のネットワークツール、ファイアウォール、仮想マシン、企業向けセキュリティソフトと経路が競合しやすくなります。

アプリ別ルーティングは、プロセスやアプリごとに通信先を決めます。モバイル環境では「選択したアプリのみプロキシ」や「選択したアプリを除外」といった機能が一般的です。デスクトップクライアントではプロセスルールを利用できる場合があります。アプリの更新で実行ファイルのパスが変わると、既存のルールに一致しなくなる可能性があるため、実際のプロセス名を確認してください。

• ✅ ブラウザーでは有効なのにゲームで使えない場合は、ゲームがシステムプロキシを無視していないか確認する。
• ✅ TUNを有効にしてLANへアクセスできなくなった場合は、LANバイパスとルーティングルールを確認する。
• ✅ アプリ別ルーティングが機能しない場合は、プロセス名とクライアントの実行権限を確認する。
• ❌ システムプロキシ、TUN、その他のネットワークツールに同じ通信を重複して制御させたまま、感覚だけで原因を判断しない。

DNSリークとルーティングが関係する理由

ドメインへアクセスする前に、端末は通常DNSを使ってドメイン名をIPアドレスへ変換します。Web通信はプロキシ経由でも、DNSリクエストが想定外のローカルリゾルバーへ送られると、アクセス先ドメインの名前解決が外部に伝わる可能性があります。また、プロキシ出口の地域と一致しないアドレスが返されることもあります。これは一般にDNSリーク、またはDNS経路の不一致と呼ばれます。

ドメインに基づくルーティングでは、クライアントが適切な段階でドメイン情報を取得する必要があります。アプリが先に名前解決を行い、IPアドレスだけをクライアントへ渡すと、ドメインルールが一致しない場合があります。DNSが地域の影響を受けたアドレスを返すと、コンテンツ配信ネットワークが適切でない入口を選ぶこともあります。そのため、最新のクライアントではDNS、ルール照合、プロキシ接続を同じ設定体系で処理することがよくあります。

よくある確認手順

1. クライアントのDNSモジュールが有効か確認し、現在の名前解決方式を確認する。
2. ブラウザー独自の暗号化DNS設定がクライアントの設定を迂回していないか確認する。
3. 対象ドメインが直結、プロキシ、フォールバックのどのルールに一致したか確認する。
4. OSとブラウザーのDNSキャッシュを削除してから再テストする。
5. ネットワーク確認ページで、出口IPとDNSリゾルバーが現在のモードの想定に合っているか比較する。

DNSテストの結果は、リゾルバー名だけで判断しないでください。一部のパブリックDNSサービスはグローバルな振り分けを使うため、表示される地域と実際のネットワーク経路が異なる場合があります。重要なのは、リクエストが想定どおりクライアントで処理されているか、ローカル通信事業者のリゾルバーが使われていないか、モード変更後に結果が合理的に変化するかを確認することです。

プラットフォームごとのクライアントの違い

同じサブスクリプションでも、プラットフォームによって表示方法や利用できる機能が異なる場合があります。通常の原因はサブスクリプションの内容ではなく、OSの権限、クライアントのコア、通信を取り込む方法の違いです。

Windows

Windowsクライアントは通常、システムプロキシとTUNの両方を提供します。システムプロキシはブラウザーやシステム設定に従うソフトに適しています。ゲーム、ストアアプリ、一部のコマンドラインプログラムにはTUNが必要な場合があります。TUNを有効にすると、仮想ネットワークアダプターの作成や経路の追加のため、管理者権限を求められることがあります。

macOS

macOSのシステムプロキシも、すべてのアプリを制御できるわけではありません。ネットワーク拡張や仮想インターフェースを使う場合、システムからユーザーの許可を求められます。クライアント更新後に接続が不安定になったら、ネットワーク拡張の権限が有効なままか、システムに別のVPN設定が残っていないか確認してください。

Android

Androidクライアントは通常、システムVPNインターフェースを通じて通信を制御し、アプリ別ルーティングにも対応します。OSは通常、同時に一つのアクティブなVPN経路しか許可しないため、他のファイアウォール、広告ブロック、企業向けネットワークアプリがプロキシクライアントと入れ替わることがあります。

iOSとiPadOS

iOSとiPadOSのクライアントは、システムが提供するネットワーク拡張機能に依存します。対応するプロトコルコアはクライアントによって完全には同じではありません。読み込みは成功したのにノードを起動できない場合は、まずプロトコルと通信方式が対応しているか確認してください。アプリ別の制御も、アプリの機能と端末管理ポリシーの影響を受けます。

接続に失敗したときは階層ごとに確認する

有効な切り分け方法は、複数のノードを続けてクリックすることではなく、どの層で問題が起きているかを判断することです。まずローカルネットワークを確認し、次にサブスクリプションとノード、その後にプロトコル接続、最後にルールとDNSを確認します。一度に一つの変数だけを変更すれば、どの調整が効果を生んだのか把握できます。

• ✅ ローカルネットワーク層：プロキシを無効にし、通常のWebサイトへ正常にアクセスできるか確認する。
• ✅ サブスクリプション層：サブスクリプションを更新し、ログインページやエラーテキストではなくノードが返されているか確認する。
• ✅ ノード層：同じサブスクリプション内の別の利用可能なノードで比較する。
• ✅ プロトコル層：ログにあるタイムアウト、証明書、認証、UDP、未対応パラメータのメッセージを確認する。
• ✅ 通信制御層：システムプロキシまたはTUNが想定どおり有効で、他のツールと競合していないか確認する。
• ✅ ルール層：対象接続に一致したルールとプロキシグループを確認する。
• ✅ DNS層：名前解決経路、キャッシュ、ブラウザー独自の設定を確認する。
• ❌ ノード、プロトコル、DNS、実行モードを同時に変更しない。そうすると原因を特定できなくなる。

ログの「タイムアウト」は、規定時間内に接続が完了しなかったことを示すだけで、サーバー、回線、ローカルネットワークのどこに問題があるかを単独で示すものではありません。「認証失敗」は認証情報やシステム時刻の問題である可能性が高く、「証明書名の不一致」ではドメイン、TLS設定、システム時刻を確認します。「未対応のプロトコルまたは通信方式」なら、クライアントのコアバージョンを確認してください。

この階層構造を理解すると、設定画面の用語をつなげて考えられます。サブスクリプションは設定を提供し、ノードは接続先を示し、回線は到達経路に影響し、プロトコルは通信方法を定め、システムプロキシやTUNは通信を取り込み、ルールモードはリクエストの行き先を決め、DNSは名前解決とルーティング判定に関わります。選ぶときは機能一覧の長さを追うのではなく、現在のプラットフォームとネットワーク環境で安定して使えることを基準にしてください。