VPN初心者向け用語集｜サブスクリプション・ノード・プロトコル・ルール分岐とグローバルモード

VPN用語ガイド：設定と通信経路を分けて理解する

VPN初心者が混同しやすいのが、サブスクリプション、ノード、プロトコル、ルール分岐、グローバルモードです。それぞれ役割の異なる設定です。サブスクリプションは設定情報を提供し、ノードは接続先を示し、プロトコルは通信方式を定め、ルールはリクエストの経路を決めます。

一般にVPNと呼ばれるものには、システム全体を対象とするトンネル型サービスと、プロキシクライアントで利用する国際通信向けのサブスクリプションがあります。プロキシクライアントが仮想ネットワークインターフェースを使って通信を取り込む場合もありますが、すべてのサービス、プロトコル、通信の取り込み方式が同じ技術というわけではありません。トラブルを調べる前に、使用中のクライアントと、実際に通信を取り込んでいるアプリを確認しましょう。

サブスクリプションURLとノード：設定情報の取得元

通信量プランはサービスの利用条件、サブスクリプションURLは設定情報の取得先です。プランを利用できる状態にしても、クライアントにはサーバーの場所やプロトコル、認証方法などの情報が必要です。通常、こうした情報はサブスクリプションから取得します。サブスクリプションの更新は設定情報を再取得する操作であり、プランの更新や通信量のリセットではありません。

サブスクリプションにはノード一覧だけが含まれる場合もあれば、プロキシグループ、ルール、DNS設定を含む設定一式の場合もあります。クライアントによって対応形式が異なるため、どの形式のURLでも任意のクライアントで使えるとは限りません。読み込み時に形式エラーが出たら、管理画面に記載されたクライアントの種類と読み込み手順を確認してください。

ノードは一覧にある個々の接続先です。クライアントがまず入口サーバーに接続し、そこから中継サーバーを経由して出口サーバーへ接続する場合があります。通常、接続先のWebサイトに表示されるのは出口のアドレスです。そのため「日本」などのノード名が示すのは出口の地域かもしれません。名前だけで経路全体を判断したり、Webサイトがその出口からの接続を必ず受け付けると考えたりしないようにしましょう。

管理画面にはプランが表示されているのにクライアントにノードがない場合は、まずサブスクリプションURLがすべてコピーされているか、設定を取得できるネットワーク環境か、クライアントがその形式に対応しているかを確認します。ノード一覧は表示されるものの接続できない場合は、プランの状態、ノードの選択、クライアントのエラー表示を確認してください。この二つの問題は分けて対処しましょう。

プロトコル名：名称より互換性を確認

Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICは、それぞれ異なるプロキシプロトコルまたは方式で、自由に置き換えられるラベルではありません。接続する双方が対応する実装を備え、認証情報、通信設定、サーバー設定が一致している必要があります。クライアント上の表示名だけを変えても、プロトコルを変換することはできません。

暗号化・通信方式・プロキシプロトコルは別の概念

Shadowsocksは暗号化されたプロキシ機能を提供し、VMessは独自の認証・暗号化の仕組みを備えています。Trojanは通常、TLSを利用して安全な通信を確立します。VLESS自体にはペイロードの暗号化機能がないため、適切なセキュア通信の設定と組み合わせて使う必要があります。Hysteria2とTUICはQUICをベースとしており、下位層でUDPを利用します。そのため、利用するネットワークでUDPが制限されていると、接続できるかどうかに影響します。

こうした違いは互換性を理解する助けになりますが、あらゆるネットワーク環境での速度順位を決めるものではありません。実際の使い心地は、出口、経路の混雑状況、クライアントの実装、ローカルネットワークにも左右されます。Webページが快適に表示されても、ゲームのUDP通信や長時間のデータ転送も同じように快適とは限りません。

クライアントを選ぶ際は、現在のバージョンとコアが、サブスクリプションに含まれるプロトコルや通信方式の組み合わせに対応しているか確認してください。あるプロトコルに対応していても、すべての拡張設定が使えるとは限りません。読み込み後に「未対応のノード」と表示されたら、公式の案内に沿ってクライアントを更新するか、互換性のある形式を選びましょう。認証情報や証明書の検証設定などをむやみに削除しないでください。

