このVPN用語集では、実際の操作に沿って基本を解説します。サブスクリプションは設定をクライアントに渡し、ノードは接続先を決め、プロトコルは通信方法を定め、ルーティングはリクエストの経路を決めます。それぞれの役割を知れば、「設定を読み込めた」ことと「サービスにアクセスできた」ことを区別でき、接続トラブル時に関係のない設定を何度も変えるのも避けられます。
クライアント・サブスクリプション・ノードの関係
クライアントは、端末上で接続やノード選択、ルーティングを行うソフトウェアです。サブスクリプションは通常、サービスから設定を取得するための入口です。クライアントが読み込むと、利用可能なノードと関連パラメーターが取得されます。ノードは具体的な接続情報のまとまりで、サーバーアドレス、ポート、認証情報、プロトコル、トランスポート設定などが含まれる場合があります。必ずしも独立した物理サーバー1台を指すわけではありません。
「VPN」は日常的にネットワーク高速化ツール全般を指す言葉として使われることがありますが、アプリ層のプロキシとシステムレベルのVPNトンネルは同じものではありません。一部のプロキシクライアントはシステムのVPNインターフェースを利用して通信を取り込みますが、これは接続先との通信プロトコルが従来型のVPNプロトコルであることを意味しません。どの通信が対象になるかは、アプリ名だけでなく、クライアントが実際にどの方式で通信を取り込むかを確認してください。
| 用語 | 実際の役割 | そこからは判断できないこと |
|---|---|---|
| クライアント | 設定を読み込み、接続とルールを適用する | インストールしただけでは、利用可能な接続が確立したとは限らない |
| サブスクリプションリンク | 設定情報を取得・更新する | 更新できても、すべてのノードにアクセスできるとは限らない |
| ノード | 具体的な接続パラメーターを提供する | 地域名だけでは、接続入口と出口の両方がその地域にあるとは限らない |
| プロトコル | クライアントとサーバーの通信方式を定める | プロトコル名だけでは回線品質はわからない |
| ルーティングルール | リクエストごとにプロキシ、直接接続、拒否を選ぶ | ルールがあっても、すべてのアプリの通信が取り込まれているとは限らない |
サブスクリプションリンクをクライアントに読み込む
サブスクリプションリンクは、一般的な案内ページではありません。多くの場合、アカウントの利用権限を識別する認証情報が含まれており、アクセスするとノード一覧やクライアント設定が返されます。リンクをブラウザーで開けても、利用中のクライアントが返された形式に対応しているとは限りません。設定全体を読み込むクライアントもあれば、ノード共有情報だけを受け付けるクライアントもあり、両者はそのまま置き換えられません。
「サブスクリプションを更新」は設定を再取得する操作であり、プランの更新や通信量のリセットではありません。ノード変更後も古い設定に無効なアドレスが残る場合があります。一方、更新リクエスト自体が失敗する場合は、すべての回線が使えないと決めつけず、まず設定取得時のネットワーク経路、リンクの状態、形式の互換性を確認してください。
- サービスの管理画面から利用するクライアントに対応したサブスクリプションのリンクを取得し、対象プラットフォームの読み込み手順を確認します。
- クライアントのサブスクリプションまたは設定管理画面から読み込み、設定名とノード一覧が表示されたことを確認します。
- 設定を選択して接続を有効にし、必要に応じてシステムプロキシまたはトンネルによる通信の取り込みを設定します。
- 目的のサービスにアクセスし、ルールの適用状況と出口情報を確認します。「読み込み成功」と表示されただけでは完了ではありません。
ノードの接続入口と出口の地域
入口は端末が最初に接続するサービスの接続ポイント、出口は接続先のWebサイトに表示されるグローバルIPアドレスです。入口と出口は異なる地域にある場合があります。ノード名の地域表示は通常、出口の位置を示す目安ですが、名称はあくまでラベルです。サービスの案内と出口情報の確認をあわせて判断してください。
同じ出口地域でも、入口や通信経路が異なる場合があります。ノードを選ぶ際は、名称に含まれる地域の近さだけで判断しないでください。また、クライアントの接続テスト結果が、目的のWebサイトでの利用体験をそのまま示すわけではありません。テストの対象はノードまでの経路の一部に限られることがあり、Webページの表示にはドメイン名の解決、接続先からの応答、接続の再利用、アプリ側の処理なども関係します。
出口IPアドレスの地域判定は、Webサイトが利用するIPアドレスデータベースにも左右されます。確認ページの表示地域と特定のプラットフォームの判定が異なることも珍しくありません。動画配信サービスやAIサービスは、アカウントの地域、支払い情報、独自のポリシーなどを組み合わせて利用を制限する場合があります。そのため、出口を変更しても利用資格が得られるとは限りません。IPアドレスを確認して基本的な出口情報を調べられますが、最終的には対象サービスに表示される案内を確認してください。
専用回線・中継・直接接続の違い
これらの用語はネットワーク経路を表すもので、クライアントのプロトコルを指すものではありません。直接接続は一般に、端末から公共インターネットを通じて海外の接続入口につなぐ方式です。中継では、まず接続ポイントにつなぎ、そこから次の回線へ転送します。ここでいう「直接接続回線」とルール設定の「直接接続」は意味が異なります。前者はプロキシサービスを利用している場合もありますが、後者は通常、選択中のプロキシノードを経由しないリクエストを指します。
IEPLは通常、国際イーサネット専用線を指し、通信事業者が提供する地域間の専用伝送回線を意味します。アクセス経路の一部に使われることがあり、端末から入口まで、また出口から接続先までの全経路を自動的にカバーするものではありません。専用線区間に問題がなくても、ローカルネットワークや接続先サービスが原因で遅くなることがあります。
専用回線だからといってプライバシー方針が保証されるわけではなく、中継が低品質とも限らず、直接接続が必ず高速とも限りません。入口の場所、専用回線が使われる区間、現在のネットワークとの相性を確認したうえで、普段利用する時間帯に目的の操作を試してください。この記事は業界用語の解説であり、VPNVDがここで説明したすべての回線やプロトコルを提供していることを示すものではありません。具体的な設定は管理画面とサーバー情報ページをご確認ください。
よく使われるプロトコルと互換性
プロトコルは、通信する双方がデータをどのようにカプセル化し、送信し、検証するかを定めます。トランスポート方式、暗号化設定、TLS設定、認証パラメーターなどは、組み合わせて使う必要があることがよくあります。ノードのプロトコル名だけでは、手作業で動作する設定を組み立てるには不十分です。クライアントに必要なコア機能がなければ、ノード名を変更しても互換性の問題は解決しません。
- Shadowsocks:暗号化プロキシプロトコルです。実際の安全性と互換性は、利用するバージョン、暗号化方式、実装によって異なるため、略称だけで判断できません。
- VMess:V2Rayエコシステムでよく使われ、独自の認証機能とデータ保護機能を備えています。接続できない場合は、設定値だけでなく、端末の時刻が正確かどうかも確認してください。
- Trojan:通常、TLSを利用して通信を保護します。証明書の検証とサーバー名の設定が重要です。トラブルシューティングのために、証明書の検証を安易に無効化しないでください。
- VLESS:軽量なプロキシプロトコルです。プロトコル自体は通信全体を保護する暗号化機能を備えていないため、設定に含まれるTLSやREALITYなどのセキュリティ層とあわせて理解する必要があります。
- Hysteria2:QUICをベースとしており、下位層ではUDPを利用します。ネットワークによるUDPの制限、輻輳制御、設定の組み合わせが接続状況に影響します。
- TUIC:同じくQUICを利用します。対応状況はクライアントの実装によって異なり、Hysteria2の設定値をそのまま共用できるわけではありません。
TCPとUDPはトランスポート層の方式であり、「安全」「安全でない」を意味する言葉ではありません。UDPベースの方式でも暗号化による保護を提供できます。また、UDPが許可されているネットワークでも、すべてのアプリに適しているとは限りません。接続できないときは、まず現在のネットワークが必要なトランスポート方式を許可しているかを確認し、次にクライアントのバージョンと設定全体を確認してください。
ルーティング・ルールモード・グローバルモード
ルーティングでは、条件に応じてリクエストの処理経路を選びます。条件にはドメイン名、宛先アドレス、アプリのプロセス、地理情報データベースなどがあり、処理方法にはプロキシ、直接接続、拒否などがあります。ルールは通常、クライアントで定められた順に照合されますが、ドメイン名の解決、ルールセットの展開、コアの実装によって動作が変わるため、異なるクライアントのルールを同じものとして扱うことはできません。
ルールモードでは、一致したリクエストごとに異なる経路を使えます。ローカルサービスやLANへのアクセスと、国際回線を使う通信を分けたい場合に適しています。グローバルモードでは通常、クライアントが取り込んだリクエストを選択中のプロキシグループにまとめて渡します。ルールの設定漏れがあるか一時的に確認するのに便利ですが、端末上のすべての通信が必ずプロキシを経由するという意味ではありません。
特に「プロキシグループ」と「ノード」は区別が必要です。プロキシグループは選択用のまとまりで、ノードを手動で指定する場合もあれば、設定に応じて自動選択する場合もあります。グローバルモードの接続先が自動切り替え中のグループなら、出口も変わる可能性があります。接続を維持する必要がある作業では、グループの選択方針を確認してから、ノードを固定するか判断してください。
同じノードでルールモードは失敗し、グローバルモードでは成功する場合、ルールの適用状況やドメイン名の解決を確認してください。どちらのモードでも失敗する場合は、通信の取り込み範囲、ノードへの接続、接続先サービスの制限を引き続き確認します。この比較は原因を絞り込むためのもので、障害の種類をすぐに特定できるわけではありません。
システムプロキシ・TUNとプラットフォームごとの違い
システムプロキシは、この設定に対応したアプリにプロキシの接続先を知らせる仕組みです。設定を無視するアプリもあります。TUNは仮想ネットワークインターフェースで通信を受け取り、クライアント経由で転送します。TUNはより多くのアプリを対象にできることが多いものの、ルーティング、除外リスト、権限、クライアントの実装にも左右されます。「有効にすればすべての問題が自動で解決する」という意味ではありません。
WindowsとmacOSのクライアントには、システムプロキシとTUNの設定がそれぞれ用意されている場合があります。ブラウザー拡張機能のプロキシは通常、そのブラウザーだけに適用され、デスクトップアプリも接続されるわけではありません。Linuxでは、デスクトップ環境のプロキシ設定、アプリの環境変数、システムルートなども関係します。ターミナルのプログラムがプロキシを経由するかは、個別に確認してください。
AndroidとiOSのクライアントは、システムのVPNインターフェースを使って通信を取り込むことがよくあります。ただし、アプリごとのルーティング、バックグラウンドでの接続維持、対応プロトコルは、システムの権限やクライアントの機能によって異なります。デスクトップで設定を読み込めたからといって、モバイル端末でも同じ形式が使えるとは限りません。クライアントは管理画面のダウンロードページから入手し、各プラットフォームの案内に沿って設定してください。
DNSリークとプライバシーの範囲
DNSはドメイン名をIPアドレスに変換します。DNSリークとは一般に、本来は想定した保護経路を通るはずの名前解決リクエストが、別の経路に送られることを指します。出口IPアドレスが変わっただけでは、DNSも同じ経路を通ったとは判断できません。ブラウザーの暗号化DNS、システムのリゾルバー、クライアントのDNS設定がそれぞれ動作する場合があります。
暗号化DNSは、DNSサービスとの通信を保護しますが、名前解決リクエストが選択中のノードを経由することまで自動的に保証するものではありません。検査ページに複数のDNSサービスが表示されても、数だけでリークと判断できません。ブラウザー独自の名前解決が有効か、DNSサービスがどこに属するか、想定した経路は何かをあわせて確認してください。
HTTPSはアプリと接続先サイトの間の通信を保護し、プロキシやトンネルは別の接続経路を担います。互いに置き換えられるものではありません。証明書エラーが発生した場合は、機密情報の送信を中止し、端末の時刻、ネットワークの認証ページ、証明書チェーンを確認してください。警告を無視して接続を「修復」しようとしないでください。
接続トラブル時の確認リスト
トラブルシューティングは層ごとに進め、一度に変更する条件は一つにして、変更前後の状況を記録しましょう。プロトコル、ノード、DNSを同時に変更すると、アクセスできるようになっても本当の原因がわからず、次回も最初から試すことになります。
- ✅ まずプロキシを有効にせずに基本のネットワークが使えることを確認し、ローカルの回線切断や公共ネットワークへの接続未完了を除外します。
- ✅ サブスクリプションを更新できること、設定が選択されていること、プランが有効であることを確認します。設定の取得とノードへの接続は分けて確認してください。
- ✅ アプリの通信がシステムプロキシまたはTUNに取り込まれているかを確認し、プロキシグループが想定したノードを実際に選択しているかを確認します。
- ✅ ノードは変更せず、ルールモードとグローバルモードを比較してから、対象のリクエストにどのルールが適用されたかを確認します。
- ✅ 出口とDNSの経路を確認します。問い合わせの際はエラー表示と発生状況を記録し、認証情報やサブスクリプションリンク全体は隠してください。
- ❌ 証明書検証の無効化、見知らぬ設定の読み込み、多数の項目の繰り返し変更を、通常の修復方法として行わないでください。
操作の流れは、サブスクリプションが設定を提供し、クライアントが設定を適用し、ノードがサービスに接続し、プロトコルが通信を担い、ルールが経路を決める、という順です。それぞれの役割を理解してから画面のスイッチやメッセージを確認すれば、「どこで失敗したのか」を具体的に説明できます。設定方法の詳細は初心者向けガイドをご覧ください。サポートが必要な場合は、お問い合わせから、確認済みの内容をお知らせください。