VPN用語を整理:設定・通信経路・ルールの違い

VPNの用語を理解するには、サブスクリプション、ノード、回線、プロトコル、ルーティングをそれぞれの役割に分けて考えることが大切です。サブスクリプションは設定を提供し、ノードはクライアントで選択できる接続先、回線は通信が通る経路、プロトコルは通信方法、ルーティングはリクエストの経路を決めます。互いに関係はありますが、同じものではありません。

日常会話では「VPN」がプロキシクライアントやネットワーク高速化サービス全般を指すこともあります。厳密には、システム全体のVPNトンネルとアプリ単位のプロキシは、通信を制御する仕組みが異なります。クライアントに「接続済み」と表示されても、接続の一部が確立したことを示すにすぎず、すべてのアプリが同じ出口を経由するとは限りません。

クライアントの操作から用語を理解する
用語役割間違えやすいポイント
サブスクリプションURL接続設定を取得・更新するためのURLクライアントのインストーラーでも、Webページのブックマークでもありません
ノードサーバー、認証情報、プロトコル設定を含む接続先表示される地域が必ずしも接続の入口の所在地とは限りません
回線利用者側から入口、出口、接続先サービスまでの通信経路プロトコル名だけでは回線の品質を判断できません
プロトコルクライアントとサーバー間の通信方法を定めるもの新しいプロトコルが、あらゆるネットワークで速いとは限りません
ルーティングルールリクエストを直結・プロキシ経由・拒否のいずれにするか決めるものノードを選んでも、すべてのリクエストがそのノードを使うとは限りません

サブスクリプションURLとノード:読み込むのは設定であり、通信量ではない

「サブスクリプション」には、料金プランと設定情報という2つの意味があります。月額サブスクリプションは料金の支払い方式で、サブスクリプションURLはクライアントが設定を読み込むためのURLです。データ容量のパッケージを利用する場合も、サブスクリプションURLからノードを取得することがあります。「サブスクリプションを更新」は通常、サービス側が提供する設定を再取得する操作であり、料金の更新ではありません。

ノードの設定には通常、サーバーアドレス、ポート、認証情報、プロトコル設定が含まれます。ノード名は識別用のラベルであり、それだけで実際の出口や回線の種類、接続先サービスの利用可否を判断することはできません。入口は接続を受け付け、出口は接続先のWebサイトへアクセスします。入口と出口が同じ地域とは限りません。

サブスクリプションの形式もさまざまです。ノード一覧のみを提供するものもあれば、グループ設定、ルーティングルール、DNS設定を含む完全な設定を提供するものもあります。クライアントにURLを読み込めても、URL内のすべての項目に対応しているとは限りません。読み込み後は、未対応項目や解析エラーがないか確認しましょう。

  1. サービスの管理画面にログインし、使用するクライアントに合ったサブスクリプションまたは設定を取得します。
  2. クライアントのサブスクリプション管理または設定の読み込み画面にURLを貼り付け、更新します。
  3. ノード一覧が表示されたことを確認し、現在の設定、グループ、選択中のノードをチェックします。
  4. 適切な通信の制御方法を有効にし、出口と対象アプリの動作をそれぞれ確認します。

IEPL専用線・中継・直結:ラベルではなく経路を比較

プロキシサービスでいう「直結」は通常、サービス事業者が別途用意した中継拠点を通さず、クライアントから公共インターネット経由でプロキシサーバーへ接続することです。「直結回線」とルーティングルールの「直結」は別の意味です。後者は通常、リクエストをプロキシに通さず、接続先へ直接アクセスすることを指します。

中継回線では、クライアントと出口の間に転送経路が加わります。サービス事業者は入口の場所や上流ネットワークとの接続を活用して経路を調整できますが、転送が1段増えても必ず遅くなる、または安定性が高まるとは限りません。実際の使用感は、利用者側の通信事業者、入口の負荷、中継区間、出口から接続先サービスまでの接続状況によって変わります。

IEPLは国際イーサネット専用線を指し、通信事業者が提供する専用のイーサネット接続を表す用語です。サービス事業者がIEPL回線と呼ぶ場合でも、アクセス経路全体の一部区間だけで専用線を使用していることがあります。家庭のネットワークから入口まで、また出口から接続先のWebサイトまでの区間は、公共インターネットを経由する場合があります。