IEPL専用線・中継・直結：通信経路の違い

プロトコルは通信方法を、回線の種類はネットワーク上の通信経路を表します。直結は通常、クライアントがプロキシサーバーへ直接接続する方式です。中継は通常、入口で接続を受け付けてから、後続のサーバーへ転送します。中継経路は長いからといって必ず遅いわけではなく、直結は経由地が少なくても混雑時に安定するとは限りません。

IEPLはInternational Ethernet Private Lineの略で、通信事業者が提供する国際イーサネット専用線サービスを指します。サブスクリプションサービスで「IEPL」と記載されている場合、経路の一部が専用線であることを示すケースが多く、ユーザーの端末から接続先のWebサイトまで全区間が専用線という意味ではありません。

ユーザーから入口までのローカルネットワーク、出口からWebサイトまでの一般ネットワーク、サービス提供者の回線容量の割り当ても、利用体験に影響します。回線の表示は暗号化プロトコルを示すものではありません。専用線を利用していても、通信の安全性は実際のプロトコルとクライアント設定を確認する必要があります。

ルール分岐とグローバルモード：リクエストの経路を決める仕組み

ルールモードでは、設定された条件に応じてポリシーを選びます。たとえば、ローカルサービスには直接接続し、指定した海外サイトにはプロキシを使い、特定のリクエストを拒否するといった設定が可能です。ルールの条件には、ドメイン、ドメインのサフィックス、宛先アドレスの範囲、プロセスなどがあります。対応範囲はクライアントによって異なります。多くのルールエンジンは設定順に照合しますが、使用中のクライアントのドキュメントを確認してください。

プロキシグループは、ルールと実際のノードの間で接続先を選ぶ仕組みです。ルールがリクエストをグループに振り分け、そのグループが手動で選択したノードを使ったり、設定に基づいて自動選択したりします。トラブル時に「現在のノード」だけを確認しても不十分な場合があります。対象のリクエストがどのルールに一致し、どのグループに渡され、最終的にどの出口が選ばれたかも確認しましょう。

グローバルモードでは通常、クライアントが取り込んだリクエストを共通のポリシーで処理します。ルールによる誤った振り分けがあるか確認するのに便利ですが、クライアントによっては、そのポリシーで直接接続を選べます。そのため「グローバル」にしただけでプロキシ接続が有効になるとは限りません。また、通常はクライアントを経由しないアプリが自動的にシステムプロキシに従うようになるわけでもありません。

通常はルールモード、トラブル時は一時的に切り替えて確認

同じノードを使っていて、グローバルモードでは接続先のWebサイトを開けるのにルールモードでは失敗する場合は、ルールの照合履歴、プロキシグループ、DNSの動作を確認しましょう。どちらのモードでも失敗するなら、ノードへの接続、ローカルネットワーク、接続先サービス自体を確認します。モードの切り替えは原因を特定するための手段です。グローバルモードをあらゆる障害の恒久的な解決策として使わないでください。

LAN内の機器やローカルサービスにアクセスする場合は、バイパスルールも確認しましょう。ルールファイル全体を安易に置き換えると、既存のローカル接続に影響することがあります。変更前に元に戻せる設定を保存し、問題に関係する条件だけを調整してください。

システムプロキシ・TUN・DNS：接続後もアプリの通信が取り込まれないことがある

WindowsとmacOSのクライアントには、システムプロキシや仮想ネットワークインターフェースによる通信の取り込み設定があります。ブラウザーはシステムプロキシに従うことが多い一方、コマンドラインツール、ゲーム、独自のネットワーク機能を持つアプリは別の設定を使う場合があります。Linuxでも、デスクトップ環境のプロキシ設定とターミナルの設定が分かれていることがあります。デスクトップのステータスアイコンだけで判断せず、アプリごとに確認しましょう。

