VPN初心者向け完全ガイド：サブスクリプション、ノード、プロトコル、ルーティング

このVPN初心者向け完全ガイドでは、クライアントでよく目にする「サブスクリプション、ノード、プロトコル、ルーティング」から解説します。ネットワークの予備知識は必要ありません。まず設定の入手元と通信経路を整理し、そのうえでどの通信を国際回線へ送るかを判断するのが基本です。概念を理解すれば、インポート失敗、ノードには接続できるのにページが開かない、国内サイトだけ遅いといった問題も、設定をむやみに切り替えず順番に確認できます。

サブスクリプションリンク、設定ファイル、ノードとは

サブスクリプションリンクは、クライアントが設定を読み込むためのアドレスです。クライアントがこのアドレスへアクセスすると、サービス側が公開するノード名、サーバーアドレス、ポート、プロトコルパラメーター、グループ情報を取得します。提供側が接続先やパラメーターを調整した場合も、通常はクライアントでサブスクリプションを更新するだけで済み、項目を一つずつ入力し直す必要はありません。

サブスクリプションリンクは、普段の閲覧に使う一般的なウェブページではありません。アカウント設定に紐づく認証情報を含む場合があるため、フォーラムや速度測定ページ、スクリーンショットに公開したり、出所の不明なオンライン変換ツールへ渡したりしないでください。クライアント間で形式を変換する必要がある場合は、提供側の互換形式を使うか、信頼できる環境で作業しましょう。

設定ファイルはサブスクリプションリンクと似た役割を持ちますが、更新方法が異なります。静的な設定ファイルには書き出した時点の内容が保存されます。一方、サブスクリプションリンクではクライアントがサーバーから最新設定を再取得できます。ノード名が更新されたのにクライアントに古い一覧が表示される場合は、まず「サブスクリプションを更新」を実行し、次にローカルキャッシュを確認してください。回線が使えないとすぐ判断するのは禁物です。

ノードは通常、クライアントから選択できる接続先の入口を指します。名前には地域、都市、回線タイプ、用途のラベルが含まれることがありますが、名前だけで完全な経路が分かるわけではありません。同じ地域名のノードでも、直接接続、中継、専用回線など構成が異なる場合があります。また同じ入口でも、利用する通信事業者、接続ネットワーク、アクセス先によって体感は変わります。

サブスクリプションをインポートする基本手順

1. サービスパネルから、現在のクライアントに対応したサブスクリプションリンクをコピーします。文字を手動で削除・変更しないでください。
2. クライアントで「サブスクリプション」「設定ソース」「リモート設定」などの項目を探し、リンクを追加して保存します。
3. 一度更新を実行し、一覧にサブスクリプション名だけでなくノードやプロキシグループが表示されることを確認します。
4. アクセス先のコンテンツに近い地域のノードを選び、システムプロキシまたはトンネルモードを有効にします。
5. アクセス先のウェブサイトを開いて確認します。失敗した場合は、サブスクリプションの更新時刻、プロトコルの互換性、システムプロキシの状態、DNS設定を順番に確認してください。

直接接続、中継、IEPL専用回線の違い

ノードはユーザーに見える入口であり、回線はローカルから入口まで、または入口から対象ネットワークまでのデータ経路を示します。回線ラベルは候補を絞るのに役立ちますが、実際の品質はローカルネットワーク、出口の混雑、接続先との相互接続、クライアントのプロトコルにも左右されます。選ぶ際は「ノードの地域」と「回線タイプ」を分けて考えましょう。

直接接続だから必ず速いとは限りません。ローカルから海外の入口までの公衆ネットワークが安定していれば、直接接続は転送工程を減らせます。一方、ネットワーク間の相互接続が不安定なら、中継によってより適切な入口へ経路を改善できる場合があります。IEPLは国際イーサネット専用回線を指す業界用語ですが、専用回線の入口、出口、その後の経路設計はサービスごとに異なります。名称だけで全通信が同じ方式で運ばれると判断しないでください。

