サブスクリプションリンク完全ガイド:取得・インポート・更新・漏えい対策

サブスクリプションリンクの用途、取得場所、クライアントへのインポート方法、更新のタイミング、漏えい時の正しい対処を解説します。

サブスクリプションリンクは、クライアントが接続設定を取得するための入口です。通常、特定の固定回線そのものでも、ブラウザで直接使う一般的なウェブアドレスでもありません。サブスクリプションサービスが生成し、対応クライアントが読み取る設定URLです。基本的な流れは、サービスの管理画面からリンクを取得し、対応クライアントにインポートしてから、ノード一覧を更新し、ノードを選択して接続結果を確認することです。

初心者が混同しやすいのは、サブスクリプションリンク、ノード設定、接続プロトコルの3つです。サブスクリプションリンクは設定の配布と更新を担い、ノード設定にはサーバーアドレス、ポート、認証情報、通信パラメータが含まれます。Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC などは、クライアントとノードの通信に使われるプロトコルまたはプロトコル体系です。この関係を理解すると、インポート失敗、ノードが表示されない、更新エラー、リンク漏えいへの対処が容易になります。

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

サブスクリプションリンクは通常、ランダムなトークンを含む1つのURLです。クライアントがそのURLにアクセスすると、サーバーから複数のノード設定が返されます。返却内容はエンコードされたテキストの場合もあれば、特定のクライアント向けの設定形式の場合もあります。インポートできるかどうかは、クライアントがそのサブスクリプション形式を解釈できるか、また設定内のプロトコルに対応しているかで決まります。

1つのサブスクリプションで、地域、入口、回線タイプの異なるノードを同時に提供できます。クライアントに表示されるノード名は識別用のラベルにすぎません。接続結果を左右するのは、プロトコル、通信方式、TLS 設定、サーバー名、UDP 対応、ルーティングルールなどのパラメータです。ノード名だけをコピーしても、完全な設定を再現することはできません。

項目 役割 よくある誤解
サブスクリプションリンク クライアントが設定一式を取得・更新できるようにする 固定ノードのアドレスだと思う
ノード設定 接続先、認証パラメータ、通信条件を定義する 地域名だけを見て、プロトコルの互換性を無視する
接続プロトコル クライアントとサーバーが通信を確立する方法を定める すべてのクライアントが全プロトコルに対応していると思う
ルーティングルール どのリクエストをプロキシ経由にし、どれを直接接続するか決める ルーティングの誤りをノード障害だと思う

主なプロトコルの見方

Shadowsocks は暗号化プロキシプロトコルで、設定が比較的シンプルであり、対応クライアントも多くあります。VMess は V2Ray 系の認証プロトコルで、さまざまな通信方式と組み合わせて使われます。VLESS は認証と暗号化の役割を分けており、実際の導入では TLS などの安全なトランスポート層に依存することが一般的です。プロトコル名だけで接続条件を判断することはできません。

Trojan は通常 TLS 上で動作するため、クライアントで証明書、サーバー名、通信パラメータを正しく処理する必要があります。Hysteria2 と TUIC は主に QUIC と UDP をベースとしており、不安定なネットワークに対して異なる輻輳制御を行います。ただし、利用中のネットワークで UDP が制限されていると、接続できなかったり動作が不安定になったりすることがあります。プロトコルに絶対的な優劣はなく、クライアントの対応状況、利用中のネットワーク、サーバー設定を合わせて判断してください。

サブスクリプション形式とプロトコル形式は同じものではありません。あるクライアントが Trojan の単一ノードをインポートできても、サービス側が提供するサブスクリプション構造に対応しているとは限りません。別のクライアントではサブスクリプションを読み取れても、そこに含まれる Hysteria2 設定を認識できない場合があります。「インポートは成功したのにノードがない」ときは、ネットワーク権限を何度も切り替える前に、形式の互換性を確認してください。

サブスクリプションリンクの取得場所

サブスクリプションリンクは、サービスのアカウント管理画面、クライアント設定ページ、またはサービス提供元が明示したダウンロード入口から取得してください。ログイン後の入口には、「サブスクリプション」「設定」「クライアントにインポート」「サブスクリプションをコピー」などの名称が使われます。汎用サブスクリプションと特定クライアント向けサブスクリプションが用意されている場合は、現在のクライアントに合う形式を優先してください。

検索結果、公開グループ、画像からの文字認識結果、見知らぬチュートリアルのサンプルURLから、実際に使う設定を取得しないでください。公開されたリンクはすでに無効になっている可能性があり、出所を確認できない設定を指している場合もあります。チュートリアルのURLは形式を理解するための例にすぎず、実際の接続元として使うものではありません。

https://example.com/sub?token=sample-token

