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

VPNを使い始めたとき、混乱しやすいのはボタンの操作よりも、サブスクリプション、ノード、プロトコル、回線、ルーティングがそれぞれどの層にあるのかという点です。どれも「接続」に関係しているように見えますが、役割は異なります。サブスクリプションは設定をクライアントに渡し、ノードは具体的な接続先、プロトコルはクライアントとサーバーの通信方式、回線はデータが通るネットワーク経路、ルーティングはどのリクエストをプロキシに処理させるかを決めます。

これらの概念を層ごとに整理すると、多くの問題を切り分けやすくなります。サブスクリプションのインポートに失敗したからといって、回線が使えないとは限りません。ノードに接続できてもウェブページが開かない場合、プロトコルの障害とは限りません。ルールモードで特定のアプリが機能しない場合は、クライアントが通信を取得できていない、またはドメイン解決が誤った経路を通っている可能性があります。以下では、実際の利用順に用語を説明し、確認方法も紹介します。

サブスクリプション、ノード、クライアントの関係

クライアントは端末にインストールするソフトウェアで、設定の読み込み、接続の確立、ルーティングルールの実行、条件に合う通信の対応ノードへの転送を担います。サブスクリプションは通常、アクセス情報を含むURLです。クライアントがそのURLにアクセスすると、ノード一覧に加え、名称、プロトコル、ポート、転送方式、ルールなどの情報を取得します。サブスクリプションはノードそのものでも、常時稼働する通信経路でもありません。

サブスクリプションは、更新可能な設定リストと考えるとわかりやすいでしょう。サービス提供側が回線を調整したり、接続先を追加したり、パラメーターを変更したりすると、クライアントは「サブスクリプションを更新」して最新のリストを取得します。一度インポートしたからといって、端末内のノード情報が自動的に永久に最新になるわけではありません。自動更新の有無やタイミングは、使用するクライアントの設定によって異なります。

ノードは、リスト内にある具体的な接続先です。通常、1つのノード設定にはサーバーアドレス、接続ポート、プロトコル、認証情報が必要です。プロトコルによっては、トランスポート層、TLS、サーバー名、パスなどのパラメーターも求められます。ノード名は識別しやすくするためのラベルにすぎず、地域名や専用線、ストリーミング対応などの表示だけで実際の接続状態を判断することはできません。

サブスクリプションURLには、アカウントやプランを識別するトークンが含まれていることがあります。認証情報と同じように扱い、完全なURLを公開スクリーンショット、フォーラム投稿、共有ドキュメントに載せないでください。端末を移行するときは、信頼できるユーザーパネルから再取得するのが安全です。URLが流出した可能性がある場合は、クライアントを端末から削除するだけでなく、サービス提供側のリセット手段を利用してください。

サブスクリプションをインポートする標準手順

1. サービスパネルから完全なサブスクリプションURLをコピーし、先頭や末尾に余分な空白がなく、チャットアプリによって途中で切れていないことを確認します。
2. そのサブスクリプション形式に対応したクライアントで、「URLからインポート」または同等の項目を選びます。「ノードを手動追加」と間違えないようにしてください。
3. インポート後、まずサブスクリプションを1回更新し、ノード一覧が表示されるか確認します。一覧が表示されて初めて、クライアントが設定を正常に解析できたと判断できます。
4. 距離が近い、または用途に合うノードを選び、システムプロキシまたはトンネルモードを有効にします。ノードを選択しただけで接続を開始していなければ、端末の通信が自動的にそのノードへ送られることはありません。
5. ウェブページを開き、実際の通信状態を確認します。クライアントに「接続済み」と表示されても、通常はローカルのトンネルが確立したことを示すだけです。出口、DNS、アプリへのアクセスは、実際のリクエストで確認する必要があります。

プロキシプロトコルが決めること：Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC

プロトコルは、クライアントとサーバーがデータを認証、カプセル化、転送する方法を定義します。ハンドシェイク方式、トランスポート層、ソフトウェア互換性、ネットワーク環境ごとの挙動に影響しますが、プロトコル名だけで速度が決まるわけではありません。サーバー負荷、接続入口の品質、国際経路、混雑、ローカルネットワークも同じように重要です。プロトコルを選ぶときは、まずクライアントが対応しているか確認し、そのうえで現在のネットワークにおけるTCP、UDP、TLSの制約を考えます。

