VPNおすすめ用語集｜サブスク・ノード・プロトコル・ルール分岐を解説

このVPN初心者向け用語ガイドでは、クライアントの画面に沿って基本を整理します。サブスクリプションは設定情報を提供し、ノードは接続先、プロトコルは通信方式、ルール分岐はリクエストの経路を決めます。それぞれ役割が異なり、ひとつの設定項目ではありません。各機能の役割を理解してから、設定の読み込み、接続、アクセス結果を確認すれば、あらゆる不具合を「ノードの問題」と決めつけずに済みます。

用語ガイド：アカウントからアクセスまで

一般に「VPN」は、OSレベルの仮想プライベートネットワークを指す場合と、国際接続用の回線を提供するプロキシサービスを指す場合があります。呼び名が似ていても、仕組みは同じとは限りません。ソフトが実際にどの通信を処理するかは、アプリ名や接続アイコンだけでなく、システムプロキシ、トンネルインターフェース、ルーティング設定を確認してください。

ウェブサイトへのアクセスには通常、複数の処理が関わります。アプリがリクエストを送り、OSまたはクライアントがドメイン名を解決し、ルールが直結かプロキシ経由かを選び、プロキシのリクエストがノードを通ってサイトに届きます。これは仕組みを理解するための簡略化した流れです。キャッシュ、リモートDNS、クライアントの実装によって、実際の処理順は異なる場合があります。

サブスクリプションURLとクライアントへの設定読み込み

「サブスクリプション」は意味が混同されやすい言葉です。プランのサブスクリプションは料金契約を指しますが、クライアントで使うサブスクリプションは、通常、更新可能な設定情報の取得元です。URLから取得する内容はノードだけの場合もあれば、プロキシグループ、ルール、DNS設定を含む場合もあります。読み込みに成功したのはクライアントが内容を認識できたということであり、すべての回線が使えると確認されたわけではありません。

クライアントによって対応する形式は異なります。同じURLでも、ノード一覧が返る場合もあれば、特定のコア向けの設定ファイルが返る場合もあります。ファイルの拡張子だけで互換性を判断しないでください。また、形式変換のために認証情報を含むURLを、運営元が不明なサイトへ送信しないようにしましょう。

1. サービスのアカウントページから、使用中のクライアントに合った設定を取得し、対応OSと読み込み方法を確認します。
2. クライアントでサブスクリプション、設定、またはインポートのメニューを開きます。URLを貼り付けて更新し、ノードと設定名が表示されるか確認してください。
3. 読み込み後に、モード、プロキシグループ、DNS設定を確認します。自動選択グループがある場合は、どのノードが選択対象になっているかも確認してください。
4. ノードを選択し、必要な通信処理の方法を有効にしてから、接続ボタンの表示だけで判断せず、目的のウェブサイトにアクセスして確認します。
5. 更新に失敗したら、まずダウンロード、認証、形式のどのエラーかを確認し、それぞれネットワーク、URLの有効性、コアとの互換性を調べます。

サブスクリプションURLはアカウントの認証情報と同様に扱ってください。スクリーンショット、公開の問い合わせ、共有ドキュメントでは、URL全体と含まれるトークンを隠しましょう。漏えいした場合は、サービスのリセット機能を使うか、アカウントのサポート窓口に相談してください。

「サブスクリプションの更新」と「ルールの更新」も区別が必要です。設定によってはルールがサブスクリプションと一緒に配信されますが、独立したルール情報を参照するものもあります。ノードを更新してもサイトへの接続経路が変わらない場合、ルール情報が更新されていないか、アプリが既存の接続を再利用している可能性があります。

ノード、IEPL専用線、中継、直結の違い

ノードはクライアントで選択できる接続設定であり、必ずしも独立した物理サーバーを指すわけではありません。複数の名称が同じ接続入口を共有している場合も、入口と出口の地域が異なる場合もあります。サイト側に表示されるのは通常、出口のアドレスです。地域に関するアクセス問題は、ノード名だけで判断せず、出口の地域やサイト側の判定も確認してください。

直結と中継は通信経路を表す

