VPN初心者向け用語早見表：サブスクリプション、ノード、プロトコル、トラフィック分岐、グローバルモードとルールモードを一度に理解

初めてVPNクライアントを開いたとき、難しいのは接続ボタンを押すことより、サブスクリプション、ノード、プロトコル、ルール分岐、グローバルモード、ルールモードが何を制御するのかを理解することです。これらは同じ階層の設定ではありません。サブスクリプションは設定を届け、ノードは接続先の入口を示し、プロトコルはクライアントとサーバーの通信方法を定め、回線種別はデータが実際に通る経路を表し、分岐モードはどのリクエストをその経路に通すかを決めます。

全体の流れは物流配送にたとえられます。サブスクリプションは更新され続ける住所録、ノードは選択可能な中継地点、プロトコルは双方が合意した梱包方法、回線は荷物が実際に通る道路、ルール分岐は配車表です。これらを接続の流れに当てはめると、クライアントに並ぶ一見複雑なボタンも、明確なデータの連鎖として理解できます。

主要用語の早見表：各設定が制御する対象を整理

ここで重要なのは「設定」と「通信」の違いです。サブスクリプション、ノード、プロトコルは接続設定に属し、ルール分岐、グローバルモード、ルールモードは通信の振り分けを担います。接続成功はクライアントとリモート入口の間に通信経路ができたことを示すだけで、すべてのアプリがその経路を使うことや、DNSリクエストが想定どおり進むことまでは意味しません。

サブスクリプションとノード：住所録と接続先は別のもの

サブスクリプションリンクで受け取るもの

サブスクリプションリンクは通常、クライアントが読み込める設定データを指します。クライアントがリンクにアクセスすると、内容をノード一覧や設定ファイルとして解析します。対応する形式はクライアントによって異なり、一般的な共有リンクを直接認識するもの、特定の設定構造を必要とするもの、ルールセット、プロキシグループ、DNSパラメータまで同時に配布するものがあります。

サブスクリプションリンクは通常のウェブページのブックマークでも、単なるダウンロードボタンでもありません。サーバーアドレス、ポート、プロトコル認証情報、伝送方式、ノード名などが含まれる場合があるため、接続情報と同じように慎重に保管してください。リンクをスクリーンショット、ログ、問い合わせ内容に公開すると、接続設定一式が同時に漏れる可能性があります。

「サブスクリプションを更新」は、クライアントがリモート設定を再読み込みする操作です。更新後は、サーバー側で追加、削除、変更されたノードがローカルに反映されます。クライアントによってはサブスクリプション内のノードを手動変更した内容が上書きされるため、長期的に保持したいローカルルールは、サブスクリプションから生成されたノードを直接編集せず、クライアントが対応する上書き設定、設定スニペット、独立したルール欄に保存するのがおすすめです。

1. サブスクリプションリンクをコピー：サービスパネルから、クライアントの形式に合うリンクを取得します。チャットのスクリーンショットを見ながら手入力しないでください。
2. インポート方法を選択：クライアントで「URLからインポート」「サブスクリプションを追加」など、同等の項目を使用します。
3. 更新を実行：クライアントの解析が完了するまで待ち、読み込み前のサブスクリプション名だけでなく、ノード一覧が表示されたことを確認します。
4. ノードを選択：まず目的地域と用途に合う出口を選び、その後、回線種別と現在のネットワーク状況に応じて調整します。
5. 通信の引き受けを有効化：プラットフォームに応じてシステムプロキシまたはTUNを選び、実際のリクエストで出口とDNSを確認します。

ノード名から分かる情報

ノードは接続を確立できるリモート設定です。名称には地域、都市、回線、用途などが記載されることがありますが、名称自体が通信に関与するわけではありません。選択の手がかりとなる運用上のラベルです。ノードに「日本」と表示されていれば、想定される出口が日本にあることを示すのが一般的ですが、入口の場所、伝送経路、通信事業者のルーティング、現在の混雑状況まで名称だけで判断することはできません。

「ノード」と「サーバー」も完全に同じ意味ではありません。複数のノード設定が同じ基盤で動作する場合もあれば、異なる入口、出口、伝送パラメータに対応する場合もあります。反対に、1つのノードの背後に入口転送と出口サービスが含まれることもあります。利用者にとってノードはクライアントで選択できる論理的な接続項目であり、サーバーはその接続を実現する基盤を指します。

• ✅ まず、出口地域が利用したいサービスの地域要件に合っているか確認します。
• ✅ 次に、現在のネットワーク環境と利用時間帯に回線種別が合っているか確認します。
• ✅ ノードを切り替えたら、目的の接続をいったん開き直し、以前の出口を古いセッションが再利用しないようにします。
• ❌ ノード名にある「高速」「専用」といった表記だけで実際の経路を判断しないでください。
• ❌ サブスクリプションの更新失敗を、すべてのノードが同時に故障したと判断しないでください。

