VPN 用語解説：サブスクリプション、ノード、プロトコル、ルール分岐とは

VPN用語を理解するために、ネットワーク理論を最初からすべて暗記する必要はありません。サブスクリプションは設定の入口、ノードは選択可能な出口、プロトコルはクライアントとサーバーのデータ交換方法、ルール分岐はどのリクエストをノード経由にするかを決める仕組みです。この関係を整理すれば、取り込み失敗、回線速度の低下、ウェブページが開かないといった問題を、ボタンを何度も切り替えて試すのではなく、層ごとに確認できます。

日常的に使われる「VPN」は、ネットワーク高速化サービス全体を指す場合もあれば、システムに備わる仮想プライベートネットワーク機能を指す場合もあります。一方、Shadowsocks、VMess、Trojan、VLESSなどは、プロキシプロトコルやそのエコシステムで使われる通信方式に近いものです。対応形式を扱えるクライアントで管理できますが、同じクライアントに表示されるからといって、すべてを同じ技術として扱うことはできません。

サブスクリプションURLと設定ファイル：何が含まれているのか

サブスクリプションURLは通常のウェブページのブックマークでも、1本の固定回線でもありません。多くの場合、サービス側が動的に生成する設定の集合を指し、ノードアドレス、ポート、プロトコル種別、認証情報、通信パラメータ、ノード名、グループ情報などが含まれます。クライアントがURLへアクセスすると内容を解析し、複数の利用可能な設定をノード一覧に表示します。

そのため、「サブスクリプションを取り込む」ことと「ノードに接続する」ことは別の操作です。前者はリモート設定をクライアントへ同期する操作で、後者で初めて一覧から1つを選んで接続を確立します。サブスクリプションの更新後は、古いノードが置き換えられたり、名前やパラメータが変更されたりすることがあります。クライアントがローカルキャッシュを使い続けていると、すでに無効な設定が表示される場合があります。

サブスクリプションURLを適切に管理すべき理由

サブスクリプションには通常、アカウントやプランを識別するための認証情報が含まれています。URLを入手した人がノード設定を読み取れる可能性があるため、スクリーンショット、フォーラム、問い合わせ件名、公開コードリポジトリなどにそのまま掲載するのは避けてください。問題を調べる際は、クライアント名、エラーが発生した段階、ノードの種類を伝え、完全なURLと認証項目は隠しましょう。

「サブスクリプション変換」もよく使われる用語です。ある設定形式を、別のクライアントで読み込める形式へ変換することを指し、ノードの統合、ポリシーグループの名前変更、ルール分岐の生成などを行う場合もあります。変換時には元のサブスクリプション内容を読み取るため、サービス事業者が明確に提供している変換機能を優先し、出所の不明なページへ認証情報を渡さないようにしてください。

• ✅ 取り込む前に、URLが現在利用しているサービスの管理画面から取得したものか確認する。チャット履歴から転送されたURLは使わない。
• ✅ 取り込み後はまず更新を実行し、想定したプロトコルと地域のノードが一覧に表示されるか確認する。
• ✅ クライアントを変更するときは、管理画面からサブスクリプションを再コピーし、古いキャッシュや形式による影響を減らす。
• ❌ 完全なサブスクリプションを、公開速度テストのスクリーンショット、共有ドキュメント、公開リポジトリに載せない。
• ❌ ブラウザーで内容を直接表示できるかどうかだけで、サブスクリプションの有効性を判断しない。

ノード、サーバー、出口アドレスの違い

ノードとは、クライアントから選択できる接続設定のまとまりです。通常は特定のサーバーや接続入口を指しますが、ノード名と物理サーバーが1対1で対応するとは限りません。複数のノードが同じ接続システムを共有することもあれば、負荷、通信事業者、回線ポリシーに応じて異なるバックエンドへ振り分けられることもあります。そのため、一覧の名称は設定の用途を見分けるための情報として使い、データセンター資産の一覧と直接解釈しないでください。

