VPNを初めて使うとき、混乱しやすいのは操作ボタンよりも、サブスクリプション、ノード、回線、プロトコル、ルーティングといった用語です。同じクライアント内に登場しますが、それぞれ設定の取得元、接続先、ネットワーク経路、通信方式、トラフィック処理ルールを指します。担当する工程を切り分けて理解すれば、サブスクリプションの導入、ノードの切り替え、接続切れの原因調査がずっと簡単になります。

まず、用語の範囲を確認しておきましょう。日常会話では「VPN」が暗号化トンネルやプロキシツール全般を指すことがありますが、Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICは、より正確にはプロキシプロトコルまたは通信方式です。クライアントがOSのVPN機能やTUNインターフェースを使って端末の通信を制御する場合でも、これらのプロトコル自体が従来型の企業VPNになるわけではありません。この違いを理解すると、「クライアントの動作モード」と「ノードのプロトコル」を同じものとして扱わずに済みます。

サービスクライアントサブスクリプションをまず区別する

サービスとクライアントは別物です

サービスとは、ノード設定、回線リソース、通信ルール、アカウント管理など、提供される内容を指します。一方、クライアントはパソコンやタブレットなどの端末にインストールするソフトウェアです。クライアント単体には通常、利用可能な回線は付属しません。メールソフトだけではメールアドレスが提供されないのと同じです。サービスから受け取った設定を対応クライアントに導入して初めて、サーバーアドレス、ポート、プロトコル、認証情報を読み込めるようになります。

同じサービス設定が複数のクライアントに対応することはありますが、対応しているからといって機能が完全に同じとは限りません。ルール分岐やTUNに対応するクライアントもあれば、システムプロキシだけを提供するものもあります。サブスクリプションを自動更新できるものもあれば、手動更新が必要なものもあります。ガイドの画面と自分の画面が違う場合は、ボタンの色ではなく、クライアント名、プラットフォーム、バージョンを確認してください。

サブスクリプションURLは更新される設定の入口

サブスクリプションURLは通常、アカウント専用のウェブアドレスです。クライアントがこのアドレスにアクセスすると、ノード名、サーバーの接続先、プロトコルのパラメータ、グループルールなどを取得します。一般的なウェブページでも、ブラウザで開くダウンロードページでもありません。ブラウザで直接アクセスした際に、エンコードされたテキストやファイル、空白のページが表示されても、URLが無効とは限りません。通常はURL全体をクライアントの「サブスクリプション」「設定ファイル」「リモート設定」などの項目に貼り付けます。

サブスクリプションURLには、アカウントを識別するトークンが含まれることがあります。機密性の高い設定として扱い、公開するスクリーンショットにはURL全体を写さないでください。また、出所の不明な変換サイトに貼り付けるのも避けましょう。有効なサブスクリプションを第三者に取得されると、ノード情報を読み取られる可能性があります。サービス側がノードを変更した場合、その相手にも更新内容が届くことがあります。

「サブスクリプションを導入する」ことと「サブスクリプションを更新する」ことは別の操作です。導入は、クライアントに初めて設定の取得元を登録する作業です。更新は、クライアントが元のURLへ再アクセスし、サービス側の最新内容をローカルに同期する作業です。ノード名、接続先、ルールが変更された後は、古いノードに切り替えるだけでは解決しないことがあります。まずサブスクリプションを更新しましょう。クライアントによっては更新時にサブスクリプション内のローカル変更が上書きされるため、長く使う独自ルールは、クライアントの上書き設定やローカルルール欄に保存するのが適しています。

ひとことで判断すると:クライアントにノードがまったく表示されない場合は、まずサブスクリプションが正常に導入されているか確認します。ノードは表示されるのに接続できない場合は、ノード、プロトコル、ローカルネットワークを確認してください。設定を導入する前に、システムプロキシを何度も切り替える必要はありません。

ノードサーバー回線の違い

