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

クライアントを開くと、サブスクリプション、ノード、プロトコル、システムプロキシ、グローバルモード、ルールモード、DNSが一度に表示され、略語だらけの宇宙船に迷い込んだように感じるかもしれません。実際には、この VPN初心者向け用語集でまず押さえる軸は一つです。サブスクリプションは設定を届け、ノードは接続先への入口を提供し、プロトコルは通信方式を定め、ルーティングはどのリクエストをどの経路に送るかを決めます。その他の設定の多くも、この軸を中心に動いています。

これらの用語は混同されがちですが、同じものではありません。ノードの数が多いからといって回線が速いとは限らず、新しいプロトコルだからといって現在のネットワークに適しているとも限りません。グローバルモードも「性能を上げる」スイッチではありません。まず用語を正しく整理してから接続問題に取り組むほうが、設定を手当たり次第に切り替えるより効率的です。

まず結論： サブスクリプションは設定一覧、ノードは選択可能な入口、プロトコルは通信ルール、ルーティングは通信の振り分けです。トラブル時はこの順番で確認し、すべての用語を同時に疑わないようにしましょう。

サブスクリプション・サブスクリプションURL・設定ファイルとは

サブスクリプションは特定の回線そのものではなく、サービス側で管理される接続設定のセットです。ノード名、サーバーアドレス、ポート、プロトコル、認証情報、通信パラメータなどが含まれる場合があります。クライアントがこの設定を読み込むことで、選択可能なノードが画面に表示されます。

サブスクリプションURLは、この設定を取得するためのアドレスです。対応クライアントに貼り付けると、クライアントがリモートの内容を取得し、自分の形式のノード一覧に変換します。サービス側で回線が変更された後は、通常クライアントで「サブスクリプションを更新」を実行するか、設定された更新を待つ必要があります。一度導入しただけで、ローカルの一覧が常に最新になるわけではありません。

設定ファイルは別の提供方式です。テキストの場合もあれば、クライアントが直接読み込めるファイルの場合もあります。サブスクリプションURLは継続的な更新に向き、個別の設定は特定の接続を保存した静的なスナップショットに近いものです。どちらも「どう接続するか」を示しますが、更新方法と構成が異なります。

サブスクリプションの導入時に行われていること

クライアントがサブスクリプションURLにアクセスし、サーバーから返された設定内容を取得します。
クライアントが対応するプロトコルと項目を解析し、ローカルのノード一覧を作成します。
ユーザーがノードを選択し、クライアントが対応するプロトコルで接続を確立します。
システムの通信が接続に入るかどうかは、システムプロキシ、仮想NIC、ルーティング設定にも左右されます。

つまり「サブスクリプションの導入に成功した」という表示は、クライアントが設定を読み取れたことを示すだけです。選択したノードが接続済みであることや、すべてのアプリがその接続を使い始めたことを意味しません。導入、接続、通信の取り込みは別々の段階です。形式が対応していないと表示される場合は、プロトコルの非互換、サブスクリプション種別の選択ミス、URLのコピー漏れ、または一時的な取得失敗がよくある原因です。

✅ サブスクリプション名とノード一覧がクライアントに表示されている
✅ 手動でサブスクリプションを更新しても解析エラーが出ない
✅ ノード選択後に明確な接続状態を確認できる
✅ ブラウザと対象アプリの通信経路が現在のモードと一致している
❌ ノード名が表示されたからといって、すべての通信が取り込まれたと判断する

ノード・サーバー・回線は同じ意味ではありません

サーバーは実際または仮想のコンピューティングリソース、ノードはクライアントから選べる接続設定、回線はローカルから出口までデータが通るネットワーク経路を指します。一台のサーバーに複数のノード設定を載せることもあり、名前の異なるノードが一部の基盤を共有する場合もあります。クライアントに見えているのは入口の一覧であり、名前だけから背後の経路を完全に推測できるとは限りません。

ノード名には地域、入口、出口、倍率、回線などのタグが付くことがあります。地域は通常、出口の位置を示しますが、具体的な命名規則はサービス提供者によって異なります。アクセス位置を確認するときは実際の出口検知結果を基準にし、ノード名をネットワーク上の証明書のように扱わないでください。