初心者が回線を選ぶときは、まずコンテンツの対象地域で絞り、次に回線タイプを比較するとよいでしょう。たとえば日本向けのコンテンツへアクセスするなら、地理的に自分に最も近いノードではなく、日本を終端地域とする入口を優先して確認します。日常の文書作成、コードリポジトリ、ウェブ閲覧では、接続の安定性とドメイン解決が正常かどうかを重視しましょう。

Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC

プロトコルは、クライアントとサーバーが接続を確立し、認証し、データをカプセル化し、転送方式を選ぶ方法を定めます。プロトコル名だけでノードの地域が分かるわけでも、速度が保証されるわけでもありません。サーバー側が同じプロトコルに対応し、クライアントも対応する転送方式とセキュリティパラメーターを正しく実装して初めて接続が確立します。

Shadowsocks

Shadowsocksは暗号化プロキシプロトコルで、設定には通常、サーバー、ポート、暗号化方式、パスワードが含まれます。従来型のシステムVPNというよりプロキシに近く、すべてのアプリを対象にできるかは、クライアントがシステムプロキシ、仮想ネットワークインターフェース、透過プロキシに対応しているかによります。ブラウザーは使えるのに他のアプリが使えない場合は、ノードだけでなくクライアントの通信取り込みモードを確認してください。

VMessとVLESS

VMessはV2Rayエコシステムで広く使われるプロトコルで、認証とプロトコル層の処理を含みます。システム時刻が大きくずれている場合などの影響を受けやすい点に注意が必要です。VLESSはより簡潔な認証とデータ構造を採用し、単体で完全な転送暗号化を提供するものではありません。通常はTLS、REALITY、その他の対応する安全な転送方式と組み合わせます。インポート時はサーバーアドレスだけでなく、転送タイプ、ホスト名、パス、セキュリティ層、認証識別子などのパラメーターも保持してください。

Trojan

Trojanは通常、TLS接続上に構築され、設定にはサーバー名、証明書の検証、パスワードが関係します。クライアントの時刻、サーバー名、証明書検証パラメーターが一致しないと、TLSハンドシェイクの段階で接続に失敗することがあります。証明書検証を無効にするのは一般的な解決策ではありません。サブスクリプションが完全か、システム時刻が正しいか、クライアントが設定内の転送方式に対応しているかを確認しましょう。

Hysteria2とTUIC

Hysteria2とTUICはいずれもUDPベースのQUIC技術を活用し、パケットロスや揺らぎのあるネットワークでの転送体験の改善と、並列データストリームに重点を置いています。ただし、すべてのネットワークで速くなるわけではありません。オフィスネットワーク、公衆ネットワーク、ルーターによってはUDPが制限され、ハンドシェイクの失敗、接続直後の切断、少量のデータしか転送できないといった問題が起こります。その場合は、関係のないルーティングルールを変更し続けるのではなく、TCPとTLSベースの互換ノードへ切り替えて比較してください。

初心者にとって最も無難な選び方は、プロトコル名を追いかけることではなく、サービス側が標準で提供し、利用中のクライアントが完全に対応している設定を使うことです。複数のプロトコルを選べる場合は、現在のネットワークがUDPを許可しているか、システム全体を取り込む必要があるか、対象アプリが安定するかを基準に比較しましょう。

システムプロキシ、TUNモード、VPNモードの違い

デスクトップクライアントで一般的な「システムプロキシ」は、OSのプロキシ設定を変更し、その設定に従うアプリのHTTPまたはSOCKSリクエストをローカルクライアントへ送ります。ブラウザーは通常システムプロキシを利用できますが、一部のゲーム、コマンドラインプログラム、独自のネットワーク処理を行うアプリは無視することがあります。「ブラウザーは使えるが、他のソフトは直接接続する」という場合は、取り込み範囲の問題であることが多いです。

