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

VPN用語ガイドで最初に理解したいのは、英語の略語を暗記することではありません。サブスクリプション、ノード、回線、プロトコル、ルーティングが接続のどの層に関わるのかを把握することです。これらはクライアント上に同時に表示されますが、同じものではありません。サブスクリプションは設定を届け、ノードは選択可能な接続先を示し、回線はデータが遠隔地へ届く経路を決め、プロトコルはクライアントとサーバーの通信方法を定め、ルーティングはどのリクエストをこの接続に通すかを決めます。

全体の流れは、荷物を送る作業にたとえられます。サブスクリプションURLは更新され続ける住所録、ノードは住所録から選ぶ受け取り拠点、プロトコルは梱包と引き渡しのルール、回線は輸送経路、ルーティングルールは専用経路とローカル経路のどちらを使うか判断する仕組みです。この関係がわかれば、クライアントの複雑に見える設定も整理しやすくなり、「サブスクリプションの更新失敗」と「ノードへの接続失敗」を混同せずに済みます。

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

サブスクリプションURLはクライアントでもプロトコルでもない

サブスクリプションURLは通常、サーバー側で発行される専用アドレスです。クライアントがこのアドレスにアクセスすると、ノード名、サーバーアドレス、ポート、プロトコルパラメータ、グループ情報などを取得し、選択可能な設定に変換します。サービス側で回線が調整された場合も、サブスクリプションを更新すれば新しい設定を取得でき、項目ごとの手入力は必要ありません。

つまり、「サブスクリプションを追加済み」という表示は、クライアントが設定を読み取れたことを示すだけで、すべてのノードとの接続が確立したことを意味しません。サブスクリプションページを開けない、URLのコピーが不完全、クライアントが対応形式をサポートしていない場合は、設定の受け渡し段階に問題があります。更新はできてもノード選択後に目的のサービスへアクセスできない場合は、プロトコル、回線、システムプロキシ、DNSを確認します。

単一ノード設定とサブスクリプションの違い

単一ノード設定には、ひとつの接続先に必要な情報だけが含まれます。テキストURL、QRコード、手動入力用のパラメータなどが一般的です。サブスクリプションは複数の設定をまとめて管理し、クライアントから再取得して更新できます。特定のプロトコルを一時的に確認するなら単一ノードの導入が便利ですが、長期利用ではサブスクリプションのほうがサービス側のノード変更に追従しやすくなります。

QRコードは設定内容を受け渡す方法のひとつにすぎず、接続の安全性や速度を自動的に高めるものではありません。読み取る前に提供元を確認し、導入後はクライアントが認識したプロトコル、サーバードメイン、メモが想定どおりか確認してください。出所不明の設定について、クライアントが通信事業者によるトラフィックの扱いを判断してくれるわけではありません。

クライアントが担う役割

クライアントは、サブスクリプションの解析、プロトコル接続の確立、システムプロキシや仮想ネットワークインターフェースの設定、ルールに基づくリクエストの転送を担います。システムプロキシに従うアプリだけを制御するクライアントもあれば、TUNモードでより広範なシステム通信を制御できるものもあります。同じサブスクリプションを導入しても、クライアントによってDNSの動作、ルール構文、バックグラウンド維持、システム権限が異なる場合があります。

• 導入前に、クライアントがサブスクリプションで使われるプロトコルとパラメータに対応しているか確認します。
• サブスクリプション更新後は、何度も再導入するのではなく、ノード一覧に妥当な変化があるか確認します。
• クライアントを変更する場合は、ルーティング、DNS、LANアクセスの設定を再確認し、自動的に引き継がれるとは考えないでください。
• デバイスを処分する前に、クライアント内のサブスクリプションURLとキャッシュされた設定を削除します。

ノード、サーバー、回線は同義ではない

「ノード」とは、クライアントがユーザーに表示する選択可能な接続項目です。通常はサーバーへの入口とプロトコルパラメータを含みますが、ノード名は単なるラベルであり、基盤の構成を完全に示すとは限りません。複数のノードが異なる入口から同じ地域へ接続する場合もあれば、一部のネットワークリソースを共有する場合もあります。同じ都市名の下に、直接接続、中継、専用線など異なる経路が存在することもあります。

「サーバー」は計算資源やネットワーク資源そのものを指すのに対し、「回線」はユーザーのネットワークからサーバーまでデータが通る経路に重点を置く言葉です。ノードに表示された地域名からわかるのは、遠隔側の出口やサービス上の表示場所だけで、実際の経路品質を単独で判断することはできません。接続体験は、利用中のネットワーク、ネットワーク間接続、混雑、経路の迂回、プロトコル、目的サイトの応答などにも左右されます。

