VPN 用語集：サブスクリプション・ノード・プロトコル・ルール分岐を徹底解説

まず接続全体の流れを確認：各用語はどの層にあたるのか

VPN 用語を理解するには、定義を一つずつ暗記するより、実際の接続を最初から追うのが効果的です。まずサービスの管理画面からサブスクリプション URL を取得してクライアントに読み込みます。クライアントはそこに含まれるノード設定を読み取り、プロトコル、伝送方式、認証情報に基づいて接続を確立します。接続後はルール分岐がどのリクエストをノード経由にするかを決め、DNS 設定がドメインをアドレスへ解決し、出口サーバーが端末に代わって対象サイトへアクセスします。

この流れでは、「サブスクリプション」が設定を配布し、「ノード」が接続可能な入口または出口を示し、「プロトコル」がクライアントとサーバーの通信方法を定め、「回線」がノードの背後にあるネットワーク経路を表し、「ルール分岐」がリクエストをプロキシ経由にするかどうかを決めます。互いに関係していますが、同じ概念ではありません。サブスクリプションを正常に更新できても、すべてのノードが現在のネットワークに適しているとは限りません。あるプロトコルでハンドシェイクに成功しても、対象サイトが必ずその回線を通るとは限りません。

サブスクリプション URL、ノード、設定ファイルの違い

サブスクリプション URL は設定への入口であり、ノードそのものではない

サブスクリプション URL は通常、サービスの管理画面で発行されます。クライアントがこのアドレスへアクセスすると、エンコードまたは構造化された設定データを取得します。そこにはノード名、サーバーアドレス、認証情報、プロトコルの種類、伝送パラメーターなどが含まれる場合があります。クライアントの「サブスクリプションを更新」操作は、このデータを再取得してローカルの一覧を更新する処理です。

サブスクリプション URL にはアカウントやサービス権限を識別できるトークンが含まれることがあるため、パスワードと同じように慎重に管理してください。完全な URL を公開ページ、スクリーンショット、フォーラム、コードリポジトリなどに掲載してはいけません。サポートへ問題を伝える場合は、クライアントのエラー内容やノード名を共有し、URL に含まれる識別パラメーターは隠してください。

サブスクリプションの更新失敗とノードの接続失敗は分けて判断します。前者は、URL の期限切れ、サブスクリプションアドレスへのネットワークアクセス不能、クライアント形式の非互換などが原因かもしれません。後者は、ノードのメンテナンス、ローカルネットワークの制限、プロトコルパラメーターの不一致、システム時刻の異常などが考えられます。古いノードへ接続できてもサブスクリプションを更新できない場合があります。逆に、更新に成功しても、すべての回線が現在の環境に適しているとは限りません。

ノードは実行可能な接続パラメーターのまとまり

クライアントの一覧に表示される「日本」「シンガポール」などの地域名は、識別しやすくするためのラベルにすぎません。実際のノード設定には、サーバーアドレス、接続ポート、ユーザー認証情報、プロトコル、トランスポート層、セキュリティ層のパラメーターも含まれます。同じノード名でも、入口、中継方式、プロトコルが異なる場合があります。

ノードの地域は通常、出口アドレスの所在地域を示しますが、サービスによっては入口、用途、回線種別に基づいて命名されることもあります。出口位置を確認するときは、接続後に本サイトの自分の IPページを開いて確認し、クライアントの名称だけで判断しないでください。ブラウザーの位置情報、アカウントの地域、サイトのキャッシュも表示に影響する場合があり、出口 IP とは別の情報です。

手動設定とサブスクリプションの読み込み

手動設定では、サーバー、認証、プロトコル、伝送パラメーターを一つずつ入力します。各項目の意味を把握しやすく、個別のデバッグに適しています。一方、サブスクリプションの読み込みは日常利用に向いています。サーバー側でノードが変更されても、クライアントで更新すれば変更内容を取得できるためです。どちらも接続の仕組みに本質的な違いはなく、主な違いは設定をクライアントへ取り込む方法です。

1. サービスの管理画面からサブスクリプション URL をコピーし、信頼できない中継サイトで変換しないでください。
2. 対応クライアントで「サブスクリプション」「設定ソース」または同様の項目を開きます。
3. URL を貼り付けて更新を実行し、一覧にノードとプロトコル情報が表示されることを確認します。
4. ノードを選んで接続し、出口 IP と DNS の状態を確認します。
5. サーバー側の設定が変わったら、まずサブスクリプションを更新し、キャッシュされた古いパラメーターに長期間依存しないでください。