Shadowsocks

Shadowsocksは比較的軽量な暗号化プロキシプロトコルです。基本設定は通常、サーバー、ポート、パスワード、暗号化方式で構成されます。対応クライアントが多く、パラメーターも比較的わかりやすいため、一般的なウェブ、アプリ、ストリーミング通信に適しています。従来型の企業向けVPNプロトコルではなく、端末全体の通信を取得できるかどうかは、ソフトウェアがシステムプロキシ、VPNインターフェース、TUNモードを提供しているかによって決まります。

VMessとVLESS

VMessはV2Rayエコシステムで広く使われているプロトコルの一つで、設定には識別子、転送方式、安全性に関するパラメーターも含まれます。VLESSはより簡潔な設計で、単体ではコンテンツの暗号化を担わず、通常はTLS、REALITYなどの安全な転送方式と組み合わせて使用します。そのため、「VLESS」と表示されているだけでは接続設定が完全か判断できません。トランスポート層、安全層、サーバー名、クライアントのコアが組み合わせに対応しているかを確認してください。

この2種類の設定では、パラメーターの一致が特に重要です。アドレスやポートが正しく見えても、転送方式、TLSの有効化、サーバー名が一致しなければハンドシェイクに失敗することがあります。手動入力では目立つサーバーアドレスだけでなく、すべての項目を照合してください。

Trojan

Trojanは通常TLS上で動作し、認証情報、サーバー名、証明書検証が設定の要点になります。端末の時刻が大きくずれている、サーバー名が誤っている、証明書チェーンの検証に失敗しているといった場合、ハンドシェイク段階で接続が終了することがあります。証明書検証を無効にすると一時的にエラーが消える場合もありますが、本人確認の安全性が低下するため、通常のトラブルシューティング方法にはしないでください。

Hysteria2とTUIC

Hysteria2とTUICはいずれもQUICやUDPを重要な基盤とし、高遅延、パケットロス、変動のある経路での通信制御を重視しています。ただし、どのネットワークでも高速になるわけではありません。現在のWi-Fi、企業ネットワーク、通信事業者の経路でUDPが強く制限されていると、ハンドシェイクに失敗したり、速度が不安定になったり、まったく利用できない場合があります。その際は関係のないパラメーターを繰り返し変更するのではなく、利用可能なTCPまたはTLS方式に切り替えて比較してください。

直接接続、中継、IEPL専用線の違い

プロトコルが解決するのは「どう送るか」であり、回線が示すのは「どこを通るか」です。同じプロトコルでも異なる回線上で動作し、同じ回線でも異なるプロトコルを運べます。速度測定でプロトコル名だけを比較し、経路を無視すると、安定した結論は得にくくなります。

直接接続とは通常、端末から遠隔ノードの接続入口へ直接アクセスし、サービス提供側が用意した中継を経由しない方式です。構成がシンプルで中間要素も少ない一方、地域をまたぐネットワーク品質はローカルの通信事業者やインターネット上の経路に左右されます。経路の迂回や混雑があると、遠隔サーバーのリソースに余裕があっても体感品質が変動することがあります。

中継回線では、まず近い接続入口のサーバーに接続し、そこから入口が通信を目的の出口へ転送します。品質の低いインターネット経路の一部を避けやすく、提供側が入口と出口の経路を調整しやすい構成です。ただし、中継ノードの容量、入口までの距離、転送経路が結果に影響します。「中継」はトポロジーを示す言葉であり、必ず高速になることを意味しません。

IEPLは国際イーサネット専用線系サービスを指す業界用語で、企業ネットワークの相互接続などに使われます。個人向けのネットワーク高速化サービスで「IEPL専用線」と表示されている場合、通常はバックボーン経路の一部に専用線リソースまたは専用線接続を利用していることを示します。ユーザーはまずローカルインターネットを通って接続入口に到達し、出口の先でも目的のウェブサイトへアクセスするため、端末からすべての接続先までが完全に公衆網から切り離されているわけではありません。

