サブスクリプションリンクとは？初心者向けに取得・インポート・更新・漏えい時の対処法を解説

サブスクリプションリンクとは、サブスクリプションサービスが発行し、対応クライアントが読み込む設定用URLです。クライアントがこのURLにアクセスすると、接続先名、サーバーアドレス、ポート、プロトコル設定、グループ情報などを取得し、選択・接続できるリストに整理します。ノードを1つずつコピーする必要はありませんが、このURLは通常のWebリンクではなく、アカウントの認証情報として管理してください。

サブスクリプションリンク自体がネットワーク接続を確立するわけではありません。実際のハンドシェイク、暗号化、ルーティング、DNS処理を担うのはクライアントと、購読内容に記載された Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC などのプロトコルです。この違いを理解すると、ブラウザでURLを開けてもクライアントが対応するとは限らないこと、インポートに成功してもシステムの通信が想定どおり経路に入るとは限らないことが分かります。

サブスクリプションリンクに含まれる情報

表面上、サブスクリプションリンクは HTTPS で始まる文字列にすぎません。しかしクライアントから見ると、更新可能な設定取得口です。クライアントがこのURLへリクエストを送り、サーバーは契約状態に応じて接続先の集合を返します。返却形式はエンコードされたノード一覧の場合もあれば、YAML、JSON、または特定クライアント専用の設定の場合もあります。形式は自動的に互換となるわけではないため、同じサービスでもクライアントごとに異なる取得先が用意されることがあります。

単一ノードのリンクとサブスクリプションリンクも別物です。ss://、vmess://、trojan://、vless://、hysteria2://、tuic:// で始まる内容は、通常1つの接続先を示します。一方、サブスクリプションURLは複数の接続先をまとめて返し、サービス側の変更後にクライアントが再取得できるようにします。複数の単一ノードリンクをまとめてエンコードする形式もあれば、完全なポリシー設定を直接提供する形式もあります。

内容の種類	主な用途	更新方法	注意点
単一ノードリンク	指定した1つの接続先をインポート	通常は再取得してインポートが必要	接続先全体は含まれない
汎用サブスクリプション	対応クライアントに接続先一覧を提供	クライアントがサブスクリプションを再取得	ルーティングルールはクライアント側で別途管理する場合がある
クライアント専用サブスクリプション	接続先、グループ、ポリシー設定を提供	対応クライアントから更新	別のクライアントにインポートすると形式が合わない場合がある
ローカル設定ファイル	インポート後の設定や手動ルールを保存	ユーザーがローカルで管理	サービス側の変更は自動取得されない

プロトコルと接続回線の種類も分けて考える必要があります。Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC は通信方式とそのパラメータを示します。一方、IEPL 専線、中継、ダイレクト接続は、通信が海外の出口へどのように到達するかを主に示します。IEPL 専線は通常、通信事業者の専用回線リソースで国際区間を運びます。中継回線は中間の入口を経由して出口へ転送し、ダイレクト接続はローカルネットワークから海外サーバーへ直接アクセスします。サブスクリプションリンクにはこれら異なる種類の回線を同時に登録できますが、ルーティング、混雑時の挙動、適した用途の違いがなくなるわけではありません。

判断のポイント：サブスクリプションリンクは設定の取得口であり、プロトコル名でも特定の固定回線でもありません。問題を切り分ける際は、サブスクリプション形式、クライアントの互換性、ノードのプロトコル、実際のルーティングをそれぞれ確認してください。

管理画面から取得して安全に保存

サブスクリプションリンクは、ログイン後のサービス管理画面からダウンロードまたはサブスクリプションの項目へ進み、現在のクライアントに合う形式を選んでコピーしてください。検索結果、チャットで転送されたURL、他人から渡された短縮URLには頼らないでください。VPNGP はユーザー名とパスワードだけで利用を開始でき、メールアドレスは不要です。自分の管理画面から取得したリンクだけが、現在の契約に対応します。