ノードに接続すると、リクエストは通常まずノードの入口へ届き、その後サービス側から目的のサイトへアクセスします。目的のサイトから見える公開元アドレスは、一般にローカルネットワークの公開アドレスではなく、サービス側の出口アドレスです。「出口地域」とは、この出口アドレスをもとに対象サービスが推測する地域を指します。コンテンツの地域設定、検索結果、サービスの利用範囲に影響する場合があります。

遅延、帯域幅、実際の速度

遅延はリクエストの往復に必要な時間、帯域幅は単位時間あたりに運べるデータ量を表し、同じ指標ではありません。低遅延の回線は頻繁な操作に向きますが、必ずしもダウンロード速度が速いとは限りません。帯域幅の大きい回線でも、混雑、パケットロス、ローカルネットワークの不安定さがあれば性能を発揮できないことがあります。クライアントに表示される遅延は通常、入口への測定値にすぎず、特定サイトまでの経路全体の性能を示すものではありません。

負荷は、ノードが現在抱えている接続数や通信量の圧力を表します。負荷の算出方法はクライアントやサービスによって統一されておらず、サーバーからの報告を使う場合もあれば、ローカル測定だけで推定する場合もあります。補助情報として扱い、1つのステータス表示だけで回線全体を判断しないようにしましょう。

プロトコルと通信方式：Shadowsocks、VMess、Trojan、VLESSの違い

プロトコルは、通信する双方がデータをどのようにカプセル化、認証、転送するかを定義します。クライアントが同じプロトコルを実装し、対応する認証情報と通信パラメータを取得して初めて、サーバーとの接続を確立できます。同じプロトコル名でも設定を自由に混用できるとは限りません。下位の通信方式、暗号化層、サーバー名、パス、証明書の検証方法が異なる場合があるためです。

Shadowsocks

Shadowsocksは軽量な暗号化プロキシプロトコルで、設定は通常、サーバーアドレス、ポート、暗号化方式、パスワードを中心に構成されます。構造が比較的シンプルで、多くのクライアントが対応しています。ただし、主にプロキシ経路を提供するものであり、システム上のすべての通信が自動的にプロキシを通るわけではありません。アプリの通信を取り込むかどうかは、システムプロキシ、仮想ネットワークインターフェース、ルール分岐によって決まります。

VMessとVLESS

VMessはV2Rayエコシステムでよく使われ、認証とプロトコル固有の処理ロジックを備え、さまざまな下位通信方式と組み合わせられます。VLESSはより簡潔な設計で、通常はTLSなどの外側の仕組みに暗号化と安全な通信を任せます。名称は似ていますが、認証項目とデータ形式が異なるため、直接置き換えることはできません。取り込み後にプロトコル非対応と表示される場合は、クライアントのコアが古いか、現在のバージョンが必要な機能を組み込んでいない可能性があります。

Trojan

Trojanは通常TLS上で動作し、サーバーアドレス、認証パスワード、サーバー名、証明書検証が主な設定項目です。安全な接続を確立するには、TLSパラメータが正しく設定されている必要があります。システム時刻の大きなずれ、誤ったサーバー名、検証できない証明書チェーンはいずれもハンドシェイク失敗の原因になります。証明書検証を無効にすると一時的にエラーを回避できる場合がありますが、接続の検証強度が下がるため、通常の解決策にはしないでください。

Hysteria2とTUIC

Hysteria2とTUICはいずれもUDPベースのQUIC機能を利用し、パケットロス、輻輳制御、多重化などの問題に対応します。品質の変動が大きいネットワークでは柔軟に動作する可能性がありますが、ローカルネットワーク、ルーター、サーバーがUDPを正常に通せることが前提です。現在のネットワークがUDPを制限していると、クライアントがタイムアウトする一方、TCPやTLSベースの別設定は接続できる場合があります。

直接接続、リレー接続、IEPL専線：回線名の見方

直接接続は、クライアントがサービス事業者の追加の国内中継を経由せず、海外または遠隔地のサーバー入口へ直接アクセスする方式です。構成がシンプルで経由箇所も少ない一方、実際の経路はローカル通信事業者とインターネットのルーティングによって決まるため、混雑時間帯には迂回、輻輳、パケットロスが発生することがあります。

