VPNの用語は、まずクライアントの画面から理解しましょう。サブスクリプションは設定情報を取得するためのもの、ノードは接続先として選べる設定、ルーティングはどのリクエストをプロキシ経由にするかを決める仕組みです。ルールモードでは、そのルールに沿って通信を振り分けます。それぞれ役割が異なり、互いに置き換えられるものではありません。接続後もサイトが開かない場合、ノードの不具合とは限りません。リクエストがクライアントに届いているか、どのルールに一致したか、ドメインがどう名前解決されたかも確認しましょう。

用語早見表:設定・経路・通信の処理

VPNという言葉は、システム全体を保護する暗号化トンネルを指す場合も、プロキシプロトコルを使うサブスクリプションサービスを指す場合もあります。プロキシクライアントでシステムプロキシを有効にする方法と、仮想ネットワークインターフェースを使う方法では、通信を取り込む仕組みが異なります。まず下の表で用語を確認してからクライアントの設定を見れば、「接続済み」を「すべてのアプリの通信が処理されている」と誤解しにくくなります。

用語 実際の意味 よくある誤解
サブスクリプションURL クライアントがノードや設定を取得するためのアドレス。通常、アクセス認証情報が含まれます。 一般的なウェブページではなく、料金プランそのものでもありません。
ノード クライアントで選択できるプロキシ接続設定。サーバーアドレス、プロトコル、認証情報などが含まれます。 名前に含まれる地域が、接続先サーバーの所在地とは限りません。
接続経路 利用者のネットワークから入口を経由し、転送経路を通って出口に至る通信経路です。 プロトコルとは別のもので、名称だけで品質を判断することもできません。
プロトコル クライアントとサーバー間でデータを転送・認証・暗号化するための取り決めです。 新しいプロトコルだからといって、どのネットワークでも速いとは限りません。
プロキシグループ ルールの振り分け先となるノードや処理方法の候補グループ。手動選択または設定に基づく自動選択ができます。 現在選択中のノードが、すべてのプロキシグループで使われるとは限りません。
ルーティング ドメイン、アドレス、アプリなどの条件に応じて、直接接続・プロキシ経由・拒否を選びます。 同じリクエストをすべてのノードに均等に分配する仕組みではありません。
DNS ドメイン名をネットワーク上のアドレスに変換する仕組みです。 ウェブのリクエストがプロキシ経由でも、DNSクエリが同じ経路を通るとは限りません。
TUN 仮想ネットワークインターフェースで通信を受け取り、クライアントに処理させます。 ルーティングの除外設定が残る場合もあり、設定不要で全通信を取り込める保証ではありません。

サブスクリプションURL:設定の取り込みであり、支払いではない

「サブスクリプション」は、料金と設定の二つの文脈で使われます。プランページの月額サブスクリプションは、課金周期や通信量のルールを表します。一方、クライアントのサブスクリプションは、通常、設定情報の取得元を指します。URLを読み込むとクライアントがサーバー設定を取得しますが、それだけでプランの有効性や通信量の残りを判断することはできず、プラン変更が自動で完了するわけでもありません。

サブスクリプションの内容は、ノード一覧だけの場合もあれば、プロキシグループ、ルーティングルール、DNS設定を含む場合もあります。形式やクライアントの対応状況はサービスによって異なります。サブスクリプションを更新すると通常はノードの変更が反映されますが、手動で変更した内容が保持されるか、ルールが上書きされるかは、クライアントの更新仕様を確認してください。初心者はまずサービスが提供する対応形式を使い、異なるクライアントの設定ファイルをそのまま混在させないようにしましょう。

  1. 信頼できる配布元からクライアントを入手し、対応するサブスクリプション形式とプロトコルを確認してください。クライアントの入手先はユーザーパネルのダウンロードページにあります。ダウンロードにはログインが必要で、実際のリンクはプランの状態に応じてパネルに表示されます。
  2. ユーザーパネルでサブスクリプションURLをコピーし、クライアントのサブスクリプションまたは設定管理画面から読み込みます。読み込みに失敗した場合は、コピー時に余分な空白が入っていないか、URLがすべてコピーされているか、形式に互換性があるかを確認しましょう。
  3. 更新を実行し、ノード一覧が表示されることを確認します。次に設定を選択し、プロキシグループ内のノードを選んで、必要な通信の取り込み方法を有効にします。
  4. 実際に使うウェブサイトやアプリを開き、クライアントの接続ログで通信経路を確認します。ノードのテストアイコンだけを見て判断しないでください。

ノードと接続経路:出口の地域と通信経路は別