TUNモードは仮想ネットワークインターフェースを作成し、システムルーティングを通じてより多くの種類のIP通信をクライアントへ送り、ルールに従って処理します。対象範囲が広い一方、ルートの競合、権限、ファイアウォール、他のネットワークツールの影響を受けやすくなります。有効にした後、ローカルプリンター、LAN機器、社内ネットワークへアクセスできなくなった場合は、すべてのプライベートアドレスをリモートへ送るのではなく、LANのバイパスルールを確認してください。

モバイルプラットフォームでは、通常OSが提供するVPNインターフェースを使って通信を取り込みます。ステータスバーにVPNマークが表示されても、すべてのドメインがリモートノードを経由しているとは限りません。クライアントがルールに従って一部の通信を直接接続にすることもあります。これはルールモードでは正常な動作です。

• ブラウザーだけ使える：システムプロキシとアプリ独自のプロキシ設定を確認します。
• すべてのアプリでアクセスできない：ノード接続、トンネル権限、デフォルトルート、DNSを確認します。
• LAN機器にアクセスできない：プライベートネットワークのバイパス設定とルート競合を確認します。
• 別のネットワークでは復旧する：元のネットワークによるUDP、プロキシポート、特定の転送方式への制限を確認します。

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

グローバルモードは通常、クライアントが取り込んだ通信をすべて現在のプロキシノードへ送る方式です。ルールモードでアクセスできないときに、問題がルーティングルールにあるかを一時的に確認する用途に適しています。グローバルモードでアクセスできるなら、プロトコルではなくドメインの一致、ルールの優先順位、DNS解決を重点的に確認しましょう。

グローバルモードは、あらゆる場面の標準設定に向いているわけではありません。国内サイト、LANサービス、接続元地域に敏感なアプリまでリモートへ送られ、経路の迂回、ログイン環境の変化、ローカルリソースへのアクセス不能を招くことがあります。また「グローバル」は、クライアントが正常に取り込めた通信だけを対象とします。システムプロキシやトンネルの制御対象外のプログラムは、引き続き直接接続する場合があります。

ルールモードは、ドメイン、IP、アプリのプロセス、ルールセットに基づいて、通信をプロキシ、直接接続、拒否のいずれにするか決めます。一般的には、ローカルサービスとLANは直接接続し、国際アクセスが必要なドメインはプロキシへ送ります。ルールは通常、上から順に照合されます。範囲の広いルールを先に置くと、後続の具体的なルールが隠れてしまうことがあります。

直接接続モードは、通信をリモートプロキシへ通さない方式です。プロキシを一時停止したいとき、LANリソースへアクセスしたいとき、ローカルネットワークが正常か確認したいときに使います。直接接続でもローカルから開けるサイトが開かないなら、問題はノードではなく基礎ネットワーク、ブラウザーキャッシュ、ローカルDNSにある可能性があります。

実用的な選択手順

1. 初回インポート後はルールモードを使い、コンテンツの対象地域に合うノードを選びます。
2. アクセスに失敗したら、短時間だけグローバルモードへ切り替え、ルール漏れかどうかを確認します。
3. グローバルモードでも失敗する場合は、ノード接続、プロトコル互換性、システム時刻、DNSを確認します。
4. ローカルサービスに異常がある場合は、直接接続へ切り替えて比較し、LANのバイパスルールも確認します。
5. 原因を確認したらルールモードへ戻し、必要なドメインまたはアプリのルールだけを修正します。

DNSリークとは？「接続できるのに開けない」理由

ユーザーがドメインを入力すると、システムはまずDNSで対応するアドレスを検索します。ウェブ通信はプロキシに入っているのに、DNSクエリだけがローカルネットワーク指定のリゾルバーへ送られると、ローカルの解析事業者に検索したドメインを見られる可能性があります。これが一般にDNSリークと呼ばれる状態です。また、解析結果とプロキシ出口の地域が一致せず、対象サイトが誤ったアドレスや地域ページを返したり、接続に失敗したりすることもあります。