管理画面に「汎用サブスクリプション」と特定クライアント専用の設定が両方表示される場合は、クライアントの説明で対応が明記されている形式を優先してください。専用設定にはポリシーグループ、DNS設定、ルールプロバイダーが含まれる場合があります。汎用サブスクリプションは移行しやすい一方、ノードだけを含むことがあります。専用形式の拡張子を別のものに変更しても、形式は変換されません。

✅ 自分の VPNGP 管理画面から取得したURLであることと、選択中のクライアント形式を確認する。
✅ クライアント内の「URLからインポート」または「サブスクリプションを追加」を優先し、パラメータを手作業で分解しない。
✅ 取得元が分かるローカル名をサブスクリプションに付け、更新時の選択ミスを防ぐ。
✅ インポート後は、一時テキスト、共有クリップボード、完全なURLを含むスクリーンショットを削除する。
❌ サブスクリプションURLを通常のダウンロードリンクとして他人に転送しない。
❌ 出所の分からないオンライン変換ツールに完全なサブスクリプションURLを入力しない。

HTTPS は通信中の内容が通常の平文として読み取られるのを防ぎますが、URLを公開してよいという意味ではありません。完全なトークンが有効な間は、リンクを入手した人が設定を読み取れる可能性があります。ブラウザの履歴、クラウドクリップボード、端末のコマンド履歴、自動同期されるメモは、漏えい範囲を広げることがあります。管理画面から信頼できるクライアントへ直接コピーし、完了後に中間コピーを削除する方法がより安全です。

5つのプラットフォームへのインポート方法

プラットフォームによってボタン名は異なりますが、基本の流れは同じです。対応クライアントを選び、リモートサブスクリプションを追加し、URLを貼り付けて保存・更新した後、接続先を選んで接続します。インポート後は、システムプロキシ、仮想ネットワークインターフェース、ルーティングモードも確認してください。ノード名が表示されただけでは、ネットワーク通信が想定どおり制御されているとは限りません。

Windows

Windows クライアントでサブスクリプション管理または設定管理を開き、URLから追加する項目を選んでURLを貼り付け、更新を実行します。その後、直前にインポートした設定が有効になっていることを確認し、必要に応じてシステムプロキシまたは TUN モードを有効にします。システムプロキシはプロキシ設定に従うアプリを主に制御します。TUN モードは仮想ネットワークインターフェースを通じてより多くの通信を処理できますが、高い権限が必要になる場合があり、他のネットワークフィルタリングソフトとルーティングが競合しやすくなります。

ブラウザではアクセスできるのに特定のデスクトップアプリだけ通信できない場合は、まずそのアプリがシステムプロキシを無視していないか確認してください。サブスクリプションを何度も削除するのではなく、クライアントのモード、バイパスリスト、システムルートを確認します。モードを切り替えて再テストすれば、ノードの問題とローカル側の通信制御の問題を切り分けられます。

macOS

macOS のインポート方法は Windows と近く、リモート設定またはサブスクリプションの項目からURLを追加します。保存後は、クライアントが必要とするネットワーク設定の作成を許可し、メニューバーの状態とクライアント内で選択したポリシーが一致していることを確認してください。システムプロキシに従うアプリもあれば、仮想ネットワークインターフェースが必要な通信もあります。そのため、「クライアントは接続済み」と「すべてのアプリの通信が回線を通る」は別々に判断する必要があります。

システム更新やクライアントのアップグレード後にネットワーク拡張の権限が取り消されると、既存のサブスクリプションは残っていても接続できないことがあります。この場合は、サブスクリプションをすぐにリセットせず、まずシステム権限と拡張機能の状態を確認してください。

Android

Android クライアントには通常、クリップボードからのインポート、URLからの追加、QRコードの読み取り機能があります。追加後は先にサブスクリプションを更新し、ノードを選んで VPN 接続の作成を許可します。アプリごとのプロキシが必要な場合は、どのアプリを回線経由にし、どれをダイレクト接続にするかを明確に選んでください。アプリ一覧を変更した後は、ルールが実際の用途に合っているか再確認します。

