VPN 初心者向け完全ガイド:サブスクリプション、ノード、プロトコル、振り分けをまとめて解説

初めてクライアントを開き、「サブスクリプション・ノード・プロトコル・振り分け」という言葉を前にして、多くの人はまず手が止まります。それぞれが何を担っていて、つながらないときはどれを直せばいいのか。この VPN 初心者向け完全ガイドでは、外側から内側へ順に、各用語を本来の位置に戻して説明します。サブスクリプションは受け取るノードを決め、ノードは通信がどの出口から出ていくかを決め、プロトコルはその通信がどんな形でネットワークを通過するかを決め、振り分けはどの通信をプロキシ経由にし、どれを直接接続にするかを決めます。

以下の各節は「それは何か → 何に影響するか → 初心者がつまずきやすい点」の順で書いています。読み終えるころには、クライアントの各設定項目を理解し、問題が起きたときにどの層から確認すべきか分かるはずです。パラメータを端から端まで書き換える必要はありません。

サブスクリプションリンク:ノード一覧への入り口

サブスクリプションリンクは、サービス提供元が発行する http/https のアドレスです。クライアントがこれをリクエストすると設定ファイルが返ってきます。よくある形式は2つ。ひとつは base64 でエンコードされたノード一覧で、各行が ss://、vmess://、trojan:// で始まる URI です。もうひとつは Clash や sing-box などのクライアントが直接読み込む YAML または JSON で、ノードに加えてルールセットやポリシーグループも含まれます。

これが解決する中心的な課題は同期です。ノードは追加・削除され、アドレスが変わり、パラメータも調整されます。手作業で1つずつ入力するのは遅いうえ、書き間違えも起きやすい。サブスクリプションはこの作業を「更新」1回にまとめてくれます。クライアントは通常、起動時と一定間隔で自動的に取得し、設定画面から手動で更新することもできます。

# サブスクリプションリンクが返す設定の抜粋(イメージ)
proxies:
  - name: "香港-01"
    type: ss
    server: hk01.example.com
    port: 443
    cipher: chacha20-ietf-poly1305
    password: "******"
  - name: "日本-02"
    type: trojan
    server: jp02.example.com
    port: 443
    sni: jp02.example.com
    password: "******"

区別しておきたいのは、サブスクリプションリンクそのものが一種の認証情報だという点です。手に入れた人はあなたのノードをインポートでき、あなたの通信量を消費できます。ですからサブスクリプションのアドレスを公開グループや掲示板に貼ったり、スクリーンショットに写したりしないでください。

もうひとつのよくある誤解:サブスクリプションの更新で同期されるのはサーバー側のノードの変化であり、ローカルで編集したルールやポリシーグループを上書きするものではありません(挙動はクライアントによって多少異なります)。設定を手で変更した場合は、更新前にその変更が上書きされないか確認しましょう。

ノードと回線:直接接続・中継・専用線の違い

ノードは設定ファイル内の1レコードです。サーバーアドレス、ポート、プロトコルのパラメータ一式で構成されます。ノードを選ぶというのは、実質的に「通信がどの出口から出ていくか」を選ぶことです。出口の地域は一部のサービスから見た位置を決め、出口の回線はその接続が安定しているかどうかを決めます。

回線タイプが表すのは出口がどこかではなく、あなたから出口までの間を通信がどう通るかです。ここは初心者が最も見落としやすく、それでいて体感に最も影響する層で、よくあるのは次の3種類です。

直接接続

クライアントがサーバーの公開アドレスに直接接続します。経路は最短でコストも最も低い方式です。代わりにこの経路は公共の国際回線を通るため、夜のピーク時間には他の通信と一緒に順番待ちになり、混雑やジッターがそのまま体感に表れます。

中継

通信はいったん中継サーバーに届き、そこから出口ノードへ転送される2ホップ構成です。1ホップ増える分のオーバーヘッドはありますが、中継は最適化された国際ルートを使うことが多く、経路を制御しやすいため、全体として直接接続より安定します。多くのサブスクリプションで主力となる回線です。

IEPL 専用線

専用線の考え方は、通信をポイントツーポイントの専用回線に載せ、他の公衆網トラフィックと帯域を共有しないというものです。強みはジッターやパケットロスを抑えやすく、夜のピーク時間でも平常時に近い性能が出ること。代わりにコストが高く、通常は安定性が重視される用途に使われます。

また、クライアントの「ポリシーグループ」を使うと、複数のノードをひとつのグループにまとめ、速度テストの結果に応じて自動選択したり、手動で指定したり、順番に切り替えたりできます。ノードは資源、ポリシーグループはその資源の使い方であり、この2つは混同しないようにしましょう。

よく使われるプロトコル:Shadowsocks から Hysteria2 まで

プロトコルは、クライアントとサーバーがどうハンドシェイクし、どう暗号化し、その通信がネットワーク上で何のように見えるかを決めます。出口の位置には影響しませんが、接続性と速度には直接影響します。同じサーバーで複数のプロトコルの入口を同時に開放でき、サブスクリプションではそれぞれ別に表示されます。

振り分けと3つのモード:ルール・グローバル・直接接続

振り分け(ルーティングとも呼ばれます)は、ある通信をプロキシ経由にするか直接接続にするかを決めます。クライアントはルール表を順に照合し、主な照合項目はドメインとドメインサフィックス、IP レンジと GeoIP の所属、プロセス名、ポートです。ルール表は通常3つに分かれます。プロキシ経由にしたいもの、直接接続にしたいもの、ブロックしたいものです。

