このVPN初心者向け用語集では、実際の利用手順に沿って説明します。まずサブスクリプションURLを取得し、クライアントにインポートしてノードを選び、プロトコルを確認します。そのうえで、分岐、グローバル、ルールのどのモードを使うかを決めます。接続できない原因は回線そのものではなく、「サブスクリプション」「ノード」「プロトコル」「動作モード」を同じものと捉え、誤った箇所を変更していることも少なくありません。
複雑なネットワーク理論を先に学ぶ必要はありません。「設定はどこから来るのか」「通信はどこを通るのか」「クライアントは通信をどう処理するのか」「どのリクエストを回線経由にするのか」を分けて考えれば、多くの設定項目を理解できます。プラットフォームによってボタン名は異なりますが、背後にある役割は基本的に共通しています。
サブスクリプションから接続までの全体像を理解する
通常の接続には、互いに独立した複数の設定層があります。サブスクリプションはクライアントにノード情報を提供し、ノードは選択可能な接続先を示します。プロトコルはクライアントとサーバーの通信方法を定め、回線タイプは接続先から先にどのようなネットワーク経路を通るかを示します。ルーティングルールは、各リクエストをノード経由にするかどうかを決めます。
| 用語 | 解決する課題 | よくある誤解 | トラブル時にまず確認する箇所 |
|---|---|---|---|
| サブスクリプション | 利用可能な設定をクライアントに渡し、後から更新できるようにする | サブスクリプションURLを通常のウェブページとして開く | サブスクリプションのインポートと更新が完了しているか |
| ノード | 具体的な接続設定を提供する | 同じ地域のノードなら経路も必ず同じだと思う | ノード名、地域、プロトコル、接続状態 |
| プロトコル | クライアントとサーバーがデータをやり取りする方法を定める | プロトコル名だけで実際の速度を判断する | クライアントが該当プロトコルと伝送方式に対応しているか |
| 回線タイプ | 接続後に通るネットワーク経路を示す | 回線タイプとプロトコルを混同する | 直結、中継、IEPL専線の表示 |
| ルーティングルール | リクエストをノード経由にするか直接接続するか判断する | クライアントを起動すれば、すべての通信が自動的にノード経由になると思う | ルールの一致結果と現在の動作モード |
サブスクリプションURLとは？クライアントにインポートする理由
サブスクリプションURLは、サービス提供元が生成し、クライアントが読み込むための設定用URLです。ノード一覧を返す場合もあれば、グループ、ルール、DNS設定を含む完全な設定を返す場合もあります。ブラウザーで直接開いた際にテキストやダウンロード画面が表示されたり、内容を読めなかったりしても、URLが壊れているとは限りません。主な利用者はウェブブラウザーではなく、対応クライアントだからです。
インポートすると、クライアントはサブスクリプションの内容を取得し、サーバーアドレス、ポート、プロトコルパラメータ、ノード名を解析してローカル設定として保存します。その後「サブスクリプションを更新」を実行すると、サービス側が提供する最新内容を再取得します。通常は追加、変更、削除されたノードも反映されますが、手動変更を保持できるかどうかはクライアントの統合方法によって異なります。
- サービスページでサブスクリプションURLをコピーし、一部だけを切り取らないでください。
- 現在のプラットフォームに対応したクライアントを開き、サブスクリプション、設定、または設定ファイルの項目を探します。
- URLからのインポートを選び、完全なURLを該当する入力欄に貼り付けます。
- 保存後に更新を実行し、クライアントにノードまたはプロキシグループが表示されることを確認します。
- ノードを選択してから、システムプロキシやTUNなどの通信取り込み機能を有効にします。
- 実際に利用したいウェブサイトやアプリで、ルーティング結果を確認します。
サブスクリプションURLには、サブスクリプションを識別する認証情報が含まれていることがあります。パスワードと同じように安全に管理してください。URLを公開フォーラムに投稿したり、完全なURLが写ったスクリーンショットを公開したり、出所の不明なオンライン変換ツールにインポートしたりすると、設定を他人に読み取られる可能性があります。URLの流出が疑われる場合は、クライアントから古い設定を削除するだけでなく、サービスページでサブスクリプションをリセットしてください。
ノード、サーバー、回線タイプは別の概念
クライアントに表示される「ノード」は、選択可能な接続パラメータのまとまりです。通常は表示名、サーバーアドレス、接続ポート、プロトコル、認証情報が含まれます。ノード名に含まれる地域、回線、用途などのラベルは選択のための説明であり、名前自体が通信に使われるわけではありません。
「サーバー」は、実際にサービスを提供するホストや接続口を指します。一方、「ノード」はユーザーがクライアントで選択する設定単位です。同じサーバーで異なるプロトコル設定を提供することもあり、同じ地域でも経路がまったく異なる場合があります。そのため、2つのノードに同じ都市名が表示されていても、入口、出口、中間経路が同じとは限りません。
直結、中継、IEPL専線の違い
直結は、クライアントが追加の転送層を経由せず、対象サーバーの入口に直接接続する方式です。構成は分かりやすい一方、現地通信事業者の経路、ネットワーク間接続、国際出口の変動による影響を受けやすくなります。
中継回線では、まず近い、または到達しやすい入口に接続し、その後に中継ネットワークを通って出口へ向かいます。中継の役割はネットワーク経路を調整することであり、アプリケーション層のプロトコルを変更することではありません。中継入口が安定していれば、一部の好ましくない公衆ネットワーク経路を避けられますが、中継区間が混雑すると、その追加経路がボトルネックになることもあります。
IEPL専線は通常、専用の国際イーサネット接続で国境をまたぐ区間を運び、入口と出口を組み合わせて接続します。「どのプロキシプロトコルを使うか」とは別の話です。VLESSノードは異なる回線上に構築でき、Trojanノードも直結、中継、専線のいずれかで接続できます。プロトコル名だけでは回線の説明になりません。
Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICの見方
プロトコルは、クライアントとサーバーがセッションを確立し、認証してデータを転送する方法を定めます。互換性、通信上の特徴、TCPやUDPの利用方法、クライアント設定に影響しますが、最終的な速度を単独で決めるものではありません。実際の使用感は、回線経路、サーバー負荷、ローカルネットワーク、輻輳制御、アプリの通信内容にも左右されます。
| プロトコル | 主な特徴 | 設定時の注意点 | 用途を判断する目安 |
|---|---|---|---|
| Shadowsocks | 比較的シンプルな構造の暗号化プロキシプロトコルで、エコシステムが成熟している | 暗号化方式、パスワード、プラグインパラメータをサーバー側と一致させる必要がある | クライアントが幅広く対応している場合、汎用的な接続方式として使いやすい |
| VMess | V2Rayエコシステムでよく使われ、さまざまな伝送層と組み合わせられる | 認証情報、伝送方式、時刻設定が接続に影響する場合がある | 互換性のある設定がすでにあるなら使い続けられるが、名前だけで性能を判断しない |
| Trojan | TLSと組み合わせ、標準的な暗号化接続でデータを運ぶことが多い | ドメイン、証明書の検証、サーバー名を正しく一致させる必要がある | TLSパラメータを完全にサポートするクライアント設定に適している |
| VLESS | 認証層が軽く、TCP、WebSocket、gRPCなどの伝送方式と組み合わせられる | VLESSは一つの層にすぎず、TLS、REALITY、伝送パラメータも一致させる必要がある | 新しいXrayエコシステムの設定を使う場面に適している |
| Hysteria2 | QUICとUDPを基盤とし、複雑なネットワーク環境での伝送性能を重視する | ローカルネットワークでUDPが制限されていると、性能を発揮できない、または接続に失敗する場合がある | パケットロスや遅延変動が目立ち、UDPを利用できるネットワークで使いやすい |
| TUIC | 同じくQUICとUDPを基盤とし、並列データ転送に対応する | クライアントのバージョン、認証パラメータ、輻輳制御の設定に互換性が必要 | サーバー側で明確に提供され、現在のネットワークでUDPを利用できる場合に適している |
WebSocket、gRPC、TCP、QUICなどの用語はプロトコルと並べて表示されることがありますが、異なる層を指す場合があります。たとえばVLESSは複数の伝送方式上で利用でき、TLSやREALITYは接続の検証と暗号化の処理を担います。サブスクリプションをインポートした後は、通常これらのパラメータを手動で組み直す必要はありません。サーバー側に対応設定がない項目を自分で変更すると、接続に失敗します。
「新しいプロトコルほど速い」という考え方は、信頼できる法則ではありません。Hysteria2とTUICはUDPに依存するため、UDPが利用でき、ネットワークの揺れが大きい環境では適する可能性があります。一方、UDPが制限されるオフィスや公共ネットワーク、特殊な接続環境では、TCPベースの設定のほうが接続しやすいことがあります。利用可能な代替プロトコルを残し、現在のネットワークで試すのが適切です。
グローバルモード、ルールモード、直結モードの切り替え方
動作モードが決めるのは「どの通信をノードに渡すか」です。ノードが使用するプロトコルとは関係ありません。同じVLESSノードをルールモードでもグローバルモードでも利用できます。モードを切り替えてもノードの回線は変わらず、クライアントがリクエストをどう処理するかだけが変わります。
ルールモード：日常利用でよく選ばれる方式
ルールモードでは、ドメイン、IP、アプリ、ポート、ルールセットなどを基準に通信の行き先を判断します。一般的には、ローカルサービスを直接接続し、国際回線が必要なリクエストをノード経由にします。不要な迂回を減らせるほか、出口地域の変更によって一部のローカルサイトで追加確認が発生するのを避けやすくなります。
ルールは通常、上から順に照合され、最初に一致したルールが適用されます。クライアントにある「プロキシ」「直結」「拒否」は、異なる処理を表します。プロキシグループを使えば、複数のノードを一つのルールの行き先としてまとめられます。特定のサイトが想定外の経路を通る場合は、現在選択しているノードだけでなく、接続ログで一致したルールを確認してください。
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-SUFFIX,local.example,DIRECT
PROCESS-NAME,browser,PROXY
MATCH,DIRECT上記はルール構造を理解するための中立的な例です。ドメインの末尾でプロキシまたは直結を指定し、アプリのプロセスごとに方針を指定することもできます。最後のMATCHは、それまでに一致しなかったリクエストを処理します。クライアントによって項目名や構文は完全には同じでないため、一つの形式をすべてのアプリにそのまま貼り付けないでください。
グローバルモード：ルールの問題かを一時的に切り分ける方法
グローバルモードでは通常、クライアントがすでに取り込んでいる通信をすべて現在のノードへ送ります。短時間の切り分けに適しており、ルールモードではアクセスできないのにグローバルモードでアクセスできるなら、問題はルールの一致、DNSの結果、またはプロキシグループの選択にある可能性が高いです。グローバルモードでも失敗する場合は、ノード、プロトコル、ローカルネットワークを引き続き確認します。
「グローバル」が端末上のすべての通信を意味するとは限りません。システムプロキシだけを有効にしている場合、その設定に従わないアプリは直接接続することがあります。TUNが取り込んでいない通信、独自のネットワークスタック、特殊なシステムサービスもクライアントを迂回する可能性があります。グローバルとはクライアント内部の判断モードを指し、端末全体の通信範囲を絶対的に示すものではありません。
直結モード：ローカルのネットワーク経路をすぐに戻す方法
直結モードでは、すでに取り込まれているリクエストも遠隔ノードを経由しなくなります。ローカルサイトが迂回によって不安定になっているか確認したい場合や、一時的に国際回線が不要な場合に使えます。取り込み自体を完全に停止するには、システムプロキシまたはTUNも無効にしてください。方針を直結に変更しただけでは、通常クライアントのプロセスは動作し続けます。
システムプロキシ、TUN、DNSリークの役割
システムプロキシは、OSにプロキシアドレスを書き込み、その設定に従うアプリがHTTPまたはSOCKSのリクエストをクライアントへ渡せるようにします。ブラウザーや一般的なアプリの多くはシステムプロキシを読み取れますが、一部のゲーム、コマンドラインプログラム、独立したランタイム、自前で接続処理を行うアプリは無視することがあります。
TUNモードは仮想ネットワークインターフェースを作成し、IP層でより広い範囲の通信を取り込んだうえで、クライアントがルーティングと分岐を処理します。システムプロキシに対応しないアプリにも適しており、TCP、UDP、DNSをまとめて扱いやすくなります。ただし、TUNにはシステムのネットワーク権限が必要なことが多く、他のネットワークフィルターツール、企業向けセキュリティソフト、既存の仮想NICと経路が競合する場合があります。
DNSはドメイン名をIPアドレスに変換します。DNSリークとは通常、本来クライアントのルールや暗号化回線で処理されるはずのドメイン問い合わせが、ローカルの通信事業者や予期しない別の名前解決経路から送信される状態を指します。問い合わせ先が知られる可能性があるだけでなく、ノードの出口地域と合わない結果が返り、サイトの地域判定を誤ったり、適切でないアドレスへ接続したり、ページは開くのに内容を利用できなかったりすることがあります。
DNSの問題を確認する際は、クライアントのDNS設定、システムの名前解決設定、ブラウザーの暗号化DNSを同時に確認します。ブラウザーが独自にDNSサービスを指定していると、クライアントの分岐設計を迂回することがあります。クライアントがFake IPや拡張モードを使う場合は、対応するスニッフィング、マッピング、除外ルールも必要です。ノードに接続できるからといって、DNS経路まで正しいとは限らないため、すべての名前解決エラーをノードの問題だと決めつけないでください。
Windows、macOS、Android、iOSクライアントの違い
各プラットフォームのクライアントは基本的な役割こそ同じですが、権限の仕組みが異なります。Windowsクライアントはシステムプロキシ、仮想NIC、サービスモードを同時に提供することがあります。macOSではシステムネットワーク拡張やプロキシ権限が必要です。Androidは通常、システムVPNインターフェースでローカルトンネルを作成します。iOSとiPadOSは、システムが許可するネットワーク拡張機能に依存します。画面に「接続中」と表示されていても、実際の取り込み範囲は現在のモードによって決まります。
デスクトップ版では、接続ログ、ルールの一致、DNS問い合わせを確認しやすく、サブスクリプションの解析や経路の問題を調べるのに適しています。モバイル端末ではバックグラウンド処理や省電力機能の影響を受けます。アプリがバックグラウンドに移ったり、Wi-Fiとモバイル通信の間でネットワークが変わったりすると、システムがトンネルを再構築することがあります。一時的な切断がサブスクリプションの失効を意味するとは限らないため、まずクライアントでシステムトンネルの状態を確認してください。
同じサブスクリプションでも、クライアントによって表示内容が異なることがあります。これは設定が失われたとは限りません。完全な設定に対応するクライアントはプロキシグループ、ルール、DNSモジュールを表示できますが、ノードサブスクリプションだけに対応するクライアントはサーバー項目のみを抽出する場合があります。一部のプロトコルや伝送方式には新しいコアの対応が必要で、ノード名をインポートできても、実際の接続まで成功するとは限りません。
クライアントを選ぶ際は、サブスクリプション形式、プロトコル対応、システムプロキシとTUNの機能、ルール構文、ログの分かりやすさを優先して確認します。画面が似ているかどうかだけで互換性を判断しないでください。サービスページで明確に案内されているクライアントと設定方法を使うほうが、パラメータの整合性を保ちやすくなります。
接続トラブルは層ごとに確認し、すべての設定を同時に変更しない
効果的なトラブル対処には比較が欠かせません。一度に一つの条件だけを変えれば、問題がサブスクリプション、ノード、プロトコル、回線、モード、DNSのどこにあるかを判断できます。サブスクリプションの更新、プロトコルの切り替え、TUNの有効化、ルールの置き換え、システムDNSの変更を同時に行うと、接続が戻っても本当の原因が分からず、次回も最初から試すことになります。
- ✅ まずサブスクリプションを更新でき、クライアントに完全なノード名が表示されることを確認します。
- ✅ 対応が明確なノードを一つ選び、接続ログでハンドシェイクが完了したか確認します。
- ✅ 同じ地域のノードに問題がある場合は、別の回線タイプに切り替えて比較します。
- ✅ ルールモードに問題がある場合は、一時的にグローバルモードへ切り替え、誤った一致かどうかを確認します。
- ✅ ブラウザーは使えるのに他のアプリが使えない場合は、システムプロキシの取り込み範囲を確認し、TUNが必要か検討します。
- ✅ ページの地域表示が合わない、またはドメインの名前解決に問題がある場合は、クライアント、システム、ブラウザーのDNS経路を確認します。
- ❌ サブスクリプションが自動生成した認証、TLS、伝送層、サーバー名をむやみに変更しないでください。
- ❌ サブスクリプションURLを、出所の不明な変換ページや公開コンテンツに貼り付けないでください。
ログにサブスクリプションリクエストの失敗が表示されるなら、問題は設定の取得段階にあります。ノードは存在するのにハンドシェイクに失敗する場合は、プロトコルの互換性、ローカルネットワークの制限、ノードの状態を確認します。ハンドシェイクは成功するのに特定サイトだけ使えない場合は、ルール、DNS、対象サイト側の制限を確認します。層ごとに判断するほうが、接続ボタンを何度も押すより効果的です。
用語を実際の操作に結び付け、安定した利用習慣を作る
初心者は「クライアントに接続済みと表示された」だけで完了と考えがちです。より正確には、サブスクリプションがインポートされ更新できること、選択したノードが現在のネットワークと互換性を持つこと、システムプロキシまたはTUNが対象アプリを実際に取り込んでいること、ルールがリクエストを想定した方針へ送っていること、DNS問い合わせが予期しない経路へ流れていないことまで確認する必要があります。
ノード名は素早い絞り込みに便利ですが、最終的には用途で判断します。ウェブ閲覧やAI ツールでは操作の安定性が重要です。ストリーミングでは出口地域とサービス側の判定も関係します。ダウンロードでは継続的な転送と通信量の配分が重視されます。ある用途で使えたノードが、すべてのアプリに最適だとは限りません。
プロトコルを頻繁に手動で新しいものへ変更する必要もありません。サブスクリプションに動作するパラメータが用意されているなら、まずサービス側の推奨設定を使います。現在のネットワークでUDPが制限される、TLS検証に失敗する、クライアントのコアが対応しないなど、明確な症状がある場合にだけプロトコルや伝送方式を切り替えてください。パラメータが多いほど、根拠のない変更は控えるべきです。
ルールモードは長期利用に向いていますが、ルールは更新が必要です。ウェブサイトのドメイン、コンテンツ配信先、アプリのAPIは変化するため、古いルールでは新しいドメインを取りこぼすことがあります。「トップページは開くのに、ログインや画像の読み込みに失敗する」場合は、端末全体を長時間グローバルモードにするのではなく、失敗したリクエストのドメインが誤った方針に分類されていないか確認してください。