用語	かんたんな説明	主な特徴	注意点
直結	クライアントが遠隔の出口サーバーへ直接接続する方式	経路構成が比較的シンプルで、実際の状態は現地の通信事業者とインターネットの経路に左右される	ネットワーク間の接続、混雑、迂回経路によって、体感が変動することがある
中継	まず近い、または適した入口に入り、そこから出口へ転送する方式	入口と出口の間の経路を調整し、インターネット上の経路による不確実性を抑えられる場合がある	中継だからといって常に低遅延とは限らず、入口の品質とその先の経路が重要
IEPL 専用線	経路の一部を企業向けの国際専用線リソースで運ぶ方式	経路の制御しやすさと国際区間の安定性を重視することが多い	接続構成や名称はサービスごとに異なるため、具体的な回線説明を確認する
出口	リクエストが最終的にインターネットへ出ていく場所	ウェブサイトから見える接続元の地域や、一部のコンテンツ表示に影響する	出口の地域が、そのまま経路全体の所在地を示すわけではない

いわゆる「遅延テスト」は、通常クライアントがノードに対して行う簡易的な探査です。クライアントによって、接続確立、ウェブ応答、簡単な探査パケットなど測定対象が異なるため、結果をダウンロード速度と直接同じものとして扱うことはできません。遅延は明らかに到達できないノードを絞り込むのに役立ちますが、通信量、パケットロス、ジッター、混雑時間帯の状態は実際の利用や個別テストで確認する必要があります。

ノード一覧は駅の案内表示に似ています。どこから乗れるかはわかりますが、途中の線路をすべて表示するわけではありません。実際の回線品質は、接続後の経路と継続的な状態で判断しましょう。

プロトコルの略称は何を定めているのか

プロトコルは、クライアントとサーバーがデータを認証・カプセル化・転送する方法を定めます。互換性、通信上の特徴、ネットワーク変化への適応、導入要件などに影響しますが、混雑した回線を自動的に直すものではありません。プロトコルは列車の規格にたとえると理解しやすいでしょう。規格は線路と互換性が必要で、線路が混雑しているなら、車両を新しくしても問題は解決しません。

Shadowsocks

Shadowsocks は暗号化プロキシプロトコルの一つで、構成が比較的シンプルでクライアントの選択肢が多い点が特徴です。通常はアプリケーション層のプロキシ通信を扱うため、それだけで従来型 VPN のようにシステム全体を取り込むとは限りません。すべてのアプリを通せるかどうかは、システムプロキシ、仮想NICモード、ルーティング機能にも左右されます。

VMess と VLESS

VMess は V2Ray エコシステムで広く使われる認証・通信プロトコルで、通常は下位の通信方式やセキュリティ層と組み合わせて設定します。VLESS はより軽量な認証を重視し、それ自体がコンテンツの暗号化を担うわけではありません。実際の導入では TLS、REALITY、その他の安全な通信方式と組み合わせます。VLESS を確認したら、プロトコル名だけでなく通信方式、セキュリティ、サーバー名などの関連項目も確認してください。

Trojan

Trojan は通常 TLS 上で動作し、一般的な暗号化ウェブサイトの通信に近い外観になります。証明書、ドメイン、TLS パラメータが正しく組み合わさっていることが必要です。システム時刻、証明書検証、サーバー名の設定に問題があると、ハンドシェイクに失敗することがあります。検証を無効にすると一時的にエラーが消える場合もありますが、長期的な対策としては推奨されません。

Hysteria2 と TUIC

Hysteria2 と TUIC はどちらも QUIC と UDP の通信機能を基盤とし、高遅延、パケットロス、変動の大きいネットワークで通信体験を改善することを重視しています。クライアントとサーバーの双方が対応している必要があり、現在のネットワークが該当する UDP 通信を許可していることも重要です。UDP と相性の悪いネットワークでは接続できない場合があるため、その際は TCP と TLS に基づく互換性のある方式へ切り替えると切り分けやすくなります。

プロトコル選びの原則： まず、クライアントが完全に対応し、サーバー設定が明確で、現在のネットワークで正常にハンドシェイクできるプロトコルを選びます。そのうえで実際の使用感を比較しましょう。プロトコル名は速度ランキングではなく、ネットワーク環境を問わず勝てる万能選手でもありません。

システムプロキシ・仮想NIC・通信の取り込み

クライアントに「接続済み」と表示されても、通信をローカルのプロキシコアへ送る必要があります。代表的な方法はシステムプロキシと仮想NICモードです。これらは「どのプログラムのリクエストをクライアントに渡すか」を決めるもので、遠隔側で使うプロトコルとは別の層の話です。

システムプロキシはOSのプロキシ設定を変更します。システムプロキシに従うブラウザやアプリは通常接続を利用できますが、独自のネットワークスタックを使うプログラム、システムプロキシを無視するプログラム、UDPを直接送信するプログラムは迂回することがあります。ブラウザは正常なのに特定のアプリだけ読み込み中になるのは、別の入口を使っているだけかもしれません。

