VPN初心者が最も混同しやすいのは、ボタンの位置ではなく、サブスクリプション、ノード、プロトコル、ルーティングの関係です。サブスクリプションはクライアントに設定を渡し、ノードは選択可能な接続先を示し、プロトコルは通信方式を定め、ルーティングはどの接続をプロキシ経由にするかを決めます。この階層を分けて考えると、インポート失敗、接続できるのにページが開かない、ノードを切り替えても遅いといった問題を特定しやすくなります。
日常の会話では、「VPN」がネットワーク高速化、暗号化トンネル、プロキシサービスの総称として使われることがあります。ただし、実際のクライアントはシステムVPNインターフェースを使う場合もあれば、システムプロキシだけを設定する場合、TUN仮想ネットワークアダプターで通信を引き受ける場合もあります。名称が似ていても、動作する場所が完全に同じとは限りません。設定が適切か判断するには、アプリのトップ画面に「接続済み」と表示されているかだけでなく、通信がどのようにクライアントへ入り、どの回線を選び、ドメイン名をどのように解決しているかを確認します。
| 用語 | 実際の役割 | よくある誤解 | 確認するポイント |
|---|---|---|---|
| サブスクリプション | クライアントにノード設定を提供し、更新時に変更内容を同期する | サブスクリプションURLを通常のダウンロード先や公開共有コンテンツと考える | URLが完全か、クライアントが対応形式をサポートしているか |
| ノード | 選択可能なサーバー入口と、その接続パラメータを表す | ノード名を完全なネットワーク経路とそのまま同一視する | 出口の地域、入口の品質、回線タイプ、現在の負荷 |
| プロトコル | クライアントとサーバーが認証、カプセル化、データ転送を行う方法を定める | プロトコル名だけで速度が決まると考える | クライアントの互換性、トランスポート層、ネットワークのUDP対応 |
| ルーティング | ドメイン、IP、アプリ、ルールセットに応じてプロキシまたは直接接続を選ぶ | グローバルモードのほうが必ずルールモードより安定すると考える | ルールの適用、DNS解決経路、デフォルトポリシー |
サブスクリプションURLに含まれるもの
サブスクリプションURLは通常、クライアントが設定を読み込むための入口です。クライアントがURLへアクセスすると、1つまたは複数のノード名、サーバーアドレス、ポート、プロトコル、認証パラメータ、トランスポート設定などを取得し、選択可能な設定へ変換します。汎用エンコードテキストを使うものもあれば、特定のクライアントが認識する構造化形式を返すものもあります。また、リクエスト元のクライアントに応じて異なる内容を返すサービスもあります。
サブスクリプションはプロトコルではありません。1つのサブスクリプションにShadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICのノードを同時に含めることができ、同じプロトコルが異なるサブスクリプションから提供されることもあります。また、サブスクリプションは現在使用中のサーバーそのものでもありません。インポートは設定をクライアントへ書き込む操作であり、実際に接続するにはノードを選択し、クライアントからシステムプロキシ、仮想ネットワークアダプター、またはシステムのネットワーク拡張機能を起動する必要があります。
サブスクリプションURLはアクセス認証情報として扱ってください。URLを入手した人は通常、その中の接続設定を読み取れるため、公開画像、公開ドキュメント、検索エンジンに登録されるページへ載せるのは避けましょう。コピー時は、チャットツールが末尾の文字を切り取っていないか、ブラウザーが特殊文字をエスケープしていないかも確認します。クライアントで形式エラーが表示されたら、まずURLが完全か確認し、次にインポート先が「サブスクリプション」ではなく「単一ノード」になっていないか確かめます。
ブラウザーで開いても文字列しか表示されない理由
サブスクリプションURLは主にクライアントが読み取るためのもので、人が閲覧するWebページとして表示されるとは限りません。ブラウザーにエンコードされたテキストや設定項目が表示されたり、ファイルのダウンロードが始まったりしても、それだけでURLが無効とは判断できません。完全なURLをコピーし、対応クライアントで「URLからインポート」「サブスクリプションを追加」などの項目を選びます。サービスがQRコードを提供している場合も、単一ノードだけでなくサブスクリプションに対応した読み取り入口か確認してください。
- ✅ サブスクリプションURLがアカウント画面または信頼できるサービスページにある
- ✅ コピーした内容に完全なプロトコルヘッダーと後続文字が含まれている
- ✅ インポート入口にサブスクリプション、リモート設定、URLなどの表示がある
- ✅ インポート後に手動で更新し、ノード一覧が表示されることを確認する
- ❌ 公開画像に完全なサブスクリプションURLを載せない
- ❌ 出所の不明なオンライン変換ページへ設定をインポートしない
ノード、出口、回線は同じ概念ではない
ノードはクライアント内の接続項目で、通常は地域、サーバー、プロトコルパラメータで構成されます。出口は、対象サイトから見えるグローバルIPの所在地です。回線は、ローカルから入口へ、さらに出口へ至るデータのネットワーク経路を表します。ノード名に地域が含まれている場合、通常は出口の位置を示していますが、名前だけで途中の通信事業者、中継の有無、夜間の混雑時に経路がどう変化するかまでは判断できません。
ダイレクト接続は、クライアントが海外サーバーの入口へ直接接続する方式です。経路が短く構成もシンプルですが、性能はローカルの通信事業者と対象ネットワーク間の国際相互接続品質に左右されます。中継回線では、近距離または品質の安定した入口へ接続してから、中継ネットワークを通じて出口へ送ります。これにより一部の不適切な公衆ネットワーク経路を避けられますが、転送区間が増えるため、サーバー側の振り分けと入口の品質が重要になります。
IEPL専線は通常、運用事業者が入口と出口の間に構成した国際イーサネット専線リソースを指します。これは伝送経路に関するもので、クライアントのプロトコルではなく、Webサイトから見える暗号化方式と同じものでもありません。クライアントは入口への接続にShadowsocks、Trojanなどのプロトコルを使用できます。専線が現在の用途に適しているかは、ローカルから入口までの経路、出口ネットワーク、対象サイトとの相互接続、実際の時間帯を合わせて判断します。
| 回線タイプ | 経路の特徴 | 優先して確認したい指標 | よくある制約 |
|---|---|---|---|
| ダイレクト接続 | ローカルから海外ノードの入口へ直接アクセスする | ローカル通信事業者のルーティング、混雑、出口との相互接続 | ピーク時は公衆ネットワーク経路の変動を受ける可能性がある |
| 中継 | まず中継入口へ接続し、そこから対象の出口へ転送する | 入口までの距離、転送経路、出口地域 | 入口に異常があると同じグループの複数の出口に影響する |
| IEPL専線 | 入口と出口の間で構成済みの専線伝送リソースを使う | ローカルから入口までの品質、出口との相互接続、振り分け方式 | 「専線」という名前だけで、すべての時間帯の性能を推測することはできない |
ノードは設定の入口、回線は伝送経路、出口は対象サイトから見える位置です。地域を選ぶと「どこからアクセスするか」を、回線を選ぶと「どのように到達するか」を決められます。
ノード一覧の「倍率」「通信量係数」などの項目は通常、通信量の課金方式に関係するもので、速度の倍率ではありません。画面に遅延が表示されていても、それはクライアントから測定先までの応答時間にすぎず、動画の実効速度、Webページの最初の応答、継続的なダウンロード性能を完全に示すものではありません。ノードをテストするときは、同じローカルネットワークと近い時間帯で比較し、対象アプリでの実際の使用感を基準にしてください。
よくあるプロトコル名の意味
プロトコルはクライアントとサーバーがデータを交換する方法を決めますが、速度はプロトコル名に固定された属性ではありません。同じプロトコルでも、サーバー、トランスポート層、回線が異なれば結果は大きく変わります。プロトコルの選択はまずクライアントの対応状況、サーバー設定、現在のネットワーク環境に制約され、その次にカプセル化のオーバーヘッドや輻輳制御方式が関係します。
Shadowsocks、VMess、VLESS
Shadowsocksは暗号化プロキシプロトコルで、設定が比較的わかりやすく、対応クライアントも多い方式です。主にプロキシ転送を担うもので、分流ルールを自動的に決めるわけではありません。アプリの通信を引き受けるかどうかは、クライアントのモードとシステム設定で決まります。暗号化方式を選ぶ際はサーバー側と一致させる必要があり、クライアント側だけで変更してはいけません。
VMessはV2Rayエコシステムのプロトコルで、認証と時刻に関係する検証機構を備え、TCPやWebSocketなどのトランスポート方式と組み合わせて使われることがあります。VLESSはより簡潔な認証設計を採用し、単体ではコンテンツを暗号化しません。実際の構成ではTLS、REALITYなどの安全な伝送方式と組み合わせることが一般的です。VLESS設定を確認するときは、プロトコル、トランスポート方式、安全層、サーバー名を一組のパラメータとして理解してください。どれか1つでも欠けると接続できない場合があります。
Trojan、Hysteria2、TUIC
Trojanは通常TLS上で動作し、一般的な暗号化Webサイトの通信に近い外観になります。正しいサーバー名、証明書、TLS設定が必要で、時刻のずれ、ドメイン解決の異常、証明書の不一致はいずれもハンドシェイク失敗の原因になります。名称に含まれる「Trojan」はプロトコル名であり、クライアントの出所やソフトウェアの動作を示すものではありません。
Hysteria2はQUICとUDPを基盤とし、高遅延で変動しやすいネットワークに適した輻輳制御の考え方を用います。TUICもQUICとUDPを基盤とし、多重化と接続管理を重視します。UDPに対応したネットワークでは良好な伝送性能を示す可能性がありますが、オフィスネットワーク、公衆ネットワーク、一部のルーターではUDPが制限されることがあります。その場合、接続失敗はサブスクリプションの無効化ではなく、基盤ネットワークが該当する通信を通していない可能性もあります。
| プロトコル | 代表的なトランスポート基盤 | 設定で確認するポイント | 接続問題が起きたとき |
|---|---|---|---|
| Shadowsocks | 通常はTCPとUDPを基盤とする | 暗号化方式、パスワード、サーバーパラメータ | 暗号化方式とクライアントの対応状況を確認する |
| VMess | 複数のトランスポート方式を組み合わせられる | 認証パラメータ、トランスポート方式、時刻の同期 | システム時刻とすべてのトランスポート項目を確認する |
| VLESS | TLSまたはREALITYと組み合わせることが多い | 安全層、サーバー名、トランスポートパラメータ | サーバーアドレスとポートだけをコピーしない |
| Trojan | TLS over TCPが一般的 | パスワード、ドメイン、証明書、TLS | 解決結果とサーバー名を確認する |
| Hysteria2 | QUICとUDP | 認証、TLS、UDPの到達性 | ネットワークを切り替えてUDP制限の有無を確認する |
| TUIC | QUICとUDP | 認証、証明書、多重化設定 | クライアントのバージョンが該当設定に対応しているか確認する |
ルーティングルール、グローバルモード、TUNモードの選び方
ルーティングは「この接続をどこへ通すか」を決めるものです。ルールモードでは、ドメイン、IP、アプリ、ポート、ルールセットに応じて、リクエストをプロキシ、直接接続、遮断のいずれかへ振り分けます。グローバルモードでは通常、クライアントが引き受けられる通信をできるだけ現在のプロキシノードへ通します。ダイレクトモードはプロキシを経由しません。これらはルーティングの判断であり、プロトコルの種類ではなく、サブスクリプション内のサーバー設定を変更するものでもありません。
日常の利用では、まずルールモードから始めるのが適しています。ローカルサービス、LAN機器、国際回線を必要としないサイトは直接接続し、指定した出口地域が必要な対象だけをプロキシ経由にします。これにより不要な迂回を減らし、出口地域の変化によって国内サイトで追加認証が発生することも避けられます。ルール漏れで対象へアクセスできない場合は、一時的にグローバルモードへ切り替えて比較します。グローバルでは使えるのにルールモードでは使えないなら、問題は多くの場合、ノードではなくルールの適用やDNS経路にあります。
システムプロキシは通常、OSのプロキシ設定に従うアプリの通信を引き受けます。一部のゲーム、コマンドラインツール、独立したアップデーター、独自ネットワークスタックを使うソフトウェアはシステムプロキシを無視することがあります。TUNモードは仮想ネットワークアダプターを通じてより広いIP通信を引き受けるため、このようなアプリを対象にしたい場合に適しています。ただし、他のネットワーク拡張、ファイアウォール、仮想マシンのネットワーク、企業管理ポリシーと競合しやすくなります。
DNSリークとルーティングの関係
ドメインへアクセスする前に、システムは通常、ドメイン名をIPアドレスへ解決します。Web通信がプロキシを経由していても、DNSリクエストがローカルネットワークへ送られていれば、解決側には検索したドメインが見え、プロキシの出口と一致しない地域の結果が返される可能性があります。この現象はDNSリークと呼ばれることがあります。必ずしも通信断として現れるわけではなく、サイトの地域判定が不自然になる、適切でないアドレスへ解決される、異なるIPを取得したルールが誤った経路を選ぶ、といった結果になることが多いです。
クライアントでよく使われる対処方法には、DNSクエリをプロキシ経由にする、リモート解決を利用する、ドメインルールに応じてリゾルバーを選ぶ、仮想DNSアドレスとTUN転送を組み合わせる方法があります。設定時は「DNSアドレスに何を入力するか」だけでなく、リクエストが実際にどの経路から送られ、どのルールが解決結果を利用するのかも確認してください。ブラウザーの暗号化DNS機能がクライアントの設定を迂回することもあるため、使用するアプリごとに確認が必要です。
プラットフォームごとにクライアントの動作が異なる理由
同じサブスクリプションを異なるプラットフォームへインポートしても、ノード数、プロトコル対応、利用できるモードが完全に一致するとは限りません。通常、原因はサブスクリプションの内容ではなく、クライアントの実装能力の違いです。対応するプロトコルが一部に限られるクライアント、サブスクリプションは認識しても未知の項目を無視するクライアント、TUNや拡張モードの利用にシステム拡張の有効化が必要なクライアントがあります。
iOSとiPadOSでは、クライアントがシステムのネットワーク拡張機能を通じて接続を確立し、初回有効化時にVPN構成の追加を求めます。システムのステータスバーに接続アイコンが表示されても、ネットワーク拡張が起動したことを示すだけです。出口アドレスと対象サイトを使って、ルールが有効か確認する必要があります。システムにはバックグラウンド動作とネットワーク拡張に関する明確な制限があるため、クライアント画面を閉じた後の接続状態は、システム設定とアプリ内ログを基準にしてください。
Windowsクライアントでは、システムプロキシとTUNモードを同時に提供することがよくあります。ブラウザーは使えるのに他のアプリが使えない場合は、まず後者がシステムプロキシに従うか確認します。TUNを有効にした後にLAN、仮想マシン、企業ネットワークで異常が出たら、ルーティングテーブル、DNS、ファイアウォールの競合を確認してください。macOSも考え方は似ていますが、ネットワーク拡張の権限、システムプロキシ、アプリのサンドボックスが具体的な動作に影響します。
Androidは通常、システムVPNインターフェースで通信を引き受け、アプリごとのルーティングを提供することもあります。画面ロック後に接続が切れる場合は、サブスクリプションを何度も再インポートするのではなく、バックグラウンド動作、省電力設定、常時接続VPNの設定を確認してください。メーカーによって設定場所は異なるため、「クライアントプロセスが一時停止した」のか「サーバーへ接続できない」のかを分けて調べます。
インポートから確認までの操作手順
初回設定では、プロトコル、DNS、ルール、システムプロキシを同時に変更しないでください。一度に多くの変数を変えると、問題発生後にどの層が原因か判断しにくくなります。まず最小限の構成で動作させ、その後にルーティングやTUN機能を段階的に追加するのが確実です。
- サブスクリプションを取得：アカウント画面から完全なサブスクリプションURLをコピーし、出所の不明な変換ページは使わない。
- クライアントを選択：クライアントがサブスクリプションで使われているプロトコルに対応し、現在のOSに適合していることを確認する。
- インポートして更新：サブスクリプションまたはリモート設定の入口からインポートし、その後に一度更新してノード一覧が表示されることを確認する。
- ノードを選択：まず目的の出口地域で選び、次にダイレクト接続、中継、IEPL専線のタイプから経路を判断する。
- 基本モードを起動：まずクライアントが推奨するルールモードを使い、ブラウザーから対象ページへアクセスできることを確認する。
- 出口とDNSを確認：出口地域が想定どおりか確認し、ドメイン解決が設定した経路を迂回していないことを確認する。
- 他のアプリも対象にする：アプリがシステムプロキシに従わない場合に限り、TUNまたはアプリ単位の通信引き受けを検討する。
確認時は「接続成功」と「対象が利用可能」を分けて考える必要があります。クライアントにハンドシェイク成功と表示されても、ノードとの接続が確立した可能性を示すだけです。対象サイトはDNS、ルーティング、出口地域、サイト側の状態によってアクセスできないことがあります。逆に、あるWebページが開いても、すべてのアプリが同じ経路を通っているとは限りません。ブラウザー、対象アプリ、システムのネットワーク設定を個別に確認してください。
接続に失敗したときの層別チェック
- ✅ まずサブスクリプションを更新し、ノード設定が古いキャッシュではないことを確認する
- ✅ 次に同じ地域の別ノードへ切り替え、単一ノードの問題かローカルネットワークの問題かを切り分ける
- ✅ システム時刻、サーバー名、TLS、トランスポートパラメータがすべて揃っているか確認する
- ✅ Hysteria2、TUICなどのプロトコルではネットワークを切り替え、UDPの到達性をテストする
- ✅ 一時的にグローバルモードでルールモードと比較し、ルーティング漏れか判断する
- ✅ DNS解決経路を確認し、リモート解決設定を調整する必要があるか判断する
- ❌ 元の設定を記録せず、プロトコル、DNS、動作モードを同時に変更しない
ログにはトップ画面の状態より多くの情報があります。よくある手がかりは、DNS解決失敗、接続タイムアウト、TLSハンドシェイク失敗、認証拒否、ルールによる直接接続、仮想ネットワークアダプターの起動失敗などです。ログを読むときは、まず最初に現れたエラーを確認してください。後続のエラーは、最初の問題による連鎖結果であることが多いためです。ログにサブスクリプションURL、サーバー認証情報、完全な認証パラメータが含まれている場合は、共有前に機密情報を削除してください。