• ✅ 接続入口の位置を確認：入口から遠すぎると、ローカルから入口までがボトルネックになることがあります。
• ✅ 経路構成を確認：直接接続、通常のインターネット中継、専用線を利用した中継を区別します。
• ✅ 実際の用途を確認：ウェブの応答、ファイル転送、リアルタイム通信では求められる回線条件が異なります。
• ✅ 混雑する時間帯を確認：短時間の空いている時間帯の測定結果は、継続利用時の安定性を示すとは限りません。
• ❌ ノード名だけを見る：ラベルは分類用であり、経路や実際の転送テストの代わりにはなりません。
• ❌ 遅延の順位だけを見る：低遅延でもスループットが高いとは限らず、パケットロスがないことも保証しません。

クライアントの「遅延テスト」も、測定方法を見分ける必要があります。TCP接続の確立だけを確認するもの、特定のウェブページへリクエストするもの、ローカルから接続入口までの応答だけを測るものなどがあります。測定値は完全に到達できないノードを素早く除外するのには役立ちますが、ダウンロード帯域、動画のバッファリング、長時間接続の安定性を十分に反映するものではありません。信頼できる選び方は、まず遅延で候補を絞り、実際の用途で確認することです。

グローバルモード、ルールモード、直接接続モードの選び方

モードは、どの通信をノードへ送るかを決めます。グローバルモードでは通常、クライアントが取得できる通信を現在のノードへまとめて送るため、ルールの問題を切り分けたり、特定のアプリがプロキシ経由で動作するか短時間で確認したりするのに適しています。ただし、端末上のすべてのパケットが取得されるとは限りません。クライアントがシステムプロキシだけを設定している場合、その設定に従わないアプリは直接接続することがあります。

ルールモードでは、ドメイン、IP、アプリ、ルールセットに基づいて、プロキシ、直接接続、拒否のいずれかを決めます。日常利用では、ローカルサービスを直接接続のままにし、国際アクセスだけを国際回線へ送れるため、ルールモードが適しています。ただし、ルールは実際のリクエストに正しく一致しなければなりません。ドメインの変更、アプリ独自のDNS、IPアドレスへの直接接続、ルール順序の誤りなどで判定を誤ることがあります。

直接接続モードは通常、ノードを経由せず、プロキシを一時停止したり、問題の原因がプロキシ経路にあるか確認したりする際に使います。クライアントによっては「グローバル直接接続」と「接続を停止」の2つを別に用意しています。前者はクライアントが通信を取得したまま直接接続の方針を実行する場合があり、後者はローカルのプロキシサービスを完全に停止します。DNSやTUNインターフェースの扱いも異なる場合があります。

システムプロキシとTUNモードは同じものではありません

システムプロキシは、HTTPまたはSOCKSプロキシのアドレスをOSに設定する機能です。その設定に従うブラウザーやアプリは、リクエストをクライアントへ送信します。負荷が比較的少なく、一時的な有効化・無効化にも便利ですが、一部のゲーム、コマンドラインツール、ストアアプリ、独自のネットワークスタックを使うソフトウェアはシステムプロキシを無視することがあります。

TUNモードは仮想ネットワークインターフェースを通じてIP通信を取得し、クライアントがプロキシまたは直接接続を判断します。より多くのアプリを対象にしやすく、UDPが必要な用途にも適していますが、追加のシステム権限が必要で、他のVPN、仮想マシンのネットワーク、エンドポイントセキュリティソフト、ローカルファイアウォールと競合することがあります。モバイル端末のクライアントは通常、OSが提供するVPNインターフェースで同様の取得を実現します。そのため、実際の内部動作がプロキシプロトコルであっても、システムのステータスバーにはVPNアイコンが表示されます。

DNSリーク、ドメイン解決、ルーティングが関係する理由

ブラウザーがドメインへアクセスする前に、通常はドメインをIPアドレスへ解決します。DNSリクエストを誰が処理するかは、プライバシー、接続性、ルーティングの正確さに影響します。ウェブ通信がノードを経由していても、DNSがローカルネットワークへ直接送られていると、解決を担当する側に検索したドメインが見えることがあります。この状態はDNSリークと呼ばれることがあります。

