VPN初心者向け用語ガイド：サブスクリプション・ノード・ルーティングを解説

VPNを初めて使うとき、混乱しやすいのは操作ボタンよりも、サブスクリプション、ノード、回線、プロトコル、ルーティングといった用語です。それぞれ接続手順の異なる段階を担います。サブスクリプションは設定を届け、ノードは接続先への入口となり、回線はデータが通るネットワーク経路を決め、プロトコルはクライアントとサーバーの通信方法を定めます。ルーティングルールは、どのリクエストをその経路に通すかを判断します。この流れを先に理解すれば、クライアントの各設定も整理して見られるようになります。

この記事では、実際の接続を例に用語同士の関係を説明し、直結、中継、IEPL専線、グローバルモード、ルールモード、システムプロキシ、TUNモード、DNS漏洩が何を意味するのかを整理します。略語を暗記することではなく、問題が起きたときに確認すべき場所を知ることが目的です。

まず接続全体の流れを確認

クライアントを開いてサブスクリプションをインポートすると、サーバーアドレス、ポート、プロトコルのパラメータ、ノード名などの設定が読み込まれます。ノードを選んで接続すると、アプリが生成したリクエストはいったんクライアントに渡されます。クライアントは現在のルーティングモードに基づき、リクエストを直接送るか、カプセル化してリモートノードに渡すかを判断します。リモートノードは目的のサービスへアクセスし、応答を接続経由で返します。

アプリのリクエスト
→ システムプロキシまたは TUN が引き継ぐ
→ ルーティングルールで判定
→ 直結、または選択したノードへ転送
→ ノードに対応するネットワーク回線
→ 目的のサービス
→ 応答が元の経路を通って戻る

この流れでは、「ノード」と「回線」は同じ意味ではありません。ノードは通常、クライアントから選択できる接続設定で、ホスト、ポート、プロトコルなどの情報を含みます。回線は、そのノードの背後にあるネットワーク経路を示します。同じ地域に複数の回線が用意されることもあれば、1つの回線に複数の入口設定が対応することもあります。ノード名だけでは実際の経路を判断しきれないため、回線の種類や用途に関するサービス提供元の説明も確認しましょう。

サブスクリプション、設定、ノードとは

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

サブスクリプションは通常、リンクとして提供されます。クライアント内のログイン状態を通じて取得する場合もあります。クライアントがサブスクリプションへアクセスすると、複数のノード設定と関連パラメータを取得します。サーバー側でノードアドレス、回線名、利用可能な設定が変更されても、ユーザーはクライアントで「サブスクリプションを更新」するだけで、項目を一つずつ入力し直す必要はありません。

サブスクリプションリンクは、一般公開されている通常のウェブページURLではありません。サブスクリプションを識別する認証情報が含まれる場合があるため、パスワードと同じように安全に保管し、公開ページ、スクリーンショット、共有ドキュメントに掲載しないでください。リンクの流出が疑われる場合は、サービス管理画面から再生成するか、サポート窓口へ相談してください。

クライアント内の「ローカル設定」と「サブスクリプション設定」も区別が必要です。手動で作成したノードは通常、その端末だけに保存されます。一方、サブスクリプションから取得したノードは配信元によって管理されます。クライアントによっては、サブスクリプションを更新すると、サブスクリプション由来のノードに加えたローカル変更が上書きされます。そのため、サブスクリプションノードにカスタムパラメータを長期間保存するのは避けたほうがよいでしょう。調整が必要な場合は、クライアントの上書き設定、ルールセット、独立した設定機能を利用してください。

ノードは接続に必要なパラメータのまとまり

ノードには少なくとも、接続先と通信方式をクライアントが把握できる情報が必要です。必要な項目はプロトコルによって異なりますが、一般的にはサーバーアドレス、サーバーポート、認証情報、伝送方式、TLS設定、サーバー名などが含まれます。クライアントはこれらの項目を接続候補としてまとめ、地域名や回線名を使って識別しやすく表示します。

ノードに表示される地域は、通常、出口や回線の位置を示すものです。ただし、アプリが最終的に地域を判断する際には、出口IPのデータベース、DNSの解決結果、ブラウザーの保存情報、アカウント情報、システムのタイムゾーンなども影響します。そのため、ノード名だけを地域判定の根拠にすることはできません。出口を確認するには、接続後にIPチェックでグローバルアドレスとDNSの結果を確認してください。

サブスクリプションの更新とクライアントのアップデートは別