プロトコル：Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC

プロトコルは、クライアントがリクエストをどのようにカプセル化し、認証を行い、サーバーとデータを交換するかを定めます。プロトコル名は伝送層、TLS、WebSocket、QUICなどのパラメータと一緒に表示されることが多く、同じプロトコルでも構成は異なります。プロトコル名だけから速度、安定性、適した地域を直接判断することはできません。プロトコル、伝送方式、回線、ローカルネットワークを総合的に見るほうが確実です。

Shadowsocksは厳密には暗号化プロキシであり、従来のネットワークインターフェースを作成する完全なVPNプロトコルではありません。日常の利用では、多くのクライアントが異なるプロキシプロトコルを「VPN」または「プロキシ」製品の画面にまとめています。これは製品上の分類であり、プロトコル本来の動作方式を変えるものではありません。

VMessとVLESSはいずれもV2Ray互換エコシステムでよく使われますが、単純な新旧名称の置き換えではありません。認証とプロトコル構造が異なるため、サーバーが提供する設定に対応した形式でクライアントへインポートする必要があります。Trojanは通常、正しいTLSパラメータを必要とします。クライアントで重要な項目が省略されると、認証前のハンドシェイクで接続が終了する場合があります。

Hysteria2とTUICはQUICおよびUDPを使用します。パケットロス、揺らぎ、帯域幅の変化があるネットワークでは、TCP方式とは異なる挙動になることがあります。ただし、現在のネットワークでUDPが正常に通信できることが前提です。社内ネットワーク、公衆ネットワーク、一部のルーターではUDPが制限される場合があり、その際はQUICパラメータを何度も変更するより、TCPベースの設定へ切り替えるほうが直接的です。

回線種別：直接接続、中継、IEPL専線の実際の違い

プロトコルは「どう送るか」を解決し、回線は「どこを通るか」を決めます。同じプロトコルを使い、同じ出口地域を指す2つのノードでも、経路が違えば遅延、揺らぎ、パケットロスの特性は大きく異なります。ノード選びでプロトコルだけを見て回線を無視するのは、車種だけを見て道路状況を確認しないようなものです。

直接接続

直接接続は、クライアントがサービス側から明示的に提供された転送入口を介さず、リモートノードの入口へ直接接続する方式です。構造がシンプルで迂回が少ない一方、国際区間の品質はローカルの通信事業者と公衆ネットワークの経路に左右されます。あるネットワーク環境で快適な直接接続が、別の事業者でも同じ性能になるとは限りません。

中継回線

中継では、まず近い、または到達しやすい入口へ接続し、そこから目的の出口へ通信を転送します。中継の意味は物理的な距離をなくすことではなく、より管理しやすい入口と後続経路を通して、品質の低い公衆ネットワーク区間を避けることです。転送工程が増えるため、入口の容量、入口から出口までの経路、制御方針が最終的な体感に影響します。

IEPL専線

IEPLは通常、国際イーサネット専線系の接続を指し、拠点間により管理しやすい専用伝送経路を提供します。サブスクリプションサービスでは、利用者がまずローカルまたは近隣の入口へ到達し、その後、専線区間を通って遠隔の出口へ向かう構成が一般的です。利用者の端末が専線全体へ直接接続することや、端末から入口までのすべての区間が公衆ネットワークを離れることを意味しません。

IEPLの技術的な価値は、経路を管理しやすいことと、国際区間の安定性にあります。特定のプロキシプロトコルと結び付いたものではありません。専線は伝送経路を担い、Shadowsocks、Trojan、VLESSなどはクライアントと入口の通信を担います。「IEPL」をプロトコル名と理解すると、設定の切り分けを誤る原因になります。

ルール分岐、グローバルモード、ルールモード：各リクエストの行き先を決める

接続が確立した後も、クライアントはどの通信をノードへ渡すか決める必要があります。この判断の仕組みがルール分岐です。主な動作はプロキシ、直接接続、ブロックです。プロキシは現在のノードまたはプロキシグループへリクエストを渡し、直接接続はローカルネットワークを使い、ブロックはリクエストを送信しません。広告ドメイン、追跡ドメイン、明らかに不要なアドレスなどで使われます。

グローバルモードは文字どおりの「すべて」ではありません

グローバルモードは通常、クライアントがすでに引き受けている通信範囲内で、デフォルトですべてをプロキシへ渡す設定です。重要なのは「すでに引き受けている」という点です。システムプロキシだけを有効にしている場合、その設定に従うアプリが対象になります。システムプロキシを無視して独自に接続するアプリは、クライアントを経由しないことがあります。TUNを有効にすると、ネットワーク層からより広い通信を引き受けられることがありますが、プラットフォームの権限、ルーティング除外、LAN設定の影響は受けます。