クライアントは一般に3つのモードを用意しており、違いは「既定でどう扱うか」だけです。

1. ルールモード:ルール表に従って照合し、プロキシに該当するものはプロキシ経由、直接接続に該当するものは直接接続、それ以外は既定の出口を使います。普段はこれを選びましょう。
2. グローバルモード:すべての通信をプロキシ出口に送ります。ルール表の直接接続項目が有効なままかどうかはクライアントによります。「問題が振り分けルールにあるのかどうか」を一時的に切り分けるのに向いています。
3. 直接接続モード:すべての通信をプロキシ経由にせず、クライアントはローカル DNS とルールエンジンだけを維持します。プロキシが不要なネットワークで一時的に止めたいときに便利です。

振り分けがうまく設定できていないときの典型的な症状は3つあります。日本国内のサイトがかえって遅くなる(通信が海外へ回ってから戻ってくる)、LAN 内の機器(プリンター、画面ミラーリング、NAS)が見つからない、一部アプリのログインや決済が失敗する。こうした場合は、まずモードがグローバルに切り替わっていないか確認しましょう。

DNS と振り分けの関係

振り分けでは「このドメインをプロキシ経由にすべきか」を判断するために、まずドメインを解決する必要があります。解決がローカルで行われると、問い合わせ内容がローカルネットワークに露出します。これがよく言われる DNS リークです。より多く起きるのは、解決結果と回線がかみ合わないケースで、海外の出口を使っているのに国内 CDN のアドレスが返ってきてしまい、速度が上がらないというものです。

現在のクライアントの多くは、fake-ip やリモート解決でこの問題に対処しています。プロキシが必要なドメインはリモート DNS で解決し、直接接続するドメインはローカル DNS を使い続けます。多くの場合、既定のままで問題ありません。「開けるけれど遅い」「一部のサイトだけ開けない」といった症状が出たときに、DNS 設定を見直せば十分です。

クライアントとプラットフォームの違い:システムプロキシ、TUN、アプリ単位の振り分け

同じサブスクリプションでも、プラットフォームによって使い方は同じではありません。違いは主に2点から来ます。通信をどうやって引き受けるか、そしてアプリ単位の振り分けができるかどうかです。

引き受け方:システムプロキシと TUN

システムプロキシは「システムのプロキシ設定に従う」アプリにだけ効きます。ブラウザやほとんどのデスクトップソフトは従いますが、一部のゲームやターミナルツール、独自のネットワークスタックを持つアプリは従いません。TUN モードは仮想ネットワークアダプタを作成し、ネットワーク層で通信を引き受けるため、より広い範囲をカバーできます。代わりに高いシステム権限が必要で、他の仮想アダプタと競合しやすくなります。

プラットフォームごとの違い

• Windows:クライアントの選択肢が最も多く、主要なクライアントはシステムプロキシと TUN に対応しています。TUN が一部のセキュリティソフトの仮想アダプタドライバと競合することがある点に注意してください。
• macOS:こちらもシステムプロキシと TUN(utun)に対応し、設定は比較的すっきりしています。初めて TUN を有効にすると権限の確認が出ます。
• Android:システムの VpnService 経由で引き受け、どのアプリをプロキシ経由にするかをアプリ単位で選べます。各プラットフォームの中で最も細かい振り分けが可能です。
• iOS:VPN プロファイルで全体を引き受けるため、通常はアプリ単位の振り分けができず、ルール表に頼るしかありません。iOS ではルールの質がより重要になる理由でもあります。

切り分けの手順と5つのよくある誤解

接続に問題が出たとき、最も時間を節約できるのはパラメータを手当たり次第に変えることではなく、層ごとに切り分けることです。おすすめの順序は、まず端末の時刻が同期しているか確認し、次にクライアントがルールモードになっているか確認し、それからノードを変え、最後にプロトコルの変更を検討する、という流れです。この順序は「最も検証しやすい層から始める」ことに対応しています。

• ✅ サブスクリプションリンクは自分の端末にだけインポートし、公開グループへ転送したりスクリーンショットで共有したりしない
• ✅ つながらないときは「時刻同期 → モード確認 → ノード変更 → プロトコル変更」の順で切り分け、各手順で変えるのは1つだけ
• ✅ サブスクリプションを更新する前に、ローカルで変更したルールやポリシーグループが上書きされないか確認する
• ❌ ノードのアドレス、ポート、パスワードを手で書き写して1つずつ入力する。サブスクリプションを更新してもこれらの設定は追随しない
• ❌ グローバルモードを常時オンにしておく。ローカルサービスや LAN 内の機器までプロキシ経由になり、故障の範囲が広がる
• ❌ システム時刻が正確でない端末で VMess を使う。ハンドシェイクはサーバー側でそのまま拒否される

これらの用語を、実際の選択に落とし込む

ここまでの内容をつなげると、サブスクリプションサービスを選ぶときに本当に確認すべきことは、実はわずかです。回線タイプが自分の用途をカバーしているか、プロトコルが自分のクライアントで対応しているか、サブスクリプションの更新が手軽か、そして合わなかったときに返金できるか。

VPNWY を例にすると、110+ の国と地域、150+ の回線をカバーし、サブスクリプションは台数無制限、登録にメールアドレスは不要、初回のお支払いから 30日以内なら理由を問わず全額返金を申請できます。月額プランとトラフィックパックの価格はプランページに記載しているので、ここでは繰り返しません。

よくある質問3つ