AndroidやiOSでは、一部のプロキシクライアントがOSのVPNインターフェースを使って通信を取り込み、システムに接続中の表示が出ます。この表示は通信を取り込むインターフェースが有効であることを示しますが、従来型の特定のVPNプロトコルが使われているとは限りません。アプリごとの除外設定、ルーティング設定、OSの制限によって、実際に対象となる通信の範囲は変わる場合があります。

DNSはドメイン名をIPアドレスに変換します。Webページへの接続がプロキシ経由でも、ドメインの問い合わせが想定と異なるDNSサーバーへ送られることがあります。DNSの問い合わせも指定した経路に通す必要がある状況で、このような状態は一般にDNSリークと呼ばれます。想定しているポリシーと照らし合わせて判断し、ローカルDNSへの問い合わせをすべて障害と決めつけないでください。

ブラウザーの暗号化DNS、OSのリゾルバー、クライアント内蔵のDNS機能が同時に使われることがあります。検査ページに表示されたリゾルバー名だけでは、通信経路全体が適切かどうかは判断できません。クライアントの接続ログ、DNS設定、アプリの設定を合わせて確認し、問い合わせをどの機能が送信し、どの経路を通っているかを特定しましょう。検査結果を揃えるためだけに証明書の検証を無効にしたり、出所の分からないDNS設定をコピーしたりしないでください。

読み込みから動作確認まで：初心者向けチェックリスト

ここまでの用語を実際の手順に当てはめると、トラブルの原因を追いやすくなります。各工程が終わるたびに結果を確認しましょう。ノードの変更、ルールの編集、DNSの変更を同時に行うと、どの変更が効果をもたらしたのか分かりにくくなります。

1. 管理画面の状態を確認する。プランが利用可能かを確認し、使用中のクライアントに合ったサブスクリプションURLを取得します。VPNWorthのアカウントに必要なのはユーザー名とパスワードで、メールアドレスは不要です。クライアントとサブスクリプションの情報は、ログイン後に管理画面で確認してください。
2. クライアントの入手元と互換性を確認する。管理画面で案内されている方法でクライアントを入手し、対応プラットフォーム、バージョン、プロトコルを確認します。ソフトウェア名が似ているだけで同じ形式を読み込めるとは限りません。
3. 設定を読み込み、更新する。クライアントの案内に従ってサブスクリプションURLを貼り付けるか、対応する方法で読み込みます。ノード一覧が表示されたら、解析エラーが残っていないか確認しましょう。一部だけ読み込まれた状態を、完全に成功したと判断しないでください。
4. ポリシーを選び、通信の取り込みを有効にする。ノードまたはプロキシグループを選択し、必要なシステムプロキシや仮想ネットワークインターフェースの機能を有効にします。システムの許可が必要な場合は、案内を読んで、使用中のクライアントに対する許可であることを確認してください。
5. 対象のアプリで動作を確認する。まずブラウザーの出口を確認し、実際に使いたいアプリも開いてみます。接続に失敗した場合はログを確認し、サブスクリプションの取得失敗、サーバーへの接続失敗、ルールによる直接接続、接続先サービスによる拒否を切り分けてください。
6. 元に戻せる状態を保つ。接続できることを確認してから、ルールやDNSを一つずつ調整します。診断情報を共有する前に、サブスクリプションのトークン、認証情報、個人情報を隠してください。必要に応じて管理画面のサポート窓口から問い合わせましょう。

• ✅ ノード一覧が表示される：設定は読み込まれています。接続できるかどうかは別途確認が必要です。
• ✅ ブラウザーの出口が想定どおり：今回のブラウザーのリクエストが、該当する経路を使ったことを示します。
• ❌ グローバルモードが有効：すべてのアプリやDNSの通信が取り込まれているとは限りません。
• ❌ ノード名に専用線とある：すべての接続先サイトにアクセスできるとは限りません。

次の関係を押さえておきましょう。サブスクリプションが設定を提供し、クライアントが設定を実行し、ノードが接続を担い、プロトコルが通信方式を定め、ルールが経路を決め、通信の取り込み方式が対象範囲を決めます。問題が起きたらこの流れに沿って順番に確認すると、設定を何度も切り替えるより原因を特定しやすくなります。詳しい操作方法は使い方と利用ガイドをご覧ください。