直接接続、中継、IEPL 専線とは何か

プロトコルは「データをどのようにカプセル化して送るか」を決め、回線は「データが実際にどこを通るか」を示します。同じプロトコルが異なる回線で動作することもあれば、同じ回線が複数のプロトコルを運ぶこともあります。そのため、ノードを比較するときはプロトコル名だけでなく、ローカルネットワーク、アクセス先、経路も考慮する必要があります。

直接接続回線

直接接続は、クライアントが対象地域のサーバーへ直接接続し、サービス側が追加で構成した接続中継を経由しない方式です。構成がシンプルで、経路は主にローカル通信事業者とインターネットのルーティングによって決まります。実際の使用感は、ネットワーク間接続、国際出口の混雑、経路の迂回などに左右されます。同じ直接接続ノードでも、地域や接続ネットワークが違えば性能が大きく異なる場合があります。

中継回線

中継回線では、まず比較的近い、または到達しやすい入口へ接続し、そこから最終出口へ転送します。中継の目的は、品質の低い直接接続経路を避けたり、入口と出口を一元管理したりすることです。転送工程が一つ増えますが、必ずしも遅くなるわけではありません。入口から出口までの経路が安定していれば、迂回の大きい直接接続より適している場合があります。

中継を選ぶときは、ローカル環境から入口までと、入口から出口までの2つの経路を分けて考えます。入口には到達できても出口に異常がある場合、クライアントには接続済みと表示されるのに、ウェブリクエストが完了しないことがあります。この場合はログを確認し、ハンドシェイク後にデータが届いていないのか、対象サイトが出口からのリクエストを拒否しているのかを判断します。

IEPL 専線

IEPL は通常、国際イーサネット専線に類する接続を指し、通信事業者の専用伝送網を通じて異なる地域のネットワーク接続拠点を相互接続します。ユーザー向けのノード名で「IEPL 専線」と表記されている場合、途中のバックボーン区間が通常のインターネット直接接続とは異なることを強調しています。ただし、端末から接続拠点まで、また出口から対象サイトまでの経路は、ローカルネットワークやインターネットを通る場合があります。

したがって、IEPL を端末からすべてのサイトまで続く物理的な専有回線全体と捉えるべきではなく、ラベルだけから固定遅延や固定帯域幅を推測することもできません。より実用的な判断方法は、自分の接続ネットワークで接続確立が安定するか、継続的な通信がスムーズか、対象プラットフォームへ正常にアクセスできるかを比較することです。本サイトのグローバルノードページでは地域と回線種別を確認できます。動的な状態は、実際に接続したときのクライアント結果を基準にしてください。

Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC

プロトコルは、クライアントとサーバーがどのように認証し、データをカプセル化して送るかを定めます。ただし、現代のプロキシ接続では、トランスポート層やセキュリティ層が組み合わされることも一般的です。プロトコル名を確認したら、TCP、WebSocket、gRPC、QUIC のどの伝送方式上で動作しているか、TLS を使っているか、サーバー名や証明書検証などのパラメーターが正しいかも確認してください。

Shadowsocks

Shadowsocks は暗号化プロキシプロトコルです。設定の中心となるのは通常、サーバー、ポート、パスワード、暗号化方式です。構成が比較的シンプルで、対応クライアントも多いため、設定の複雑さを抑えたい場面に適しています。クライアントとサーバーで互換性のある暗号化方式とパラメーターを使わなければ、データを復号できません。Shadowsocks 自体は従来の意味での端末全体向け VPN ではなく、すべてのアプリを経由させるかどうかは、クライアントがシステムプロキシ、TUN モード、その他の転送方式のどれを使うかによって決まります。

VMess

VMess は V2Ray エコシステムでよく使われ、認証機構を備え、さまざまな伝送方式と組み合わせて利用できます。実装によってはシステム時刻のずれに敏感なため、認証に失敗したときは、端末の時刻とタイムゾーンが自動補正されているか確認してください。VMess は接続設定の一部にすぎず、WebSocket パス、ホスト名、TLS、伝送パラメーターもサーバー側と一致させる必要があります。

VLESS

VLESS は認証とデータ構造を簡素化した方式で、完全な伝送暗号化を単独で提供するものではありません。通常は TLS、REALITY、または保護された下位伝送と組み合わせます。VLESS 設定の安全性を判断するときは、プロトコル名だけでなく、セキュリティ層が有効か、証明書や公開鍵のパラメーターが一致しているか、クライアントが正しくサーバー認証を実行しているかを確認してください。

