VPN初心者向け用語集：サブスクリプション、ノード、プロトコル、ルーティングを解説

VPNや国際ネットワークサービスの商品ページを初めて見るとき、操作ボタンよりも混乱しやすいのが「サブスクリプション」「ノード」「プロトコル」「ルーティング」といった用語です。それぞれ役割が異なり、サブスクリプションは設定を提供し、ノードは接続先の候補を示し、プロトコルはデータの伝送方法を決め、ルーティングルールはどの接続をプロキシ経由にするかを決めます。階層を分けて考えると、商品説明やクライアント画面が理解しやすくなります。

まず、簡略化したデータ経路を見てみましょう。アプリがリクエストを送ると、クライアントがルーティングルールに従って処理方法を決定します。プロキシが必要なリクエストは、指定されたプロトコルでノードに接続し、ノードまたは中継回線を経由して対象サイトへ送られます。プロキシが不要なリクエストは、ローカルネットワークを直接利用します。サブスクリプションURL自体が日常のWebデータを転送するわけではなく、主にノードと関連パラメータをクライアントへ渡す役割を担います。

サブスクリプションURL、クライアント、設定ファイルとは

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

プロキシツールでは、サブスクリプションは通常、サービス側が発行するURLを指します。クライアントがそのURLへアクセスすると、ノード名、サーバーアドレス、ポート、プロトコル、認証情報などの接続パラメータを取得できます。サービス側でノードが変更された場合も、クライアントでサブスクリプションを更新すれば、新しい設定を一つずつ手入力せずに反映できます。

サブスクリプションURLには、アカウントやプランを識別できる認証情報が含まれることがあります。そのため、公開ページやスクリーンショット、共有ドキュメントに掲載するのは避けてください。URLを知っている人がノード設定を読み取ったり、プランの通信量を消費したりする可能性があります。漏えいが疑われる場合は、クライアントを端末から削除するだけでなく、サービスの管理画面からサブスクリプションをリセットしてください。

クライアントは設定を解析し、接続し、ルールを実行する

クライアントは端末にインストールするソフトウェアです。サブスクリプションの内容を読み込み、ノード一覧を表示し、プロトコル接続を確立したうえで、現在のモードに応じてシステムやアプリから発生するネットワーク通信を処理します。クライアント名が異なっても、基盤となるプロトコルまで異なるとは限りません。同じプロトコルが複数のクライアントで実装されていることもあります。取り込み可否を判断するときは、ソフトウェア名だけでなく、対応プロトコルとサブスクリプション形式を確認しましょう。

設定ファイルは、クライアントが読み込める静的な設定です。単一のノードだけでなく、ノードグループ、DNS設定、ルールセット、ポリシー選択などを含む場合もあります。サブスクリプションと異なり、静的ファイルはサービス側の変更に自動追従しません。サービス側で接続先が変更されても古い情報が残る可能性があるため、長期利用では再取り込みや更新が必要になることがあります。

ノード、入口、出口、回線の違い

「ノード」はクライアント画面で最もよく表示される選択肢ですが、ノード名が示すのは経路全体の一部だけの場合があります。クライアントが最初に接続するのは入口サーバーで、対象サイトから見えるのは通常、出口側のアドレスです。入口と出口が同じ地域にあることもあれば、中継回線で接続されていることもあります。ノード名の都市名や旗だけでは、実際の経路全体を判断できません。

直結回線

直結とは通常、クライアントが対象地域にあるサーバーへ直接接続し、サービス側が追加で用意した転送入口を経由しない構成を指します。構造が比較的単純で、追加の転送区間も少ない一方、国際区間は利用中の通信事業者による公衆ネットワークの経路に左右されやすくなります。夜間の混雑、事業者間接続の変化、ローカルネットワークの品質などが、直結の使用感に影響することがあります。

中継回線

中継回線では、まず比較的近い、または安定した入口へ接続し、その後サービス側が用意した回線で出口へ転送します。中継の目的は、品質の低い公衆ネットワーク区間を避けたり、入口を利用者のネットワークに近づけたりすることです。中継したからといって遅延が必ず下がるわけではありません。転送処理と経路が増えるため、入口の位置、国際区間の品質、出口の負荷によって結果は変わります。