リレー接続は、クライアントがまず近い接続サーバーへ接続し、その接続サーバーが遠隔地の出口へ通信を転送する方式です。変動しやすいインターネット経路の一部を、サービス事業者が管理できる転送経路に置き換えられる点に意味があります。ただし、リレー接続が必ず直接接続より速いとは限りません。接続地点との距離が不適切だったり、転送経路が混雑していたり、出口自体に制限があったりすると、利用感は低下します。

IEPLは国際イーサネット専線サービスを表す一般的な略称で、専用の伝送特性を持つ国際企業ネットワーク接続を説明する際に使われます。サブスクリプションサービスのノード名に「IEPL専線」とある場合、接続や国際区間の伝送に専線リソースを使っている可能性がありますが、ノード名だけではネットワーク全体の構成、リソースの品質、全区間が専用かどうかまでは確認できません。この種の回線は、混雑時間帯の安定性、通信事業者ごとの接続状況、サービス事業者による回線構成の説明を確認して判断しましょう。

専線は伝送経路と回線の提供方式を表すもので、アプリケーション層の暗号化プロトコルとは異なります。専用の伝送方式を採用していても、クライアントとサーバー間では正しいプロトコル、認証、暗号化設定が必要です。

グローバルモード、ルールモード、直接接続モード

回線接続が成功したということは、クライアントとサーバーが通信できたことを示すだけです。どのアプリのリクエストをこの経路へ送るかは、ルーティングモードが決めます。代表的なモードにはグローバル、ルール、直接接続があります。クライアントによってボタン名は多少異なりますが、判断の基本はほぼ同じです。

グローバルモードでは、クライアントが取り込める範囲の通信をすべて、選択したノードで処理しようとします。「あるリクエストをノード経由にするとアクセスできるか」を素早く確認するのに適していますが、国内サイト、ローカルネットワーク機器、地域判定に敏感なサービスにも影響する可能性があります。ここでいう「グローバル」もクライアントの取り込み能力に左右されます。ブラウザーのプロキシだけを設定した場合、システムプロキシを参照しない他のアプリはノードを経由しないことがあります。

ルールモードでは、ドメイン、アドレス範囲、アプリ、ポート、ルールセットなどに基づき、リクエストをプロキシ、直接接続、拒否のいずれにするか決めます。長期利用に向いていますが、ルールが正確で最新かどうかに左右されます。ドメインルールに一致しなかったり、対象サービスがアドレスを変更したり、DNSの結果が変わったりすると、ウェブページの一部は直接接続、一部はプロキシ経由になることがあります。

直接接続モードは通常、リクエストを遠隔地のノードへ送らないことを意味します。一時的にプロキシを停止する用途にも、ルールシステムの出口アクションにも使えます。直接接続はクライアントを終了することとは違います。クライアントは動作を続け、DNS、ルール、ローカルネットワークのリクエストを処理する場合がありますが、最終的にローカルネットワークの出口を選びます。

システムプロキシと仮想ネットワークインターフェースモード

システムプロキシは、プロキシアドレスをOSのネットワーク設定へ書き込み、その設定に従うアプリが自発的にプロキシリクエストを送る仕組みです。ブラウザーは対応していることが多い一方、一部のアプリ、コマンドラインプログラム、独自のネットワーク処理を実装したソフトウェアはシステムプロキシを無視する場合があります。

仮想ネットワークインターフェースモードは、TUNモードとも呼ばれます。仮想ネットワークインターフェースを通じて、より広い範囲のIP通信を取り込み、クライアントがプロトコル変換とルーティング判断を行います。システムプロキシに対応しないアプリに適していますが、対応するシステム権限が必要で、ローカルファイアウォール、他のネットワークソフトウェア、ルーティングテーブルの競合の影響も受けやすくなります。