仮想NICモードは TUN と表示されることがよくあります。OSが提供する仮想ネットワークインターフェースを通じて、より広範なIP通信を取り込み、クライアントがルールに従って処理します。システムプロキシより網羅性が高い一方、ファイアウォール、他のネットワークツール、企業向けセキュリティソフト、既存の仮想NICと競合しやすくなります。有効化にはOSの許可が必要な場合があります。

取り込み方法	適した場面	取りこぼす可能性があるもの	確認するポイント
アプリ内プロキシ	特定のアプリだけ接続を利用させたい場合	他のアプリは自動的に追従しない	プロキシアドレス、ポート、アプリの設定
システムプロキシ	ブラウザとシステム設定に従うアプリ	システムプロキシを無視するプログラムと一部のUDP通信	システムプロキシの有効状態、ポートの使用状況
仮想NICモード	より多くのシステム通信を対象にしたい場合	経路、権限、ルーティングルールの影響を受ける可能性がある	権限、ファイアウォール、経路の競合、他の仮想NIC

グローバル・ルール・直結モードのルーティング

ルーティングは、ドメイン、IP、アプリ、ルールセットに応じてリクエストの行き先を決める仕組みです。主な行き先はプロキシ、直結、ブロックです。ノード自体を変更するのではなく、リクエストがノードに到達する前に振り分けます。

グローバルモードは通常、クライアントが取り込んだリクエストを、できる限り選択中のノードへ送ります。ノードが対象サービスに接続できるか一時的に確認したい場合や、ルールのマッチング問題を切り分けたい場合に適しています。ただし、OS上のすべてのデータが必ず接続に入るわけではありません。クライアントの取り込み範囲、LAN通信、システムコンポーネントには例外が残ることがあります。

ルールモードは、あらかじめ用意されたルールやカスタムルールに応じて、プロキシまたは直結を選びます。一般的にはローカルサービスを直結し、国際回線が必要な対象をプロキシへ送る、またはアプリごとに指定します。日常利用にはルールモードが向いていますが、ルールが古い、ドメイン分類が誤っている、複数ルールが上書きし合うといった場合、対象サイトが意図しない出口へ送られることがあります。

直結モードは通常、遠隔ノードを経由せず、現在のローカルネットワークを直接使います。プロキシ経路が原因かどうかを比較したり、特定アプリが本当にクライアントの制御下にあるか確認したりできます。直結へ切り替えても変化がない場合、そのアプリがクライアントに取り込まれていないか、キャッシュされた古い接続がまだ残っている可能性があります。

クライアントにリクエストが入る
├─ 直結ルールに一致 → ローカルネットワークを使用
├─ プロキシルールに一致 → 現在のノードへ渡す
├─ ブロックルールに一致 → リクエストを阻止
└─ ルールに一致しない → クライアントの最終ルールを使用

ルールには通常、適用順があります。より具体的なルールは優先的に一致する位置に置き、最終ルールで前のルールが判定できなかったリクエストを受け止めます。変更後も結果が変わらない場合は、対象アプリを終了して再起動し、既存の接続を張り直してください。必要に応じてDNSキャッシュも削除します。

✅ グローバルモードでノードと対象サービスの接続を一時的に確認する
✅ 確認後、ルールモードに戻してマッチング結果を調べる
✅ クライアントの接続ログで対象ドメインと最終的な行き先を確認する
✅ ルール変更後、対象アプリのネットワーク接続を張り直す
❌ グローバルモードを無条件に速度を上げるスイッチとして扱う

DNS・DNSリーク・ドメイン解決

DNSはドメイン名を接続可能なアドレスへ変換します。ブラウザにドメイン名を入力すると、システムまたはクライアントが先に名前解決を行い、その後で接続を開始します。ノードは利用できてもDNS解決に失敗すると、ドメインだけ開けないことがあります。一方、既知のアドレスへ直接アクセスすると応答する場合があります。

リモートDNSは通常、プロキシ側または指定した暗号化DNSサービスで処理し、ローカルDNSは現在のネットワークが提供する解決経路を使います。ルーティング機能を持つクライアントでは、ルールに応じてドメインごとに処理を分け、ローカルサービスと海外サイトの両方に対応できます。DNS問い合わせがローカルネットワークを通り、実際のアクセスだけが遠隔ノードを通る場合、出口に合わない解決結果になったり、プロキシ経路で処理したい問い合わせが外部に出たりする可能性があります。

