このVPN初心者向け用語集では、よくある利用手順に沿って解説します。まずサブスクリプションを取得し、設定をクライアントに読み込み、ノード、プロトコル、ルーティングモードを選び、最後に通信が想定どおり回線を通っているか確認します。複雑に見える用語も、実際にはこの流れの各段階を表しているだけです。役割を分けて考えれば、多くの問題を順番に切り分けられます。
先に結論を言うと、サブスクリプションはクライアントではなく、ノードはプロトコルではありません。回線名も実際のネットワーク経路そのものではありません。グローバルモードはプロキシを通す通信を決め、プロトコルはクライアントとサーバーの通信方法を定め、DNSはドメイン名をアドレスに変換します。どこかの設定が合わないと、「接続済みなのにウェブページが開かない」という状態になることがあります。
まずは早見表で基本用語を整理
| 用語 | 意味 | 意味しないもの | 問題が起きたら確認すること |
|---|---|---|---|
| サブスクリプション | サーバー側で管理されるノード設定の一覧。通常はサブスクリプションリンクでクライアントに渡し、更新します。 | 接続を確立するアプリではありません | リンクが完全か、有効期限内か、クライアントが正常に更新できたか |
| クライアント | 設定を読み込み、トンネルを確立し、ルーティングルールを実行するソフトウェア | 回線そのものではありません | 対応プロトコルとシステム権限が有効か |
| ノード | クライアントから選択して接続できるサーバー設定の入口 | 専用サーバーや固定された物理経路を必ず意味するわけではありません | アドレス、ポート、認証情報、プロトコルが一致しているか |
| プロトコル | クライアントとサーバーが取り決めるデータのカプセル化、認証、転送方式 | 速度ランクでも地域名でもありません | クライアントのコアが対応しているか、必要なパラメータがそろっているか |
| 回線 | 利用環境の入口から接続先の出口までのネットワーク経路と制御方式 | ノード名だけでは完全に確認できない属性です | 出口地域、ルートの安定性、実際のアプリ利用時の状態 |
| ルーティング | ドメイン、アドレス、アプリ、ルールセットに応じて、プロキシ、直接接続、拒否を決める仕組み | 複数のノードへ同時接続することの同義語ではありません | ルールの順序、マッチ結果、最終的なフォールバック設定 |
| DNS | ドメイン名をネットワークアドレスに変換するシステム | ウェブページの内容を転送するプロトコルではありません | どの経路から問い合わせが送られ、結果がルールどおり処理されたか |
サブスクリプション、クライアント、ノードの関係
サブスクリプションは設定一覧であり、インストールパッケージではありません
サブスクリプションリンクは通常、エンコードまたは構造化されたノード情報を返します。クライアントが読み込むことで、地域、プロトコル、ノード名が表示されます。サーバー側で入口やパラメータが更新された場合、クライアントで「サブスクリプションを更新」を実行すると、ローカル設定も同期されます。サブスクリプションリンクは認証情報として扱い、フォーラムやスクリーンショット、公開文書に掲載しないでください。
サブスクリプションの更新に失敗しても、既存のノードがすべて直ちに無効になるとは限りません。クライアントには前回正常に取得したローカルコピーが残っている場合がありますが、古い設定で接続できるかはサーバーの状態によります。逆に、更新に成功したからといって、ノードが必ず利用できるわけでもありません。確認できるのは、設定一覧をクライアントが読み込めたことだけです。
クライアントは設定を接続に変える
クライアントは、プロトコルの実装、認証、通信の取り込み、DNS処理、ルーティングルールの実行を担います。プラットフォームによって画面は大きく異なりますが、基本的な役割は共通しています。デスクトップではシステムプロキシやTUNを選べることが多く、モバイルではシステムのVPN権限を使って仮想ネットワークインターフェースを作成する場合があります。ステータスバーにVPNアイコンが表示されても、インターフェースが確立したことを示すだけで、出口地域やDNS経路まで正しいとは限りません。
ノードは接続可能な設定です
ノード設定には通常、サーバーアドレス、ポート、プロトコルの種類、認証情報、プロトコルに必要な追加パラメータが含まれます。ノードを選ぶとは、クライアントにそのパラメータでセッションを確立させることです。ノード名には地域、用途、回線ラベルなどが使われますが、名称は提供元が定めるものです。名前だけで基盤となるルートを判断することはできません。
- ✅ サブスクリプションリンクは信頼できるクライアントだけに読み込み、認証情報として管理する
- ✅ 更新後、ノード一覧が実際に同期されたか確認する
- ✅ 読み込む前に、クライアントがサブスクリプション内のプロトコルに対応しているか確認する
- ❌ 「サブスクリプションが更新された」ことを「すべてのノードに接続できる」と同一視しない
- ❌ ノード名だけからネットワーク経路全体を推測しない
直接接続、中継、IEPL専線の違い
回線とは、利用側から出口側までデータが通る経路を指します。出口が同じ地域でも、入口の位置、通信事業者間の接続、国際区間、混雑状況が異なれば、実際の体感も変わります。速度テストは測定時点の状態を示すだけで、長期的なルートや特定アプリの状況を確認する代わりにはなりません。
直接接続回線
直接接続は通常、クライアントがサービス提供元の追加中継入口を経由せず、対象サーバーの入口へ直接接続する方式です。構成は比較的シンプルですが、異なるネットワーク間の接続品質は、利用中の通信事業者、接続先ネットワーク、その時点のルートに左右されます。ここでいう「直接接続」は、インターネット上でルーターを一切経由しないという意味ではなく、サービス構成に追加の中継層がないことを指します。
中継回線
中継では、まず近い、または相互接続条件のよい入口へ接続し、そこから対象の出口へ転送します。不安定な公衆ネットワーク経路を複数区間に分けて調整できるのが特徴です。ただし、中継だから必ず速いわけではありません。入口の負荷、転送経路、出口の品質、利用側のネットワークが結果に影響します。経路を調整しやすい一方、構成は複雑になります。
IEPL専線
IEPLは通常、国際イーサネット専線系の接続を指し、比較的制御しやすい国際通信区間の構築に使われます。高速化サービスでは、利用側から入口までが国内の公衆ネットワークを経由し、その後の一部区間だけが専線に入る場合もあります。そのため「IEPLノード」は、端末から接続先までの全区間が公衆ネットワークから切り離されているという意味ではありません。具体的な接続範囲と出口構成は、サービス提供元の説明を確認してください。
| 回線タイプ | 代表的な経路 | 主な特徴 | 判断のポイント |
|---|---|---|---|
| 直接接続 | 利用側のネットワークから遠隔地の入口へ直接アクセス | 構成がシンプルで、公衆ネットワークの接続品質に左右されやすい | 利用中の通信事業者から対象地域までの継続的な状態を見る |
| 中継 | 利用側のネットワークから中継入口へ進み、そこから出口へ接続 | 経路を調整できるが、入口と転送層の両方が体感に影響する | 一度の遅延だけでなく、実際のアプリで安定性を確認する |
| IEPL | 公衆ネットワーク区間と専線区間の組み合わせ | 一部の国際経路をより制御しやすいが、範囲は構成によって異なる | 入口、出口、専線がそれぞれどの区間をカバーするか確認する |
代表的なプロトコルが解決する課題
プロトコルは、クライアントとサーバーがデータをカプセル化し、認証を行い、通信を転送する方法を定めます。クライアントがプロトコル名に対応しているだけでは不十分で、トランスポート層、TLS、サーバー名、輻輳制御のパラメータも互換性が必要です。読み込み後に「不明なプロトコル」と表示される場合、クライアントのコアが古い、または設定形式が合っていない可能性が高く、ノードの地域が原因とは限りません。
Shadowsocks
Shadowsocksは軽量な暗号化プロキシプロトコルです。基本設定には通常、サーバー、ポート、パスワード、暗号化方式が含まれます。幅広く実装され、一般的なプロキシ用途に適しています。ただし、暗号スイートやプラグインの対応は実装ごとに異なるため、古いクライアントでは新しい実装が生成した設定を読み込めない場合があります。
VMessとVLESS
VMessはV2Rayエコシステムでよく使われ、プロトコル自体に認証とデータのカプセル化機構があり、さまざまな転送方式と組み合わせられます。VLESSはよりシンプルな設計で、プロトコル自身による完全なデータ暗号化には依存せず、通常はTLSなどの安全なトランスポート層と組み合わせます。名称は似ていますが、設定項目と認証ロジックは異なり、直接置き換えることはできません。
Trojan
Trojanは通常TLS上で動作し、設定にはサーバーアドレス、認証パスワード、サーバー名、証明書検証に関するパラメータが含まれます。クライアントは証明書とサーバー名を正しく検証する必要があります。一時的な切り分けのために証明書検証を無効にすると、接続の検証機能が弱まるため、長期設定にはしないでください。
Hysteria2とTUIC
Hysteria2とTUICはいずれもQUICとUDPを重要な基盤とし、複雑な経路での転送制御や接続体験の改善を重視しています。ただし、どのネットワークでもTCPベースの方式より優れているわけではありません。現在のネットワークがUDPを制限していたり、ルーターのUDPセッション処理に問題があったりすると、接続に失敗したり性能が低下したりします。その場合は、関係のないルーティングルールを何度も変更するのではなく、互換性のあるプロトコルと回線に切り替えてください。
| プロトコル | 基本的な特徴 | 互換性チェックの要点 | よくある誤解 |
|---|---|---|---|
| Shadowsocks | 暗号化プロキシ | 暗号化方式、プラグイン、クライアント実装 | 同じ名前のクライアントなら同じ設定に対応すると考える |
| VMess | V2Rayエコシステムの認証とカプセル化 | 転送方式、認証パラメータ、コアのバージョン | VLESS設定と直接置き換える |
| VLESS | 簡素化された認証で、安全なトランスポート層と組み合わせることが多い | TLS、サーバー名、転送パラメータ | 外側の安全なトランスポート設定を無視する |
| Trojan | TLS接続とパスワード認証 | 証明書、サーバー名、時刻の状態 | 証明書検証を長期的に無効にする |
| Hysteria2 | QUICとUDPを基盤とする転送 | UDPの到達性、認証、帯域幅パラメータ | プロトコル名を固定速度と同一視する |
| TUIC | QUICとUDPを基盤とするプロキシ転送 | クライアントのバージョン、UDP、証明書設定 | 現在のネットワークによるUDP制限を無視する |
グローバル、ルール、直接接続モードの選び方
接続に成功した後も、クライアントはどのリクエストをノードへ送るか決める必要があります。これがルーティングモードです。一般的な画面ではグローバル、ルール、直接接続と表示されますが、プロキシ、ルール、直接接続など似た名称を使うクライアントもあります。ここでいう「グローバル」は通常、クライアントが取り込んだ通信を一律にプロキシへ送ることを指し、端末上のすべてのプログラムやプロトコルが対象になるとは限りません。
グローバルモード
グローバルモードは、ルールがアクセス障害を起こしているか切り分けるのに適しています。グローバルでは利用できるのにルールモードでは利用できない場合、問題はドメイン分類、アドレスのマッチング、DNS解決、ルールの順序にある可能性が高いです。常用すると、ローカルサービスや国際接続を必要としないアプリまで遠隔地の出口を経由することがあるため、用途に応じて選んでください。
ルールモード
ルールモードでは、ドメイン、ネットワークアドレス、プロセス、ルールセットを順番に照合し、プロキシ、直接接続、拒否を決めます。ルールには通常順序があり、先に一致したリクエストは後続のルールを照合しません。最後のフォールバック設定も重要です。認識されなかったリクエストを直接接続するかプロキシへ送るかは、クライアント設定によって決まり、「ルールモード」という名称だけでは判断できません。
直接接続モード
直接接続モードは通常、通信を選択したノードに通さない設定です。プロキシ効果を一時停止したり、LANリソースへアクセスしたり、障害を比較したりする用途に使えます。ただし、このモードでも仮想インターフェースが有効な場合があります。遠隔地の出口を経由しているかは、システムアイコンだけでなく、接続ログ、ルールのマッチ結果、出口情報を確認してください。
- ✅ ウェブサイトに異常があるときは、まずグローバルモードと比較してルールの問題か判断する
- ✅ 対象ドメインと関連ドメインがそれぞれどのルールに一致したか確認する
- ✅ フォールバック設定がプロキシ、直接接続、拒否のどれか確認する
- ✅ ローカル端末とLANリソースは必要に応じて直接接続にする
- ❌ 「ルールモード」ならクライアントがすべての通信を自動判別すると考えない
システムプロキシ、TUN、アプリ内プロキシの違い
システムプロキシは、OSがアプリに提供するプロキシ設定です。この設定に従うブラウザーやアプリは、対応するリクエストをクライアントへ渡しますが、システムプロキシを無視するプログラムや、ウェブ通信だけをプロキシするプログラムもあります。そのため、ブラウザーは正常なのに、特定のデスクトップアプリは直接接続のままということがあります。
TUNモードは仮想ネットワークインターフェースを通じて、より広範な通信を取り込み、クライアントがルーティングルールに従って処理します。システムプロキシを読み取らないアプリに適していますが、システム権限が必要です。また、他のネットワークツール、仮想マシン、企業向けセキュリティソフト、既存のVPNインターフェースとルートが競合することがあります。TUNを有効にした後も、ローカルネットワークの除外とDNS方針を設定し、ローカルサービスに接続できなくなるのを防いでください。
アプリ内プロキシは、そのアプリだけに適用されます。たとえばブラウザーにローカルプロキシポートを個別設定しても、他のプログラムが同じ接続を自動的に使うことはありません。範囲が明確でテストに向いていますが、複数アプリの設定を管理するのは手間がかかります。クライアントを終了した後もアプリにプロキシアドレスが残っていると、ネットワークにまったく接続できない状態になることがあります。
DNSリークと名前解決エラーとは
ドメインへアクセスする前に、端末は通常、そのドメインに対応するネットワークアドレスを問い合わせます。DNSリークとは、指定した管理下の経路で処理されるはずの問い合わせが、実際にはローカルネットワークや別のリゾルバーから直接送信される状態です。調べているドメインが露出したり、名前解決の結果とプロキシの出口地域が一致しなかったりする可能性があります。
DNSの問題は、必ずしも「まったく開けない」という形で現れるとは限りません。ドメインでは失敗するのにアドレスへ直接アクセスすると応答する、同じノードでもアプリによって結果が違う、回線を切り替えても古いキャッシュが使われる、ドメインに基づくルールなのに解決済みアドレスだけが参照される、といった症状もあります。クライアントのリモートDNS、ローカルDNS、暗号化DNS、仮想アドレスマッピングなどは異なる段階を処理するため、意味を理解せずすべて有効にするのは避けましょう。
切り分けでは、問い合わせをOS、ブラウザー、クライアントのどれが開始しているかを確認し、DNS通信がTUNやシステムプロキシに取り込まれているかを見ます。ブラウザーによっては独自のセキュアDNS設定を使い、OSの既定の名前解決経路を迂回する場合があります。DNSを変更した後は、システムとブラウザーのキャッシュも考慮してください。古い結果が残っていると、新しい設定が反映されていないように見えます。
- ✅ クライアントがDNS問い合わせを処理しているか、どのリゾルバーを使っているか確認する
- ✅ ブラウザーで独自のセキュアDNS設定が有効になっていないか確認する
- ✅ 方針を切り替えた後、関連キャッシュを削除して接続を再確立する
- ✅ ルールログでドメインと解決先アドレスのマッチ結果を確認する
- ❌ 「ノードに接続できる」ことだけでDNS経路の確認を済ませない
サブスクリプションの読み込みから有効性確認までの手順
初心者は複数の設定を何度も切り替え、どの変更が効いたのか分からなくなりがちです。設定、接続、ルーティング、DNS、アプリの順に、一度に1つの段階だけ確認する方法が確実です。
- 対応クライアントを選ぶ。まず、クライアントがサブスクリプション内のプロトコルと設定形式に対応していることを確認します。プロトコルを認識できなければ、その後の回線選択やルーティング設定に意味はありません。
- サブスクリプションを読み込み、更新する。完全なサブスクリプションリンクを貼り付け、クライアントが成功状態を返すまで待ちます。その後、ノード一覧が表示されたか確認してください。出所の不明な変換サイトにサブスクリプションリンクを入力しないでください。
- ノードを選んで接続する。まずはクライアントの既定パラメータを使い、トランスポート層、証明書、DNS、ルーティングの設定を同時に変更しないでください。接続に失敗したら、プロトコルエラーとハンドシェイクログを優先して確認します。
- グローバルモードで基本確認を行う。クライアントからサーバーへデータを転送できることを確認し、出口地域が選択したノードと一致するか確認します。この手順でルーティングルールの影響を切り分けます。
- ルールモードに戻す。よく使うウェブサイトとアプリをテストし、プロキシ、直接接続、拒否のルールが想定どおり一致するか確認します。異常があれば、ドメインと一致したルールを記録してください。
- DNS経路を確認する。名前解決のリクエストと出口方針が一致しているか確認し、ブラウザー独自のDNS、キャッシュ、仮想インターフェースの影響にも注意します。
- 最後に通信の取り込み方式を調整する。ブラウザーではまずシステムプロキシを試し、システムプロキシに従わないプログラムでTUNを検討します。変更するたびに再確認してください。
初心者が覚えておきたい注意点
遅延、帯域幅、ジッター、パケットロスは同じ指標ではありません。遅延は往復時間、帯域幅は単位時間あたりに転送できるデータ量、ジッターは遅延の変動、パケットロスは再送を引き起こしたりリアルタイム通信に直接影響したりします。ノード一覧の遅延は通常、クライアントから入口までの測定値にすぎず、動画、ダウンロード、オンライン会議の最終的な性能を完全には表しません。
同じノードでも、ネットワークや端末によって結果は変わります。家庭用回線、公衆Wi-Fi、企業ネットワーク、モバイルネットワークでは、ルートや制限が異なります。デスクトップ、Android、その他のモバイルプラットフォームでも、バックグラウンド動作、仮想インターフェース、システムプロキシの扱いは異なります。設定を流用するときは、ノード名だけでなく、プラットフォームの権限とクライアントの実装も確認してください。
最後に、接続ツールが変えるのは一部の通信の経路であり、ウェブサイトの信頼性を自動的に判断したり、アカウントの安全対策、ソフトウェア更新、証明書検証を代替したりするものではありません。クライアントに証明書エラーやシステム時刻の異常、出所不明の設定が表示されたら、検証を無効にして接続を続けるのではなく、まず基本的な問題を解決してください。