「サブスクリプションを更新」はノードやルールなどの設定を再取得するだけで、「クライアントをアップデート」は新しいプログラムをインストールする操作です。サブスクリプションにクライアントが認識できないプロトコルが含まれている場合、更新だけでは解決しません。現在のクライアントがそのプロトコルと伝送パラメータに対応しているか確認する必要があります。反対に、クライアントが起動できても、サブスクリプションの内容が最新とは限りません。

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

回線の種類は、ローカルネットワークから出口ノードまでデータが通る経路を示します。公衆インターネットの混雑、ネットワーク間接続、ルーティングの変化による影響の受けやすさに関係しますが、名称だけで時間帯ごとの実際の性能を判断することはできません。回線を選ぶ際は、利用地域、目的地、利用時間を合わせてテストしましょう。

回線の種類	基本経路	主な特徴	確認したいポイント
直結	ローカルネットワークからリモートノードへ直接接続	構成がシンプルで、公衆インターネットのルーティングに左右されやすい	利用中の通信事業者と目的地域との接続品質
中継	中継入口へ接続してから出口へ転送	公衆インターネット上の一部の不安定な区間を避けられる場合がある	入口の品質、中継経路、出口の状態
IEPL専線	国際イーサネット専線または同等の伝送経路を利用して接続	一般的な公衆インターネットの直結とは異なる経路構成	サービス提供元が示す入口、出口、利用範囲

直結は「ローカルアプリがプロキシを使わずに通信する」という意味ではありません。ノード回線の文脈では、通常、ユーザーがリモートサーバーへ直接接続することを指します。一方、ルーティングの文脈で「DIRECT」と表示される場合は、リクエストがプロキシノードを経由しないことを示します。同じ言葉に見えても、属する階層が異なります。クライアントのログを読むときは、ノードの経路を指しているのか、ルールの動作を指しているのかを先に確認しましょう。

中継回線では、管理された転送区間が1つ以上追加されます。価値は、入口から出口までの経路を再構成する点にあり、単純にデータを「1拠点多く経由させる」ことではありません。ローカルから中継入口までの接続が安定し、入口から出口までのネットワーク品質も良ければ、公衆インターネットの直結より継続的な通信に適する場合があります。入口が現在のネットワークに合わなければ、結果が逆になることもあります。

IEPLはInternational Ethernet Private Lineの略で、一般には国際イーサネット専線を指します。これはネットワークの伝送や回線構成に関する概念であり、プロキシプロトコルでも、クライアントが対応すべき特別なボタンでもありません。クライアントはShadowsocks、Trojan、VLESSなどのプロトコルで入口へ接続し、その後のデータをサーバー側のネットワークが伝送する場合があります。「IEPLノード」と表示されている場合は、ノードの背後で該当する回線が使われていると理解しましょう。IEPLという名前の暗号化プロトコルが存在するという意味ではありません。

判断のポイント： プロトコルはクライアントとサーバーの通信方法を決め、回線はカプセル化されたトラフィックが主にどのように出口へ到達するかを決めます。同じプロトコルでも回線が同じとは限らず、同じ回線名でも、すべてのローカルネットワークで同じ結果になるとは限りません。

代表的なプロトコルが解決する問題

プロトコルは、クライアントとサーバーの間でセッションを確立し、認証、暗号化、データ伝送を行う方法を定めます。接続を確立するには、クライアントとサーバーが同じプロトコルと適合するパラメータをサポートしていなければなりません。プロトコル名だけでは完全な設定を表せません。伝送層、TLS、サーバー名、その他の拡張パラメータも互換性に影響するためです。

Shadowsocks

Shadowsocksは一般的な暗号化プロキシプロトコルで、設定は通常、サーバー、ポート、パスワード、暗号化方式を中心に構成されます。対応する暗号化方式は実装によって異なる場合があります。インポート後に「対応していない暗号化方式」と表示されたら、ルーティングモードを何度も切り替えるのではなく、まずクライアントのバージョンとコア実装を確認してください。

VMessとVLESS

VMessは識別情報とプロトコル構造を備えたプロキシプロトコルで、さまざまな伝送方式と組み合わせて使われます。VLESSはより軽量に設計されており、それ自体で完全な伝送暗号化を提供するものではありません。実際の構成では、通常TLSなどの安全な伝送層と組み合わせます。名前は似ていますが、設定項目やサーバー側の実装を自由に置き換えることはできません。