1. まずルールモードで、状態が正常なノードに接続し、よく使うウェブページを開けるか確認します。
2. 特定のアプリに通信がない場合は、システムプロキシに従うアプリか確認し、必要に応じて仮想ネットワークインターフェースモードを試します。
3. 特定のドメインだけ失敗する場合は、接続ログでルールの一致結果と最終出口を確認します。
4. ローカルサービスに影響が出る場合は、LANアドレスと必要なドメインに直接接続ルールを追加します。
5. ルールを変更したら、以前のルーティングを使い続けないよう、リクエストを新たに実行します。

DNSリーク、汚染、ルール分岐の競合

DNSはドメイン名をネットワークアドレスへ変換します。DNSリークとは通常、管理された経路や指定したリゾルバーで処理すべきクエリが、ローカルネットワークのデフォルトリゾルバーへ送信されることを指します。これによりDNSリクエストと実際のアクセス経路が一致しなくなり、アクセス先ドメインに関する問い合わせ情報が露出する可能性もあります。プロキシプロトコル自体が必ず無効という意味ではなく、ドメイン解決が想定した経路で行われていないということです。

DNS汚染や誤った解決では、ドメインに対して不正確なアドレス、到達できないアドレス、現在の回線に適さないアドレスが返されます。この場合、ノードには正常に接続できても、対象サイトが開かないことがあります。ノード変更で解決したように見えても、実際には新しい接続で異なるDNS解決が行われた可能性があります。

ルール分岐の競合は、「ドメインルール」と「アドレスルール」の判定が一致しない場合によく起こります。たとえば、ドメインはプロキシと判定されたのに、解決リクエストがローカルDNSを通り、そのアドレスがアドレスルールで直接接続と判定されるケースです。メインページはプロキシ経由でも、画像、ログインAPI、メディアリソースが別のルールに一致することもあります。ページは開くのにログインできない、表示内容が不完全、プレーヤーが待機し続けるといった症状につながります。

リモートDNS、ローカルDNS、Fake IP

ローカルDNSは通常、現在のネットワークが提供する、またはシステムで指定されたリゾルバーを使います。リモートDNSでは、クライアントがクエリを遠隔地または指定したリゾルバーへ渡し、解決経路とプロキシ出口を一致させるために使われることがあります。ドメインごとに使い分けることもでき、ローカルドメインはローカルDNS、国際的なサービスはリモートDNSに任せるといった構成が可能です。

Fake IPは、一部のクライアントがドメインベースのルール分岐を強化するために使う仕組みです。クライアントはまず、予約済みアドレス範囲の一時アドレスをアプリへ返し、内部に元のドメインとの対応関係を保存します。アプリがその一時アドレスへ接続すると、クライアントがドメインを復元してルールを適用します。これは対象サイトが実際にそのアドレスを使っているという意味ではありません。LANアプリ、ゲーム、セキュリティソフトなどで互換性の問題が出る場合は、すべてのルール分岐を削除するのではなく、該当ドメインを除外リストへ追加しましょう。

クライアントへの取り込みとプラットフォームごとの違い

クライアントは端末上で動作する接続ツールで、サブスクリプションの解析、プロトコルの実装、ノードの選択、システムプロキシや仮想ネットワークインターフェースの確立、DNSとルール分岐の実行を担います。サービス事業者、プロトコル、クライアントは異なる層の要素です。サービス事業者がアカウントと回線を提供し、プロトコルが通信方式を定め、クライアントがこれらの設定を実行します。

WindowsとmacOSのクライアントは通常、システムプロキシと仮想ネットワークインターフェースの両方に対応しますが、権限の仕組みは異なります。Windowsでは仮想ネットワークインターフェースのドライバー、ファイアウォール、他のネットワークフィルタリングソフトに注意が必要です。macOSではネットワーク拡張機能やVPN設定の権限を確認し、システムプロキシと他のネットワークツールの競合にも対処します。クライアントを終了する前にシステムプロキシを元へ戻すと、停止したローカルポートをシステムが参照し続ける事態を避けられます。