ノードとは、クライアント上で選択できる一つの接続設定です。通常はサーバーアドレス、接続ポート、プロトコル、認証情報、通信パラメータが含まれます。一覧にある「東京」「ロサンゼルス」「シンガポール」などは、識別しやすくするための表示名であることが多く、サーバーのデータセンター、出口アドレス、ネットワーク経路全体が同じ場所にあるとは限りません。

サーバーは、接続を処理するソフトウェアとコンピューティングリソースです。一つのサーバーに複数のノード設定を載せることもあれば、一つのノードが中継サーバーを経由して別の出口から対象サイトへアクセスすることもあります。つまり「ノード」はクライアントから見える設定上の入口に近く、「サーバー」はバックエンドで実際に稼働するリソースに近い概念です。

回線とは、端末から出口までの大まかな経路と、トラフィックの振り分け方法を指します。回線品質は地理的な距離だけで決まらず、事業者間接続、迂回ルート、夜間の混雑、入口の負荷、対象サイト側のネットワーク状況にも左右されます。距離の近いノードから試すのは合理的ですが、国や地域名だけで結論を出すことはできません。

用語 実際に指すもの クライアントでの表示例 問題発生時にまず確認すること
ノード 選択可能な接続設定の一つ ノード一覧にある個別の選択肢 設定の有効期限とプロトコル対応
サーバー 接続・中継・出口を担うソフトウェアとリソース バックエンドの構成全体は通常表示されない 接続を確立できるか、サーバーが応答するか
回線 端末、入口、中継、出口の間のネットワーク経路 直接接続、中継、専用線などのラベル 混雑、迂回、事業者間接続の状況
出口アドレス 対象サイトから見える最終的なパブリックアドレス 接続後にネットワークチェックで確認する 地域が目的に合っているか、ローカル出口のままではないか

直接接続、中継、IEPL専用線

直接接続とは通常、端末が中間にサービス提供者の中継ノードを挟まず、海外の入口へ直接接続する方式です。構成がシンプルで、経路は主に利用中の事業者と国際インターネットのルーティングに左右されます。相互接続が良好なときは快適ですが、ネットワークが混雑したり経路が迂回したりすると、変動も大きくなります。

中継とは通常、端末がまず近距離または相互接続の良い入口へ接続し、サービス提供者が管理する回線で出口へ転送する方式です。中継の利点は経路を選び直せることであり、必ずしも速度が速くなるわけではありません。入口の選択、転送容量、出口の負荷のいずれかが適切でなければ、中継による改善は失われます。

IEPLはもともと、通信事業者が提供する国際イーサネット専用線系の接続を指し、比較的独立した管理可能な国際通信経路を重視します。実際のサービス表示では、IEPLが回線の一部だけを示す場合もあり、利用者側では共有入口や公衆回線を先に通ることがあります。比較する際は、入口・中継・出口をサービス提供者がどう定義しているかを確認し、ノード名だけで経路全体を判断しないでください。

一般的なプロキシプロトコルの役割

プロトコルは、クライアントとサーバーがデータを認証・暗号化・カプセル化・転送する方法を定めます。サブスクリプションはプロトコルのパラメータをクライアントに渡すだけで、一方のプロトコルを別のものへ自動変換するわけではありません。クライアントがノードのプロトコルに対応していない場合、ノードを導入できない、導入後に項目が欠ける、接続ボタンを押すとすぐ失敗するといった症状が現れます。