DNSの問題はプライバシーだけに関係するものではありません。ドメイン名で経路を決めるルールでも、アプリがクライアントの外部で先に解決すると、プロキシプログラムにはIPアドレスしか見えない場合があります。逆に、すべてのドメインを遠隔DNSで解決すると、ローカルサービスが現在地に適さないアドレスを返すことがあります。適切なルーティング設定では、ローカルで解決するドメインと遠隔で解決するドメインを分け、解決結果とその後の経路を一致させます。

クライアントにある「DNSハイジャック」や「DNS取得」は、通常、端末から送られた解決リクエストをクライアントで設定したリゾルバーへリダイレクトする機能です。ここでいう「ハイジャック」は技術機能の名称であり、必ずしも悪意を意味しません。有効にした後は、使用するプロトコルをクライアントが処理できるか確認し、ブラウザー内蔵の暗号化DNSや他のネットワークフィルターツールとの重複取得を避けてください。

ルーティングルールはどのように一致するか

ドメインルールはウェブサイトやサービスの分類に、IPルールは既知のアドレス範囲に、アプリルールはプロセスやパッケージ単位の通信分けに適しています。ルールには通常、優先順位があります。より具体的な条件を広い条件より前に置き、最後にデフォルトルールで一致しなかったリクエストを処理します。クライアントごとにルール構文や一致優先度の実装は完全には同じではありません。設定を移行するときはクライアントの説明を確認し、ルールファイルをそのまま共用できると考えないでください。

ウェブサイトのトップページは開くのに、画像、ログイン、動画が失敗する場合、複数のドメインに依存しているのにルールがメインドメインしか対象にしていない可能性があります。切り分けでは一時的にグローバルモードへ切り替えて比較します。グローバルモードで正常なら、ノードとプロトコルはおおむね利用可能です。次にリソース用ドメイン、DNS解決、ルールの一致状況を確認してください。

異なるプラットフォームでクライアントの操作が違う理由

WindowsとmacOSのクライアントは通常、システムプロキシとTUNの両方を提供します。システムプロキシはブラウザーやプロキシ設定に従うソフトウェアに適し、TUNはシステムプロキシを読まないアプリの通信取得に向いています。TUNを有効にすると、仮想ネットワークコンポーネントのインストールや管理者権限の許可を求められる場合があります。クライアント終了時にシステムプロキシが元に戻らないと、ネットワークが切れたように見えることがあります。その場合はソフトウェアを再インストールする前に、OSのプロキシ設定を確認してください。

Androidクライアントは通常、システムVPNインターフェースを利用して通信を取得します。初回有効化時には、システムの許可画面が表示されます。クライアントによってはアプリ単位のルーティングに対応し、どのアプリをノード経由にするか指定できます。システムの常時接続VPNや他のネットワークフィルタリングサービスも有効にしている場合は、同時利用が許可されているか確認してください。

iOSとiPadOSのクライアントは、OSが提供するNetwork Extension機能を使用します。サブスクリプションをインポートした後、初回の接続確立時にVPN設定の追加を許可するよう求められます。クライアントごとに対応するプロトコルコアが異なるため、同じサブスクリプションでも、あるクライアントではすべてのノードが表示され、別のクライアントでは一部のプロトコルが表示されないことがあります。この違いがある場合は、サブスクリプションを何度も削除するのではなく、ソフトウェアのバージョンとプロトコル対応状況を確認してください。

ルーター上のプロキシは、ゲートウェイ単位で通信を取得します。そのルーターに接続した端末は統一したルールを利用できますが、ルーターのプロセッサー性能、ファームウェアのコア、DNS設定、ハードウェアアクセラレーションがスループットに影響します。ルーターがサブスクリプションをインポートできるかどうかは、ファームウェアのプラグインが対応する形式とプロトコルにも左右されます。デスクトップクライアントで使える設定が、ルーターでそのまま使えるとは限りません。

• ✅ WindowsまたはmacOS：システムプロキシとTUNのどちらを使うか確認し、どのアプリを取得対象にするか判断します。
• ✅ Android：システムVPNの許可とアプリ単位のルーティング設定を確認します。
• ✅ iOSとiPadOS：VPN設定の追加を許可したことを確認し、クライアントが対応するプロトコルを照合します。
• ✅ ルーター：ファームウェア、プラグインのコア、DNS、ハードウェア処理能力を確認します。
• ❌ 複数の通信取得ツールを同時に実行する：ルーティング、DNS、仮想インターフェースが互いに上書きする可能性があります。