Trojan

Trojan は通常 TLS 上で動作し、パスワードで認証を行います。接続の外観は一般的な TLS トラフィックに近いものです。設定では、サーバー名、証明書検証、パスワードなどがよく使われます。証明書検証を無効にすると設定ミスを一時的に回避できる場合がありますが、サーバーの身元確認が弱くなるため、長期的なトラブルシューティングには適しません。ドメイン、証明書、端末の時刻を確認するのが適切です。

Hysteria2

Hysteria2 は UDP と QUIC の考え方に基づいて設計され、不安定な回線やパケットロスの多い経路を想定した輻輳制御機構を備えています。適したネットワークでは、継続的な通信で良好な性能を得られる可能性がありますが、ローカルネットワークが UDP 通信を許可し、ルーター、ファイアウォール、通信事業者の経路による大きな制限がないことが前提です。UDP が遮断されている、または品質が非常に悪い場合は、無関係なルール分岐を何度も変更するのではなく、利用可能な別のプロトコルを選んでください。

TUIC

TUIC も QUIC と UDP を基盤とし、多重化と接続管理を重視しています。Hysteria2 とパラメーターを交換して使える同一プロトコルではなく、クライアントとサーバーがそれぞれ対応する実装を備えている必要があります。「プロトコルに対応していません」と表示されたら、TUIC ノードを通常の TLS ノードとして手入力するのではなく、まずクライアントのバージョンとコア機能を確認してください。

ルール分岐、グローバルモード、ルールモードの仕組み

ルール分岐とは、クライアントがネットワーク上の各リクエストに対して行う経路選択です。一般的な結果には、プロキシ、直接接続、ブロックがあります。判断基準には、ドメイン、対象 IP、アプリのプロセス、ポート、地域データベース、カスタムルールなどを使えます。具体的な機能はクライアントと実行プラットフォームによって異なります。

グローバルモード

グローバルモードでは通常、クライアントが取り込んだトラフィックを原則すべて現在のノードへ渡します。「あるリクエストがルールに一致せず直接接続されているのか」を一時的に確認したい場合や、出口を統一したい短時間の利用に適しています。ただし、グローバルモードでも端末上のすべてのパケットが必ずノードを経由するわけではありません。システムプロキシの対象外のアプリ、LAN 通信、システムサービス、クライアントが対応していないプロトコルは、元の経路を使う可能性があります。TUN モードを有効にすると取り込める範囲を広げられますが、最終的にはクライアントの説明とルーティングテーブルを確認してください。

ルールモード

ルールモードでは、リクエストをルールの順番に沿って照合します。たとえば、ローカルネットワークのアドレスは直接接続し、指定した海外サイトはプロキシ経由にし、広告ドメインはブロックし、それ以外は既定の方針を使うといった設定です。ルールには通常優先順位があり、先に一致したリクエストは後続のルールで再判定されません。カスタムルールが機能しない場合は、ルールの内容だけでなく、より前のルールに上書きされていないかも確認してください。

ドメインルールと IP ルールにも違いがあります。ドメインルールには、クライアントが元のドメイン名を確認できることが必要です。アプリがすでに DNS 解決を済ませている場合、クライアントには対象 IP しか見えないことがあります。逆に、ドメインが動的に変化するアドレスへ解決される場合、固定 IP ルールだけでは機能しにくくなります。充実したルールセットでは、通常ドメイン、IP データ、DNS 処理を組み合わせます。

直接接続と LAN のバイパス

直接接続は、リクエストが遠隔ノードを経由せず、ローカルネットワークから通常どおりアクセスすることを示します。プリンター、ルーターの管理画面、LAN ストレージなどのローカルリソースでは、通常直接接続が必要です。グローバルモードでこれらのリソースへアクセスできなくなった場合は、「LAN をバイパス」を有効にするか、ローカルアドレスのルールを追加します。直接接続ルールではローカルネットワーク本来の出口が使われますが、これはルール分岐の設計結果であり、接続障害とは限りません。

システムプロキシと TUN モード

システムプロキシは、OS のプロキシ設定に従うアプリに主に影響します。ブラウザーは対応しやすい一方、一部のゲーム、コマンドラインツール、独自のネットワークスタックを持つソフトウェアは設定を無視することがあります。TUN モードは仮想ネットワークインターフェースを通じて、より広範な IP トラフィックを取り込みます。通常はカバー範囲が広くなりますが、ファイアウォール、企業ネットワークソフトウェア、他の VPN 設定と衝突しやすくもなります。

