VPN用語には、サブスクリプション、ノード、プロトコル、グローバルモード、ルールモード、DNSなど、まとめて登場するものが多くあります。似ているように見えても、実際には接続プロセスの異なる階層に位置します。これらを理解する目的は用語を暗記することではなく、クライアントの画面を読み解き、回線の違いを見極め、ウェブサイトが開かないときやアプリの接続に問題があるときに確認すべき箇所を判断することです。

1回の接続を、それぞれ役割の異なる経路として考えると分かりやすくなります。サブスクリプションは設定情報をクライアントに渡し、ノードは遠隔接続の入口を提供します。プロトコルはクライアントと入口の通信方法を定め、回線はネットワーク上でのデータ伝送方式を決めます。ルーティングルールは、どのリクエストをこの経路に通すかを判断します。どの層に問題が起きても、見た目には「接続できない」だけに見えることがありますが、対処方法は同じではありません。

VPN・プロキシ・トンネルの違い

日常会話では、「VPN」がさまざまな国際回線クライアントや暗号化接続ツールを指すことがあります。厳密には、VPNは端末と遠隔ネットワークの間に仮想ネットワーク接続を構築し、システムのトラフィックをルーティングテーブルに従ってトンネルへ送る仕組みです。一方、プロキシは通常アプリケーション層で動作するか、ローカルのプロキシポートでトラフィックを受け取り、ルールに従って遠隔サーバーへ転送します。

使用感は似ている場合があります。クライアントに接続すると、ブラウザーやアプリが設定に従ってネットワークへアクセスできます。しかし、トラフィックを取り込む方法は異なります。システムVPNインターフェースは、プロキシ設定に対応していないアプリもカバーしやすい傾向があります。ローカルプロキシモードは、システムプロキシ、アプリのプロキシ設定、または透過転送機能に依存します。最近のクライアントでは、仮想NICでトラフィックを取り込み、プロキシプロトコルでもVPNトンネルに近いシステム全体のカバー範囲を実現する場合があります。

「トンネル」はカプセル化された伝送経路を表す言葉であり、特定のプロトコルと同義ではありません。端末からクライアントに入ったデータはプロトコルでカプセル化され、インターネット、中継ネットワーク、または専用回線を通って出口へ送られます。「トンネルを有効にする」と表示された場合は、システムプロキシ、仮想NIC、ネイティブVPNインターフェースのどれを使うのかも確認してください。アプリの互換性、DNS処理、ルーティング動作に影響するためです。

実用上の結論: 初心者が、あるツールをVPNと呼ぶべきかプロキシと呼ぶべきかで悩む必要はありません。重要なのは、対象アプリのトラフィックを取り込めるか、必要なプロトコルに対応しているか、DNSとルーティングが接続とともに正しく機能するかを確認することです。

サブスクリプション・設定ファイル・サブスクリプションURL

サブスクリプションとは、更新可能な接続設定のまとまりです。通常はノード名、サーバーアドレス、ポート、プロトコルパラメータ、認証情報、通信設定などが含まれます。クライアントがこれらを読み込むことで、画面上に選択可能なノードが生成されます。サブスクリプション自体は稼働中のサーバーではなく、どのノードもあらゆる用途に適していることを自動的に示すものでもありません。

サブスクリプションURLは、この設定一式を取得するための入口です。対応クライアントにURLを取り込むと、クライアントがサブスクリプションの内容を取得してローカルに保存します。サーバー側でノードや設定が更新された場合も、クライアントでサブスクリプションを更新でき、項目ごとの手作業による変更を避けられます。一部のクライアントはローカル設定ファイルにも対応しています。この方法は固定設定に向いていますが、後続の更新が自動で反映されるわけではありません。

サブスクリプションURLには、アカウントの識別や設定権限に関する情報が含まれることがあります。パスワードと同じように慎重に管理してください。完全なURLを公開フォーラムやスクリーンショット、公開コードリポジトリに掲載したり、出所の不明なオンライン変換サイトに渡したりしないでください。クライアントを変更する場合は、元のサービスページから再度コピーし、信頼できるクライアントへ直接取り込むのが安全です。