DNSリークは、1つのテストページだけで判断しないでください。ブラウザーが独自の暗号化DNSを使っている場合や、OSがキャッシュを保持している場合があります。クライアントがドメインごとに異なるリゾルバーを使うこともあります。正しく確認するには、まず現在の取り込みモードを明確にし、次にクライアントのDNS設定とルーティングの仕組みを確認します。

DNSの確認手順

1. クライアントでリモートDNS、プロキシDNS、またはトンネルが管理する名前解決機能を有効にしているか確認します。
2. ルールモードで、IPとの照合前にドメインを解決しているか確認します。処理順序はクライアントによって異なります。
3. OSとブラウザーのDNSキャッシュを消去してからノードへ再接続し、古い結果の影響を避けます。
4. ブラウザー独自の暗号化DNSを一時的に無効にして比較し、DNSリクエストをどの機能が送っているか確認します。
5. TUNを有効にした後、まったく名前解決できなくなった場合は、仮想インターフェースのDNS、システムファイアウォール、他のネットワークツールの競合を確認します。

DNSが正常にアドレスを返しても、接続に失敗することがあります。その場合は、対象通信が本当にプロキシルールに一致しているか、ノードが対応するネットワークタイプをサポートしているか、IPv6通信がIPv4だけを処理する設定を迂回していないかを確認します。クライアントが両方のアドレス種別を完全に取り込めないと、同じサイトが開いたり開かなかったりすることがあります。

ルーティングルールでドメインとアプリを照合する方法

ルーティングルールには通常、ドメイン、ドメインサフィックス、IPサブネット、地域ルール、アプリのプロセス、最終フォールバックルールが含まれます。ドメインサフィックスルールはサイトとサブドメインをまとめて対象にできますが、大規模なサービスはコンテンツ配信、ログイン、画像、APIなど別のドメインにも依存します。トップページのドメインだけを追加すると、ページの枠組みは表示されても内容の読み込みに失敗することがあります。

ルールの順序も重要です。クライアントは通常、上から順に最初に一致する項目を探します。「すべてのドメインを直接接続」のような範囲の広いルールが前にあると、後ろの具体的なプロキシルールは機能しません。前の条件に一致しなかった通信を処理する最終ルールをプロキシにするか直接接続にするかで、全体の挙動は大きく変わります。

IPルールには、クライアントが先に対象アドレスを取得するという前提があります。DNS検索がローカルで行われると、ドメインがプロキシ出口と合わないアドレスへ解決される可能性があります。リモートDNSを使う場合は、結果が異なることもあります。地域による振り分けに依存するサイトでは、ドメインルールを優先した方が理解しやすく、管理もしやすいでしょう。

LANとローカルサービス → 直接接続
国際アクセスが必要なドメイン → プロキシ
ローカル出口を維持する必要があるアプリ → 直接接続
一致しない通信 → 現在の用途に合わせてフォールバック方針を選択

上記の順序は論理的な例であり、そのままインポートできる設定ではありません。クライアントによってYAML、JSON、GUIルール、専用構文などを使い、フィールド名も異なります。ルールをコピーする前にクライアントのドキュメントを確認し、特にドメインサフィックス、完全修飾ドメイン名、キーワード照合の違いに注意してください。

Windows、macOS、Android、iOS、Linuxのクライアントの違い

同じサブスクリプションでも、プラットフォームによって表示される項目が完全に同じとは限りません。多くの場合、ノードが変わったのではなく、OSが提供するネットワークインターフェース、バックグラウンド制限、クライアントの実装が異なることが原因です。プラットフォームを移行する際は、プロトコルと転送方式が対応しているか確認し、クライアント名だけで比較しないでください。