プロトコル 主な特徴 設定時の確認点 よく使われる場面
Shadowsocks 構成が比較的シンプルな暗号化プロキシプロトコル 暗号化方式、パスワード、サーバー、ポートを一致させる必要がある 対応クライアントが多く、一般的なプロキシ転送に適している
VMess V2Ray系で早くから使われてきた認証プロトコル 識別子、トランスポート層、時刻同期が接続に影響する 既存設定や互換環境で現在も使われている
VLESS 認証と通信の設計が軽く、さまざまなトランスポート層と組み合わせやすい フロー制御、セキュリティ層、ドメイン、通信パラメータを一致させる必要がある 通信方式を柔軟に組み合わせたい設定に適している
Trojan 通常はTLSで暗号化接続を確立する ドメイン、証明書検証、パスワード、サーバー名を正しく設定する必要がある TLS設定が整ったサーバーとクライアントに適している
Hysteria2 QUICとUDPを基盤とし、高遅延やパケットロスのある回線での通信を重視する UDPの到達性、証明書、帯域幅パラメータが性能に影響する UDPの条件が良く、クライアントが完全対応しているネットワークに適している
TUIC 同じくQUICとUDPを利用して多重通信を行う 認証、輻輳制御、証明書、クライアントのバージョンを一致させる必要がある このプロトコルに対応し、UDP通信が許可されている環境に適している

プロトコル名だけで最終的な速度は決まりません。回線が混雑している場合、カプセル化方式を変えても容量不足は解決しないことがあります。ローカルネットワークでUDPが制限されていると、QUICに依存する方式は接続できない一方、TCPやTLSベースの設定は動作する場合があります。反対に、遅延やパケットロスが目立つ回線では、適切に設計されたQUIC方式のほうが復旧がスムーズなこともあります。まずネットワーク条件を確認し、同じ時間帯・同じ出口に近い条件で異なるプロトコルを比較してください。

TLSだからといって「接続成功」とは限りません。TrojanやTLSを使用するVLESS設定では、クライアントが証明書とサーバー名を検証します。端末の時刻が大きくずれている、ドメインが一致していない、証明書が失効している、クライアントで必要な検証を無効にしている、といった原因でハンドシェイクに失敗することがあります。証明書エラーが出た場合は設定を修正するかサブスクリプションを更新し、検証無効化を恒久的な対策にしないでください。

選ぶ順番:まず、サービスが明確に推奨し、利用中のクライアントが完全対応しているプロトコルを使います。接続に失敗したら、ローカルネットワークでUDPが許可されているか、証明書エラーが出ているか、特定のアプリだけに問題があるかを確認します。新しいプロトコルほど、すべてのネットワークに適しているとは限りません。

グローバルモードルールモード直接接続モードの選び方

クライアントの「モード」は通信の行き先を決めるもので、プロトコルを切り替えるボタンではありません。グローバルモードは通常、クライアントが取得した通信をまとめてプロキシノードへ渡します。ルールモードはドメイン、アドレス、アプリ、ネットワーク種別などを確認してから、プロキシ、直接接続、ブロックのいずれかを選びます。直接接続モードはプロキシを迂回し、一時的な切り分けやプロキシ停止に使います。

グローバルモードは確認向けで、常用に適しているとは限りません

グローバルモードはルールチェーンが最も単純で、設定を導入した直後にノードが使えるか確認するのに適しています。対象サイトがグローバルモードでは正常で、ルールモードでは失敗する場合、原因はノード本体よりもルールのマッチング、DNSの結果、クライアントが通信を取得する範囲にある可能性が高いです。グローバルモードを長時間使うと、国内サイト、LAN上の機器、プロキシ不要のダウンロードまで遠隔出口を経由し、迂回が増えて使い勝手に影響することがあります。

ルールモードは「マッチング順」に左右されます

ルールは通常、アプリ、ドメインのサフィックス、アドレス範囲など、より具体的な条件から順に照合し、最後にどの条件にも一致しなかったリクエストを既定ルールで処理します。同じドメインが複数の条件に該当する場合、クライアントは通常、最初に一致した結果を採用します。範囲の広いルールを先に置くと、後ろの精密なルールが機能しなくなることがあります。

ルール内の「プロキシ」は、特定のノードを直接指すとは限りません。ポリシーグループを指し、手動選択、接続性チェック、サービス側から配布されたロジックによって、さらにノードが決まる場合があります。そのため、ルールにプロキシと書かれていても、想定した地域の出口を通っているとは限りません。ポリシーグループの現在の選択と実際の出口アドレスを確認してください。