サブスクリプションをインポートした後、ノードは表示されるのに接続できない場合は、伝送方式、TLS、サーバー名、パスなどのパラメータがクライアントに正しく読み込まれているか確認してください。サーバーアドレスとポートだけをコピーしても、元の設定を完全に再現できないことがよくあります。

Trojan

Trojanは通常、TLS接続上で動作します。認証情報、サーバー名、証明書の検証が重要な設定です。システム時刻が大きくずれている、サーバー名が誤っている、証明書の検証に失敗しているといった状況では、ハンドシェイクを完了できないことがあります。トラブル解決のために証明書検証を長期間無効にするのは適切ではありません。時刻、ドメイン、設定の入手元を見直してください。

Hysteria2とTUIC

Hysteria2とTUICはいずれもUDPベースの現代的な伝送を重視しており、パケットロスや変動があるネットワーク環境で使われることがあります。ローカルネットワーク、ルーター、サーバー側がUDPを正常にサポートしていることが前提です。同じサブスクリプション内のTCP系プロトコルは接続できるのに、この2種類だけ失敗し続ける場合は、現在のネットワークがUDPを制限していないか、クライアントのコアが対応しているか、システムのファイアウォールが対象プログラムの通信を許可しているかを確認してください。

プロトコルを選ぶときは、略語の新しさだけを追う必要はありません。名称そのものより、クライアントの互換性、回線との適合性、現在のネットワーク条件が重要です。サービス提供元がサブスクリプションでパラメータを指定している場合は、通常、まず元の設定を使いましょう。意味を理解しないまま伝送層やセキュリティ設定を変更するのは避けてください。

システムプロキシ、TUN、アプリ内プロキシ

ノードへの接続に成功したことは、クライアントとサーバーの通信経路が確立したことを示すだけです。次に、アプリのトラフィックをどのようにクライアントへ取り込むかを決める必要があります。一般的な方法には、システムプロキシ、TUNモード、アプリ独自のプロキシ設定があります。

システムプロキシ

システムプロキシは、プロキシアドレスをOSのネットワーク設定に書き込みます。システムプロキシに従うブラウザーやアプリはリクエストをクライアントへ渡しますが、一部のプログラムはシステム設定を無視して直接通信します。そのため、ブラウザーの出口は変わっているのに、コマンドラインツールや特定のアプリはローカルネットワークを使い続けることがあります。

TUNモード

TUNモードは仮想ネットワークインターフェースを通じて、より多くの種類のIPトラフィックを取り込みます。通常、システムプロキシより対象範囲が広く、システムプロキシ設定を読み取らないアプリにも適しています。有効化にはシステムの許可が必要な場合があり、他のネットワークフィルター、企業向けセキュリティソフト、既存の仮想ネットワークインターフェースと競合することもあります。

TUNを使っても、すべてのリクエストがリモートノードを経由するわけではありません。トラフィックがTUNに入った後も、ルールに基づいてプロキシまたは直結を選べます。つまり、「取り込み方式」と「ルーティング方針」は別の軸です。前者はクライアントがどのトラフィックを認識できるかを決め、後者は認識したトラフィックをどう処理するかを決めます。

アプリ内プロキシ

一部のブラウザー、ダウンロードツール、開発ツールでは、HTTPまたはSOCKSプロキシを個別に設定できます。対象範囲が明確なため、特定アプリのテストに適しています。ただし、入力するのはクライアントが提供するローカル待受アドレスであり、互換性のないプロキシ入力欄にリモートノードのパラメータを直接入れるものではありません。アプリを終了しても、この設定はクライアントの状態に自動追従しません。

グローバルモード、ルールモード、直結モード

ルーティングモードは、クライアントが取り込んだリクエストの次の行き先を決めます。名称はクライアントによって多少異なりますが、基本的にはグローバル、ルール、直結の3つに整理できます。

グローバルモード：取り込まれた大半のリクエストを選択したノードへ渡します。ノードが機能しているかを確認したり、ルールのマッチング問題を切り分けたりする際に便利です。
ルールモード：ドメイン、IP、アプリ、ルールセットに基づいて、プロキシ、直結、拒否を選びます。日常利用では最も一般的な方式です。
直結モード：取り込まれたリクエストをローカルネットワークから直接送信します。プロキシ経路を一時的に停止したり、ローカル接続をテストしたりする際に使われます。