IEPLは回線層の概念であり、「より高機能なVPNプロトコル」ではありません。クライアントは引き続き何らかのプロトコルでサーバーと通信し、アプリケーションデータもDNS名前解決、経路選択、目的サイトの処理を経由します。IEPLとTrojan、VLESS、Shadowsocksを同じ選択肢として直接比較するのは、輸送道路と梱包ルールを比べるようなもので、比較する次元が異なります。

地域は物理的な距離だけで選ぶべきではありません。地域限定サービスを利用する場合は、出口地域を目的側の要件に合わせます。一般的なウェブ閲覧では、接続の安定性と経路のスムーズさを先に比較するとよいでしょう。ノード名にある「高速」「最適化」などの表現は分類の目安にすぎず、実際の判断は利用中のネットワーク、時間帯、目的サービスに基づいて行います。

主要プロトコルの見方と選び方

プロトコルは、クライアントとサーバーがどのようにハンドシェイク、認証、カプセル化、データ転送を行うかを定めます。サービスの画面では複数のプロキシプロトコルがまとめて「VPN」に分類されることがありますが、技術的には従来のシステムVPNプロトコルと完全に同じではありません。デバイス全体の通信を制御できるかどうかは、クライアントでTUN、仮想ネットワークインターフェース、システムのVPN権限を有効にしているかにも左右されます。

Shadowsocks

Shadowsocksは暗号化プロキシプロトコルのひとつで、設定には通常、サーバー、ポート、パスワード、暗号化方式が含まれます。実装が軽く、対応クライアントも多い一方、互換性は双方が対応する暗号スイートや拡張機能によって決まります。導入後に認証や暗号化方式の互換性エラーが出た場合は、ノードを繰り返し切り替えるのではなく、クライアントのバージョンと設定項目を確認します。

VMessとVLESS

VMessは認証情報と転送設定を含み、システム時刻のずれに影響されやすいプロトコルです。デバイスの時刻が大きくずれていると、ハンドシェイクに失敗することがあります。VLESSは簡素な認証と転送を重視しており、それ自体を完全な暗号化層と考えるべきではありません。実際の構成では、TLS、REALITY、その他の安全な転送設定と組み合わせることが一般的です。VLESSの設定を確認するときは、安全層、転送方式、サーバー名、証明書関連のパラメータをまとめて確認します。

Trojan

Trojanは通常TLS上で動作し、設定にはサーバードメイン、パスワード、証明書検証、サーバー名が関わります。TLSを使っていても、証明書の確認を省略してよいわけではありません。検証を無効にすると一時的に設定ミスを回避できる場合がありますが、サーバーの身元確認が弱くなります。証明書が一致しない場合は、ドメイン、システム時刻、サーバー名表示、設定内容が対応しているかを確認するのが適切です。

Hysteria2とTUIC

Hysteria2とTUICはいずれもQUICとUDPを重要な基盤とし、複雑なネットワーク環境での輻輳制御や多重伝送に重点を置いています。適しているかどうかは、利用中のネットワークがUDPをどの程度サポートしているかで決まります。会社、ホテル、公衆ネットワークの一部ではUDPが制限され、ハンドシェイクに失敗したり、ネットワーク切り替え後に不安定になったりします。その場合は、サブスクリプション全体が無効だと判断する前に、TCPとTLSを基盤とする利用可能な設定と比較してください。

プロトコル名だけで速度を直接判断することはできません。接続性能は、ローカル接続、回線経路、サーバー負荷、輻輳制御、パケット損失、目的サイトなど複数の要素で決まります。選ぶときは、まずクライアントの互換性と接続の安定性を確保し、そのうえで同じネットワーク、同じ地域、近い時間帯の実際の使用感を比較します。

ルーティング、ルールモード、グローバルモードの関係

ルーティングが答えるのは、「このリクエストをどこから外へ出すか」です。クライアントでは、プロキシ経由、直接接続、特定条件での接続拒否を選べるのが一般的です。ルールはドメイン、IPアドレス、アプリ、プロセス、地域データベースなどを基準に照合できます。クライアントが上から順にルールを確認する場合、先に一致した項目が最終経路を決めることが多いものの、具体的な優先順位は使用するクライアントのルール仕様を確認してください。

ルールモード

ルールモードは、あらかじめ設定した条件に基づいて経路を決めます。たとえば、ローカルでよく使うサービスは直接接続し、国際回線が必要な宛先はプロキシへ送り、LANアドレスはローカルアクセスのままにします。不要な迂回を減らし、ローカル機器の管理画面が誤って遠隔側へ送られるのを防げる点が利点です。一方でルールの保守が必要で、目的サイトがドメインを変更したり、新しいCDNドメインを呼び出したり、複数のインターフェースを使ったりすると、古いルールが一部のリクエストを取りこぼすことがあります。