回線の説明でいう「直結」は通常、クライアントから海外のサービス入口へ直接接続することです。「中継」は、まず転送用の入口に接続し、そこから出口へ通信を送ります。中継によって一部の経路が改善する場合もあれば、迂回や混雑の原因が増える場合もあります。中継が一段増えるだけで、必ず遅くなる、または安定するとは限りません。

ルール設定でいう「直結」は別の意味です。対象のリクエストをプロキシの出口経由にしないことを表します。この言葉を見たら、サービス回線の説明なのか、特定のリクエストに対するクライアントの処理結果なのかを確認してください。

IEPLでもアクセス全体が専用回線で保証されるわけではない

IEPLは一般に、国際イーサネット専用線を指します。サービスでいうIEPL回線は、入口と出口の間の一部区間のみをカバーする場合があります。デバイスから入口まで、また出口から接続先のウェブサイトまでには、それぞれ別のネットワーク環境が関わります。IEPLはアプリケーション層のプロトコルとは異なる概念であり、名称だけから低遅延、固定帯域、動画配信サービスの利用可否を判断することはできません。

プロトコル名とクライアントのコア互換性

Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICは、いずれもプロキシクライアントの設定に使われることがありますが、自由に置き換えられるものではありません。サーバー側で指定された認証、暗号化、転送方式、安全性に関するパラメーターをクライアント側と一致させる必要があります。プロトコル名を変更しても、既存のノードが別のプロトコルに変換されるわけではありません。

• Shadowsocks：暗号化プロキシのプロトコルです。クライアントがサーバー側の具体的な暗号方式に対応している必要があります。「Shadowsocks対応」という表示だけで、すべての設定が互換性を持つとは限りません。
• VMessとVLESS：異なるプロトコルです。VLESS自体には通信を暗号化する機能がないため、通常は適切なセキュリティレイヤーと組み合わせます。認証と通信経路の暗号化を混同しないようにしてください。
• Trojan：通常、TLS接続上でプロキシ通信を行います。証明書の検証やサーバー名などの設定が接続に影響するため、証明書の検証を無効にすることを一般的な対処法にしないでください。
• Hysteria2とTUIC：どちらもQUICベースの方式で、通信にはUDPを使用します。利用中のネットワークでUDPが制限されていると、接続できない場合があります。これはアカウントが無効になったことを意味するわけではありません。

アプリの画面は操作用の外側の部分であり、設定の解析や接続の確立はコアが担います。同じアプリでも、バージョンによって対応範囲が異なる場合があります。「未対応のプロトコル」や「不明なフィールド」と表示されたら、回線の問題を疑う前に、コアと設定形式の互換性を確認してください。

ここでは一般的な技術用語を解説しています。VPNPastが上記のすべてのプロトコルや、任意のサードパーティ製クライアントの設定を提供するという意味ではありません。実際に利用できる方法は、アカウント内のダウンロードページ、設定ガイド、クライアントの対応状況をご確認ください。

ルール分岐、ルールモード、グローバルモード

ルール分岐は、条件に応じてリクエストの処理方法を振り分ける仕組みです。主な処理には、直結、プロキシグループへの振り分け、接続の拒否があります。ルールはドメイン、接続先アドレス、プロセスなどを条件にできますが、利用できる条件はクライアントのコアとOSの権限によって異なります。

多くのクライアントでは、ルールを上から順に照合し、最初に一致したルールでリクエストの経路が決まります。一致しないリクエストは、最後の処理項目に渡されます。広い範囲に当てはまるルールを具体的なルールより前に置くと、後者が機能しなくなることがあります。変更する際は、使用中のコアの構文を確認し、別のクライアント向けのルールをそのまま貼り付けないでください。

グローバルモードでもデバイス全体の通信を処理するとは限らない

ルールモードでは設定に従ってリクエストの経路を決めます。グローバルモードでは通常、クライアントに届いたリクエストをグローバルポリシーで処理します。重要なのは「クライアントに届いた」という点です。システムプロキシを使わないアプリのリクエストは、プロキシのコアに届いていない可能性があり、グローバルモードに切り替えても結果が変わらないことがあります。