バックグラウンドの省電力設定によってクライアントのプロセスが停止し、アプリを切り替えると接続が切れたり、システムがネットワークを再構築したりすることがあります。この場合は、クライアントのバックグラウンド実行権限とシステムの電池管理を確認してください。サブスクリプション更新を常駐維持の手段にしてはいけません。サブスクリプションは設定を担い、バックグラウンド設定はクライアントを継続実行できるかを左右します。

iOS

iOS クライアントでは通常、サブスクリプションURLを貼り付ける、対応URLを開く、QRコードを読み取る方法でインポートします。初回接続時には、ネットワーク設定の追加を許可するようシステムから求められます。サブスクリプションのQRコードが同じ端末に表示されている場合は、読み取るよりURLを直接コピーする方が便利なことがあります。コピー後は、完全なURLを複数端末間のクリップボードに長時間残さないでください。

インポート後にノードだけが表示され、想定していたポリシーグループがない場合は、汎用ノードサブスクリプションを使っている一方で、クライアントには専用設定が必要な可能性があります。この場合は管理画面に戻って対応形式を選び直し、クライアント内で不慣れなルールを1つずつ追加しないでください。

Linux

Linux にはGUIクライアントとコマンドラインコアの両方があります。GUIクライアントでは通常、リモートサブスクリプションを直接追加できます。コマンドライン環境では、先に設定をダウンロードしてからコアにローカルファイルを読み込ませる場合があります。ダウンロードコマンドを実行するときは、シェルの履歴に完全なパラメータが保存される点に注意してください。サブスクリプションURLを共有スクリプト、ログ、公開設定リポジトリに直接書くことは推奨しません。

システムサービスとして実行する場合は、サービスアカウントが設定ファイルを読み取れること、DNSとルーティング用コマンドに必要な権限があること、デスクトップセッションのプロキシ変数とシステムサービスの設定が一致していることも確認します。Linuxで最も多い誤解は、コアが動作しているのにアプリが以前の環境変数やDNS経路を使い続けているケースです。

インポート後の確認手順
サブスクリプションの更新に成功したか
現在の設定が有効になっているか
対象の接続先を確立できるか
システムプロキシまたは仮想インターフェースが有効か
ルーティングと DNS が想定どおりか

どのくらいの頻度で更新し、何が変わるのか

すべてのクライアントに共通する固定の更新時刻はありません。自動更新の頻度は、クライアントの設定、設定形式、実行状態によって決まります。起動時だけ確認するクライアント、バックグラウンド取得に対応するクライアント、手動操作だけに頼るクライアントもあります。管理画面で回線の調整が案内されたとき、ノード一覧が明らかに古いとき、現在の接続先が使えないとき、またはサービス側から更新を求められたときに、手動で更新するのが確実です。

更新時、クライアントは元のサブスクリプションURLへ再アクセスし、新しいリモート内容で接続先一覧を更新します。ノード名、サーバーアドレス、プロトコル設定、グループ、リモートルールは変わる可能性があります。対象範囲は形式によって異なります。ノード一覧だけの汎用サブスクリプションは通常、ローカルのルーティングを管理しません。一方、完全な設定を含むサブスクリプションは、同じ設定内のポリシーグループ、DNS、ルールを上書きする場合があります。

これが、手動変更が失われやすい理由です。リモートサブスクリプションから生成されたノードを直接編集すると、次回の更新時にクライアントがサービス側の内容で設定を再構築することがあります。長く使うローカルルールは、クライアントが明確に提供する上書き、マージ、ローカル設定のレイヤーに置いてください。そうした仕組みがない場合は、サブスクリプション認証情報を含まないルールのバックアップを保管すると安全です。

✅ 更新前に正しいサブスクリプションを操作していることを確認し、同名設定の上書きを防ぐ。
✅ 更新後に追加、削除、改名された接続先を確認し、ポリシーを選び直す。
✅ ローカルのルーティングはクライアントが対応する上書きレイヤーに置き、ルールの用途を記録する。
✅ ノード一覧に異常がある場合は、まず手動更新してから再インポートの必要性を判断する。
❌ システム権限、ルーティングの競合、バックグラウンド停止の問題を、更新の繰り返しで解決しようとしない。

