VPN初心者がまず押さえたい用語と役割を解説します。サブスクリプションは設定の取得、ノードは接続先、プロトコルは通信方式、ルール分けはリクエストの経路を決めます。設定を読み込めてもWebページが開かない場合は、ノードを何度も変えるのではなく、各段階を順に確認しましょう。
日常会話で「VPNクライアント」と呼ばれるアプリが、実際にはプロキシプロトコルを使っている場合があります。従来型の端末全体を対象とする仮想プライベートネットワークとは異なることもあります。アプリにVPNの表示があっても、仮想ネットワークインターフェースで通信を処理しているだけの場合があります。接続状態のアイコンだけで判断せず、設定とリクエストの経路を確認してください。
用語の整理：設定から通信の出口まで
| 用語 | 意味 | 混同しやすい点 |
|---|---|---|
| サブスクリプションURL | ノードや設定一式を取得・更新するためのURL | 支払い周期とは別のもの。ルール分けの設定が含まれるとは限らない |
| ノード | クライアントで選択できる接続パラメーターの一式 | ノード名が実際の出口の場所を示すとは限らない |
| プロトコル | クライアントとサーバーが通信し、データを転送する方式 | プロトコル名は通信速度や安定性のランクではない |
| 回線 | 入口、中継ネットワーク、出口で構成される通信経路 | 同じ地域・同じプロトコルでも経路が異なる場合がある |
| ルール分け | ドメインやアドレスなどの条件に応じて、直接接続・プロキシ・拒否を選ぶ設定 | ルールモードでも、海外サイトがすべて自動的にプロキシ経由になるわけではない |
| DNS | ドメイン名をネットワークアドレスに変換する仕組み | Webページの通信がプロキシ経由でも、DNSクエリまでプロキシ経由とは限らない |
| TUNモード | 仮想ネットワークインターフェースを使って通信を取り込み、処理する方式 | 対象範囲はルーティング、除外設定、クライアントの実装によって異なる |
一連の経路として考えるとわかりやすくなります。クライアントがサブスクリプションを読み込み、ノードとルールを取得します。アプリがリクエストを送ると、ルールが接続方法を選択します。プロキシが必要なリクエストは、ノードに設定されたプロトコルと回線を通って出口へ届きます。DNSは接続先アドレスの特定に関わるため、別途設定が必要な場合があります。
サブスクリプションとノード：設定の取得元と通信の出口は別
サブスクリプションを更新すると何が変わる？
「プランのサブスクリプション」はサービスの課金方式、「クライアントのサブスクリプション」は設定の取得方法を指し、別の概念です。クライアントはサブスクリプションURLからデータをダウンロードします。取得できるのはノード一覧の場合もあれば、プロキシグループ、DNS、ルールを含む設定一式の場合もあります。形式はサービスの提供内容によって異なります。
URLをコピーしたら、クライアントのサブスクリプションまたは設定のインポート画面に追加し、更新して該当する設定を有効にします。ブラウザーにURLを貼り付けても、自動でインポートされるとは限りません。また、更新しただけでは有効化されません。複数の設定を保存できるクライアントでは、古い設定が引き続き動作している場合があります。
ノードには通常、サーバーアドレス、ポート、認証情報、プロトコル、通信パラメーターが含まれます。いずれかを手動で変更すると、設定が一致しなくなることがあります。ノード名に含まれる地域、倍率、回線の表記は提供元が付けたラベルであり、プロトコルによって検証された事実ではありません。地域ごとの機能を確認するには、回線の説明と接続後の出口情報を併せて確認してください。
プロトコルの違い：まず互換性、次にネットワーク環境を確認
Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICは、それぞれ異なるプロキシプロトコルまたは方式で、自由に置き換えられる名称ではありません。クライアントが該当プロトコルと設定形式に対応し、サーバー側にも一致するパラメーターが必要です。ノードのプロトコル欄を別の名称に変えるだけでは接続できません。
- Shadowsocks：所定の暗号化方式と認証情報を使ってプロキシ通信を行います。クライアントがサーバー側の暗号化方式に対応している必要があります。
- VMess：独自の認証・通信方式を備えています。実装によっては端末の時刻が影響するため、トラブル時にはシステム時刻が正確か確認してください。
- Trojan：通常はTLSと組み合わせて使います。証明書の検証やサーバー名などを正しく設定してください。検証を無効にする方法を通常の解決策にしないでください。
- VLESS：プロトコル自体はデータを暗号化しません。安全性は組み合わせるセキュリティ層と設定全体によって決まるため、プロトコル名だけでは判断できません。
- Hysteria2とTUIC：QUICをベースとし、UDP通信を利用します。現在のネットワークでUDPが制限されていると、ハンドシェイクに失敗したり、接続が不安定になったりすることがあります。
プロトコル、トランスポート層、回線は分けて考えましょう。WebSocketは通信方式、TLSはセキュリティ層の機能、IEPLはネットワークの伝送経路を示すもので、同じ階層の選択肢ではありません。クライアントがあるプロトコルに対応していても、すべての通信方式との組み合わせに対応するとは限りません。インポートエラーが起きたら、まずコアのバージョンと形式の要件を確認してください。
選び方：初心者は、サービスが明示的に提供し、クライアントも対応している設定を使うのがおすすめです。プロトコルの新旧だけで速度の違いは判断できません。実際の使用感は、ローカルネットワーク、回線の混雑、サーバーのリソース、接続先サイトにも左右されます。
回線の種類：直接接続・中継・IEPL
直接接続とは通常、端末が海外のプロキシサーバーに直接接続し、サービス提供元が用意した中継用の入口を経由しない方式です。通信事業者のルーティングを一切通らないという意味ではありません。通信品質は、ローカルネットワークの海外向け出口や事業者間接続の状況に影響されやすくなります。
中継方式では、まず入口に接続し、その入口から後続のノードや出口へ転送します。「中継」は転送区間が一つ増えることを示すだけで、専用線の利用や直接接続より優れた品質を保証するものではありません。入口への接続状況、入口から出口までの経路、混雑具合を考慮しましょう。
IEPLは国際イーサネット専用線で、回線の特定区間に使われることがあります。これはデータを運ぶサービスを示すもので、プロキシプロトコルではありません。また、端末から接続先サイトまでの全区間が専用線になるわけではなく、端末から入口、出口から接続先サイトまでは別のネットワークを使う場合があります。
回線を選ぶ際、地域名は主に出口の場所や、接続先サービスの提供地域との相性を判断する目安になります。最寄りの地域が最もスムーズな通信経路とは限らず、遅延が小さくてもダウンロードが常に速いとは限りません。回線一覧を見るときは、名称だけでなく、入口、出口、回線の種類、用途を合わせて比較してください。
ルール分けのモード：グローバルとルールの使い分け
ルールモードでは通常、設定された順にリクエストを照合し、直接接続、プロキシグループ、拒否のいずれかに振り分けます。ルールの条件にはドメイン、接続先アドレス、プロセスなどがあり、対応範囲はクライアントによって異なります。どのルールにも一致しないリクエストは、通常は最終ルールに送られます。最終ルールが直接接続かプロキシかは、現在の設定を確認してください。
グローバルモードでは通常、プロキシコアに渡されたリクエストを共通のポリシーで処理します。端末全体の通信がすべて取り込まれるわけではありません。システムプロキシを使わないアプリ、除外ルート、クライアントが処理できない通信は、別の経路を使う場合があります。
システムプロキシはアプリにプロキシ設定を提供する仕組みで、設定に従うかどうかはアプリによります。TUNモードは仮想ネットワークインターフェースで通信を取り込むため、より広い範囲を扱えますが、ルーティングとDNSの適切な設定が必要です。AndroidやiOSのクライアントはシステムのVPNインターフェースを利用することが多く、デスクトップではシステムプロキシとTUNが別々の設定になっていることがよくあります。
普段の利用では、信頼できるルール設定から始めましょう。特定のサイトで問題が起きたら、接続ログで適用されたルールと選択されたプロキシグループを確認してください。一時的にグローバルモードへ切り替えると、ルールの問題を特定しやすくなります。アクセスが回復した場合は、ノードに問題があると決めつけず、ルール分けを確認しましょう。
DNS 漏えいと出口の確認
DNS漏えいとは、本来想定した経路で処理されるはずのドメイン検索が、たとえばローカルネットワークのDNSリゾルバーに直接送られるなど、意図しない経路で行われる状態です。検索したドメイン名が知られる可能性はありますが、それによってHTTPSの通信内容まで解読されるわけではありません。
検査結果にローカルのDNSリゾルバーが表示されても、設定の意図に照らして判断する必要があります。直接接続するドメインにローカルDNSを使う設定は、意図的なルール分けの場合があります。一方、プロキシ経由にするはずのドメインがローカルDNSを使っている場合は、詳しく確認してください。ブラウザーの暗号化DNS、システムのDNS設定、クライアントのDNS設定がそれぞれ有効になっている場合があるため、スイッチを一つ変えただけで全体が統一されるとは限りません。
出口アドレスの確認でわかるのは、検査リクエストに使われた接続経路だけです。ブラウザーにプロキシの出口が表示されても、ほかのアプリが同じ経路を使っているとは限りません。DNSの検査でも、通常の名前解決、ブラウザー独自の名前解決、プロキシサーバーのドメインの処理を区別してください。結果に食い違いがある場合は、検査ページを何度も再読み込みするより、クライアントの接続ログを確認するほうが有効です。
初心者向けの手順：設定の読み込みからトラブル対応まで
- クライアントの互換性を確認する。使い方ガイドで対応プラットフォームと設定形式を確認し、管理画面のクライアントのダウンロードページから適切なアプリを入手します。
- サブスクリプションを読み込み、有効にする。対応する形式のURLを使い、更新が完了したこと、ノードが表示されたこと、読み込んだ設定が現在有効になっていることを確認します。
- ノードとポリシーを選ぶ。実際に使用するポリシーグループでノードを選択します。ノード一覧の選択状態だけを変えて、ポリシーグループを変更し忘れないようにしてください。
- 通信が取り込まれているか確認する。プラットフォームに必要な権限を付与し、システムプロキシまたはTUNの状態を確認してから、対象のアプリでテストします。
- 出口とDNSを確認する。出口の検査、DNSの検査、接続ログを照らし合わせて実際の経路を確認します。状態アイコンだけで判断しないでください。
- 問題の発生箇所ごとに確認する。読み込みに失敗した場合は形式とURL、接続に失敗した場合はネットワーク、認証情報、プロトコルを確認します。一部のサイトだけで問題が起きる場合は、ルール、DNS、サイト側の制限を確認してください。
- ✅ 問い合わせる際は、クライアント名、OS、エラーメッセージ、問題が起きた手順を伝えましょう。
- ✅ 設定を変更する前に元の内容を保存し、関係する項目だけを一度に一つ変更して結果を比較しましょう。
- ❌ 公開の場にサブスクリプションのトークン、ノードの認証情報一式、または情報を隠していない設定画面のスクリーンショットを載せないでください。
最後に、確認する順番を一文にまとめます。設定を取得できているか、ノードに接続できるか、リクエストがクライアントに届いているか、ルールによってどの経路に送られたか。複数のプロキシツールを同時に有効にするより、この順に確認するほうが問題を特定しやすくなります。さらにサポートが必要な場合は、管理画面のサポートチケットから、個人情報を伏せた内容を送信してください。