グローバルモード

グローバルモードは通常、クライアントが制御する通信を現在のプロキシノードへ一律に通すことを意味します。ただし、ここでいう「グローバル」はデバイス上のすべてのパケットと同義ではありません。クライアントがシステムプロキシだけを設定している場合、その設定に従わないアプリは直接接続する可能性があります。ブラウザが独自のセキュアDNSを有効にしている場合も、クライアントが想定する名前解決経路を迂回することがあります。実際の制御範囲を判断するには、TUNまたはシステムレベルのネットワークインターフェース、DNS設定、クライアント権限を合わせて確認する必要があります。

直接接続モード

直接接続モードでは遠隔プロキシを経由せず、接続を一時停止したり、問題がプロキシ経路に起因するかを確認したりする際に使います。直接接続にしてもクライアント自体が終了するとは限らず、ローカルDNS、ルールエンジン、仮想インターフェースが残る場合もあります。トラブルシューティングでは、直接接続の方針へ切り替えたのか、完全に切断してシステムのネットワーク設定を復元したのかを明確にしてください。

実用的な判断方法：日常利用ではまずルールモードを使います。ルールの漏れが明らかな場合は、短時間だけグローバルモードに切り替えて比較します。ローカルサービスに異常があるときは、直接接続モードで問題がルーティング経路に由来するか確認します。

ルーティングルールで最も問題になりやすいのは、ドメインの連鎖です。ウェブページを開くと、ログインAPI、画像、動画、フォント、CDNリソースなどが続けて読み込まれることがあります。メインドメインがプロキシを通っていても、関連するすべてのドメインが同じ経路を使うとは限りません。ページの枠組みは表示されるのに画像、ログイン、再生が失敗する場合は、クライアントログで失敗したリクエストが実際にどのルールへ一致したかを確認します。

DNSリークと名前解決経路の確認方法

DNSはドメイン名をネットワークアドレスへ変換します。DNSリークとは通常、ドメイン検索が管理されたプロキシまたは暗号化された名前解決経路を通ると想定しているのに、実際にはローカルネットワークの標準DNSから送信される状態を指します。これにより、名前解決結果と出口地域が一致しなくなったり、検索中のドメインが露出したりする可能性があります。HTTPSがアプリケーション内容を保護するため、すべての通信内容が漏れることと同じではありませんが、名前解決経路はプライバシーと接続性を左右する重要な要素です。

よくある原因には、クライアントがアプリ通信だけを制御してDNSを制御していない、ブラウザが独自のセキュアDNSを有効にしている、システムが複数のネットワークインターフェースから標準リゾルバーを選んでいる、ルールによってDNSサーバーアドレスが直接接続になっている、仮想インターフェース終了後に設定が正しく復元されていない、といったものがあります。クライアントによってはDNSハイジャックを使ってシステムの問い合わせを独自の解析モジュールへ送りますが、遠隔DNSと直接接続用DNSを手動設定する必要があるものもあります。

• 接続前後に、システムが現在使用しているDNSサーバーと出口ネットワークが想定どおりか確認します。
• ブラウザでシステムとは別のセキュアDNSが有効になっていないか確認し、ルーティング先と一致しているか確認します。
• クライアントログでドメイン名前解決のリクエストを探し、プロキシ、直接接続、拒否のどのルールに一致したか確認します。
• ノード切り替え後は古いDNSキャッシュを削除し、以前の名前解決結果を新しい回線の問題と誤認しないようにします。
• クライアント切断後、システムの名前解決が正常に戻ったことを確認し、残った仮想インターフェースが後続の通信に影響しないようにします。

IPv4とIPv6の違いにも注意が必要です。プロキシが一方のアドレスファミリーしか制御しておらず、システムがもう一方を優先すると、一部の接続が想定経路を迂回したり、宛先アドレスに到達できず読み込みが遅くなったりします。解決策はIPv6をすべて無効にすることではありません。まずクライアント、サブスクリプション設定、TUN実装、現在のネットワークが共通して対応しているかを確認し、デュアルスタックで名前解決するか、対応するアドレスだけを返すかを判断します。

プラットフォームごとにクライアントの動作が異なる理由

同じサブスクリプションでも、Windows、macOS、iOS、Android、Linuxでは動作が異なる場合があります。多くの場合、原因はサブスクリプションの内容ではなく、システムのネットワークインターフェース、権限モデル、バックグラウンド制御にあります。クライアントを比較するときは、画面の似ているかどうかではなく、プロトコル互換性、システムの制御方式、DNS機能、ルール形式、更新状況を重点的に確認します。