そのため、「専用線」という表示だけで、遅延が一定、帯域が専有、すべてのWebサイトが利用可能とは判断できません。回線を選ぶ際は、実際に使うネットワークと時間帯で、利用したいアプリが安定して動くか確認しましょう。Web閲覧、ファイル転送、リアルタイム通話では、パケットロス、ジッター、スループットへの影響が異なります。遅延の数値だけで結論を出すことはできません。

判断のポイント:まず経路が利用環境に合っているかを確認し、次に目的のアプリが安定して使えるかを確かめましょう。IEPL、中継、直結は経路の情報であり、利用環境を問わず品質を順位付けする指標ではありません。

プロキシプロトコル:名称より互換性を重視

プロトコルは、通信相手の認証、データのカプセル化、転送方法を定めるもので、出口の地域を直接決めたり、回線品質を補ったりするものではありません。以下は業界で一般的に使われるプロトコルの概要です。VPNHeadがすべてのプロトコルを提供しているという意味ではありません。対応状況は管理画面の設定とクライアントの説明をご確認ください。

  • Shadowsocks:暗号化プロキシプロトコルです。クライアントとサーバーで暗号化方式と認証パラメーターを一致させる必要があります。実装やバージョンによって互換性が異なる場合があります。
  • VMess:認証機能を備えたプロキシプロトコルです。サーバーアドレスに加え、ユーザー識別子や使用するトランスポート層の設定が必要になる場合があります。
  • Trojan:通常、TLSを使ってプロキシ接続を保護します。証明書の検証やサーバー名などの設定はハンドシェイクに影響します。エラーを解消するために、検証をむやみに無効化しないでください。
  • VLESS:軽量なプロキシプロトコルで、プロトコル自体はデータを暗号化しません。接続の保護にはTLSなど、組み合わせるセキュリティ層が必要です。VLESSという名称だけでは、セキュリティ設定全体を判断できません。
  • Hysteria2とTUIC:どちらもQUICをベースとしており、UDPで通信できることが前提です。利用中のネットワークでUDPが制限されている場合、サブスクリプションの設定が正しくても接続できないことがあります。

プロトコルとトランスポート方式は分けて考えましょう。プロトコルによっては複数のトランスポート方式を組み合わせられますが、クライアントがその組み合わせ全体に対応している必要があります。「読み込みは成功したがハンドシェイクできない」場合は、クライアントのバージョン、プロトコルの対応状況、システム時刻、証明書エラーを確認してから、ネットワークの到達性を調べてください。すぐにプランの利用停止と判断する必要はありません。

ルールモード・グローバルモード・TUN:プロキシを経由する通信を決める

ルールモードでは、ドメイン名、接続先アドレス、アプリのプロセス、ルールセットなどに基づいて通信経路を決めます。たとえば、ローカルサービスは直結し、国際回線を使うリクエストはプロキシのグループに送る設定が一般的です。ルールの順序が重要なこともあります。先に一致したルールで経路が決まり、最後のフォールバックルールが未一致のリクエストを処理します。

グローバルモードでは通常、クライアントが制御するリクエストを、選択したプロキシ設定に統一して送ります。ただし、対象となるのは「クライアントが制御するリクエスト」です。システムプロキシ設定に従わないアプリや、独自の接続方法を使うアプリは、クライアントを経由しない場合があります。グローバルモードでも、端末のすべての通信が対象になるとは限りません。

システムプロキシは通常、その設定に対応したアプリのリクエストをローカルのプロキシポートへ送るために使います。TUNは仮想ネットワークインターフェースを通じて通信を制御する方式で、より広い範囲をカバーできますが、ルーティング、DNS、アクセス権限、他のネットワークソフトとの互換性にも関わります。TUNは通信を制御する方式であり、プロキシプロトコルでも新しい出口ノードでもありません。

WindowsとmacOSでは、システムプロキシと仮想インターフェースモードを区別する必要があります。Linuxでは、ルーティングやアクセス権限の設定が関わることもあります。AndroidとiOSのクライアントは、システムが提供するVPNインターフェースを使うことが一般的です。アプリごとのルーティングやLANの除外などに対応しているかは、OSとクライアントの実装によって異なります。

特定のアプリが開けない場合は、一時的にグローバルモードへ切り替えて比較できます。グローバルモードでは正常でルールモードでは問題がある場合、ルールの一致状況やプロキシグループを優先して確認してください。どちらのモードでも失敗する場合は、ノード、出口、アプリ側の制限を調べましょう。原因を特定したら適切なルーティングに戻してください。ローカルサービスまで常に別経路にする必要はありません。