したがって、「グローバル」と表示されても、端末上のすべてのデータがノードを通るとは限りません。目的のアプリの出口、DNS経路、クライアントの接続ログを確認するのが正しい検証方法です。ブラウザーの出口は変わったのに、独立したアプリがローカルネットワークを使い続ける場合は、そのアプリがシステムプロキシを回避していないか、TUNが正しく有効になっているか確認してください。

ルールモードはリクエストをどう照合するか

ルールモードでは、ドメイン、IPアドレス、地理データベース、アプリのプロセス、ポートなどの条件に応じて動作を選びます。クライアントは通常、ルールを上から順に照合し、該当した時点で対応するポリシーを実行します。該当しないリクエストは最終ルールへ進みます。そのためルールの順序が重要です。広い範囲を指定したルールを前に置くと、後ろの詳細なルールが適用されなくなることがあります。

ドメインが目的のサービスに属する → プロキシ
ドメインがローカルでよく使うサービスに属する → 直接接続
アドレスがLANの範囲に属する → 直接接続
ドメインがブロックリストに属する → 拒否
その他のリクエスト → 最終ルールに従って処理

このロジックは特定クライアントの固定構文ではなく、判断の流れを理解するためのモデルです。クライアントごとにルール形式は異なります。ルールをコピーする前に、使用中のコアが対応する構文、ポリシーグループ名、DNSモードを確認してください。インポートに成功しても、認識できないルールは実際には適用されない場合があります。

• ✅ 国際サービスを利用するときは、対象ドメインと依存するドメインをプロキシポリシーの対象にします。
• ✅ ローカルサービスは原則として直接接続にし、不要な迂回や地域判定の変化を減らします。
• ✅ LAN機器は通常、直接接続のままにして、プリンター、ストレージ、ルーター管理画面への接続を保ちます。
• ✅ ルールを変更したら、古い接続を閉じて再テストし、接続の再利用が判断に影響しないようにします。
• ❌ 意味を理解しないまま、すべてのリクエストを同じポリシーに長期間固定しないでください。

システムプロキシとTUN：接続成功後も一部のアプリで反映されない理由

システムプロキシは、OSがアプリに提供するプロキシ設定です。ブラウザーや、システムのネットワーク設定に従う多くのデスクトップアプリが利用しますが、ゲーム、コマンドラインツール、仮想マシン、独自のネットワークスタックを実装するプログラムは無視することがあります。システムプロキシは設定が簡単で、ウェブ閲覧や一般的なアプリに適していますが、対象範囲はアプリが対応するかどうかに左右されます。

TUNモードは仮想ネットワークインターフェースを作成し、ルーティングによって通信をクライアントへ送ります。システムプロキシに対応しないアプリもより広く対象にでき、UDPやプロセス単位のルール分岐が必要な場面にも適しています。一方で、TUNにはより高いシステム権限が必要で、他のネットワークツール、ファイアウォール、仮想マシンのネットワークアダプター、企業のセキュリティポリシーとルーティングが競合することがあります。

クライアントによっては「拡張モード」「仮想ネットワークアダプターモード」などの名称も使われますが、実質的には異なるTUN実装である場合があります。名称はクライアントの画面によって異なるため、ボタンの文言だけでなく、仮想インターフェースを作成するか、DNSを引き受けるか、デフォルトルートを変更するかを確認してください。

DNSリークと名前解決の経路：出口が正しくても設定完了とは限らない

ドメインへアクセスする前に、端末は通常DNSを使ってドメイン名をアドレスへ変換します。DNSリークとは、指定したリゾルバーや経路で処理されるはずのDNSリクエストが、実際には想定外の経路へ出てしまうことです。たとえばウェブ接続はプロキシノードから送信されているのに、ドメイン検索だけはローカルネットワークのリゾルバーへ直接送られるケースがあります。その結果、地域判定の不一致、ルールの誤判定、プライバシー上の想定とのずれが生じる可能性があります。

DNSの問題は「リーク」だけではありません。DNSがローカルネットワーク向けのアドレスを返し、実際の接続が遠隔の出口から送信されると、サービスへの接続が遅くなったり、誤った地域へ誘導されたりすることがあります。ルールがドメインに依存している場合、クライアントが解決後のアドレスしか確認できないと、ドメインによる分岐が機能しないこともあります。クライアントによってはFake-IP、リモートDNS、DNSハイジャックなどを使って名前解決をルールエンジンに組み込みますが、具体的な機能はクライアントコアと設定に依存します。