DNSリークは通常、管理下の経路で処理すべきDNS問い合わせがクライアントを迂回し、ローカルネットワークのDNSサーバーへ送られる状態を指します。IPリークとは別の概念です。対策として、クライアントのDNS取り込みを有効にし、仮想NICモードでの名前解決経路を確認し、ルール対象外の方法でアプリが独自にDNSを使わないようにします。ブラウザ内蔵のセキュアDNSとクライアントの方針が競合していないかも確認してください。

プラットフォームによってクライアントの見た目が違う理由

同じサブスクリプションでも、プラットフォームによって表示される設定や対応プロトコルが異なる場合があります。これはサブスクリプションが突然変化したのではなく、OSの機能、クライアントのコア、アプリの権限が異なるためです。

Windows クライアントでは、システムプロキシと TUN モードを同時に利用できることがよくあります。システムプロキシは扱いやすく、TUN はより広い範囲をカバーしますが、管理者権限、ドライバー、システムファイアウォール、他のネットワークツールに注意が必要です。macOS クライアントは通常、システムのネットワーク拡張またはプロキシ設定を利用し、初回有効化時に許可を求めます。許可が完了していなければ、ノードを導入できても通信を実際に取り込めません。

iOS と iPadOS のクライアントは通常、システムの VPN 構成を通じてネットワークを取り込みます。サブスクリプション導入後は構成の追加を許可し、システムの状態画面で接続を確認する必要があります。プラットフォームの制約により、対応するプロトコル、スクリプト、ルール機能はクライアントごとに異なります。デスクトップ版の全設定が同じように表示されるとは限りません。

Android クライアントは通常、システムの VPN インターフェースを利用し、アプリごとに接続を経由するか設定できますが、具体的な機能はクライアントによって異なります。OSの省電力機能でバックグラウンド動作が制限されると、画面ロックやネットワーク切り替え後に接続が切れることがあります。Linux クライアントではコマンドライン、サービスプロセス、手動設定が一般的で、システムプロキシとルーティングの取り込みを個別に設定する場合が多いです。

クライアントを選ぶときは、まずサブスクリプションのプロトコルと通信パラメータに対応しているか確認し、次にシステムプロキシ、TUN、ルール編集、サブスクリプション更新、ログ機能を見ます。見た目の華やかさだけで比べると、計器盤は光るのに設定を理解できない宇宙船を選びかねません。

初心者のトラブル解決はどの順番で行うか

接続問題で避けたいのは、プロトコル変更、ノード交換、クライアント再インストール、DNS調整、ルール全削除を同時に行うことです。直ったとしても、どの手順が効いたのかわからなくなります。再現性のある切り分けは外側から内側へ進め、毎回一つの変数だけを変更します。

ローカルネットワークを確認：クライアントを一時的に停止し、通常のウェブサイトへ直接アクセスできるか確認します。
サブスクリプションを更新：サブスクリプションを取得でき、ノード一覧に解析エラーがないことを確認します。
ノードを変更：同じプロトコルとモードのままノードを変更し、単一ノードの障害か全体設定の問題かを切り分けます。
プロトコルの互換性を確認：クライアントが対象プロトコルと通信方式、セキュリティパラメータに対応しているか確認します。
取り込み方法を切り替え：ブラウザは正常で他のアプリに問題がある場合は、システムプロキシと TUN を重点的に確認します。
一時的にグローバルモードを使用：グローバルでは使えてルールモードでは使えない場合、問題は主にルーティングルールまたはDNS経路にあります。
ログを確認：解析失敗、接続タイムアウト、TLSハンドシェイク、認証失敗、経路競合などの明確な表示に注目します。

ログの「タイムアウト」は、待機時間内に応答がなかったことを示し、ノードへの到達不能、パケットロス、ファイアウォール制限などが考えられます。「認証失敗」は認証情報や設定の不一致に近い問題です。「TLSハンドシェイク失敗」では、システム時刻、サーバー名、証明書、セキュリティパラメータを確認します。「アドレスはすでに使用されています」は、ローカルポートの競合でよく発生します。クライアントによって表現は異なりますが、問題の層はおおむね同じです。

最後に覚えておきたいこと： まずサブスクリプションが読み込まれたかを確認し、次にノードがハンドシェイクできるかを確認します。その後、通信が取り込まれているか、最後にルーティングとDNSを確認します。問題を層ごとに分ければ、用語は障害物ではなく道しるべになります。

これらの用語がわかると、クライアントの画面は略語だらけの荒野ではなくなります。サブスクリプションは設定を届け、ノードは入口を示し、プロトコルは通信を確立し、システムプロキシや仮想NICは通信を集め、ルーティングルールは行き先を決め、DNSは目的地のアドレスを探します。問題が起きたら通信の流れに沿って層ごとに確認するほうが、すべての設定を闇雲に切り替えるより確実です。