クライアントにサブスクリプションを取り込む一般的な手順

  1. まず、クライアントがサブスクリプションで使われているプロトコルと設定形式に対応しているか確認します。URLを取り込めても、含まれるすべてのノードを認識できるとは限りません。
  2. サービスの管理画面からサブスクリプションURLをコピーし、クライアントで「サブスクリプションを追加」「URLからインポート」など、同じ意味の項目を選択します。
  3. 初回更新を実行し、ノード一覧が表示されるか確認します。形式エラー、認証失敗、未対応フィールドなどの報告がないかも確認してください。
  4. 用途に合ったノードを選び、システムプロキシ、仮想NIC、またはVPNインターフェースを起動します。
  5. 対象のウェブページとアプリが想定どおり接続できるか確認し、ローカルサイト、LAN内のデバイス、必要なシステムサービスが誤って転送されていないことも確認します。

サブスクリプションの更新に失敗しても、以前保存したノードに接続できるなら、問題はサブスクリプションの取得処理にあり、回線の切断とは限りません。反対に、更新が成功したということは設定をダウンロードできたことを示すだけで、含まれるすべてのノードが正常に接続できることを証明するものではありません。「サブスクリプションの更新」と「ノードのテスト」を分けて判断すれば、クライアントの削除やシステムの再インストールを繰り返さずに済みます。

ノード・出口・回線は同じ概念ではありません

ノードとは、クライアントで選択できる接続設定の1つです。国、地域、都市、用途、回線タイプなどに基づいて名前が付けられることが多いですが、ノード名だけではデータが通るネットワークを完全には説明できません。似た名前の2つのノードでも、入口、中継方式、出口ネットワーク、プロトコルが異なる場合があります。同じ地域のノードでも、時間帯によって使用感が変わることがあります。

出口とは、サービスネットワークからリクエストが出ていく場所で、対象ウェブサイトから見える接続元です。ノードに表示された地域は通常、出口を示していますが、実際の意味はサービスの説明を確認してください。入口は、クライアントが最初に接続するサーバーまたは接続ポイントです。中継や専用回線を使う場合、入口と出口が同じネットワーク上にあるとは限りません。

回線とは、ユーザー側から出口までの伝送経路の構成を指します。回線を判断するときは、地図上の距離だけを見ないようにしましょう。物理的な距離は伝送遅延に影響しますが、通信事業者間の接続、混雑、迂回ルート、国際リンクの品質、対象ウェブサイトが接続するネットワークも結果を左右します。

回線タイプ 接続経路 一般的な特徴 選ぶときのポイント
直結 端末から遠隔の入口へ直接接続 構成がシンプルで、インターネット上のルーティングの影響を受けやすい 利用中の通信事業者から遠隔地までの実際の経路を確認する
中継 まず中継入口に入り、そこから出口へ向かう インターネット上の一部の経路を調整できるが、入口と中継リソースに左右される 入口の位置、混雑状況、中継経路を確認する
IEPL 専用回線 企業向け国際専用回線のリソースを通じて接続ポイント間を接続 一般的なインターネット経由の直結とは異なる経路構成 サービス側の表示、出口の用途、ローカル側の接続条件を確認する

IEPLは国際イーサネット専用回線のカテゴリーを表す業界用語です。一般ユーザー向けサービスでは、専用回線のリソースを国際伝送区間の一部に使用する形が一般的で、ユーザーの端末が専用回線を独占するわけではありません。そのため、「IEPLノード」は、そのノードの経路に該当する専用回線リソースが使われていると理解するのが適切です。固定の遅延、固定帯域幅、絶対的な安定性をそこから導くことはできません。

中継も専用回線と同じではありません。中継は1つ以上の転送工程を追加する仕組みで、それらがインターネット上で動作する場合もあります。質の高い中継は望ましくない直結ルートを避けられますが、入口が混雑していたり、中継構成がローカルネットワークに適していなかったりすると、直結より劣ることもあります。回線を選ぶときは、名前だけで並べ替えず、用途に合わせてテストしてください。

Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC

プロトコルは、認証、カプセル化、暗号化の組み合わせ、伝送方式など、クライアントとサーバーがデータを交換する方法を定めます。プロトコル名は速度のランクではありません。同じプロトコルでも、サーバーの負荷、ネットワーク経路、クライアントの実装によって結果は大きく変わります。初心者がプロトコルを選ぶときは、まずクライアントの互換性、次に現在のネットワークが必要な伝送方式を利用できるかを確認し、そのうえで用途を考えます。