確認時は「どの出口を使っているか」と「どのリゾルバーを使っているか」を分けて考えます。出口の確認はウェブ接続の発信元を示すだけで、DNS経路が正しいことを単独で証明するものではありません。ノードやDNSモードを切り替えた後は、OS、ブラウザー、アプリ自身のキャッシュも考慮してください。ブラウザーで独立した暗号化DNSを有効にしていると、クライアント設定のリゾルバーを回避することもあります。

1. 引き受け方式を確認：現在システムプロキシとTUNのどちらを使っているか、DNSをクライアントが処理しているか確認します。
2. 古いセッションを整理：対象アプリの既存接続を閉じ、必要に応じてDNSキャッシュを消去します。
3. 出口を確認：対象リクエストに、想定したノード地域が表示されることを確認します。
4. 名前解決を確認：出口アドレスだけでなく、リゾルバーが現在の設定に合っているか確認します。
5. ログを確認：ドメインが想定したルールに一致し、前方のルールに先取りされていないことを確認します。

各プラットフォームのクライアントの違い：同じサブスクリプションでも画面が異なる理由

サブスクリプションの内容が同じでも、Windows、macOS、Linux、Android、iOSでは権限モデル、バックグラウンド制限、ネットワークインターフェースが異なります。あるクライアントが特定のプロトコルをインポートできても、そのプロトコルのすべての伝送方式に対応しているとは限りません。同じ名称の機能でも、異なるコアで実装されている場合があります。

Windowsのクライアントでは、システムプロキシとTUNを同時に提供することがよくあります。TUNを有効にした場合は、仮想ネットワークアダプター、システムファイアウォール、他のネットワークソフトを主な確認箇所にします。macOSでもシステムプロキシやネットワーク拡張を利用できますが、システム権限の許可、スリープからの復帰、ネットワーク切り替えが接続状態に影響することがあります。Linuxはクライアントの形態がより多様で、GUIだけでなく、設定ファイルやサービスプロセスとして動くコアもあります。デスクトップのプロキシ環境変数、システムルート、コンテナネットワークは個別に確認が必要です。

Androidのクライアントは通常、システムVPNインターフェースを利用して通信を引き受け、アプリ単位の分岐に対応することもあります。省電力設定やバックグラウンド管理は長時間の接続に影響し、Wi-Fiとモバイルデータの切り替えで再接続が発生する場合もあります。iOSのクライアントはシステムのネットワーク拡張機構で管理されます。プロトコル、ルールセット、スクリプト機能の対応範囲はアプリごとに異なるため、インポート前に形式の互換性を確認してください。

プラットフォーム間で移行する場合は、あるプラットフォームから書き出した完全な設定をそのままコピーするより、移行先クライアントに合うサブスクリプションを改めてインポートするほうが確実です。完全な設定には、特定コア向けのルール構文、スクリプト、ポリシーグループ、DNS項目などが含まれることがあり、別のクライアントがファイルを受け付けても、認識できない部分を無視する可能性があります。

初心者向けトラブルシューティング：サブスクリプションから通信まで順に確認

クライアントの表示に異常があっても、プロトコル、ノード、DNS、ルール分岐を同時に変更しないでください。一度に複数の変数を変えると、問題が一時的に解消しても本当の原因が分からなくなります。設定の配信、接続の確立、通信の引き受け、ルールの照合、ドメイン解決の順に、階層ごとに確認するほうが効果的です。

• ✅ サブスクリプションを更新できる：リンクが有効で、クライアントが対応形式を解析できる。
• ✅ ノードに接続できる：認証、プロトコル、伝送、TLSパラメータが一致している。
• ✅ 通信が引き受けられている：システムプロキシまたはTUNが有効で、対象アプリがクライアントに入っている。
• ✅ ルールが一致している：対象ドメインが想定したポリシーに入り、前方のルールに上書きされていない。
• ✅ 出口が想定どおり：新しい接続が選択した地域から送信されている。
• ✅ DNS経路が正しい：リゾルバーが現在のモードと一致し、アプリ単独で回避されていない。
• ❌ 接続ボタンの色だけで、すべての設定が正常だと判断しないでください。
• ❌ 1つのサイトのキャッシュ、アカウント地域、サービス制限を、すぐにノード障害と決めつけないでください。

サブスクリプションを更新できないのに、以前インポートしたノードには接続できる場合、問題は設定取得層にある可能性が高いです。すべてのノードでハンドシェイクが成功するのにアプリの通信がない場合は、引き受け層を確認します。特定のドメインだけ経路を誤る場合は、ルールとDNSを確認してください。あるプラットフォームだけ異常で他は正常なら、クライアントコア、権限、対応する設定項目を優先的に比較します。