Androidのクライアントは通常、システムVPNインターフェースを通じて通信を取り込みます。同時にこのインターフェースを利用できるネットワークツールは、一般に1つだけです。アプリごとのルール分岐はよく使われますが、メーカーごとのバックグラウンド制限によって接続が中断することがあります。iOSとiPadOSはシステムが提供するネットワーク拡張機能に依存し、対応するプロトコルやルールは、アプリに組み込まれたコアとシステム権限によって決まります。

Linux環境では、コマンドライン用コア、デスクトップフロントエンド、サービスプロセスなどの形態が一般的です。ブラウザーではアクセスできるのにターミナルのコマンドではアクセスできない場合、デスクトップ側のプロキシだけが設定され、コマンドラインプログラムが関連する環境変数を読み取っていない可能性があります。反対に、仮想ネットワークインターフェースが通信を取り込んでいる場合は、ルーティングテーブル、DNS、ファイアウォールルールを重点的に確認します。

サブスクリプションの取り込み
  ↓
クライアントによる設定解析
  ↓
ノードとプロトコルの選択
  ↓
プロキシまたは仮想ネットワークインターフェースの確立
  ↓
DNS解決とルールの一致
  ↓
プロキシ / 直接接続 / 拒否
  ↓
対象サービスへのアクセス

取り込みに失敗したときの確認方法

クライアントがサブスクリプションを認識できないと表示した場合は、まずコピーした内容が完全か、URLがまだ有効か、クライアントがサービス側の出力形式に対応しているかを確認します。更新はできるのに一覧が空の場合は、絞り込み条件、ノードグループ、クライアントログを確認してください。ノードは存在するのにすべて接続に失敗する場合は、システム時刻、ローカルネットワークの制限、プロトコルコアのバージョン、認証パラメータを確認します。

• ✅ サブスクリプションをダウンロードできない：URLの完全性、ネットワーク接続、サービス管理画面の状態を確認する。
• ✅ ダウンロードできるが解析できない：クライアントの形式対応とコアのバージョンを確認する。
• ✅ 一部のノードだけ失敗する：プロトコル、入口の種類、通信パラメータに共通する点を比較する。
• ✅ ノードには接続できるがアプリに通信がない：システムプロキシ、仮想ネットワークインターフェース、アプリごとのルール分岐を確認する。
• ✅ ウェブページの一部だけ異常：DNS、ルールの一致、リソースごとのドメインの出口を確認する。
• ❌ ログを確認せずにクライアントを何度も再インストールしない。設定の誤りはそのまま再び取り込まれることが多いためです。

概念マップ：問題が起きたら最初に確認する層

すべての用語を接続の流れに戻すと、安定したトラブルシューティングの方法が見えてきます。管理画面がサブスクリプションを生成し、サブスクリプションにノード設定が含まれ、クライアントが設定を解析してプロトコルコアを呼び出します。プロトコルが入口サーバーへ接続し、回線がデータを出口へ運び、DNSとルール分岐がリクエストの解決方法と経路を決めます。各層には異なる症状があり、それぞれに適した対処方法があります。

サブスクリプション層の問題は、更新失敗、解析失敗、ノード一覧の異常として現れることが多いです。ノードとプロトコル層の問題は、ハンドシェイク失敗、認証失敗、接続タイムアウトとして現れます。回線層では、速度の変動、パケットロス、特定の通信事業者での経路不良が起こりやすくなります。ルール分岐とDNS層の問題は、一部サイトの異常、地域判定の不一致、特定アプリの通信不足として現れやすい傾向があります。

ログは接続処理を観測できる記録です。ログを読むときは、各行の内部実装まですべて理解する必要はありません。まず「サブスクリプションのリクエストは成功したか」「どのノードを選んだか」「どのプロトコルを使ったか」「ドメインはどのルールに一致したか」「最終的にどの出口を通ったか」という重要なイベントを探します。エラーを該当する層に分類し、サブスクリプションの更新、ノードの変更、モードの調整、ルールの修正のいずれを行うか決めましょう。