上のアドレスはダミーの例です。実際のサブスクリプションには、アカウント権限を識別するランダムなトークンが含まれることが多く、完全なリンクを知っていれば設定を取得できます。コピーする際はパラメータが途中で切れていないことを確認し、引用符、空白、改行を追加しないでください。一部のチャットツールでは長いURLに見えない文字が挿入され、クライアントで形式エラーになることがあります。

  • 現在利用しているサービスの管理画面から取得したリンクか確認する。
  • 選択したサブスクリプション形式がクライアントに対応しているか確認する。
  • URL全体をコピーし、トークンやクエリパラメータを手動で書き換えない。
  • 実際のリンクを公開ドキュメント、コードリポジトリ、共有スプレッドシートに保存しない。
  • インポート後、ノード名と管理画面の情報を照合して出所を確認する。

クライアントへの標準インポート手順

クライアントによってボタンの位置は異なりますが、操作の流れはほぼ共通しています。対応クライアントをインストールし、サブスクリプションURLを追加して更新を実行します。その後、ノードを選択し、システムプロキシまたはトンネルモードを有効にして、目的のサービスへのアクセスと DNS 経路を確認します。インポート後の異常をすぐに回線の問題と決めつけないでください。モードが有効になっていない、またはルールが古い設定を参照していることもよくあります。

インポート前にクライアントの対応状況を確認

まず、クライアントがサブスクリプション内のプロトコルに対応しているか確認します。サービスの管理画面に専用クライアントが案内されている場合は、形式変換に起因する問題を減らせます。汎用クライアントを使う場合は、公式ドキュメントに記載された対応プロトコルとサブスクリプション形式を確認してください。クライアントのバージョンが古いと、インポートできても新しいプロトコル項目が無視されることがあります。

Windows と macOS のクライアントには、通常、システムプロキシモードと仮想ネットワークアダプターモードがあります。システムプロキシはOSのプロキシ設定に従うアプリを主に対象とし、仮想ネットワークアダプターモードはより多くの通信をカバーできますが、対応するシステム権限が必要です。Linux のクライアントは、GUI、デーモン、コマンドラインで管理することが多く、DNS とルーティング設定はディストリビューションの環境により大きく異なります。

iOS と Android では通常、システムが提供する VPN インターフェースを使ってローカルトンネルを確立します。クライアントはシステム内にネットワーク設定を作成し、初回の有効化時に権限の確認を求めます。バックグラウンド動作、オンデマンド接続、アプリごとのルーティングに関する対応はモバイルOSによって異なるため、デスクトップ版の手順をそのまま当てはめないでください。

基本的なインポート手順

  1. サービスの管理画面で、現在のクライアントに対応するサブスクリプションリンクをコピーする。
  2. クライアントのサブスクリプション、設定ソース、リモート設定のページを開く。
  3. URLから追加する項目を選び、完全なリンクをアドレス欄に貼り付ける。
  4. 識別しやすい名前を付け、保存後に更新を実行する。
  5. 地域、回線、プロトコルの表示が適切なノード一覧になっているか確認する。
  6. 目的のノードを選び、システムプロキシまたはトンネルモードを有効にする。
  7. 目的のサービスにアクセスし、DNS、出口地域、アプリ内の接続状態を確認する。

クライアントがQRコードによるインポートに対応している場合は、QRコードが自分のアカウント管理画面から表示されたものか確認し、公開配信やスクリーンショットに画面が映り込まないようにしてください。QRコードはリンクを別の形で表しただけであり、含まれる認証情報の機密性が下がるわけではありません。

インポートに成功しても、接続済みとは限りません。サブスクリプション追加後にノードを自動選択しても、システムプロキシが無効のままというクライアントがあります。別のクライアントではプロキシコアが起動していても、ブラウザやアプリの通信を取り込めていないことがあります。サブスクリプションの更新状態、現在のノード、稼働状態、通信の取り込みモードをそれぞれ確認してください。

サブスクリプションの更新と古い設定の扱い

サブスクリプション更新の目的は、サーバーから設定を再取得することです。回線名、入口アドレス、証明書パラメータ、対応プロトコルなどが変更されても、古いキャッシュは自動的に変化を把握できないため、サブスクリプションを更新する必要があります。自動更新に対応している場合は、実際の利用頻度に合わせて設定してください。長期間使っていなかった場合は、再接続前に手動更新するほうが確実です。

更新すると通常、サブスクリプションで管理されるノードは上書きされますが、手動で作成したローカル設定には影響しません。サブスクリプション内のノードを編集できるクライアントでは、次回の更新時に変更が上書きされることがあります。長く保持したい個人ルールは、クライアントが対応するオーバーライド、ルールセット、独立した設定領域に保存し、サブスクリプションが生成した内容を直接編集しないでください。

更新に失敗したときの切り分け