更新のポイント：サブスクリプションの更新は「サービス側の設定を同期する操作」と考え、万能な修復ボタンとして扱わないでください。回線の変更は更新で対応し、ローカル権限、通信制御モード、システムルートは個別に確認します。

インポート後にルーティングと DNS を確認

クライアントに遅延や「接続済み」と表示されても、テスト用のリクエストが成功したことを示すだけで、実際のアプリがすべて想定した経路を通るとは限りません。確認前に、全通信を制御するのか、ドメイン単位で振り分けるのか、指定アプリだけを回線経由にするのか、目的を決めてください。目的ごとに確認方法は異なるため、出口アドレスだけを見て判断してはいけません。

ルーティングルールは通常、ドメイン、IP、アプリ、ルールセットに基づいてダイレクト接続とプロキシを決めます。上から順に照合する場合、広すぎるルールが先にリクエストを処理し、後続ルールが適用されないことがあります。ドメインルールはDNSの解決方法の影響も受けます。クライアントが解決後のIPしか認識できず、ルールにはドメインだけが書かれている場合、照合結果が想定と異なる可能性があります。

DNSリークとは通常、管理された経路で解決されるべき問い合わせが、別のDNSリゾルバーへ送信されることを指します。「一部の通信をルールに従ってダイレクト接続する」こととは別の概念です。意図的に設定したダイレクト接続用DNSは設定上の選択であり、想定外にトンネルの外へ出た問い合わせが確認対象になります。クライアントがシステムDNS、プロキシDNS、暗号化DNS、仮想DNSのどれを使っているかを確認し、問い合わせ経路とルーティングの目的が一致しているかを調べてください。

現象	優先して確認する項目	最初に行わない操作
ノードは表示されるが接続できない	プロトコルの互換性、システム時刻、ネットワーク権限、回線の状態	同じサブスクリプションを連続して再インポートする
ブラウザは使えるが他のアプリは使えない	システムプロキシ、TUN モード、アプリ独自のプロキシ設定	サブスクリプションの内容が誤っていると決めつける
一部のドメインがルールどおりに振り分けられない	ルールの順序、ドメイン解決、キャッシュ	ルールを確認せずノードだけ切り替える
更新後にローカルの変更が消えた	リモート設定の適用範囲と上書きの仕組み	更新で置き換えられるリモートノードを編集し続ける
更新時に形式を解析できないと表示される	サブスクリプションの種類とクライアントが対応する形式	ファイル拡張子だけを変更する

回線の選択も用途に合わせる必要があります。ダイレクト接続は構成が比較的シンプルですが、国際区間は公衆ネットワークのルーティングの影響を受けやすくなります。中継は入口までの経路を改善できる一方、中間区間が増えます。IEPL 専線は国際区間の伝送方式を重視します。実際の利用では、まずルーティングとDNSを正しく設定してから、回線の違いを比較してください。ノード、プロトコル、通信制御モード、DNSを同時に変えると、どの要素が影響したのか判断しにくくなります。

漏えい後のリセットと復旧方法

サブスクリプションURLを公開場所に貼った、関係のない人へ送った、信頼できない変換ページに入力した、または撤回できないログに残った場合は、認証情報が漏えいしたものとして対応してください。公開内容を削除するだけでは不十分です。URLがすでにコピーやキャッシュされている可能性があるためです。ローカルクライアントから設定を削除するだけでも、古いURLは無効になりません。

VPNGP 管理画面にログインし、サブスクリプションのリセットまたは再生成の項目から、元のURLを無効にする。
自分のクライアントから古いリモートサブスクリプションを削除し、バックグラウンドで無効なURLへのリクエストが続かないようにする。
新しく発行された対応形式のURLを取得して再インポートし、設定を正常に更新できることを確認する。
自分が使う他の端末も確認し、古いURLを参照している設定をすべて置き換える。
ブラウザ履歴、クリップボード同期、端末履歴、メモ、スクリーンショットに残る古い完全URLを削除する。
ルーティング、DNS、ローカルの上書き設定を再確認し、新しい設定のインポート後に誤った設定を引き継がないようにする。

