サブスクリプションリンクは、クライアントが接続設定を取得するための入口であり、日常の閲覧に使う通常のウェブページではありません。対応クライアントに読み込むと、クライアントがリモート設定を取得して認識可能なノードやパラメータを解析し、その内容をローカル設定として保存します。その後の「サブスクリプションを更新」は、同じ入口へ再度アクセスし、サーバー側で現在提供されている設定を同期する処理です。

結論から言えば、サブスクリプションリンクはユーザーパネルから取得し、クライアントの「URLから読み込む」または「サブスクリプションを追加」機能で設定します。リンクを公開状態で送信したり、ネット上の例をもとにURLを手作業で組み立てたりしないでください。読み込みに成功しただけでは、すべてのノード、プロトコル、ルーティングルール、対象サイトまで確認できたことにはなりません。接続後も、ネットワーク経路、DNS、クライアントモード、対象サービス側の条件を個別に確認する必要があります。

サブスクリプションリンクと通常のURLの違い

見た目はサブスクリプションリンクも https:// で始まるため、通常のウェブアドレスと間違えやすいものです。違いは接頭辞ではなく、返される内容と利用者にあります。通常のウェブページは主にブラウザで表示されますが、サブスクリプションの入口は通常、プロキシクライアントが解析する機械可読な設定を返します。返却内容はエンコードされている場合や、YAML、JSON、サービス独自形式の場合があります。形式は提供元とクライアントの対応状況によって異なるため、URLの見た目だけで判断することはできません。

よく使われるリンクと設定項目の用途
対象 主な用途 一般的な処理方法 注意点
サブスクリプションリンク 接続設定をまとめて取得・更新する 対応クライアントに取得・解析させる リンク自体が設定へのアクセス権を示す場合がある
通常のウェブリンク 説明、パネル、公開ページを開く ブラウザで内容を表示する ページを開けてもサブスクリプションとして読み込めるとは限らない
単一ノードの共有情報 特定の接続設定を1件読み込む クライアントがプロトコル項目を識別する 接続設定全体を自動取得するものではない
ローカル設定ファイル ノード、ルール、クライアント設定を保存する ファイルから読み込む、またはクライアントが読み取る ローカルでの変更はサブスクリプション更新時に置き換わる場合がある

サブスクリプションリンクは、特定のプロトコルそのものでもありません。さまざまな設定を届ける入口であり、返却内容には Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC など異なるプロトコルのノードを含められます。クライアントがサブスクリプションを取得できても、その中のすべてのプロトコルを解析できるとは限りません。ノードを表示できる場合でも、対応する通信方式、暗号化パラメータ、輻輳制御オプションを現在のコアがサポートしているとは限りません。

取得と読み込みの正しい手順

サブスクリプションの入口は、対象アカウントのユーザーパネルから取得してください。パネルに表示されるのは、そのアカウントで現在利用できる設定入口であり、リンクが漏えいした場合のリセットにも使えます。チャット履歴に残った古いURL、検索結果、スクリーンショットから読み取った文字列、他人から転送された内容を起点にしないでください。それらが現在のアカウントに属するものか、途中で切れたり書き換えられたりしていないか確認できないためです。

  1. ユーザーパネルを開く。自分のアカウントでログインし、サブスクリプションまたはクライアント関連の項目から取得入口を探します。VPNFD はメールアドレスなしでアカウントを作成できますが、ユーザー名とパスワードは適切に管理してください。
  2. クライアントの提供元と対応状況を確認する。まず、クライアントが使用中のOS、サブスクリプション形式、サブスクリプションに含まれるプロトコルに対応しているかを確認します。画面に「読み込み」ボタンがあるかどうかだけで判断しないでください。
  3. リンク全体をコピーする。末尾の文字が抜けたり、改行が混ざったり、説明文まで一緒にコピーされたりしないよう注意します。「見た目をすっきりさせる」ためにクエリパラメータを自分で削除しないでください。
  4. サブスクリプションの読み込みを選ぶ。クライアントで「サブスクリプションを追加」「URLから読み込む」など同じ意味の入口を使い、URL全体を単一ノード用のサーバー欄に貼り付けないでください。
  5. 初回更新を実行する。保存後、クライアントに設定を取得させ、ノード一覧が表示されるか、プロトコル解析エラーや取得失敗の案内が出ないか確認します。
  6. ノードを選んで接続する。読み込みが完了してから、地域、経路、実際の通信状況をもとにノードを選び、対象サイトとアカウント側の条件も確認します。

クライアントに「ローカル設定」「リモート設定」「サブスクリプションプロバイダー」など複数の入口がある場合は、先にそのクライアントの項目説明を読んでください。ソフトウェアによって用語の使い方は完全には統一されていません。リモートサブスクリプションを内部設定に変換するもの、リモートプロバイダーとの関係を維持するもの、ノードサブスクリプションとローカルのルーティングルールを組み合わせられるものがあります。名称が似ていても、更新動作が同じとは限りません。

プロトコル互換性が読み込み結果を左右する理由