IEPL 専用線

IEPL は、企業向けの国際イーサネット専用線サービスを表す際によく使われます。小売向けのネットワークサービスで IEPL と表示されている場合、国際区間の主要部分に該当する専用線または専用線リソースを採用していることを示すのが一般的で、利用端末が専有の物理回線へ直接接続するという意味ではありません。商品ページでは、「国際区間の回線タイプ」と「利用者から入口までのローカルな公衆ネットワーク接続」を分けて確認しましょう。主要区間が安定していても、ローカル接続の品質は最終的な使用感に影響します。

ノードは選択可能な入口設定、回線はデータが実際に通る経路、出口は対象サイトから見えるネットワーク上の位置を決めます。3つは関連していますが、同じ概念ではありません。

プロキシプロトコルが決めること

プロトコルは、クライアントとサーバーが接続を確立し、認証し、データをカプセル化して転送する方法を定めます。互換性、ハンドシェイク方式、パケットロスへの耐性、リソース使用量などに影響しますが、プロトコルだけで回線全体の速度が決まるわけではありません。品質の高い回線でも適さないプロトコルでは性能が出ず、正しいプロトコル設定でも基盤ネットワークの深刻な混雑は解消できません。

Shadowsocks の「暗号化方式」はプロトコル設定の一部であり、方式を変更する場合はサーバーとクライアントを一致させる必要があります。VMess、Trojan、VLESS は TLS、WebSocket、gRPC などのトランスポート方式と組み合わせることが多いため、取り込みに失敗しても認証情報だけが原因とは限りません。ドメイン、パス、サービス名、安全性に関する設定の不一致も確認しましょう。

Hysteria2 と TUIC は UDP に依存します。企業ネットワーク、学校ネットワーク、ルーターなどで UDP の制限が多い場合、クライアントが正常にハンドシェイクできなかったり、接続後に不安定になったりすることがあります。その場合は、関係のないルーティングルールを何度も変更するのではなく、利用可能な別のプロトコルや回線へ切り替えてください。

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

接続を確立した後も、クライアントは各リクエストをどこへ送るか決める必要があります。この判断は、動作モードとルーティングルールによって行われます。モードを誤ると、ローカルサイトへの経路が遠回りになる、一部のアプリが接続できない、LAN機器にアクセスできない、接続済みなのに対象アプリがプロキシを通らない、といった現象が起こります。

グローバルモード

グローバルモードでは通常、クライアントが処理できる接続をすべて、選択したノード経由で処理します。ルールの問題を一時的に切り分けるのに適しており、ルールモードではアクセスできないのにグローバルモードではアクセスできる場合、ドメイン分類、アプリルール、ルールの優先順位に原因がある可能性があります。ただし、直結に適したローカルサービスまで遠隔の出口を経由するため、遅延が増えたり、サイトから見える地域が変わったりすることがあります。

ルールモード

ルールモードでは、ドメイン、IP、アプリ、プロセス、ルールセットなどに基づいて、プロキシ、直結、拒否のいずれかを選びます。ローカルサービスは直結のままにし、国際回線が必要なリクエストだけをノードへ送れるため、日常利用には通常こちらが適しています。正確に動作するかどうかは、ルールが更新されているか、クライアントが対象のドメインやアプリ通信を認識できるかに左右されます。

直結モード

直結モードでは通常、通常のリクエストをプロキシノードへ送らず、プロキシを一時停止したり、ローカルネットワークの状態と比較したりするために使います。ただし、完全にクライアントを終了した状態と同じとは限りません。一部のソフトウェアでは、ローカル DNS、仮想ネットワークアダプター、システムプロキシ設定が残ることがあります。切り分ける際は、クライアントの状態とシステムのネットワーク設定を同時に確認してください。

• ✅ ルールが原因か一時的に判断する：同じノードのまま、まずグローバルモードとルールモードを比較する。
• ✅ ローカルサービスと国際サービスを日常的に利用する：正常にメンテナンスされているルールモードを優先する。
• ✅ LAN機器を開けない：LANのセグメントが誤ってプロキシへ送られていないか確認する。
• ❌ システムプロキシや仮想ネットワークアダプターを制御するクライアントを同時に複数起動しない。
• ❌ ルールの意味を確認せず、既存の設定をまとめて上書きしない。