サブスクリプションのリセットで通常変更されるのは、設定へアクセスする認証情報です。クライアント内のローカルルールが自動的に修復されるわけではありません。問題の切り分けでDNS、システムプロキシ、ルーティングを変更していた場合は、再インポート後も項目ごとに確認してください。複数端末で利用している場合、1台でも置き換えを忘れると更新失敗の表示が続くことがありますが、そのために古いURLを再び使ってはいけません。

ローカルのサブスクリプションを誤って削除しただけで、リンクが外部に漏れていないなら、通常はリセット不要です。管理画面から再度コピーしてインポートしてください。リセットの判断基準は「クライアント内に残っているか」ではなく、「完全なURLを信頼できない相手が取得した可能性があるか」です。この判断により、不要な設定移行を避けつつ、本当に漏えいした場合は古い認証情報を速やかに無効化できます。

よくある質問と最終確認

ブラウザでサブスクリプションURLを開くと文字列だけ表示されます。正常ですか？

通常は正常です。サブスクリプションの応答はクライアント向けで、エンコードされている場合もあれば、YAML、JSON、ノードリンクの集合がそのまま返る場合もあり、ブラウザで読みやすいとは限りません。重要なのは、クライアントがその形式に対応しているか、インポート後に正しく解析できるかです。内容を「理解する」ために完全な応答をオンラインのデコードページへ送らないでください。

サブスクリプションリンクは複数のクライアントに同時にインポートできますか？

利用できるかどうかは、サービスのルールとクライアント形式の互換性によって決まります。同じURLを複数のクライアントで読み込めても、ポリシーグループ、DNS、ルールプロバイダー、プロトコル機能の実装はクライアントごとに異なる場合があります。別のプラットフォームへ移行する際は、元のURLがすべてのクライアントで同じように動作すると考えず、管理画面で対応形式を選び直してください。

更新後に回線が減ったり、名前が変わったりするのはなぜですか？

リモートサブスクリプションには、サービス側で現在提供されている設定が反映されます。回線のメンテナンス、入口の調整、命名の整理、形式の変更によって一覧が変わることがあります。まず更新時刻とサブスクリプションの取得元を確認し、次に管理画面の案内を確認してください。ノード数だけでサブスクリプションが完全かどうかを判断したり、古いキャッシュを長期間有効な設定として使い続けたりしないでください。

QRコードとテキストURLでは、どちらが安全ですか？

通常、どちらも同じ認証情報を保持しており、リスクは表示方法と保存方法で決まります。QRコードは画面に記録されやすく、テキストはクリップボード、履歴、同期ツールに残りやすい特徴があります。中間コピーを減らせる方法を選び、インポート後に一時データを削除することが、形式だけを比較するより重要です。

サブスクリプションを更新すると、現在の回線は変わりますか？

現在の回線が新しい設定から削除された、名前が変わった、別のポリシーグループに移動した場合、クライアントがデフォルトの選択に戻ることがあります。回線が残っている場合の動作は、クライアントが更新をどのように統合するかによって異なります。更新後は現在のポリシーを確認し、更新前の選択が必ず維持されるとは考えないでください。

✅ サブスクリプションの取得元、形式、クライアントが互いに対応している。
✅ 現在の設定が有効で、システムの通信制御方法がアプリの用途に合っている。
✅ どのリクエストがダイレクト接続になり、どれが回線を通るのかをルーティングルールで説明できる。
✅ DNSの問い合わせ経路がルーティングの目的と一致している。
✅ ローカルの上書き設定とリモートサブスクリプションを分けて保存し、更新時に互いを上書きしない。
✅ 完全なURLは管理された場所にだけ保存し、漏えいしたらすぐにリセットする。

最終結論：サブスクリプションリンクを正しく使うポイントは、「コピーしてノードが表示されること」だけではありません。形式の一致、設定の有効化、ルーティングとDNSの確認、そしてURLをアカウント認証情報として管理することが重要です。各工程を分けて確認すれば、インポート、更新、漏えい時の対応が明確になります。