ルールは通常、クライアントが定めた順序で照合されます。一般的な条件には、完全なドメイン名、ドメインのサフィックス、IPサブネット、プロセス名、地域データベースの分類などがあります。条件に一致すると対応する動作が実行され、一致しない場合は最終ルールが使われます。「特定のウェブサイトが選択したノードを経由しない」ときは、メイン画面に接続済みと表示されているかだけでなく、接続ログでどのルールに一致したかを確認してください。

ドメインルールとIPルールでは、結果が異なる場合があります。アプリがまずドメインへアクセスするなら、クライアントはドメインに基づいてルーティングできます。一方、アプリが自ら名前解決を行い、IPだけを送信する場合はドメイン情報が見えず、IPルールやスニッフィング機能に頼ることになります。スニッフィングを有効にするとクライアントのトラフィック認識方法が変わるため、クライアントのドキュメントに従って設定してください。あらゆる問題に使える万能スイッチではありません。

ルーティングを切り分ける最も効果的な方法は、一時的にグローバルモードへ切り替えて比較することです。グローバルモードでは使えるのにルールモードでは使えない場合、問題は通常、ルールのマッチング、DNS解決、またはアプリの取り込み範囲にあります。両方のモードで使えない場合は、ノード接続とローカルネットワークの確認に戻りましょう。

DNS解決とDNS漏洩

DNSはドメイン名を接続可能なIPアドレスへ変換します。プロキシ接続が確立していても、DNSリクエストが必ず同じ経路を通るとは限りません。システムの名前解決、クライアント内蔵DNS、ブラウザーの暗号化DNS、アプリ独自の名前解決が同時に存在することもあり、DNSはルーティングの切り分けで見落とされやすい層です。

DNS漏洩とは一般に、プロキシ側または指定したリゾルバーで処理されるはずの問い合わせが、ローカルネットワークのDNSサービスへ送信され続ける状態を指します。検索したドメインの範囲が知られたり、地域判定に食い違いが生じたりする可能性があります。確認時はグローバル出口IPだけでなく、チェックページに表示されるDNSの解決場所が現在の設定と一致しているかも確認してください。

ルールモードでは、DNSの設計が特に重要です。クライアントがまずドメインでルールを照合し、その後にローカルまたはリモートの名前解決を選ぶ場合があります。また、仮想IPによってドメインと接続の対応関係を保持する実装もあります。クライアントごとに仕組みは異なるため、別のソフトのDNS設定をそのまま流用しないでください。変更後にドメインだけ開けずIPではアクセスできる場合は、リゾルバーに到達できるか、ルールによってDNSリクエストが誤った経路へ送られていないか、ブラウザーが独自の暗号化DNSを有効にしていないかを確認します。

ブラウザーのキャッシュやシステムのDNSキャッシュには、古い結果が残ることがあります。回線を切り替えた後も表示内容が変わらないからといって、ノードの切り替えに失敗したとは限りません。まずシークレットウィンドウを開く、対象アプリを終了して再起動する、といった方法を試してください。必要に応じてOSの手順でDNSキャッシュを消去し、その後に出口と解決結果を再確認します。

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

サブスクリプションは複数のプラットフォームで利用できますが、クライアントの機能が完全に一致するとは限りません。違いは通常、OSのネットワークインターフェース、バックグラウンド実行の制限、プロキシコアのバージョン、クライアント独自の設計から生じます。

Windows：一般的なクライアントはシステムプロキシとTUNの両方に対応しています。TUNを有効にする際は、管理者権限、ファイアウォール、他の仮想ネットワークアダプターに注意してください。
macOS：システムプロキシは、システム設定に従うアプリに適しています。より広範囲のトラフィックを取り込む場合は、ネットワーク拡張機能やTUNを使い、システムの許可が必要になることがあります。
iOS：クライアントはシステムが提供するネットワーク拡張機能を使って接続します。バックグラウンド動作、オンデマンド接続、ルール機能は、クライアントの実装とシステムの制限によって異なります。
Android：クライアントは通常、システムのVPNインターフェースを使ってトラフィックを取り込み、アプリ単位でルーティングできる場合もあります。省電力設定がバックグラウンドでの接続維持に影響することがあります。
Linux：ディストリビューションやデスクトップ環境による違いが大きく、GUIクライアント、システムプロキシ、TUN、コマンドラインコアを利用できます。権限とDNS連携については自分の環境で確認が必要です。