DNSリークと名前解決が重要な理由

ドメイン名を入力すると、端末は通常、まず DNS に問い合わせて対応する IP アドレスを取得します。Web接続がプロキシ経由でも、DNS問い合わせがローカルネットワークから直接送信されると、ローカルの名前解決サービスにドメイン名を見られる可能性があります。これが一般に DNSリークと呼ばれる状態です。また、出口はある地域にあるのにDNSの結果はローカルネットワーク向けになるなど、地域判定の不一致が起き、適切でない配信先へ接続されることもあります。

クライアントによって DNS の処理方法は異なります。システムの問い合わせを引き受けてルールに従い振り分けるもの、暗号化 DNS を使うもの、仮想アドレスへマッピングしてドメインルールと後続の接続を関連付けるものがあります。どの方式でも、名前解決と接続経路を一致させ、ローカルドメイン、LAN機器、社内ドメインが外部の名前解決サービスへ誤って送られないようにすることが目的です。

DNSの問題でよく見られる症状

• ノードは接続済みと表示されるのに、特定のドメインだけ開けない。既知のIPアドレスを直接入力すると結果が異なる。
• ノードを切り替えてもサイトの地域表示がすぐに変わらず、古い名前解決キャッシュが使われ続けている。
• ルールはドメイン一致に依存しているのに、アプリがIPアドレスを直接使うため、想定したルールに一致しない。
• 問い合わせが内部名を認識しない名前解決サービスへ送られ、LAN機器の名前を解決できない。

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

サブスクリプションの取り込み手順は基本的に共通しています。サービスの管理画面からURLをコピーし、対応クライアントでURLからの取り込みまたはサブスクリプション追加を選び、更新後にノードを選択して、システムプロキシまたは仮想ネットワークアダプターを有効にします。実際に問題になりやすいのは、システム権限、プロトコル互換性、通信を制御する範囲です。

Windows クライアントでは、システムプロキシと仮想ネットワークアダプターの2つの方式が用意されていることが多くあります。システムプロキシは主にシステム設定に従うアプリを対象とし、仮想ネットワークアダプターはより多くの種類の通信を処理できる一方、対応するネットワークコンポーネントのインストールとシステム権限が必要です。ブラウザーは使えるのにデスクトップアプリだけ使えない場合は、そのアプリがシステムプロキシを回避していないか確認してください。

macOS では、ネットワーク拡張機能と VPN 設定に明確なシステム認証手順があります。クライアントが初めて関連機能を有効にするとき、システムによる確認を求められる場合があります。認証が完了していないと、クライアント画面では設定済みと表示されても、システム通信が制御されていないことがあります。クライアント更新後に問題が発生した場合は、ネットワーク拡張機能が引き続き有効かどうかも確認しましょう。

iOS と iPadOS のクライアントは、システムの VPN 設定を使って通信を制御します。初回接続時には設定の追加を確認する必要があります。Android クライアントでは、省電力設定、バックグラウンド制限、常時接続設定の影響を受けることがあります。モバイル端末が Wi-Fi からモバイルネットワークへ切り替わる際、QUIC ベースの接続はコネクション移行によって動作を継続できる場合がありますが、具体的な挙動はクライアントの実装とネットワーク環境によって異なります。

Linux 環境では違いがさらに多くなります。デスクトップクライアントはシステムプロキシまたは仮想ネットワークアダプターで動作し、コマンドラインプログラムは環境変数を読み込むか、透過プロキシで制御する必要がある場合があります。コンテナ、サブシステム、リモートセッションには独立したネットワーク名前空間があることもあるため、ホストのブラウザーが使えても、コンテナ内のリクエストが同じ経路を使っているとは限りません。