ノード名に日本やシンガポールと表示されていても、通常は出口の地域を示しています。実際のリクエストは、まず入口サーバーに届き、中継経路を経て出口に到達することもあります。接続先のウェブサイトに表示されるアドレスは主に出口で決まります。一方、利用者側の接続品質は、アクセス回線、入口への接続性、転送経路、サーバー負荷の影響を受けます。

直接接続・中継・IEPLの違い

直接接続は通常、クライアントから海外のプロキシサーバーへ直接接続する方式です。経路は比較的わかりやすい一方、日本国内の国際回線やネットワーク上の制限の影響を受けます。中継では経路上に転送ポイントを設け、入口を介して一部区間の接続性を改善します。専用線を使うとは限らず、混雑する時間帯の性能が保証されるわけでもありません。IEPLはイーサネット専用線サービスです。サブスクリプションサービスが通信に利用している場合、経路の特定区間が専用線で運ばれることを示しますが、利用者の端末から接続先までの全区間が専用線という意味ではありません。

接続方式はノード選びの参考になりますが、実際の使い勝手に代わるものではありません。クライアントに表示される「遅延」は測定方法にも左右されます。プロキシのハンドシェイク、テスト用ウェブサイトへのアクセス、ネットワークの往復時間測定では、それぞれ意味が異なります。遅延が低くても、スループット不足やパケットロスで動画が止まることがあります。まず自分が使う会議、文書、メディアアプリで動作を確認し、リクエストログで出口とエラー情報を確認しましょう。

接続先選びのポイント:まず利用したいサービスの条件に合う地域を選び、そのうえで実際のアプリを継続して使ったときの状態を比較しましょう。国名を通信経路の説明と混同せず、IEPLの表示をあらゆる時間帯の速度保証と受け取らないでください。

プロトコル名:速度より互換性を優先

Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICは、よく使われるプロキシプロトコルまたは方式です。提供地域、プランのランク、回線の等級を示すものではありません。以下は技術的な概要であり、VPNLMがすべてのプロトコルを提供するという意味ではありません。利用できるものはパネルの設定とクライアントの説明を確認してください。

  • Shadowsocks:暗号化プロキシプロトコルです。クライアントとサーバーで暗号方式と認証情報を一致させる必要があります。機能やバージョンの対応状況は実装によって異なる場合があります。
  • VMess:認証と暗号化の仕組みを備えたプロキシプロトコルで、さまざまな通信方式と組み合わせて利用できます。ノードに接続できるかどうかは、プロトコルと通信方式のパラメーターが一致しているかによります。
  • Trojan:通常、TLSを使ってプロキシ通信を行います。証明書の検証、サーバー名、認証情報を正しく設定してください。接続を成功させるために、証明書の検証を安易に無効化してはいけません。
  • VLESS:軽量な認証プロキシプロトコルです。プロトコル自体はデータを暗号化しないため、TLSやREALITYなどのセキュリティ層が必要です。VLESSという名称だけでは、設定全体のセキュリティを判断できません。
  • Hysteria2とTUIC:QUICをベースにしたプロキシ方式で、通常はUDPで通信できる必要があります。ネットワークによってUDPが制限されている場合、接続できないことがあります。また、ほかのプロトコルに対応しているクライアントでも、これらを利用できるとは限りません。

プロトコルを選ぶ際は、「クライアントが対応しているか」「ネットワークで利用できるか」「サーバー設定と一致しているか」を確認しましょう。経路や混雑状況が変わらなければ、プロトコルを替えるだけでは使い勝手が改善しないこともあります。エラーが出たら内容を記録し、認証失敗、証明書の問題、名前解決の失敗、接続タイムアウトを切り分けましょう。あらゆる設定を次々に切り替えるのは避けてください。

ルーティングとルールモード:条件に応じた通信の振り分け

ルールモードでは、クライアントが取り込んだリクエストをルールと照合します。ルールの条件には、ドメイン、ドメインのサフィックス、接続先アドレス、アプリのプロセスなどがあります。利用できる条件はクライアントによって異なります。照合結果は、直接接続、特定のプロキシグループ、拒否などです。多くのクライアントはルールを上から順に確認し、最初に一致した時点で処理を決定します。最後のフォールバックルールは、それまでのルールに一致しなかったリクエストを処理します。

たとえば、コラボレーションツールのドメインを業務用プロキシグループに割り当て、LAN内のデバイスは直接接続、それ以外のリクエストはフォールバックルールに割り当てられます。業務用グループで日本のノードを選んでも、メディア用グループまで日本に切り替わるわけではありません。「ノードを変えたのに出口が変わらない」場合は、サブスクリプションを再読み込みする前に、そのリクエストがどのグループに一致したかを確認しましょう。