WindowsとmacOS

デスクトップOSでは、システムプロキシとTUNの2方式が一般的です。システムプロキシは設定が簡単ですが、その設定に従うアプリしか対象になりません。TUNはより多くの種類の通信を処理できる一方、仮想ネットワーク権限が必要で、ファイアウォール、仮想マシン、コンテナネットワーク、ほかのネットワークツールと競合することがあります。macOSではシステムネットワーク拡張の権限、Windowsでは仮想NICとルーティングが異常終了後に正しく削除されているかにも注意します。

iOSとAndroid

モバイルOSでは通常、システムが提供するVPNインターフェースを使って通信を制御します。iOSクライアントはシステム拡張の機能とバックグラウンド制御の影響を受け、対応プロトコルやルール構文はアプリによって異なります。Androidクライアントではアプリごとのプロキシを設定できることが多く、指定アプリだけをノード経由にして、ほかのアプリを直接接続にできます。ただし、省電力設定によって画面ロック後にクライアントが停止する場合があります。Wi-Fiとモバイルネットワークを切り替えたときは、トンネルが自動的に再構築されたかも確認します。

Linux

Linuxは環境差が大きく、デスクトップのシステムプロキシ、TUN、ルーティングテーブル、透過プロキシなどで通信を制御します。コマンドラインプログラムはデスクトップのプロキシ設定を自動的に読み取らないことが多く、環境変数、アプリ自身の設定、システムレベルの転送が必要です。コンテナを使う場合は、ホスト、コンテナネットワーク、DNS名前空間を分けて考え、ホストの接続だけを確認してコンテナも同じ経路を使っていると判断しないようにします。

導入からトラブルシューティングまでの手順

初心者にとって最も効果的なのは、一度にひとつの条件だけを変更することです。ノード、プロトコル、クライアント、DNSを同時に変更すると、接続が戻っても原因を特定できません。次の順序で確認すれば、設定の受け渡し、プロトコルのハンドシェイク、システム制御、目的サービスの問題を段階的に切り分けられます。

1. サブスクリプションの提供元を確認します。サービスパネルから完全なサブスクリプションURLをコピーし、公開変換サイトを経由しないでください。貼り付け後、先頭や末尾に余分な空白や文字抜けがないか確認します。
2. 更新して一覧を確認します。クライアントからサブスクリプションを手動更新し、ノード名とプロトコルが表示されるか確認します。この段階で失敗する場合は、まずURLの状態、ネットワークアクセス、サブスクリプション形式を確認します。
3. 互換性のあるノードを選びます。まずクライアントが明確に対応しているプロトコルを選び、システム時刻が自動同期されていることを確認します。TLSを使う場合は、ドメインと証明書パラメータも同時に確認します。
4. シンプルな制御方式から始めます。まずシステムプロキシでブラウザ閲覧ができるか確認し、ゲーム、コマンドライン、その他システムプロキシに従わないソフトが必要な場合にTUNを有効にします。
5. ルールの一致結果を確認します。クライアントログを開き、目的ドメインがプロキシと直接接続のどちらになっているか確認します。ページの一部リソースだけが失敗する場合は、関連ドメインのルール結果も確認します。
6. DNSを確認します。システム、ブラウザ、クライアントがそれぞれ異なるリゾルバーを使っていないか確認し、問い合わせ経路が想定した出口と一致しているか確認します。
7. 一変数で比較します。地域とクライアントを固定して回線またはプロトコルだけを切り替えます。あるいはノードを固定してルールモードとグローバルモードだけを切り替え、違いを記録します。

すべてのノードで更新できない場合は、サブスクリプションへのアクセス、クライアントの解析、ローカルネットワークに問題がある可能性が高くなります。特定のプロトコルだけが失敗する場合は、プロトコル互換性、UDP制限、システム時刻、安全層のパラメータを確認します。特定のウェブサイトだけが失敗する場合は、ルーティング、DNS、ブラウザセッション、目的サービスの地域要件を確認します。このように分類するほうが、ノードを無作為に切り替え続けるより原因を見つけやすくなります。

接続に成功しても、設定が完全に正しいとは限りません。ローカルサイトが不要に迂回していないか、LAN機器にアクセスできるか、スリープ復帰後に再接続するか、ネットワーク切り替え後にDNSが更新されるか、クライアント終了後にシステムプロキシが復元されるかも確認します。安定利用には、クライアントのボタンに「接続済み」と表示されることだけでなく、システム全体の動作確認が必要です。