Shadowsocks

Shadowsocksは暗号化プロキシプロトコルの1つで、通常はサーバー、ポート、パスワード、暗号化方式を設定します。実装が成熟しており、対応クライアントも多いため、一般的なウェブ閲覧やアプリのプロキシに適しています。複雑なルールシステムはプロトコル自体ではなく、通常クライアントが提供します。取り込み時に暗号化方式がクライアントでサポートされていなければ、他のパラメータが正しくても接続できません。

VMess と VLESS

VMessはV2Rayエコシステムのプロトコルで、認証とプロトコル層の暗号化機構を備え、複数の伝送方式と組み合わせられます。クライアントとサーバーのユーザー識別子、伝送タイプ、TLS設定、パスなどのパラメータを一致させる必要があります。重要なフィールドのどれか1つでも一致しないと、ハンドシェイク失敗として現れることがあります。

VLESSはより軽量な設計を採用し、プロトコル自体の暗号化を完全なセキュリティ層とはしません。通常はTLS、REALITY、その他の安全な伝送設定と組み合わせて使います。VLESSノードを見たとき、サーバーアドレスとポートだけをコピーしてはいけません。フロー制御、伝送方式、セキュリティタイプ、関連する識別情報も接続設定に含まれます。

Trojan

Trojanは通常、TLSを利用して接続を確立します。設定にはドメイン、証明書の検証、サーバー名、パスワードなどが関係します。クライアントのシステム時刻、ドメイン解決、証明書検証に問題があると、TLSハンドシェイクに失敗することがあります。一時的な切り分けのために証明書検証を無効にするのは、長期的な対策として適切ではありません。まずドメイン、システム時刻、設定の一致を確認してください。

Hysteria2 と TUIC

Hysteria2とTUICはいずれもQUICとUDPを基盤に伝送機構を構築し、複雑なネットワーク環境に向けて輻輳制御などの機能を提供します。変動やパケットロスのある経路では、従来のTCP伝送とは異なる挙動を示す可能性があります。ただし、現在のネットワークがUDPを正常に利用でき、クライアントも該当プロトコルを完全にサポートしていることが前提です。

一部のオフィスネットワーク、公共ネットワーク、ルーターはUDPを制限します。この場合、Hysteria2やTUICはハンドシェイクできなかったり、接続後の動作が不安定になったりすることがあります。そのときは、アカウント、サブスクリプション、サービス全体が利用できないと決めつけず、まずTCP伝送に対応した設定へ切り替えて比較してください。

グローバルモード・ルールモード・直結モード

ルーティングとは、リクエストの行き先をクライアントが決める処理です。ドメイン、IPアドレス、アプリ、ポート、ルールセットなどに基づき、トラフィックをプロキシノードへ送るか、直接接続するか、アクセスを拒否するかを判断します。ルーティングはローカルクライアントで行われ、サーバー側の回線タイプとは別のものです。

グローバルモードは通常、取り込み可能なトラフィックの大部分を現在のプロキシノードへ送ることを意味します。切り分けに便利で、グローバルモードでは対象アプリが使えるのにルールモードでは使えない場合、問題はノード全体の停止よりも、ルールの一致、DNSの判定、アプリによる迂回にある可能性が高くなります。ただし、ローカルサイト、LANサービス、国際回線が不要なアプリまで遠回りになることがあります。

ルールモードは、あらかじめ設定された条件に従って経路を選びます。一般的には、ローカルリソースは直結し、国際回線が必要なドメインはプロキシへ送り、LANアドレスは直結します。日常利用に適していますが、ルールの品質と更新状況に左右されます。新しいドメイン、アプリ内蔵のドメイン、コンテンツ配信ネットワークのアドレスが正しく判定されないと、ページ本体は開くのに画像、ログイン、APIリクエストが失敗することがあります。

直結モードは通常、選択したノードを経由せずにトラフィックを送る状態を指します。ローカルネットワークが正常か比較したり、LAN内のリソースへアクセスしたりする際に使えます。ただし、クライアントによっては「システムプロキシを無効にする」だけでは仮想NICが停止せず、画面を閉じてもバックグラウンドサービスが残る場合があります。切り分けでは、ウィンドウが閉じているかだけでなく、実際の動作状態を確認してください。