まず、どの層でエラーが起きているか確認します。アドレスを解決できないと表示された場合は、リンクが完全か、DNS が正常か、現在のネットワークからサブスクリプションのドメインにアクセスできるかを確認してください。未認証またはサブスクリプションが存在しないと返された場合は、トークンの期限切れ、アカウント状態の変化、古いリンクのリセットが考えられます。ダウンロードは成功しても解析に失敗する場合は、クライアントとサブスクリプション形式の互換性に問題がある可能性が高いです。

症状 優先して確認する項目 対処の方向性
サブスクリプションをダウンロードできない アドレスの完全性、DNS、ローカルネットワーク リンクをコピーし直し、ネットワークの名前解決を確認する
未認証と表示される サブスクリプションのトークンとアカウント管理画面の状態 管理画面からリンクを再生成または再取得する
更新後にノードが空になる サブスクリプション形式とクライアントの互換性 対応する形式または対応クライアントに切り替える
ノードはあるがアクセスできない プロトコル対応、接続モード、ルーティング、DNS クライアントのログを確認し、層ごとに検証する
古いノードが表示され続ける キャッシュ、更新元、現在の設定グループ 現在使っているサブスクリプションを更新しているか確認する

古いサブスクリプションを削除する前に、新しいサブスクリプションを正常に取得でき、接続できることを確認してください。同名のサブスクリプションが複数あると、クライアントが古い設定グループを使い続け、更新が完了してもノードが変わらないことがあります。サブスクリプションの取得元、更新時刻、ノード名を手がかりに、現在正しいものが選択されているか確認できます。

回線タイプとノード選択

サブスクリプション一覧の「直接接続」「中継」「IEPL」などのラベルは、経路設計の違いを示すもので、接続プロトコルではありません。直接接続は通常、利用中のネットワークから海外ノードへ直接接続します。経路がシンプルな一方、利用地域の通信事業者や国際出口の影響を受けやすくなります。中継回線では、まず近い入口に接続し、その後中継ネットワークから出口ノードへ転送します。一部地域で経路品質を改善できる一方、入口の混雑や転送経路も結果に影響します。

IEPL は国際イーサネット専用線に類する接続を指し、サービス提供者の入口と海外リソースの間で専用の伝送路として使われることがあります。公共インターネットへの直接接続とは経路方式が異なりますが、入口までのローカルネットワーク、クライアント端末、接続先サービスも最終的な使用感に影響します。専用線のラベルがあっても、すべての環境で同じ結果になると考えないでください。

ノードを選ぶときは、まず目的の地域を決め、その後に回線タイプとプロトコルの互換性を比較してください。ウェブ閲覧、長時間の接続、容量の大きいファイル転送では、重視すべき点が異なります。ウェブ閲覧では応答の連続性、長時間の接続ではセッション維持、ファイル転送では安定したスループットとパケットロスがより重要になります。

遅延テストで分かるのは、測定時点における測定先との往復状況であり、対象サイトの読み込み速度を単独で示すものではありません。クライアントでテストに失敗しても、測定先が遮断されているだけで、ノード自体は接続できる場合があります。最終的には、実際に使うサービス、連続利用時の動作、切り替え後の安定性で判断してください。

DNS 漏れとルーティングルールの確認

DNS 漏れとは、アプリの通信はプロキシやトンネルを経由しているのに、ドメイン検索だけがローカルネットワークの DNS 経路から送信される状態です。地域判定の不一致、名前解決結果の異常、ローカルのDNS事業者による照会先ドメインの把握につながる可能性があります。漏れが起きるかどうかは、クライアントのモード、システムDNS、ブラウザのセキュアDNS、ルーティング設定に左右されます。

システムプロキシモードでは、プロキシ経由の名前解決に対応するアプリはプロキシでドメインを処理できますが、システムプロキシに従わないアプリは直接検索する可能性があります。仮想ネットワークアダプターモードは通常、より広い通信を取り込めますが、クライアントのDNSモードとルーティングルールも確認が必要です。ブラウザで独立したセキュアDNSを有効にしていると、クライアントが想定する名前解決経路を迂回することがあります。

ルーティングルールは、リクエストをプロキシ経由にするか直接接続にするかを判断します。判定材料には、ドメイン、IP、アプリ、ルールセットなどがあります。ルールが古いと、目的のドメインが直接接続に分類されることがあります。優先順位を誤ると、範囲の広い直接接続ルールが先に適用される場合もあります。問題がルーティングに由来するか確認するにはグローバルモードが役立ちますが、常用するモードは実際の接続先と利用環境に合わせて決めてください。

  • 現在、ルールモード、グローバルモード、直接接続モードのどれが選択されているか確認する。
  • 目的のドメインに最終的に適用されたルールと出口を確認する。
  • トンネルの有効化に合わせて、クライアントのDNSも切り替わっているか確認する。
  • ブラウザで独立した名前解決設定が有効になっていないか確認する。
  • モードを切り替えた後、古い接続を終了して目的のアプリを開き直す。

