サブスクリプションURLとは？簡単に言えば、クライアントがリモートのノード設定を読み込むための入口です。サーバーアドレス、ポート、プロトコル、認証情報を一つずつ入力する必要はありません。サービスパネルからURLを取得して対応クライアントに導入するだけで、選択可能な回線一覧を作成できます。その後の回線追加や削除、パラメータ変更も、通常は同じサブスクリプションを更新して反映します。
サブスクリプションURLは通常の商品紹介ページではなく、特定のノードアドレスそのものでもありません。多くの場合、契約情報を識別する専用の認証情報が含まれており、クライアントがアクセスすると設定一式が返されます。URLを知っている人はサブスクリプションの内容を読み込み、利用できるため、パスワードと同じように管理してください。フォーラム、スクリーンショット、サポートへの問い合わせ以外の公開チャット履歴、公開コードリポジトリなどに貼り付けてはいけません。
サブスクリプションURLには何が含まれるのか
クライアントがサブスクリプションURLをリクエストすると、サーバーはそのクライアントで解析できる設定を返します。内容はエンコードされたノードURLの集合の場合もあれば、YAML、JSONなどの構造化設定の場合もあります。返される形式は、サーバーが提供するサブスクリプションの種類と、クライアントから送られたリクエスト方式によって異なります。コピーすると単なるURLのように見えても、実際のレスポンスには通常、次の情報が含まれます。
- ノード名、サーバーアドレス、接続ポート。
- 使用するプロトコルと対応する認証情報。
- TLS、SNI、トランスポート方式など、プロトコルに関するパラメータ。
- ノードグループ、自動選択ポリシー、リモートルールの取得元。
- クライアントが認識できるDNS、ルーティング、ポリシーグループの設定。
Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICはいずれもクライアントが対応する可能性のあるプロトコルまたは設定形式ですが、フィールド構造はそれぞれ異なります。Shadowsocksでは暗号化方式とパスワードを指定します。VMessとVLESSでは識別子を使うことが多く、WebSocket、gRPC、TLSと組み合わせる場合があります。Trojanは認証パスワードを使用し、通常はTLSと併用します。Hysteria2とTUICは異なるトランスポート設計に基づいており、それぞれに合った認証情報とネットワークパラメータが必要です。
サブスクリプションの内容だけでは、回線が運用側でどのように転送されるかまでは分かりません。たとえば、IEPL専線、中継回線、公衆インターネットへの直接接続は、ノードの入口より先にあるネットワーク経路を示します。直接接続ではユーザーが目的のノードへ直接接続します。中継ではまず中継入口に入り、サービス側が出口まで転送します。IEPLは特定の国際専線接続方式です。クライアントに表示されるのは入口アドレスだけの場合もあるため、URLの文字列だけで経路全体の種類を判断せず、サービスパネルの回線表示を確認してください。
サブスクリプションの取得と安全な保管方法
正しい取得方法は、サービスパネルにログインし、サブスクリプションまたはクライアントのダウンロード欄から専用URLをコピーすることです。検索結果、見知らぬチュートリアルの添付ファイル、他人から転送された設定から「共用サブスクリプション」を取得しないでください。出所不明の設定は想定と異なるサーバーを指している可能性があり、更新や失効の仕組みも確認できません。
- サービスパネルにログインし、サブスクリプション管理またはクライアント設定のページを開きます。
- 使用するクライアントに合わせて、明確に対応しているサブスクリプション形式を選択します。
- コピー機能でURL全体を取得し、手動選択時に末尾の文字が欠けないようにします。
- 取得したらクライアントに切り替えて導入を完了し、URLを公開クリップボードツールや共有ドキュメントに長時間残さないでください。
- 導入後、サブスクリプション名と回線一覧を確認し、サービスパネルの表示と一致しているか確かめます。
サービスによっては、共用URL、Clash設定、特定クライアント向けにそれぞれ別の入口を用意しています。クライアント名と一致する入口を優先して使用してください。複数のURLをブラウザで開けるからといって、相互に使えるとは限りません。ブラウザに文字化けした内容が表示されたり、テキストがダウンロードされたり、別ページへ移動したりしても、サブスクリプションが壊れているとは限りません。多くの場合、ブラウザがクライアント設定の表示方法を知らないだけです。
サブスクリプションURL自体がアクセス認証情報です。保管する際は、管理されたパスワード管理ツールまたはサービスパネルに置き、必要なときだけコピーしてください。実際のURLをチュートリアルのスクリーンショット、端末録画、クラウドメモのテンプレート、公開アクセス可能な設定ファイルに書き込まないでください。
05VPNのアカウントはユーザー名とパスワードで管理でき、メールアドレスは不要です。サブスクリプションを取得した後もアカウント情報を適切に保管し、共有端末にパネルのログイン状態を残さないようにしてください。サブスクリプションURLとログインパスワードは役割が異なります。ログインパスワードを変更しても、古いサブスクリプションが自動的に無効になるとは限りません。URLが漏えいした場合は、パネルからリセットする必要があります。
クライアントへ正しく導入する手順
導入前に、クライアントがサブスクリプションで使われているプロトコルに対応しているか確認してください。Shadowsocksだけに対応するアプリでは、VLESS、Hysteria2、TUICを含む設定を完全には読み込めません。Clash YAMLを解析できるクライアントでも、コアのバージョンによっては新しいフィールドを無視する場合があります。「導入は成功したのに回線が空」と表示されたら、同じURLを何度も貼り直すのではなく、まず形式とプロトコルの互換性を確認します。
デスクトップへの導入
WindowsとmacOSのクライアントには通常、「URLから導入」「リモート設定を追加」「サブスクリプション管理」などの入口があります。URLをサブスクリプション欄に貼り付け、設定を識別しやすい名前を付けてから更新を実行します。導入後はまず回線を1つ選択し、システムプロキシ、仮想ネットワークアダプター、またはクライアントが提供する接続モードを有効にします。
システムプロキシモードは、OSのプロキシ設定に従うソフトに主に影響します。一部のゲーム、コマンドラインプログラム、独自のネットワークスタックを実装したアプリは、この設定を読み込まない場合があります。仮想ネットワークアダプターモードは、より広いシステムトラフィックを処理できますが、クライアントに適切な権限があり、DNSとルーティングが正しく設定されている必要があります。単純な優劣ではなく、ソフトウェアとの互換性に応じて選択してください。
モバイル端末への導入
AndroidとiOSのクライアントでは通常、サブスクリプションURLを貼り付ける、本人のサービスパネルで生成したQRコードを読み取る、ブラウザからアプリを起動するなどの方法で導入できます。初回接続時には、OSがVPN設定の作成許可を求めます。これは端末上にローカルトンネルを確立するために必要な権限です。導入後は、画面ロック後に接続が停止しないよう、省電力設定、バックグラウンド動作、アプリごとのプロキシ設定を確認してください。
モバイルクライアントによってアプリ単位のプロキシ機能の名称は異なり、「アプリを除外」「アプリプロキシ」「対象リスト」などと表示されます。特定のアプリだけ国際回線を使いたい場合は、「選択したアプリだけをプロキシする」のか「選択したアプリを除外する」のか、リストの動作を一つずつ確認してください。解釈を逆にすると、想定と異なる通信経路になります。
導入後の基本確認
- サブスクリプション名と取得元が正しく、回線一覧が正常に表示されているか。
- クライアントで有効なノードが選択されており、未選択のままになっていないか。
- システムプロキシまたは仮想ネットワークアダプターモードが有効になっているか。
- 目的のウェブサイトを開いたとき、アクセス経路が現在のルーティングルールに合っているか。
- 接続を切断した後、システムのネットワークが正常に戻り、プロキシ設定が残っていないか。
最終判断をクライアントのボタンに表示される「接続済み」だけに頼らないでください。この表示は、ローカルのプロキシポートが起動したことだけを示し、リモート側のハンドシェイク、DNS解決、目的のサイトへのアクセスがすべて成功したことを意味しない場合があります。ノードへの接続、ドメイン解決、実際のウェブページへのアクセスを個別に確認すると、障害がどの層にあるか判断しやすくなります。
サブスクリプション更新の仕組み
クライアント内のリモートサブスクリプションは、一度きりの静的ファイルではありません。更新を実行すると、クライアントは元のURLへ再度リクエストを送り、サーバーが現在提供しているノードとルールをダウンロードして、ローカル設定を置き換えるか統合します。サービス側が入口を変更したり、証明書パラメータを更新したり、回線を追加・削除したりしても、通常はURLを取得し直す必要はなく、既存のサブスクリプションを更新するだけで済みます。
ただし、「サブスクリプションを更新する」ことと「ノードをテストする」ことは別の操作です。更新に成功したのは、クライアントが解析可能な設定を受け取ったことを示すだけで、すべての回線が現在のネットワークに適しているとは限りません。更新に失敗しても、クライアントが前回のキャッシュを保持していれば、既存のノードがすぐにすべて使えなくなるとは限りません。切り分けでは、設定の取得とノード接続を分けて確認してください。
一部のクライアントでは自動更新を利用できますが、システムのスリープ、バックグラウンド制限、ネットワーク切り替えの影響を受ける場合があります。接続前に手動で一度更新すると、結果を確認しやすくなります。サービスパネルでサブスクリプションをリセット済みの場合、古いURLは無効になります。このときは古いサブスクリプションを削除して新しいURLを導入する必要があり、更新ボタンを押すだけで古い認証情報が新しく変わるわけではありません。
更新に失敗したときの段階的な切り分け
更新失敗では、リクエストのタイムアウト、空のレスポンス、解析エラー、認証失敗、更新後も回線一覧が変わらないといった症状が見られます。更新ボタンを連続して押すより、「URL、ネットワーク、形式、クライアント、アカウント状態」の順に確認してください。
まずURLの完全性を確認する
URLがチャットアプリで途中までしか送られていない、空白や改行、文末の句読点が混入していないことを確認します。手動で設定を編集したことがある場合は、パネルからもう一度コピーし、不足している文字を推測して補わないでください。URL内の専用認証情報は通常、大文字・小文字や文字の違いを区別します。わずかな変更でもサーバーが認識できなくなる可能性があります。
次に現在のネットワークによる遮断を除外する
クライアントがリモート設定を取得するには、まずサブスクリプションサーバーへアクセスできなければなりません。誤ったシステムプロキシを一時的に無効にするか、通常どおりウェブを閲覧できるネットワークへ切り替えてから更新してください。古いプロキシが使えないのに、システムがそのプロキシ経由でサブスクリプションを取得し続けると、「接続するには更新が必要なのに、接続できないため更新できない」という循環に陥ります。この場合は先に直接接続を復旧し、その後サブスクリプションを更新します。
形式とクライアントのコアを確認する
サーバーから正常な内容が返っているのにクライアントが解析失敗を表示する場合、形式の不一致、フィールドのバージョンが古い、未対応プロトコルなどが原因になりやすいです。クライアントの説明を確認し、共用サブスクリプションまたは対応する設定形式を選んでください。YAMLを、ノードURIだけを受け付けるアプリに導入してはいけません。クライアントを長期間更新していない場合、Hysteria2、TUIC、新しいVLESSのトランスポートフィールドを認識できないこともあります。
サブスクリプションがリセットまたは停止されていないか確認する
パネルで新しいURLが発行されている場合、古いURLは通常使い続けるべきではありません。パネルにログインして現在のサブスクリプション入口を確認し、クライアントのURLとパネルからコピーした内容を照合します。再度の漏えいを避けるため、完全なURLを公開フィードバック欄に直接送らないでください。サポートへ連絡する際は、エラーメッセージ、クライアント名、OS、発生手順を伝え、必要な情報はサポートが案内する安全な方法で補足します。
URLが漏えいしたときの対処
サブスクリプションURLが公開スクリーンショット、共有設定、コードリポジトリ、ブラウザの同期履歴に含まれていたり、保有すべきでない相手に送られたりした場合は、漏えいしたものとして扱います。公開内容を削除するだけでは不十分です。URLはすでにコピー、キャッシュ、取得されている可能性があります。重要なのは古い認証情報を無効にすることです。
- サービスパネルにログインし、サブスクリプションのリセットまたは再生成を実行します。
- 古いURLが無効になったことを確認し、公開ページを削除しただけで安心しないようにします。
- クライアントから古いサブスクリプションを削除し、後から誤って更新しないようにします。
- 新しいURLを本人が使用するクライアントに改めて導入します。
- URLを保存していた場所を確認し、公開ドキュメント、スクリーンショット、設定のバックアップを整理します。
- アカウントのログイン情報も漏えいした可能性がある場合は、アカウントのパスワードを変更し、使用しなくなったログイン状態を終了します。
サブスクリプションをリセットした後は、通常、既存のクライアントに再導入が必要です。一部のクライアントが古いノードのキャッシュを保持していても、古いサブスクリプションが安全に使えるとは限りません。キャッシュ設定はサーバー側のパラメータ変更後に無効になる場合があり、残しておくと切り分けも複雑になります。移行が完了したら古い設定を削除し、取得元が明確な新しいサブスクリプションだけを残してください。
QRコードもサブスクリプション認証情報を表示する形式です。完全なサブスクリプションURLを含むQRコードを、公開チュートリアルやSNSの画像に掲載してはいけません。一部だけ隠す方法も安全とは言えないため、実際のQRコードを公開しないのが最も確実です。すでに公開した場合は、画像編集に頼らず、漏えい時の手順に従ってリセットしてください。
ルーティングとDNSリークは追加確認が必要
サブスクリプションの導入後、通信が想定した回線を通るかどうかは、クライアントのモードとルーティングルールによって決まります。グローバルプロキシでは、対象範囲の大部分の通信を現在のノードへ渡します。ルールベースのルーティングでは、ドメイン、アドレス範囲、アプリ、ルールセットに応じて直接接続とプロキシを決定します。アプリ単位のモードでは、どのプログラムをプロキシに通すかをユーザーが選択します。サブスクリプションの既定ルールは出発点になりますが、現在のクライアントが実際にどのモードで動作しているかを理解しておく必要があります。
DNSリークとは通常、プロキシまたは管理された名前解決経路を通すべきドメイン問い合わせが、ローカルネットワークのDNSサーバーへ送信され続ける状態を指します。これにより、回線の地域と異なる名前解決結果になったり、問い合わせたドメインが外部に知られたりする可能性があります。対処時は、クライアントがDNSを引き受けているか、システムに別の名前解決設定が残っていないか、ブラウザがクライアントのポリシーを迂回する独自のセキュアDNSを有効にしていないかを確認してください。
ルーティング環境でローカルDNSへの問い合わせが発生しても、必ずしも設定ミスとは限りません。直接接続するドメインは、もともとローカルの名前解決を使う設計の場合があります。重要なのは、プロキシ対象の問い合わせがルールどおり想定した名前解決経路に入っているかどうかです。切り分けでは、まず直接接続するドメインとプロキシを通すドメインを明確にし、そのうえで動作が設計に合っているか判断してください。
クライアントがサブスクリプションを更新した後、ユーザーが追加したルールを保持できるかどうかは、ソフトウェアの実装によって異なります。リモート設定全体を置き換えるクライアントもあれば、ローカル上書きや独立したルールセットを利用できるクライアントもあります。編集前に上書きの仕組みを確認し、更新によって手動設定が消えないようにしてください。長期利用では、リモートサブスクリプションから生成されたファイルを直接編集するより、クライアントが明確に対応する上書き領域に個人ルールを置くほうが確実です。
よくある誤解と最終確認
1つ目の誤解は、サブスクリプションURLをノードの速度測定用URLだと考えることです。サブスクリプションサーバーは設定を配布するだけなので、その応答速度が目的のサービスへの回線品質を示すわけではありません。2つ目は、サブスクリプションが長く、ノード名が多いほど良いと考えることです。実際に重視すべきなのは、プロトコルの互換性、回線の用途、現在のネットワーク環境、サービス側の保守状況です。
3つ目の誤解は、導入後に長期間更新しないことです。回線パラメータは変更される可能性があり、古いキャッシュは徐々にサーバーの状態と合わなくなります。4つ目は、設定ファイルを共有する際にノード名だけを削除し、認証情報を残してしまうことです。認証情報が残っている限り、名前を変更しても利用権限は消えません。
設定が完了したら、次の順序で最終確認を行います。パネルから正しい形式をコピーする。対応クライアントにリモートサブスクリプションを追加する。更新して回線が表示されることを確認する。ノードを選択し、適切なプロキシモードを有効にする。目的のサイトへのアクセス、DNS、ルーティングの結果を確認する。URLを安全に保管する。公開された場合は、すぐにリセットして再導入する。