TUNモードを使うと処理対象を広げられますが、ルーティング、権限、除外設定の影響は受けます。モバイル端末にシステムのVPNアイコンが表示されるのは、通常、アプリがOSのトンネルインターフェースを使っていることを示します。それだけで内部のプロトコルまで特定することはできません。

• ✅ ウェブサイトは見られるのに特定のアプリが使えない：そのアプリがシステムプロキシに対応しているか、トンネル経由の通信処理が必要かを確認します。
• ✅ ノードを切り替えても出口が変わらない：ホーム画面に表示されたノードだけでなく、対象リクエストに適用されたプロキシグループを確認します。
• ✅ グローバルモードでは使えるのにルールモードでは使えない：適用されたルール、最後の処理項目、DNSの結果を確認し、設定の問題を絞り込みます。
• ❌ ノード、DNS、ルール、コアを同時に変更する：要因が混ざり、元に戻せたとしても原因を特定しにくくなります。

DNSリークとOSごとの違い

DNSリークとは、プライバシーやルーティングの方針に沿って処理されるべきDNS問い合わせが、想定外の経路やDNSリゾルバーを通じて送信されることです。ウェブサイトから見える出口がプロキシのアドレスでも、DNS問い合わせまで想定どおりの経路を通っているとは限りません。一方、検査ページに表示されたDNSリゾルバーの地域だけで、リークがあったと判断することもできません。実際にどの経路からアクセスされたかも確認が必要です。

ブラウザーの暗号化DNS、OSの名前解決サービス、クライアント内蔵DNS、キャッシュが同時に関わる場合があります。調査する際は、クライアントがDNSを処理する範囲と、ブラウザーが想定した設定を回避していないかを確認してください。暗号化DNSはリゾルバーまでの問い合わせ通信を保護できますが、DNSとウェブリクエストが自動的に同じ出口を通るわけではありません。

WindowsとmacOSでは、システムプロキシと仮想インターフェースの権限を区別する必要があります。iOSとAndroidでは通常、OSが提供するトンネルインターフェースを使って通信を処理しますが、アプリごとの振り分けなどの機能はOSやクライアントによって異なります。Linuxでは、デスクトップのプロキシ設定、環境変数、システムサービス、ルーティング設定が関係する場合があります。コマンドラインのツールがデスクトップブラウザーの設定を引き継ぐとは限りません。

デバイスを変える際、別のプラットフォームの操作手順をそのまま使わないようにしましょう。VPNPastはWindows、macOS、iOS、Android、Linuxに対応しています。設定手順は使い方ガイドをご覧ください。クライアントはアカウントのダウンロードページから入手できます。

用語をトラブルシューティングの手順に活かす

問題が起きたら、まず現象を整理し、原因の層を特定します。ノードが表示されない場合は、サブスクリプションの取得や形式を確認します。ノードは表示されるのに接続できない場合は、認証、プロトコル、ネットワークへの到達性を確認します。接続できてもアクセスできない場合は、ルール分岐、名前解決、出口、接続先サイトの制限を調べます。接続テストと実際のサービスへのアクセスでは異なるリクエストが使われる場合があり、片方での結果をもう片方の代わりにはできません。

1. 設定の取得元を確認：正しいアカウントから、使用中のクライアントに合った設定を読み込んでいるか確認します。問い合わせ時に認証情報を公開しないでください。
2. リクエストの経路を確認：クライアントの接続ログで接続先、適用ルール、プロキシグループを確認し、個人情報は隠してください。
3. 変更は一度にひとつ：まず同じプロキシグループ内のノードだけを切り替え、その後モードやDNS設定を個別に確認します。変更ごとに結果を記録してください。
4. 実際の用途で確認：利用したいウェブサイトやアプリを開き、テストアイコンだけでなく、ログイン、コンテンツの読み込み、接続の継続を確認してください。

技術設定とは別に、プランのデータ通信量とプライバシーポリシーも確認しましょう。VPNPastはログを保存しない方針です。メールアドレス不要で、ユーザー名とパスワードだけでアカウントを作成できます。同時接続台数は無制限で、14日間の無条件返金に対応しています。こうしたサービス条件は、デバイスの権限管理に代わるものではなく、接続先サイトのアクセスルールを変更するものでもありません。