グローバルモードでは通常、クライアントが取り込んだリクエストを指定したプロキシ経由で処理します。直接接続モードでは通常、これらのリクエストはプロキシサーバーを経由しません。ただし、モード名やLANの除外設定、特殊なリクエストの処理方法はクライアントによって異なります。グローバルモードはルールに問題があるかを一時的に切り分けるのに役立ちますが、もともとクライアントを経由しないアプリの通信を自動的にプロキシへ取り込むものではありません。

  • ✅ ルールモードを普段使いする前に、対象ドメインが想定したプロキシグループに一致し、グループ内で適切なノードが選ばれていることを確認しましょう。
  • ✅ グローバルモードに切り替えると問題が解消する場合は、ルーティングルール、ルールの順序、フォールバック設定を優先して確認しましょう。
  • ❌ 「グローバル」を、デバイス上のすべての通信が必ず処理されるという意味に捉えないでください。通信を取り込む範囲は別途確認が必要です。
  • ❌ 複数のクライアントでシステムプロキシ、ルーティング、DNSを同時に変更し続けないでください。どのクライアントがリクエストを処理しているのか、特定が難しくなります。

DNS リーク:DNSクエリの経路も確認

ドメインにアクセスするとき、アプリは通常、最初にアドレスを名前解決します。ウェブ接続がプロキシ経由でも、DNSクエリがローカルネットワークから送信されると、検索したドメインが外部に知られる可能性があります。一般にDNSリークと呼ばれますが、プライバシー上の想定から外れているかどうかは設定の目的に照らして判断してください。ルールによって意図的に直接接続するドメインなら、ローカルで名前解決されるだけで異常とは限りません。

クライアント内のDNS、OSのDNS、ブラウザーの暗号化DNSがそれぞれ有効になる場合があります。ブラウザーの暗号化DNSを有効にしても、クエリが必ず現在のプロキシを通るとは限りません。DNS接続が直接接続されることもあります。TUNを有効にした場合も、DNSの取り込み設定、ルーティング、IPv6の処理を確認してください。IPv4の出口を確認しただけで調査を終えないようにしましょう。

クライアントによってはFake-IPを使用します。ドメインを仮想アドレスに対応付け、転送時にドメインと実際の接続先を関連付ける仕組みです。ルーティングを補助する技術であり、DNS障害と同じ意味ではありません。また、例外設定が必要なアプリもあります。見知らぬ設定のDNS部分をコピーしただけで問題が解決したと思わず、クライアントが対応する構文とモードを確認してください。

クライアントごとの違い:接続後のトラブルを切り分ける

WindowsやmacOSのクライアントでは、システムプロキシやTUNなどの通信取り込み方式がよく使われます。システムプロキシの影響を受けるのは、主にOSのプロキシ設定に従うアプリです。独自のネットワーク設定を使うプログラムもあります。TUNは追加の権限が必要なことが多く、ほかのネットワークソフトのルーティングと競合する場合があります。Linuxでは権限、ルーティング、DNSの管理方法も確認してください。デスクトップクライアントのメニュー手順をそのまま当てはめられるとは限りません。

iOSやAndroidのクライアントは、通常、OSが提供するVPNネットワーク拡張機能やVPNインターフェースを使って通信を処理します。ただし、アプリの除外、バックグラウンドでの動作、プロトコル対応状況はクライアントとOSの設定によって異なります。Androidでは省電力機能がバックグラウンド動作に影響することがあります。モバイル端末がWi-Fiからモバイルネットワークに切り替わると、接続を再確立する必要が生じる場合もあります。システムにVPNと表示されていても、接続先のウェブサイトが利用できるとは限りません。

原因を切り分けるときは、やみくもに再インストールするより、通信の流れに沿って確認するほうが効果的です。設定が正常に読み込まれたか、ノードに接続できるか、アプリのリクエストがクライアントに届いているか、ルールで正しい出口が選ばれているか、DNSが利用可能な結果を返すかを確認し、最後に接続先サービスの地域制限やアカウント制限を調べます。一般的なウェブサイトは開くのに特定のサービスだけ拒否される場合、サービス側のポリシーや出口アドレスの制限が原因かもしれません。すぐにプロトコルの問題と決めつけないでください。

詳しい操作方法は使い方ガイドをご覧ください。パネルのサポート窓口に問い合わせる際は、利用プラットフォーム、クライアント名、ネットワーク環境、モード、エラー全文を記載し、認証情報は隠してください。「接続できない」と「接続済みだがアプリを使えない」を分けて説明すると、原因を絞り込みやすくなります。

初心者向けの手順:まず対応するサブスクリプションを読み込み、ノードと通信の取り込みを確認してから、ルールとDNSを調べましょう。変更する設定は一度に一つに絞り、変更前後の状態を記録してください。プロトコル名を覚えるより、リクエストがどの経路を通るかを説明できることが役立ちます。