ノードサブスクリプションリンクとは？簡単に言えば、サービス側で発行され、プロキシクライアントが読み込む設定の入口です。クライアントがこのリンクにアクセスすると、現在のアカウントで利用できる回線名、サーバーアドレス、ポート、プロトコルの種類、認証情報を取得し、選択可能なノード一覧として整理します。特定の固定回線でも、接続プロトコルそのものでもなく、回線設定を管理するための入口です。
ノードを1つずつ手動で追加する場合は、各パラメータを個別に入力する必要があります。サブスクリプションリンクを使えば、クライアントが一覧全体を一度に読み込み、サービス側で回線が調整された後に設定を再取得できます。この違いを理解しておくと、「サブスクリプションの更新」「ノードの切り替え」「クライアントのアップデート」を混同せずに済み、コピーの誤りによる接続失敗も減らせます。
サブスクリプションリンクに含まれる情報
ユーザーインターフェース上では、サブスクリプションリンクは単なるURLに見えます。しかしクライアントから見ると、返されるのは機械が読み取れる回線設定です。サービス側やクライアントによってサブスクリプション形式は異なりますが、目的は共通しています。利用できる回線と、各回線への接続に必要なパラメータをクライアントへ伝えることです。
サブスクリプションには通常、回線の表示名、サーバーの接続先、接続ポート、トランスポートプロトコル、認証項目、トランスポート層のオプション、必要なセキュリティパラメータが記載されます。一部のクライアントはグループ設定の提案も読み取れますが、ローカルの分流ルール、アプリごとのプロキシ範囲、DNS設定はクライアント側で管理することが多く、サブスクリプションだけですべてのネットワーク方針が設定されるとは限りません。
| 設定項目 | 主な役割 | よくある誤解 |
|---|---|---|
| サブスクリプションリンク | 回線一覧全体を取得・更新する | リンク自体が1つのノードだと思う |
| ノード設定 | 回線の接続先、プロトコル、認証パラメータを定義する | ノード名だけで実際の回線品質が決まると思う |
| 接続プロトコル | クライアントとサービス側が接続を確立し、通信する方法を定める | すべてのクライアントが全プロトコルに対応していると思う |
| 分流ルール | どのリクエストをプロキシ経由にし、どれを直接接続するか決める | サブスクリプションを導入すればルール確認は不要だと思う |
| DNS設定 | ドメインをどのリゾルバーで処理し、どの経路で名前解決するか決める | ノードに接続できればDNS漏えいは起きないと思う |
サブスクリプションはプロトコルではない
Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICは、それぞれ異なる接続プロトコルまたはプロトコル体系です。サブスクリプションリンクは、対応する設定をクライアントへ渡すだけのものです。1つのサブスクリプションに複数のプロトコルを含めることもできますが、利用できるかどうかは、クライアントのコアが該当プロトコルに対応しているか、また設定内のトランスポートオプションをクライアントのバージョンが認識できるかによって決まります。
- ✅ Shadowsocksの設定は比較的シンプルですが、クライアントが使用する暗号方式と認証情報を認識できる必要があります。
- ✅ VMessとVLESSは異なるトランスポート方式と組み合わせて使われることが多く、インポートに成功しても、すべての組み合わせが現在のコアでサポートされるとは限りません。
- ✅ Trojanは正しいドメイン名とトランスポート層のパラメータを必要とすることが多く、システム時刻や証明書検証の異常が接続に影響する場合もあります。
- ✅ Hysteria2とTUICは現代的なトランスポート設計に基づいているため、使用前にクライアントのコアが明確に対応していることを確認してください。
- ❌ ノード名だけでプロトコルの互換性を判断する。名前は表示用の項目であり、実際の判断材料は設定内容です。
アカウント管理画面から取得して安全に保存する
信頼できる取得先は、サービス公式のアカウント管理画面です。ログイン後、サブスクリプション、回線、またはクライアント設定に関するページを開き、管理画面に用意されたコピー機能を使ってください。チャットに残った古いスクリーンショットをもとにURLを手入力したり、検索結果にある第三者のページでいわゆる「変換リンク」を生成したりするのは避けましょう。変換の過程で、完全なサブスクリプション認証情報が外部に渡る可能性があります。
VPNHuのユーザーは、アカウント管理画面から現在のアカウントに対応するサブスクリプションの入口を取得できます。管理画面に複数のクライアント形式が用意されている場合は、実際に使うクライアントに合わせて選択してください。ファイル拡張子だけで判断するのは禁物です。形式を間違えると、クライアントに内容が空と表示されたり、解析できなかったり、導入後に回線が1つも生成されなかったりします。
- アカウント管理画面を開く：使用するアカウントでログインしていることを確認し、サブスクリプションまたはクライアントのダウンロードエリアを開きます。
- 対応する形式を選ぶ：クライアントの対応状況を確認し、管理画面で明示された対応形式または汎用サブスクリプションの入口を優先します。
- リンク全体をコピーする：コピー機能を使い、クエリパラメータ、認証項目、末尾の文字が欠けないようにします。
- クライアントへ直接導入する：信頼できるクライアント内に貼り付け、短縮URL、オンライン変換ツール、公開メモを経由しないでください。
- 導入後に一覧を確認する：回線名、プロトコルの種類、更新入口が表示されていることを確認してから、接続テストを行います。
保存を避けるべき場所
サブスクリプションリンクは、公開コードリポジトリ、共有スプレッドシート、公開チケット、フォーラム投稿、検索エンジンに登録される可能性のあるページには保存しないでください。ブラウザーの同期ブックマークやシステムのクリップボードは便利ですが、使用中の端末が共用ではないか、他のアプリがクリップボード履歴を読み取れないかも確認しましょう。
自分の端末間で移す必要がある場合は、チャット履歴に長期間残すのではなく、管理画面から管理された方法で再取得することを優先してください。これによりコピーの数を減らせ、リンクをリセットした後に、どのクライアントへ再導入すべきかも確認しやすくなります。
Windows、Android、Apple、Linuxへの導入方法
プラットフォームによって操作名は異なりますが、よくある入口は「サブスクリプションを追加」「URLからインポート」「リモート設定」「サブスクリプション管理」などです。ボタン名にかかわらず、基本的な流れはリンクをリモート設定ソースとして保存し、クライアントから回線一覧を取得することです。
| プラットフォーム | 一般的な導入手順 | 重点的に確認する点 |
|---|---|---|
| Windows | サブスクリプション管理でリモートアドレスを追加し、更新を実行する | システムプロキシモード、仮想ネットワークインターフェースモード、分流ルールが用途に合っているか |
| Android | 設定を追加するか、クリップボードからサブスクリプションをインポートする | クライアントにVPN設定を作成するシステム権限が付与されているか |
| Appleプラットフォーム | 対応クライアントでサブスクリプションアドレスを追加し、システムによる設定追加を許可する | クライアントのプロトコル対応、オンデマンド接続、システムDNSの動作 |
| Linux | グラフィカルクライアントまたは信頼できるコマンドラインツールでリモート設定を読み込む | 実行権限、ルーティングテーブル、システムプロキシの環境変数、DNSの引き継ぎ方法 |
導入後にノードが表示されない場合
まずクライアントを何度も削除するのはやめましょう。エラーがネットワーク通信の失敗なのか、サブスクリプション内容が空なのか、形式の解析失敗なのかを確認してください。ネットワーク通信の失敗は、クライアントがサブスクリプションURLへアクセスできないことを示す場合が多く、内容が空の場合はアカウントの状態やサービス側の応答が関係している可能性があります。形式の解析失敗なら、クライアント形式の選択ミス、コアのバージョンが古い、または現在のクライアントがサブスクリプション内のプロトコルに対応していない可能性が高いでしょう。
コピーした内容が完全かどうかも確認してください。アプリによっては貼り付け時にスペースや改行が入り、ページによっては表示テキストが途中で省略されることもあります。正しい方法は、管理画面でコピー機能をもう一度使うことであり、欠損したURLを手作業で修正することではありません。
接続後もウェブサイトを開けない場合
「ノードが接続済み」と表示されても、クライアントが接続の一段階を完了したことを示すだけで、すべてのアプリのリクエストが想定どおりプロキシを通るとは限りません。この場合は、システムプロキシが有効か、仮想ネットワークインターフェースが対象トラフィックを引き継いでいるか、分流ルールが対象ドメインを誤って直接接続にしていないか、DNSの経路がトラフィックと異なる出口になっていないかを確認します。
ブラウザーではアクセスできるのに他のアプリではできない場合、ブラウザーはシステムプロキシを読み込んでいて、他のアプリはシステムプロキシを迂回していることがよくあります。より多くのアプリを対象にする必要がある場合は、クライアントの機能に応じて仮想ネットワークインターフェースモードを使えます。ただし有効にするとシステムのルーティングが変わるため、ローカルネットワーク、開発環境、社内ネットワークで直接接続を残す必要がないか確認してください。
サブスクリプションはどのくらいの頻度で更新すべきか
サブスクリプションの更新に、すべてのサービスやクライアントへ共通する固定スケジュールはありません。更新とは、サービス側の現在の一覧を読み直す操作です。必要かどうかは、回線一覧に変更があるか、クライアントが正常に接続できるか、サービスの管理画面で設定変更が告知されているかを基準に判断します。
通常の利用では、クライアントに用意された起動時更新や定期更新を有効にしても構いませんが、高頻度で繰り返し更新する必要はありません。頻繁に更新しても現在の接続が自動的に改善したり、直接接続の回線が中継回線や専用線に変わったりすることはありません。更新は設定を再取得するだけであり、使用中の回線品質は実際の経路、ネットワーク環境、サービス側の状態によって決まります。
- ✅ 管理画面で回線一覧の調整が通知されたら、サブスクリプションを更新する。
- ✅ 既存の回線が一斉に使えなくなったり、名前が明らかに古くなったりした場合は、まずサブスクリプションを更新してから切り分ける。
- ✅ クライアントを変更または再インストールした後は、管理画面から現在のサブスクリプションを再導入する。
- ✅ リンクをリセットしたら、古いサブスクリプションを削除して新しいリンクを導入する。
- ❌ ノードを切り替えるたびにサブスクリプションを再取得する。ノードの切り替えと一覧の更新は別の操作です。
- ❌ サブスクリプションの更新を速度測定だと考える。更新できるのは設定の同期であり、回線の現在の性能を示すものではありません。
サブスクリプションの更新とクライアントの更新の違い
サブスクリプションを更新すると新しい回線設定を取得し、クライアントを更新するとアプリケーションやプロトコルコアが置き換わります。サービス側が現在のクライアントでは認識できないプロトコルを追加した場合、サブスクリプションを更新しても回線を読み込めないことがあります。その場合は、サブスクリプションを繰り返し更新するのではなく、クライアントのバージョンとコアの対応状況を確認してください。
反対に、クライアントをアップデートしても最新の回線が自動的に取得されるわけではありません。ローカルに古い一覧が残っている場合は、サブスクリプションを手動で更新する必要があります。切り分けでは、「アプリのバージョン」「サブスクリプションの更新時刻」「ノードの接続結果」を分けて記録すると、何度も再インストールするより効果的です。
直接接続、中継、IEPL専用線は導入方法で変わらない
サブスクリプションは設定を配布する方法にすぎず、回線の種類を決めるものではありません。直接接続の回線は通常、ユーザーのネットワークから対象サーバーへ直接接続するため、経路は利用中の通信事業者や国際出口の影響を受けやすくなります。中継回線はまず中継入口へ接続し、そこから対象地域へ転送することで、一部のネットワーク環境で経路を改善します。IEPL専用線は特定の国際専用線を利用する方式で、通常の公衆網による直接接続とは異なる経路構成になります。
同じサブスクリプションを別のクライアントに導入しても、直接接続が中継に変わったり、通常回線がIEPLに変換されたりすることはありません。クライアントは、コアの実装、トランスポートパラメータ、ルーティングモードの違いによって異なる使用感になることがありますが、サービス側の経路タイプは提供元の設定によって決まります。
選ぶときは、まず用途に合わせてください。通常のウェブ閲覧なら一般的な回線から試し、長時間接続、ストリーミング出力、継続的なデータ転送が重視される用途では、中継回線と専用線の一覧を比較するとよいでしょう。利用中のネットワークが特定のトランスポートを制限している場合は、クライアントが対応する範囲でプロトコルや回線を変更し、認証パラメータを無闇に変更しないでください。
DNS漏えいと分流ルールは別途確認する
サブスクリプションの導入に成功しても、プライバシーやアクセス結果はDNSと分流設定の影響を受けます。DNS漏えいとは通常、ドメイン名の名前解決リクエストが想定した経路で処理されない状態を指します。たとえばウェブの通信はプロキシを通っているのに、名前解決だけがローカルネットワークの既定リゾルバーへ送信されるケースです。その結果、名前解決の地域とプロキシ出口の地域が一致しなかったり、ローカルのDNSサービスに検索したドメインを知られたりする可能性があります。
対策は、むやみにサブスクリプションを変更することではありません。クライアントのDNSモード、システムの名前解決設定、仮想ネットワークインターフェースが引き継ぐ範囲を確認してください。DNSリクエストをプロキシ側で解決できるクライアントもあれば、システム設定に依存するもの、分流ルールに応じて処理を分けるものもあります。プラットフォームごとにシステム上の制約が異なるため、別のプラットフォームの設定の組み合わせをそのまま適用することはできません。
分流ルールはトラフィックの経路を決めます。一般的な方法では、ドメイン、宛先アドレス、アプリ、ルールセットなどを基準に、直接接続とプロキシ接続を判断します。ルールが広すぎるとローカルサービスまで遠回りになり、ルールが不足すると対象アプリが直接接続する可能性があります。調整するときは明確な目的から始め、アカウント管理画面、ローカルネットワーク、必要なシステムサービスには正常にアクセスできる状態を残してください。
サブスクリプションリンクが漏えいした場合の対処
完全なサブスクリプションリンクを公開場所へ送信した、不可信なツールにアップロードした、またはアクセス範囲を管理できない記録に残した場合は、漏えいしたものとして扱ってください。公開内容を削除するだけでは不十分です。リンクはすでにコピー、キャッシュ、取得されている可能性があります。正しい対処は、古い認証情報を無効にしてから、自分のクライアントに新しいリンクを設定することです。
- 拡散を止める：公開ページ、共有文書、メッセージにあるリンクやQRコードを削除し、漏えい範囲がさらに広がらないようにします。
- アカウント管理画面を開く：サブスクリプションのリセット、認証情報の更新、古いサブスクリプションの無効化に関する入口を探します。管理画面にセルフサービスの入口がない場合は、公式サポート窓口へ連絡してください。
- 新しいサブスクリプションの入口を発行する：古いリンクが無効になったことを確認してから、管理画面に表示された新しいリンクをコピーします。
- 古い設定をすべて削除する：自分が使用している各プラットフォームのクライアントから古いサブスクリプションソースを削除し、無効化済みのアドレスへクライアントがアクセスし続けないようにします。
- 再導入して更新する：新しいリンクを管理下にある端末へそれぞれ導入し、一覧が読み込まれて接続できることを確認します。
- 漏えい元を確認する：リンクが公開場所に入った経緯を振り返り、クリップボード履歴、スクリプト設定、ログ、リポジトリの履歴にあるコピーを削除します。
サブスクリプションをコードリポジトリに登録していた場合、最新ファイルを削除するだけでは、過去のコミットに残った内容を消せません。まずサブスクリプションの認証情報をリセットし、その後リポジトリサービスの履歴削除手順に従って古い記録を処理してください。順番が重要です。先に古いリンクを無効にすれば、削除作業中に使われ続けるリスクを抑えられます。
クライアントのログやトラブルシューティング用スクリーンショットから漏えいした場合は、ログにノードの認証項目が残っていないかも確認してください。問い合わせ時に残すべきなのは、エラーの種類、クライアントのバージョン、発生した段階までです。完全なサブスクリプションURLは添付しないでください。
日常利用のチェックリスト
サブスクリプション管理の目的は、操作を増やすことではなく、回線一覧、クライアントの機能、ローカルネットワークの方針を一致させることです。問題が起きたら、設定の取得元から接続経路まで順番に確認すると、サブスクリプション、プロトコル、クライアント、システムのネットワーク設定のどこに原因があるかを素早く切り分けられます。
- ✅ サブスクリプションはアカウント管理画面またはサービス公式クライアントの入口からのみ取得する。
- ✅ 導入前に、クライアントがサブスクリプションで使われているプロトコルに対応していることを確認する。
- ✅ 回線一覧が変わったとき、または管理画面で調整が通知されたときに更新する。
- ✅ 接続後に、システムプロキシ、仮想ネットワークインターフェース、分流ルール、DNSの経路を確認する。
- ✅ 端末を変更するときは管理画面からリンクを再取得し、不要な中間コピーを減らす。
- ✅ 漏えいが疑われるときは、先に認証情報をリセットしてから各端末の古いサブスクリプションを置き換える。
- ❌ 出所の不明なオンライン変換ツールにサブスクリプションURLを入力する。
- ❌ スクリーンショット、公開チケット、リポジトリ、共有文書に完全なリンクを残す。
要するに、ノードサブスクリプションリンクは更新可能な回線一覧へアクセスするための入口です。取得時は入手元、導入時は形式とプロトコルの互換性、更新時は一覧の変化、接続後は分流とDNS、漏えい時は古い認証情報の無効化を確認します。これらを分けて理解すれば、クライアント設定が整理され、トラブル対応も削除と再インストールの繰り返しで終わらなくなります。