システムプロキシとTUNでは通信の取得範囲が異なります

システムプロキシは、OSの設定にプロキシアドレスを書き込み、その設定に従うアプリの通信をクライアント経由にします。一部のゲーム、コマンドラインプログラム、独立したネットワークコンポーネント、独自に接続処理を行うアプリはシステムプロキシを無視することがあります。TUNモードは仮想ネットワークインターフェースを作成し、より低い層でIP通信を取得するため、対象範囲は通常広くなりますが、セキュリティソフト、別のVPN、仮想マシンのネットワーク、企業ネットワークのポリシーと衝突しやすくなります。

DNSリーク、出口アドレス、WebRTCの意味

DNSはドメイン名をネットワークアドレスに変換します。プロキシ接続後も、ドメインの問い合わせがローカルネットワークのリゾルバーによって直接処理され、暗号化経路や指定した遠隔リゾルバーを通る想定と異なる場合、そのような迂回した問い合わせは一般にDNSリークと呼ばれます。すぐにウェブページが開けなくなるとは限りませんが、アクセスしたドメインが露出したり、プロキシ出口と一致しないアドレスが返されたりして、ルール判定や地域別アクセスに問題が起きることがあります。

「DNSをプロキシ経由にすること」と「ウェブ通信をプロキシ経由にすること」は別の設定です。ローカルで先に名前解決して結果に基づき分岐するクライアントもあれば、ドメインルールで行き先を決めて異なるリゾルバーに問い合わせるクライアントもあります。接続確立前もドメインルールを使えるよう、仮想アドレスへのマッピングを提供するものもあります。実装はクライアントごとに異なるため、マッピング方式を理解しないままDNS設定全体をコピーしないでください。

出口アドレスとは、サイトから見えるパブリックな送信元アドレスです。接続後も出口がローカルネットワークのアドレスのままなら、現在のアプリが取得対象外である、ルールが直接接続と判定している、システムプロキシだけが設定されていてアプリが無視している、といった可能性があります。出口は変わったのにDNSの解決地域が想定と異なる場合は、ノードを替え続けるのではなく、DNSの経路を個別に確認してください。

WebRTCは、ブラウザやリアルタイム通信アプリが利用する技術群です。環境によっては、通常のページリクエストとは異なる候補ネットワークアドレスが露出することがあります。現代のブラウザ、OS、ネットワーク構成によって処理は大きく異なるため、検査ページにLANアドレスが一つ表示されたというだけでプロキシが失敗したとは判断できません。想定した出口を迂回するパブリック候補アドレスがあるか、ブラウザが現在のプロキシまたはTUNルートに従っているかを確認しましょう。

プラットフォームごとにクライアントの操作が違う理由

WindowsとmacOSのクライアントは、システムプロキシとTUNの両方を提供することが多い一方、仮想ネットワークコンポーネントの導入、OS権限の付与、ルーティング衝突への対処方法は異なります。デスクトップのブラウザはシステムプロキシを読み取ることが多いですが、コマンドラインツールでは環境変数や独自のプロキシ設定が必要な場合があります。ターミナルで接続できないからといって、ブラウザが使っているノードが無効だとは限りません。

Androidのクライアントは通常、システムのVPNServiceを通じて通信を取得します。アプリごとのプロキシ設定、LANのバイパス、アプリ単位でのプロキシ・直接接続の切り替えなどが一般的な機能です。省電力設定によってバックグラウンド動作が制限されることがあるため、画面ロック後に頻繁に切断される場合は、バックグラウンド制限とバッテリー最適化を確認してください。プロトコルを何度も切り替えるだけでは解決しません。アプリ別リストの意味も確認が必要です。「選択したアプリだけがプロキシを通る」場合と、「選択したアプリがプロキシを迂回する」場合があります。