グローバルモードでは使えるのにルールモードでは使えない場合は、ルーティングを重点的に確認します。ノードは接続を確立できるのにドメインを開けず、既知の接続先アドレスを直接入力した場合に異なる結果になるなら、DNS を重点的に確認してください。どのモードでもハンドシェイクできない場合は、プロトコル、証明書、UDP 対応、ローカルネットワークの順に切り分けます。

サブスクリプションリンクが漏えいしたときの正しい対処

実際のサブスクリプションリンクが公開ページ、共有ドキュメント、公開コードリポジトリ、画面録画、または誤った相手への送信に含まれた場合は、すでに漏えいしたものとして扱ってください。公開内容を削除するだけでは十分ではありません。リンクがキャッシュ、コピー、自動取得されている可能性があるためです。正しい対処は、古いリンクを無効にしてから、すべてのクライアントの設定を置き換えることです。

推奨する対処の順序

  1. アカウント管理画面を開き、サブスクリプションリンクをリセットするか、新しいサブスクリプショントークンを生成する。
  2. 古いリンクで設定を取得できなくなったことを確認する。
  3. 管理画面から新しいリンクをコピーし、自分が管理するすべてのクライアントを更新する。
  4. クライアントに残っている古いURLを参照するサブスクリプションソースを削除する。
  5. 公開ページ、共有履歴、コマンド履歴、同期クリップボードに残る古いリンクを削除する。
  6. アカウント管理画面の接続情報と通信情報を確認し、異常があればサポート窓口に問い合わせる。

古いリンクの末尾に文字を追加したり、URLを短くしたり、ローカルのサブスクリプション名を変更したりしても、漏えい対策にはなりません。これらの操作では、サーバー側のトークンの有効性は変わらないためです。実際に有効なのは、サーバー側で古い認証情報を無効にし、新しいサブスクリプションURLを発行することです。

クライアントが完全な設定のエクスポートに対応している場合、出力ファイルにもサーバーアドレスや認証情報が含まれることがあります。扱いはサブスクリプションリンクと同じです。公開アップロードを避け、端末を譲渡する前に設定を削除し、バックアップはアクセスを管理できる場所に保管してください。ログファイルにサブスクリプションへのリクエストや接続パラメータが含まれることもあるため、トラブルシューティング情報を送る前に機密項目を確認してマスキングしてください。

よくある質問と最終チェック

ブラウザでリンクを開くと文字列が表示されるのはなぜですか?

サブスクリプションの応答は一般的なウェブページではなく、クライアント用の設定だからです。アカウント管理画面から取得したリンクであれば、対応クライアントに直接インポートしてください。内容を確認するために、実際のリンクをオンラインのデコードサイトへ入力しないでください。

インポートに成功したのにノードが1つも表示されないのはなぜですか?

まず、サブスクリプション形式とクライアントの互換性を確認してください。アカウント状態によってサーバーから空の内容が返されていないかも確認が必要です。管理画面で現在のクライアントに合う形式を選び、古いソースを削除してから再インポートしてください。

更新後も古い回線に接続されるのはなぜですか?

クライアントに古い設定グループが残っているか、現在のプロキシグループがキャッシュ済みのノードを固定選択している可能性があります。更新しているサブスクリプションが現在使用中の設定と一致するか確認し、ノードを選び直して、クライアントの手順に従って設定を再読み込みしてください。

サブスクリプションリンクは複数のプラットフォームで使い回せますか?

サービスの利用条件とサブスクリプション形式によって異なります。アカウントが複数のプラットフォームに対応していても、同じ汎用サブスクリプションがすべてのクライアントで使えるとは限りません。Windows、macOS、iOS、Android、Linux ではクライアントの対応状況が異なるため、それぞれサポートされている形式を選んでください。

ノードに接続できないときは、先にプロトコルと地域のどちらを変えるべきですか?

まずクライアントのエラーメッセージを確認してください。プロトコルが対応外なら、クライアントまたは互換性のあるノードを変更します。UDP が制限されている場合は、その経路に依存しない設定を試してください。特定の地域だけで異常が起きているなら、同じ地域の別回線と比較します。目的なく切り替え続けると、本当の原因を見失います。

まとめ: サブスクリプションリンクは設定を配布し、クライアントは設定を解析して通信を取り込み、ノードとプロトコルが実際の接続方法を決めます。取得時は出所、インポート時は互換性、更新時はダウンロードと解析のエラーを確認し、利用時はルーティングと DNS を点検してください。漏えいした場合は、古いリンクを直ちに無効化し、すべてのクライアント設定を置き換えます。
無料で始める