• ✅ 取り込み前に、クライアントがサブスクリプション内のプロトコルとトランスポート方式に対応しているか確認する。
• ✅ 取り込み後はまずサブスクリプションを更新し、ノードを1つ選んで基本的な接続テストを行う。
• ✅ システムプロキシ、仮想ネットワークアダプター、ネットワーク拡張機能が実際に有効か確認する。
• ✅ 特定のアプリだけに問題がある場合は、独自のプロキシ設定を使っていないか確認する。
• ❌ 認証情報を含むサブスクリプションURLを公開の検査サイトへ貼り付けない。
• ❌ 競合するシステムプロキシ、仮想ネットワークアダプター、ブラウザー拡張機能を同時に有効にしない。

購入前に商品パラメータを読み解く方法

用語を理解したら、購入時にはパラメータを自分の利用経路に置き換えて考えましょう。まず、プランが期間制の通信量か、期限なしの通信量パックかを確認し、対応クライアントとプロトコルを確認します。次に入口、出口、回線タイプを見て、最後に返金ルール、通信量のリセット方法、同時利用端末の制限を確認してください。ノード名、プロトコル数、ページ上の単一のラベルだけで判断してはいけません。

閲覧や軽いオフィス作業が中心なら、最大速度の測定値よりも、ルールの品質、DNS処理、クライアントの安定性が重要になることが多いでしょう。長時間の動画視聴に使う場合は、持続的な通信速度、回線の混雑、出口の利用可能性に注目します。異なるネットワーク間を頻繁に移動する場合は、クライアントの再接続速度、UDP環境、システムのバックグラウンド制限も考慮してください。

商品ページにある「対応プロトコル」という表記は、サービス側と設定がその機能を備えていることを示すだけで、すべてのプラットフォームのクライアントで使えるとは限りません。同様に、「特定地域のノード」は通常、出口またはノードのラベルを示すもので、入口の位置や完全な経路までは分かりません。情報が不明確な場合は、ノードページやヘルプドキュメントを確認するか、サポートに項目の意味を問い合わせましょう。

• ✅ プラン説明に、通信量の計算方法とリセット方法が明記されているか。
• ✅ よく使うプラットフォームに対応クライアントがあり、必要なプロトコルを取り込めるか。
• ✅ ノード説明で、入口、出口、直結、中継、専用線が区別されているか。
• ✅ 返金、トラブルシューティング、サブスクリプションのリセット方法が明確に案内されているか。
• ✅ ルーティングルールと DNS 設定を実際の利用シーンに合わせて調整できるか。
• ❌ ノード数を接続品質や安定性の代替指標として直接扱わない。

よくある質問まとめ

サブスクリプションを更新すると手動変更は上書きされますか

クライアントがリモート設定をどのように管理するかによります。一部のクライアントは更新時にサブスクリプションのノードを再生成するため、直接変更したノード項目がサービス側の内容に戻ることがあります。ローカルのポリシーグループや上書きルールは別に保存される場合があります。長く残したいカスタム設定は、リモートノードを直接変更せず、クライアントが対応する上書き、マージ、ローカルルール機能に記述してください。

ノードには接続できるのにWebページが開けません。ノードが故障していますか

必ずしもそうとは限りません。接続済みという表示は、クライアントとサーバーのハンドシェイクが完了した可能性を示すだけです。Webページが開けない原因には、DNS、ルーティングルール、システム時刻、ブラウザーのプロキシ、対象サイトの制限、ローカルネットワークなどもあります。まず異なるドメインをテストし、グローバルモードとルールモードを比較して、DNSとシステム側の制御状態を確認してください。

同じサブスクリプションでもクライアントによって挙動が異なるのはなぜですか

クライアントごとに、プロトコルの細部、DNS、ルール構文、仮想ネットワークアダプター、システム権限の実装が異なります。サブスクリプションの変換時に、クライアントが認識しない項目が無視されることもあります。比較する際は、ノード、プロトコル、DNS、動作モードをそろえてください。そうしなければ、見えている差がクライアントの性能差だけとは限りません。

回線とプロトコルはどちらを先に変更すべきですか

接続をまったく確立できない場合は、まずプロトコルの互換性、認証パラメータ、ネットワークが UDP や TLS をサポートしているかを確認します。接続できるものの速度や遅延が不安定な場合は、異なる入口と回線を優先して比較してください。特定のサイトだけに問題がある場合は、まず出口、DNS、ルーティングルールを確認します。一度に1つの変数だけを変更すると、再現可能な結論を得やすくなります。