「接続できない」から原因特定までのトラブルシューティング手順

効率的なトラブルシューティングの鍵は、毎回1つの変数だけを変更することです。クライアント、プロトコル、ノード、ネットワークを一度に変えると、接続が戻っても原因を特定できません。まずローカル環境から確認し、サブスクリプション、ノード、プロトコル、回線、ルールの順に調べることをおすすめします。

1. 端末自体が通常のウェブページへ直接アクセスできることを確認し、システムの日付と時刻を合わせます。基本的なネットワークが使えない状態では、クライアントはサブスクリプションの更新やプロトコルのハンドシェイクを完了できません。
2. サブスクリプションを更新し、ノード一覧を正常に取得できるか確認します。サブスクリプションのリクエストに失敗する場合は、まずURL、ネットワークアクセス、クライアントの形式互換性を確認してください。
3. 同じプロトコルの別ノードを選んで比較します。1つのノードだけが失敗する場合は、そのノードまたは対応する回線に問題がある可能性が高くなります。
4. クライアントが対応する別のプロトコルを選びます。UDP系プロトコルが使えず、TCPまたはTLS方式が正常なら、現在のネットワークによるUDP制限を確認してください。
5. 一時的にグローバルモードを使って確認します。グローバルモードでは正常でルールモードだけ異常な場合は、ルールの一致、リソース用ドメイン、DNSを重点的に調べます。
6. システムプロキシで一部のアプリだけが動作する場合は、アプリがシステムプロキシに従うか確認します。必要に応じてTUNまたはシステムVPNインターフェースでテストしてください。
7. ネットワークを取得する可能性のある他のツールを終了し、ファイアウォール、仮想ネットワークアダプター、ローカルプロキシポートの競合を確認してから、接続を再確立します。

クライアントのログを読むときは、エラーを解析、接続、ハンドシェイク、認証、DNS、ルーティングの段階に分けて考えます。サブスクリプション形式のエラーは解析段階、接続タイムアウトはアドレスに到達できないかポートが制限されている可能性、TLS証明書エラーはハンドシェイク段階の問題です。認証失敗は通常、認証情報または設定の不一致に関係します。接続できてもドメインが開かない場合は、DNSとルーティングを重点的に確認しましょう。

ログにはサーバーアドレス、サブスクリプション識別子、接続認証情報が含まれることがあります。問い合わせやスクリーンショットを送る前に、機密項目を隠してください。問題を説明するときは、「使えない」とだけ伝えるより、OS、クライアント名、プロトコル、通信取得モード、エラーが発生した段階、実施済みの比較テストを伝えるほうが原因特定に役立ちます。

これらのVPN用語を実際の接続に当てはめる

完全な接続は次のように考えられます。ユーザーがサブスクリプションURLをクライアントへインポートし、クライアントが複数のノード設定を解析します。ユーザーが1つのノードを選ぶと、クライアントはそのノードで指定されたShadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICなどのプロトコルで接続を確立します。接続は直接接続、中継、専用線を利用したネットワーク経路を通って出口へ到達し、システムプロキシまたはTUNが端末の通信を取得します。ルールモードは各リクエストをプロキシ経由にするか直接接続にするかを決め、DNS設定はドメイン解決とルーティング結果を一致させます。

どの層に異常があっても、表面上は「ウェブページが開かない」という症状になることがありますが、解決方法は異なります。サブスクリプションの期限切れなら設定を更新し、プロトコルに互換性がなければクライアントまたはコアを変更します。回線の混雑なら接続入口の経路を変え、システムプロキシが機能しないなら通信取得方式を調整します。ルールの漏れならドメインを追加し、DNS経路が一致しないなら解決設定を確認します。

初心者がすべての設定項目を一度に覚える必要はありません。まず階層を理解しましょう。サブスクリプションは設定の入手元、ノードは接続先、プロトコルは通信方法、回線は伝送経路、モードは通信範囲、ルールは行き先の判断、DNSはドメイン解決です。どのチュートリアルを読むときも、まず何の層を扱っているかを見極め、自分の端末やクライアントに適用できるか判断できます。