モード トラフィック処理 適した用途 よくある問題
グローバルモード 大部分のトラフィックを現在のノードへ送る ノードとアプリの互換性をすばやく確認する ローカルリソースへの経路やLANアクセスに影響する
ルールモード ドメイン、アドレス、アプリに応じて経路を選ぶ 日常のアクセスと用途別のルーティング ルールの不足、適用順序、DNS判定の異常
直結モード リクエストをローカルネットワークから直接送る 基準テストとLANアクセス ノードが引き続きトラフィックを処理していると思い込む

DNS・DNSリーク・ドメイン解決

DNSの役割は、ドメインをネットワークアドレスに解決することです。ブラウザーでウェブサイトを開く前には、通常この解決処理が行われます。ノードに接続できていても、DNSリクエストが失敗したり、到達できないアドレスが返されたり、解決結果とルーティングルールが一致しなかったりすると、ウェブページは開けません。

DNSリークとは一般に、本来トンネルや指定したリゾルバーを経由させるはずのDNSリクエストが、ローカルネットワークの別の経路から送信されることです。検索中のドメインが露出したり、地域判定が一致しなかったり、ルーティングの判断を誤ったりする可能性があります。ノード名を変えるだけで解決する問題ではなく、クライアントのDNS取り込み方式、システム設定、ブラウザーのセキュアDNS、仮想NICの設定を確認する必要があります。

暗号化DNSは、端末とリゾルバー間のDNSリクエストを保護できますが、リクエストが必ず選択したノードを経由することを保証するものではありません。ブラウザーが独自のセキュアDNSを有効にしていると、クライアントのDNSモジュールを迂回する可能性があります。クライアントがドメインベースのルールを使う場合、システムが先に解決することでルールの一致に影響することもあります。ブラウザー、システム、クライアントの解決方針を連携させることが適切です。

仮想IPまたはFake IPモードでは、まずクライアントが管理するアドレスをアプリへ返し、ドメインルールに従って実際の接続経路を決定します。ドメイン情報を保持しやすく、透過的なルーティングを改善できますが、一部のLANアプリ、ゲーム、実アドレスを必要とするプログラムでは除外設定が必要になることがあります。Redir Hostモードは実際の解決結果を返す方式で、互換性の仕組みが異なり、DNSとルールの連携により強く依存します。

DNSの問題を確認するときのポイント

  • 対象ドメインを解決できるか、解決失敗が接続を有効にした後だけ起きるか。
  • ブラウザーで、システムとは別のセキュアDNS設定が有効になっていないか。
  • クライアントがシステムDNSを取り込んでいるか、仮想NICモードが実際に起動しているか。
  • LAN内のドメインやローカルデバイスのアドレスが、誤って遠隔のDNSへ送られていないか。
  • IPv4とIPv6の解決およびルーティングが、異なる経路を使っていないか。

システムプロキシ・仮想NIC・プラットフォームごとの違い

WindowsとmacOSのクライアントは、システムプロキシと仮想NICモードを同時に提供することがよくあります。システムプロキシはOSのプロキシ設定を変更しますが、その設定に従うアプリだけがプロキシを通ります。仮想NICはネットワークインターフェースとルーティングを通じて、より広範なトラフィックを取り込みます。通常、システムプロキシを読み取らないアプリに適していますが、対応するシステム権限が必要です。

iOSとAndroidでは、サードパーティ製のネットワーククライアントが、通常はシステムのVPNインターフェースを使ってトラフィックを取り込みます。システムのステータスバーにVPNアイコンが表示されても、特定のプロキシプロトコルを使っていることまでは意味しません。実際のプロトコルは、取り込んだノード設定によって決まります。モバイルOSでは、省電力設定、ネットワーク切り替え、バックグラウンド制限によって接続が一時停止することもあります。

Linuxは環境による違いが大きいプラットフォームです。デスクトップアプリはプロキシ環境変数を変更したり仮想インターフェースを作成したりする場合がありますが、コマンドラインツールでは別途プロキシ変数の設定が必要になることがあります。ターミナルは接続できるのにブラウザーは接続できない、またはブラウザーは正常なのにパッケージマネージャーが失敗する場合、各プログラムが同じプロキシ入口を使っていない可能性が高く、ノードが特定のコマンドを制限しているとは限りません。