DNSリークと出口の確認:接続後にチェックするポイント

DNSはドメイン名をネットワークアドレスに変換する仕組みです。DNSリークとは、名前解決のリクエストが想定した経路を通らず、利用者側のネットワークや意図しないDNSサーバーに送られる状態を指します。Webサイトへのアクセス時に使う出口が変わっているかとは別の問題です。Webサイトからプロキシの出口が見えていても、DNSリクエストが想定どおり処理されているとは限りません。

クライアントがシステムDNSを制御する場合もあれば、ブラウザーが独自の暗号化DNSを使い、アプリが独自の名前解決を行う場合もあります。調査時は「暗号化DNS」の設定だけを見るのではなく、実際にどこで名前解決され、どの経路を通るかを確認してください。暗号化通信を使えばDNSサーバーまでのリクエストを保護できますが、リクエストがプロキシを経由するとは限りません。

DNSを確認する際は、クライアントのログ、ルールの一致状況、検査ページを併せて確認しましょう。DNSサーバーの所在地が出口と異なるだけでは、リークの証拠になりません。DNSサービスが分散ネットワークを使っている場合があるためです。一方、検査ページで異常が見つからなくても、すべてのアプリや接続が同じ経路を使っているとは限りません。

  • ✅ IP確認ページで現在のブラウザーの出口を確認し、目的のアプリでも実際に動作するかテストします。
  • ✅ クライアントの接続ログを確認し、接続先ドメインに一致したルールとプロキシグループが想定どおりか確かめます。
  • ✅ OS、クライアント、ブラウザーのDNS設定を確認し、設定どうしが上書きし合わないようにします。
  • ✅ 一度に変更する設定は1つにし、エラーメッセージを記録して、元に戻したり原因を特定したりできるようにします。
  • ❌ 証明書の検証を無効化する、サブスクリプションの設定をむやみに置き換える、すべてのルールを削除するといった方法を、万能な解決策として使わないでください。

出口が正しくても接続先サービスを利用できない場合、アカウントの地域、サービスのポリシー、出口IPの評価、アプリのキャッシュなどが原因として考えられます。プロトコルを変えても解決するとは限りません。サポートを利用する際は、サポートページからクライアント名、OS環境、エラーメッセージ、問題が発生する状況をお知らせください。スクリーンショットを共有する前に、サブスクリプションURLと認証情報を隠してください。

用語を選択に活かす:必要なことを整理し、設定を確かめる

ブラウザーで海外のWebサイトを閲覧するだけなら、まずアプリがシステムプロキシに対応しているか確認しましょう。より多くのデスクトップアプリを対象にする場合は、TUNとその互換性を検討してください。家庭内の端末をまとめて接続するには、ルーターの性能、ポリシールーティング、LANへのアクセスも関わるため、デスクトップクライアントの設定をそのまま流用できるとは限りません。

サービスを選ぶ際は、プランのデータ容量、利用頻度、必要な回線を分けて検討しましょう。VPNHeadでは月額サブスクリプションと、使い切るまで有効で期限のないデータ容量パッケージを提供しています。月間データ容量は利用開始日を基準に毎月リセットされます。台数無制限は端末の利用条件を示すものであり、通信量が無制限になることや帯域幅が保証されることを意味しません。料金はプランページでご確認ください。

VPNHeadでは、プライバシーポリシーについて「匿名・ノーログ」と案内しています。これはプライバシーに関する方針であり、接続先のWebサイトからログイン中のアカウントや端末を識別できなくなるという意味ではありません。アカウントはユーザー名とパスワードで利用でき、メールアドレスは不要です。クライアントとサブスクリプションの取得にはログインが必要です。iOSクライアントの取得には有効なプランも必要ですが、その他のプラットフォームではログインすればダウンロードできます。

要点:サブスクリプションは設定を取得するもの、ノードは接続先を選ぶもの、回線は経路を表すもの、プロトコルは通信方法を定めるもの、ルーティングは通信の行き先を決めるものです。読み込み後は通信の制御方式、ルールの一致状況、出口、目的のアプリの動作を順に確認しましょう。ノードをやみくもに切り替えるより、問題を見つけやすくなります。設定方法は使い方ガイドをご覧ください。