ブラウザーはアクセスできるのに特定のアプリだけ利用できない場合は、そのアプリがシステムプロキシに従うかを確認してください。すべてのアプリでネットワークに接続できない場合は、TUN の経路、DNS、システムファイアウォールを確認します。「システムプロキシがアプリをカバーしていない」ことを、ノードの障害と誤判断しないでください。

DNS、リモート解決、DNS リーク

DNS の役割は、ドメインを接続可能な IP アドレスへ解決することです。ブラウザーがサイトへアクセスするときは、通常まずドメイン解決を行い、その後ネットワーク接続を確立します。プロキシに接続できていても、DNS リクエストまで同じ経路を通るとは限りません。これはクライアントの DNS モード、システム設定、アプリ独自の動作によって決まります。

DNS リークとは

関連するすべてのリクエストをプロキシ経由にしたい状況で、ドメイン検索がローカルネットワークの DNS サーバーへ送信され続けると、一般に DNS リークと呼ばれる状態になります。その結果、ローカルの DNS 事業者に検索したドメインを把握される可能性があります。また、ローカルと遠隔の解決結果が異なることで、サイトへのアクセスに問題が生じる場合もあります。

確認時は出口 IP だけを見ないでください。DNS 検査ページに表示される DNS サーバーが現在の設定に合っているかを確認し、ブラウザーで独自のセキュア DNS が有効になっていないかも確認します。ブラウザー内蔵の暗号化 DNS は検索の通信を保護できますが、ローカルの直接接続出口を選んでいる場合、検索がプロキシノード経由になっているとは限りません。

ローカル解決とリモート解決

ローカル解決では、端末またはローカルネットワークが先に対象 IP を取得し、その後ルール分岐エンジンが接続方法を決めます。応答は速い一方、ドメイン情報がローカル経路に残る可能性があります。リモート解決では、プロキシ側または指定した遠隔 DNS リゾルバーへ検索を渡すため、ドメイン判定と出口地域をそろえやすくなります。クライアントによっては、プロキシ DNS、リモート DNS、Fake IP、拡張モードなどの名称で表示されますが、実装は同一ではありません。

Fake IP モードでは、まずクライアントが管理する対応アドレスをアプリへ返し、内部で実際のドメインと関連付けてルール分岐を実行します。これによりドメイン情報を保持しやすくなりますが、一部の LAN サービス、デバイス検出、特殊な DNS 結果に依存するアプリでは互換性の問題が起こる場合があります。問題が生じたときは、DNS 管理全体を無効にするのではなく、関連ドメインを除外リストへ追加してください。

1. 接続前に現在の出口と DNS の解決状態を記録します。
2. ノード接続後に出口 IP をもう一度確認し、トラフィックが実際に切り替わったことを確認します。
3. DNS の解決先がクライアントの設定に合っているか確認します。
4. ブラウザーとその他のアプリを個別にテストし、アプリ独自の DNS が使われていないか判断します。
5. ルールモードとグローバルモードを切り替えて比較し、DNS の問題かルール分岐の問題かを切り分けます。

Windows、macOS、iOS、Android、Linux のクライアントの違い

同じサブスクリプションでも、プラットフォームによって表示される項目が異なる場合があります。これは OS のネットワークインターフェースやクライアントコアの違いによるもので、サブスクリプションの内容が変わったわけではありません。読み込む前に、クライアントがサブスクリプション内のプロトコル、伝送方式、セキュリティパラメーターに対応しているか確認してください。

Windows

Windows クライアントでは、システムプロキシと TUN モードを同時に提供することがよくあります。システムプロキシはブラウザーのトラフィックをすばやく切り替えるのに便利で、TUN はプロキシ設定に従わないアプリの取り込みに適しています。TUN を有効にするとシステム権限が必要になる場合があるため、他の仮想ネットワークアダプター、企業向けセキュリティソフト、既存の VPN 接続との競合も確認してください。

macOS

macOS でも、システムプロキシまたはネットワーク拡張を通じてトラフィックを取り込めます。関連する拡張機能を初めて有効にするときは、システムが権限の確認を求めます。クライアントが接続済みと表示されるのに一部のアプリが直接接続する場合は、システムプロキシと仮想ネットワークインターフェースのどちらを使っているかを確認し、アプリ独自のプロキシや DNS 設定も確認してください。

iOS と Android