同じサブスクリプションでも、プラットフォームによって表示されるノード数が異なる場合があります。よくある原因は、クライアントが対応するプロトコルの範囲、設定の解析能力、プラットフォームのネットワークインターフェースの違いです。取り込みが不完全なときは、まずクライアントログで「未対応プロトコル」や「フィールドの解析に失敗」といった内容を確認し、そのうえで対応クライアントへの変更を検討してください。

現象から問題を切り分ける手順

効果的な切り分けのポイントは、一度に1つの条件だけを変更することです。ノード、プロトコル、クライアント、DNSを続けて変更すると、比較結果の意味が失われます。ローカルネットワーク、サブスクリプション、プロトコルのハンドシェイク、ルーティング、対象ウェブサイトの順に確認し、範囲を段階的に絞り込みましょう。

  1. 直結モードでローカルネットワークから一般的なウェブサイトへ正常にアクセスできることを確認し、端末のオフライン、ルーターの異常、システム時刻の誤りを除外します。
  2. サブスクリプションを更新し、明確なエラーが表示されるか確認します。更新に失敗した場合はサブスクリプションの状態とクライアントのネットワークを確認し、成功した場合はノードを個別にテストします。
  3. クライアントが明確に対応しているプロトコルを選びます。UDP系プロトコルが失敗した場合はTCP伝送の設定と比較し、TLSハンドシェイクが失敗した場合は時刻、ドメイン、設定フィールドを確認します。
  4. まずグローバルモードで対象アプリを検証します。グローバルモードでは使えるのにルールモードでは使えない場合、ルール、DNS、アプリの迂回設定を重点的に確認します。
  5. ブラウザーと他のアプリを比較します。特定のアプリだけに問題がある場合は、独自プロキシ、独自DNS、内蔵ネットワークスタックを使っていないか確認します。
  6. クライアントログで、接続タイムアウト、認証失敗、DNSエラー、ルールの適用情報を確認します。ログのほうが、接続ボタンを繰り返し押すよりも、問題がどの層にあるかを明確に示します。

「タイムアウト」は通常、定められた待機時間内に期待した応答を受信できなかったことを示します。ローカルから入口、入口から出口、出口から対象ウェブサイトまでのいずれで起きる可能性もあります。「接続拒否」は、対象ポートがリクエストを受け付けていない状態に近い表現です。「認証失敗」の場合は、サブスクリプションの期限、設定の更新状況、認証フィールドの不足を優先して確認します。クライアントによって表現は多少異なりますが、この3種類の現象を同じものとして扱わないことが大切です。

判断のポイント: サブスクリプションを更新できること、ノードがハンドシェイクできること、DNSを解決できること、ルールが適用されること、対象サービスが応答することは、それぞれ独立した確認項目です。階層ごとに切り分けるほうが、すべての異常を単に「ノードが悪い」と考えるより効果的です。

初心者が回線を選ぶときに本当に見るべき条件

ノードを選ぶとき、地域は最初の絞り込み条件にすぎません。一般的なウェブ閲覧では、経路が分かりやすく接続が安定し、対象サービスの地域要件に合う回線を優先するとよいでしょう。ビデオ会議やリアルタイムの共同作業では遅延の変動とパケットロスがより重要です。大容量ファイルの転送では、継続的なスループットと長時間接続の安定性が重視されます。ダウンロードに適した回線が、リアルタイム通話にも適しているとは限りません。

プロトコルもネットワーク環境に合わせる必要があります。UDPを利用でき、変動が大きいネットワークではHysteria2やTUICを比較できます。UDPが制限される環境では、TCPで接続できるプロトコル設定を用意してください。ルールモードを使う場合は、会議、ログイン、静的リソース、APIのドメインが一貫した出口に割り当てられているかも確認し、同じセッションのリクエストが異なる地域から送信される事態を避けます。

最後に、クライアントに表示される1回の遅延値を結論として扱わないでください。この数値は通常、クライアントからテストエンドポイントまでの1回の測定を示すだけで、対象ウェブサイトの応答、継続的な帯域幅、混雑時間帯の性能を表すものではありません。実際のアプリで短時間比較を行い、ノード、プロトコル、モード、ネットワーク環境を記録して、自分の用途に合う組み合わせを見つけるほうが確実です。