プロトコルの互換性は、「認識できるか」と「接続できるか」の2段階で考える必要があります。クライアントが VMess や VLESS の項目を認識しても、それは解析器が設定構造を理解したことを示すだけです。実際に接続を確立するには、通信方式、TLS関連パラメータ、サーバー側の要件をクライアントのコアがサポートしている必要があります。Trojan は通常TLSの動作に依存し、Shadowsocks は双方で一致した暗号化・認証パラメータが必要です。Hysteria2 と TUIC は QUIC の考え方を基盤としており、UDPの利用可否やネットワーク環境の影響を受けやすくなります。リストにプロトコル名があるだけで、現在のネットワークに適していると判断しないでください。

サブスクリプションには、備考、グループ、倍率、ポリシー名などが含まれる場合もあります。これらは設定のメタデータであり、プロトコル自体の性能ではありません。ノード名に「専用線」「中継」や地域名が含まれていても、判断材料は提供元の回線説明と実際の経路確認にしてください。ノード名だけで物理的な経路を推測することはできません。

IEPL、中継、直接接続の違い

直接接続は通常、クライアントが対象ノードの入口へ直接接続する方式で、経路は主に利用回線、国際相互接続、対象ネットワークの影響を受けます。中継ではユーザーと出口の間に転送入口を追加し、一部の公衆網経路を変えたり相互接続品質を改善したりしますが、最終的な効果は利用回線と中継経路に左右されます。IEPL は国際イーサネット専用線系の接続を示すことが多く、通常の公衆網による直接接続や中継とはネットワーク構成が異なります。ただし、実際のサービスが全経路で該当回線を使っているかは、サブスクリプション形式から判断できません。

サブスクリプションリンクが届けるのは「接続方法」の設定であり、回線の商用帯域、物理トポロジー、第三者プラットフォームの利用可否をクライアントに証明するものではありません。回線を比較する際は、備考欄を技術的な証明とみなさず、実際の経路、安定性、利用目的を確認してください。

サブスクリプション更新で変わる内容

サブスクリプションの更新では、クライアントがリモート設定を再取得します。サーバー側でノード入口、ノード備考、プロトコルパラメータ、グループ内容が変更され、クライアント側の項目が追加、削除、置換される場合があります。更新周期を経験則で決めつけないでください。手動操作時だけ更新するクライアント、自動更新を設定できるクライアント、バックグラウンド動作、省電力設定、ネットワーク権限の影響を受けるクライアントがあります。

「上書き」と「統合」の違いには特に注意が必要です。上書きモードでは通常、リモートの結果で元のサブスクリプション内容を置き換えます。統合モードでは一部のローカル項目が維持される場合があります。サブスクリプションプロバイダーモードでは、リモートのノード群とローカルルールを分けて管理することがあります。サブスクリプションから生成されたノード名、サーバー欄、プロトコルパラメータを直接変更すると、次回更新で変更内容が消える場合があります。

ルーティングルールとノードサブスクリプションは分けて考える

ルーティングルールは、どのリクエストをプロキシ経由にし、どれを直接接続にし、どれを遮断するかを決めます。ドメイン、IP、プロセス、ルールセットなどで照合できるかはクライアントによって異なります。ノードサブスクリプションが解決するのは「どの接続設定があるか」であり、ルーティングが解決するのは「通信をどの経路へ振り分けるか」です。サブスクリプションにポリシーグループやルールが含まれる場合もありますが、すべてのサブスクリプションに完全なルーティング設定が含まれるとは限りません。

特定のウェブサイトを開けない場合は、まずルールによって誤って直接接続に振り分けられていないか確認し、次に選択中のポリシーグループが利用可能なノードを指しているか確認します。ブラウザ、OS、クライアントで異なるプロキシ設定が有効になっていると、一部のリクエストだけがプロキシを経由し、別のリクエストが迂回することもあります。トラブルシューティングでは設定の重複を減らし、現在どの通信をシステムプロキシ、TUNモード、アプリ内プロキシが受け持っているかを明確にしてください。

DNSリークと接続確認

DNSリークとは通常、ドメイン名の問い合わせが想定した名前解決経路を通らず、OS、ルーター、ブラウザの暗号化DNS、ローカルネットワーク内のリゾルバーなどで処理される状態を指します。必ずしも「まったくアクセスできない」形で現れるとは限りません。ウェブ接続はプロキシを通っていても、名前解決はローカルネットワークを通るため、地域判定の不一致、異常な解決結果、想定したプライバシー境界からの逸脱が起きることがあります。

確認時は公開出口アドレスだけを見ないでください。クライアントのDNSモード、OSのネットワーク設定、ブラウザ独自のDNS設定、ルーティングルールが一致しているかも確認します。TUNモードはより広いシステム通信を取り込めることが多い一方、対応するOS権限が必要です。システムプロキシモードは主にプロキシ設定に従うアプリへ影響し、一部のプログラムやDNSリクエストは経由しない場合があります。クライアントにある「リモートDNS」「ローカルDNS」「ルールDNS」などの名称はソフトウェア間で統一されていないため、具体的なドキュメントを確認してください。