モバイル向けのプロキシクライアントは、通常システムの VPN インターフェースを使ってトラフィックを処理します。ステータスバーに VPN アイコンが表示されても、システムのネットワーク拡張が動作していることを示すだけで、ノードの出口や DNS が期待どおりとは限りません。モバイル OS では通常、主要な VPN 設定を1つだけアクティブにできます。広告ブロック、企業ネットワーク接続、プロキシクライアントが同じインターフェースを取り合う場合があります。

Android 端末では、VPN の常時接続やアプリごとのルール分岐などのシステム機能も利用できます。端末メーカーごとの省電力設定によって、クライアントのバックグラウンド動作が制限される場合もあります。iOS のルール分岐機能は、クライアントのネットワーク拡張の実装に大きく左右されます。スリープ後に接続が切れる場合は、まずシステム権限とバックグラウンド設定を確認し、その後でノードの変更を検討してください。

Linux

Linux 環境では、GUI クライアントのほか、コマンドラインコア、システムサービス、ルーティングルールを使って動作させることもあります。システムプロキシの環境変数は、それを読み取るプログラムにしか有効ではなく、透過転送や TUN の代わりにはなりません。トラブルシューティングでは、プロセスの稼働、リスニング状態、ルーティングテーブルの更新、システムのネットワーク管理サービスによる DNS 設定の上書きを確認してください。

接続異常は層ごとに確認し、すべての項目を同時に変更しない

用語が役立つのは、問題を検証可能な工程に分解できるからです。プロトコル、DNS、ノード、ルール分岐、システムプロキシを一度に変更すると、問題が一時的に解消しても原因が分かりません。次の順序で確認すると、再現と切り分けが容易になります。

サブスクリプションを更新できない

• コピーしたサブスクリプション URL が完全なものか、空白や途中で切れた文字が混ざっていないか確認します。
• サービスの状態とサブスクリプションの権限が有効か確認します。
• クライアントがそのサブスクリプション形式に対応しているか確認し、更新ログに表示されたネットワークエラーを確認します。
• 認証情報を含む URL を、出所の不明なオンライン変換ツールで処理しないでください。

ノードへの接続を確立できない

• まず同じプロトコルの別ノードへ切り替え、単一ノードの問題かプロトコル全体の問題かを判断します。
• システム時刻を補正します。特に VMess、TLS、証明書検証を使う場合は重要です。
• Hysteria2 または TUIC を使う場合は、現在のネットワークが UDP を許可しているか確認します。
• サーバー名、伝送パス、認証、証明書関連のパラメーターを確認します。

接続済みと表示されるのにウェブページを開けない

• 出口 IP が変化しているか確認し、ハンドシェイクの成功と実際の転送成功を区別します。
• グローバルモードに切り替えて比較し、対象ドメインがルールから漏れていないか判断します。
• DNS が結果を返せるか、またその結果が誤った経路へ送られていないか確認します。
• ブラウザーに無効なプロキシ設定や独自のネットワーク拡張が残っていないか確認します。

ブラウザーは使えるのに他のアプリは使えない

• 現在、システムプロキシだけが有効になっていないか確認します。
• 対象アプリがプロキシに対応しているか、TUN による取り込みが必要か確認します。
• プロセスのルール分岐設定で、そのアプリが直接接続になっていないか確認します。
• アプリ独自の DNS、QUIC、固定出口ポリシーによる違いを切り分けます。

接続は安定しているのにアクセス結果が期待と異なる

まず出口地域を確認し、次に対象サイトがアカウント地域、キャッシュ、言語設定、ブラウザーの位置情報に基づいてコンテンツを表示していないか確認します。ノードが変更するのは、取り込まれたトラフィックのネットワーク出口だけであり、サイトのアカウント情報を自動的に変更するものではありません。プラットフォームが現在の出口を拒否する場合も、すべての結果をプロトコルのせいにせず、適した地域または回線へ切り替えて検証してください。

これらの VPN 用語を理解すると、接続を明確な流れとして捉えられます。サブスクリプションが設定を提供し、クライアントがノードを解析し、プロトコルが通信を確立し、回線がデータを運び、ルール分岐が経路を選び、DNS がドメインを解決し、出口が端末に代わって対象へアクセスします。サービス選びやトラブルシューティングでは、この流れに沿って層ごとに確認する方が、特定のプロトコル名だけを追いかけるより確実です。実際の操作をさらに知りたい場合は、初心者ガイドと完全ガイドをご覧ください。