Windowsクライアントでは、システムプロキシとTUNモードを同時に利用できることが多いです。TUNには仮想ネットワークアダプター用のドライバーと適切な権限が必要な場合があり、企業のセキュリティポリシーによってドライバーのインストールが制限されることもあります。クライアント終了後もシステムがインターネットに接続できない場合は、システムプロキシが正しく元に戻っているか確認します。

macOSでは通常、ネットワーク拡張を使ってトンネルを構築し、初回有効化時に関連するシステム権限の承認が必要です。システムプロキシとネットワーク拡張は別々の機能で制御される場合があります。メニューバーに接続済みと表示されても、現在どの取り込みモードが有効か確認してください。他のファイアウォールやネットワークフィルター拡張がルーティングやDNSに影響することもあります。

Androidクライアントは通常、システムのVPNServiceインターフェースを利用し、アプリ単位のルーティングに対応する場合があります。バッテリー最適化やバックグラウンド制限により、画面ロック後にクライアントプロセスが停止し、接続マークは表示されたままデータ転送だけが続かなくなることがあります。長時間接続を維持する場合は、そのクライアントのバックグラウンド実行ポリシーを確認してください。

iOSクライアントはシステムのネットワーク拡張を通じて動作し、利用できるプロトコルはクライアントの実装とシステム権限によって決まります。サブスクリプション内の転送方式にクライアントが対応していない場合、無視されたり利用不可と表示されたりすることがあります。インポート前にクライアントの対応一覧を確認し、認識できないフィールドを手動で削除して接続を続けるのは避けてください。

Linuxでは、ディストリビューション、デスクトップ環境、ルーティングツール、DNS管理コンポーネントによる違いが大きくなります。コマンドラインプロキシは、プロキシ環境変数を明示的に使うプログラムにしか影響しません。他のアプリも取り込むには、通常TUN、ポリシールーティング、透過プロキシなどの設定が必要です。確認時は、インターフェース、ルーティングテーブル、DNS管理、ファイアウォールルールを分けて調べましょう。

接続異常を確認する順番

プロトコル、ノード、DNS、ルーティング、システムプロキシを同時に変更すると、原因の特定が難しくなります。より効果的なのは、一度に1つの変数だけを変更し、どの手順で結果が変わったか記録する方法です。以下では、設定の入手元から始め、アプリ側まで段階的に確認します。

1. サブスクリプションを確認：リンクが途中で切れていないか、更新操作に明確な成功表示があるか、ノード一覧が古いキャッシュではないか確認します。
2. クライアントの互換性を確認：現在のプロトコル、転送方式、セキュリティパラメーターにクライアントが対応しているか確認します。
3. ノード接続を確認：DNS、TCP、UDP、TLS、認証のどの段階でエラーが発生しているか確認します。
4. 取り込み方式を確認：対象アプリがシステムプロキシに従っているか、またはTUNやシステムVPNインターフェースに取り込まれているか確認します。
5. ルーティングを確認：一時的にグローバルモードを使って比較し、ドメインが誤って直接接続に割り当てられていないか判断します。
6. DNSを確認：キャッシュを消去し、リモートDNSとブラウザー独自のDNS設定を確認します。
7. ローカル環境を確認：ファイアウォール、他のVPN、ネットワークフィルター拡張、企業ポリシーの競合を切り分けます。
8. ネットワークを変えて比較：同じ設定が別のネットワークで使える場合は、元のネットワークによるUDPとルーティングの制限を重点的に確認します。

クライアントのログは「接続できない」という説明より有用です。ただし共有する前に、サブスクリプションリンク、認証情報、サーバーの認証情報、ローカルファイルパスを削除してください。サポートへは、プラットフォーム、クライアントのバージョン、取り込みモード、ノードのプロトコル、エラーが発生した段階、実施済みの比較テストを伝えると、画面のスクリーンショットを何枚も送るより原因を特定しやすくなります。