iOSのクライアントは、OSが提供するネットワーク拡張機能に依存します。サブスクリプションを導入した後、初回接続時にVPN構成の追加を許可する必要があることが多いです。ルールセット、スクリプト、プロトコル、アプリ単位の制御への対応はクライアントごとの差が大きく、デスクトップ向けガイドのTUN、システムプロキシ、複雑な上書き設定がiOSでそのまま見つかるとは限りません。設定に互換性がない場合は、サービスが明確に対応している形式を使い、未知の項目を無理に書き換えないでください。

ブラウザ拡張機能は、そのブラウザ内でプロキシ可能なリクエストだけを処理し、ほかのアプリ、OSの更新、コマンドラインプログラムを自動的に取得することはありません。ルーターのクライアントは、そのネットワークに接続する複数の端末を対象にできますが、ルール、DNS、ハードウェア性能をルーターが担うため、原因調査は難しくなります。初心者はまず一台の端末でサブスクリプション、ノード、ルールを確認してから、ルーターへの移行を検討するのがよいでしょう。

プラットフォームまたは方式 一般的な通信の取得方法 見落としやすい点
Windows システムプロキシまたはTUN コマンドラインプログラムがシステムプロキシを読み取らないことや、仮想ネットワークコンポーネントの競合
macOS システムプロキシまたはネットワーク拡張 OS権限、プロキシ除外リスト、ほかのネットワークツールがルーティングに影響する
Android システムVPNService バックグラウンド制限、アプリ別リストの方向、省電力設定
iOS システムネットワーク拡張 プロトコル互換性、設定の許可、クライアント機能の違い
ブラウザ拡張機能 ブラウザ内のリクエストだけを処理する ほかのアプリはブラウザと一緒にプロキシ経由にならない
ルーター ネットワークゲートウェイで一括して通信を振り分ける ルール、DNS、性能、障害が配下の端末に影響する

サブスクリプションの導入から接続確認までの手順

初心者のトラブル対処でよくあるのは、ノード、プロトコル、DNS、TUN、ルールを同時に変更し、どの変更が効いたのかわからなくなることです。より確実なのは、決めた順番で一つずつ確認する方法です。以下はリモートサブスクリプションに対応する多くのクライアントで使える流れですが、具体的なボタン名は利用中のクライアントに従ってください。

  1. クライアントの互換性を確認する。まずプラットフォーム、クライアント名、サービスが対応するプロトコルを確認します。サブスクリプションを導入できても、含まれるすべてのノードを現在のクライアントが正しく認識できるとは限りません。
  2. サブスクリプションURL全体を導入する。URLをサブスクリプションまたはリモート設定の項目に貼り付け、識別しやすい名前を付けてから更新します。
  3. 更新結果を確認する。認証、形式、ネットワークに関するエラーが出ていないか確認し、ノード一覧が表示されるか確かめます。一覧が空の場合は、速度測定に進まず、先にサブスクリプションを解決してください。
  4. 推奨ノードを選ぶ。サービスが常用向け、または現在地のネットワークとの接続に適していると明示しているノードを優先します。最初から名前だけで最速の回線を推測しないでください。
  5. グローバルモードで確認する。接続を確立したらネットワーク検査ページを開き、パブリックな出口が変わったことを確認してから、対象サイトやアプリをテストします。
  6. ルールモードに戻す。グローバルモードが正常ならルールモードを有効にし、よく使うサイトを確認します。国内サービスは直接接続、国際サービスはプロキシという想定でも、実際の行き先はルールとポリシーグループに従います。
  7. 最後にDNSまたはTUNを調整する。解決地域の異常や、一部アプリがシステムプロキシに従わないなど、明確な症状がある場合に限って該当項目を変更します。

感覚で設定を変えず、症状から原因を絞り込む

まとめ:サブスクリプションは設定の取得元、ノードは接続の選択肢、回線はデータの経路、プロトコルは通信方式、ルーティングは通信の行き先を決めます。トラブル時は「サブスクリプションを更新できるか—ノードに接続できるか—アプリが取得対象か—ルールが一致しているか—DNSが想定どおりか」の順に確認すると、闇雲にノードを切り替えるより早く原因を見つけられます。