更新後に「ノードは表示されるが接続できない」場合は、サブスクリプション取得、設定解析、ノード選択、通信確立、ドメイン解決、対象へのアクセスの順に確認します。これにより、サブスクリプション入口の障害、クライアントのプロトコル非互換、現在の回線の問題、対象サービス側の制限を切り分けられます。原因を特定しないまま設定を何度も削除することも避けられます。

各プラットフォームのクライアントの違い

Windows クライアントでは通常、システムプロキシと仮想ネットワークアダプターのモードを切り替えられます。トラブルシューティングでは、アプリがシステムプロキシに従うか、仮想ネットワークアダプターのドライバーが正常かを確認します。macOS の全体的な通信制御ではシステムネットワーク拡張の権限が必要になることが多く、読み込みに成功しても権限が有効でなければ通信を引き継げない場合があります。

Android ではバックグラウンド制限や省電力設定によって接続やサブスクリプション更新が停止する場合があります。ネットワークを切り替えた後は、VPN設定が引き続き有効か確認してください。iOS クライアントはシステムネットワーク拡張とアプリの機能制限を受けます。クライアントによって対応プロトコルやサブスクリプション形式が異なるため、別のプラットフォームの設定ファイルをそのまま互換できるものと考えないでください。

Linux は環境差がさらに大きく、デスクトップクライアント、コマンドラインコア、サービスプロセス、コンテナが異なる設定場所を読み込む場合があります。コマンドラインコアを使うときは、コア本来の設定とサブスクリプション変換後の設定を区別してください。変換ツールを使うと解析処理が1段階増えるため、問題はリモート取得、形式変換、コアへの読み込みのいずれでも起こり得ます。

複数の端末で使う場合は、各端末に同じアカウントで利用が許可されているサブスクリプションを読み込めますが、公開同期ドキュメントにリンクを保存しないでください。VPNFD のプランは利用端末数に制限がありません。それでも、各プラットフォームのクライアントでプロトコル対応、権限状態、更新方法を個別に確認してください。設定内容が同じでも、OSの動作まで同じとは限らないためです。

リンクが漏えいした後の対応手順

サブスクリプションリンクには、アカウント設定を識別するトークンが含まれる場合があります。リンクが公開スクリーンショット、ブラウザの同期履歴、公開ドキュメント、コードリポジトリ、管理外の端末に残っていることに気づいたら、公開テキストを削除するだけでなく、古い入口も無効化してください。リンクを取得した人が設定を要求できる可能性があるためです。

  1. 拡散を止める。公開ページ、共有ドキュメント、メッセージにあるリンクのコピーを削除し、スクリーンショットや書き出しファイルが残っていないか確認します。
  2. ユーザーパネルでサブスクリプションの入口をリセットする。新しい入口を生成した後は、旧リンクが無効になっているかをパネルの実際の状態で確認し、古いURLを再利用しないでください。
  3. 信頼できる端末を更新する。古いサブスクリプションを削除するかリモートURLを置き換え、更新を実行してクライアントが新しい設定を読み込んでいることを確認します。
  4. ローカルに残った情報を削除する。クリップボード履歴、ターミナル履歴、ブラウザのダウンロード履歴、設定のバックアップ、クラウド同期ドキュメントを確認します。
  5. アカウント状態を確認する。身に覚えのない利用がある場合やリセットを完了できない場合は、ユーザーパネルから状況を説明して問い合わせを送信してください。

「ノード名を非表示にする」ことを漏えい対策と考えないでください。ノードの備考は通常、アクセス認証情報ではありません。本当に保護すべきなのは、サブスクリプション入口全体と直接読み込める設定内容です。クライアント内の表示名を変更するだけでも、リモート入口のアクセス状態は変わりません。

読み込みに失敗した場合の確認順序

読み込みに失敗したときは、エラーがどの層で発生したかを見極めるのが最も有効です。クライアントに取得タイムアウトと表示された場合は、まずローカルネットワークとサブスクリプション取得を確認します。形式エラーなら、コピーが完全か、クライアントが返却形式に対応しているかを確認します。更新できても一部のノードが欠ける場合は、プロトコル対応と解析ログを確認します。ノードを選べても対象サイトにアクセスできない場合は、回線、DNS、ルーティング、対象サービスの条件を確認してください。

サポート担当者にログを提供する必要がある場合は、サブスクリプションURL、認証項目、ノード設定を復元できる内容を先に削除し、日時、エラーの種類、クライアントバージョン、OS、再現手順だけを残してください。ログは障害の層を説明するためのものであり、サブスクリプション入口を再拡散する経路にしてはいけません。

一連の流れは、パネルから取得し、対応クライアントに読み込み、プロトコル解析を確認し、接続後にルーティングとDNSを確認し、必要に応じて手動更新し、リンクが公開されたらすぐにリセットする、という形にまとめられます。各手順を明確な障害レイヤーに対応させると、クライアントやノードを何度も変更するより原因を見つけやすくなります。