別のプラットフォームへ移行するときは、サブスクリプションを再インポートし、画面のスクリーンショットからサーバーとポートだけをコピーしないでください。新しいクライアントがサブスクリプション内のプロトコル、伝送方式、ルール形式に対応しているかも確認します。サービスに公式クライアントがある場合は、サブスクリプション設定に合ったバージョンを使うと、互換性の確認を減らせます。

サブスクリプションのインポートから接続確認まで

初心者は決まった順番で操作し、各ステップで1つの項目だけを確認するとよいでしょう。接続に失敗しても、設定、ノード、取り込み、ルーティング、DNSのどこに問題があるかを素早く判断できます。

信頼できるサブスクリプションを取得する。サービス管理画面からサブスクリプションをコピーするか、クライアント内でログインして取得します。出所が不明な公開設定は使用しないでください。
互換性のあるクライアントを選ぶ。クライアントがサブスクリプションに含まれるプロトコルをサポートし、OSが求めるネットワーク権限を許可できることを確認します。
サブスクリプションをインポートして更新する。ノード名が表示されるか確認します。リストが空の場合は、まずサブスクリプションの読み込み問題を解決してください。
ノードを選んで接続する。ボタンの色だけを見るのではなく、クライアントのログでプロトコルのハンドシェイクが成功したことを確認します。
トラフィックの取り込み方式を確認する。対象アプリの範囲に応じてシステムプロキシまたはTUNを有効にし、用途の分からないプロキシ設定を複数重ねないでください。
まずグローバルモードで検証する。対象のリクエストがノードを経由できることを確認してから、ルールモードへ戻します。
出口とDNSを確認する。グローバルIP、出口地域、DNSの解決結果を照合し、トラフィックが想定どおり送信されているか判断します。
通常のルーティングに戻す。対象ドメインがどのルールに一致したかを確認し、必要な場合だけ関連ルールを調整します。ネットワーク設定全体をリセットする必要はありません。

よくある誤解と切り分けのヒント

ノードは接続済みなのにウェブページが開けない

「接続済み」は、クライアントとノード間のハンドシェイクが完了したことだけを示している場合があります。次に、アプリがシステムプロキシまたはTUNに取り込まれているか、ルールがリクエストを直結にしていないか、DNSで名前解決できるか、ブラウザーが独自のプロキシ設定を使っていないかを確認してください。グローバルモードと複数のアプリで比較するのも有効です。

プロトコルを変えても速度が変わらない

性能はプロトコルだけで決まりません。ローカルの接続環境、回線経路、目的のサービスの応答、現在のネットワーク混雑も影響します。複数のプロトコルが実際には同じ入口と同じ出口回線を使っているなら、プロトコルを切り替えただけでは主なボトルネックが変わらないことがあります。異なる回線タイプを比較し、テスト時間、目的地、アプリをそろえるほうが有効です。

サブスクリプション更新後にカスタムノードが消えた

通常は、サブスクリプション管理下の設定を変更したため、更新時にサーバー側のバージョンで上書きされたことが原因です。カスタムルールはクライアントの上書き領域に保存するか、ローカル設定として別に保存してください。変更前にバックアップをエクスポートし、その内容を公開共有しないよう確認します。

出口地域は正しいのに、サービスが別の地域と判定する

地域判定には、出口IP、DNS、アカウント情報、ブラウザーキャッシュ、位置情報の権限、システム環境などが総合的に使われることがあります。まず古いセッションを消去してDNSを再確認し、多数のノードを頻繁に切り替えるのは避けてください。目的のサービスがアカウント地域に独自のルールを設けている場合は、公開されている案内に従います。ネットワーク出口が変わっても、アカウント属性が自動的に変更されるわけではありません。

ルールモードが一部のアプリにしか適用されない

まず、適用されないアプリがクライアントに取り込まれているかを確認します。システムプロキシではすべてのプログラムを対象にできず、TUNのアプリ除外設定が特定のプロセスを除外している場合もあります。ログにそのアプリの接続記録がまったくないなら、問題は取り込み層にある可能性が高いでしょう。ログはあるものの動作が直結になっているなら、ルール層を確認します。

要点： サブスクリプションがノード設定を届け、ノードが特定のプロトコルで入口への接続を確立し、回線が入口から出口までのデータを伝送します。システムプロキシまたはTUNがアプリのトラフィックを取り込み、ルーティングルールがプロキシか直結かを決め、DNSがドメイン解決と地域判定の整合性に影響します。この順序に沿って確認するほうが、クライアント設定を何度も変更するより効果的です。