サブスクリプションリンクとは？簡単に言えば、サブスクリプションサービスが生成し、対応クライアントが読み取るためのアドレスです。クライアントがこのアドレスにアクセスすると、ノード名、サーバーアドレス、ポート、プロトコルパラメータ、サービス側が提供する一部のグループ情報を取得できます。クライアントそのものでも、固定された1本の回線でもありません。より正確には、クライアントとサーバー側の設定を同期するための入口です。

初回利用時は、通常、サービス画面からサブスクリプションアドレスをコピーし、クライアントで「リンクからインポート」などの項目を選ぶだけです。インポートに成功すると、クライアントがリモート設定をローカルで選択できるノードに変換します。その後、サーバー側で回線が追加されたり接続パラメータが調整されたり、古いノードが停止されたりした場合も、サブスクリプションを更新すれば変更を取得できます。項目を一つずつ手入力する必要はありません。

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

サブスクリプションの中心となるのは接続設定です。一般的な項目には、サーバーのドメインまたはアドレス、接続ポート、暗号化や認証のパラメータ、通信方式、ノード名、グループに関する情報などがあります。必要な項目はプロトコルによって異なるため、クライアントが該当プロトコルを実際にサポートしている必要があります。「サブスクリプションのインポートに対応」と書かれているだけで、すべてのノードに接続できるとは限りません。

情報の種類 通常含まれるか 実際の役割 よくある誤解
ノード接続パラメータ 含まれる クライアントに接続先と認証・通信方式を伝える ノード名が似ていても、出口の場所や回線品質が完全に同じとは限らない
プロトコル設定 含まれる Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICなどの接続に必要なパラメータを記述する クライアントがリンクを認識できても、そこに含まれるすべてのプロトコルを完全にサポートするとは限らない
グループ分けと並べ替え 形式によって異なる 地域、用途、自動選択用のグループをクライアント上で表示しやすくする サーバー側のグループ設定が、ローカルのすべてのルール分岐を自動で上書きするわけではない
クライアントアプリ 含まれない 対応ソフトを別途インストールする必要がある サブスクリプションアドレスをコピーしただけでは、ネットワーク接続は確立されない
ローカルシステムの権限 含まれない プロキシやトンネルを有効にする際に、システムとクライアントが要求する サブスクリプションサービスが、システム権限の確認を代行することはない

プロトコル名は回線の種類を意味するものでもありません。Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICは、クライアントと接続先サーバーがどのように通信するかを示します。一方、IEPL専線、中継、直接接続は、接続地点から出口までトラフィックが通るネットワーク経路を示します。両者は異なる層の情報です。

直接接続は、ローカルネットワークから遠隔の接続先サーバーへ直接アクセスする方式です。経路が単純な一方、通信事業者間の接続状況に左右されやすくなります。中継回線は、まず近い入口に接続し、そこから中継ネットワークを経由して出口へ送ります。ネットワークをまたぐ経路の改善に使われることがあります。IEPL専線は、特定の企業向け国際伝送リソースを利用する仕組みであり、ノード名に「専線」と書かれているだけで実際のネットワーク構成を判断することはできません。サービス提供元の説明を確認し、プロトコル名だけでなく時間帯ごとの安定性も見て判断しましょう。

結論：サブスクリプションリンクは設定を届け、プロトコルは接続を確立し、回線の種類は途中の経路を決めます。トラブルを切り分ける際は、これらを別々の層として確認してください。そうしないと、クライアントの互換性問題を回線障害と誤認しやすくなります。

サービス画面からサブスクリプションを取得して安全に保存する

サブスクリプションアドレスは、サービス画面、公式クライアント、またはサービス提供元が明確に案内している入口から取得してください。検索結果にある出所不明の「変換ページ」や、無作為なオンライン検査ツールにアドレスを貼り付けないでください。サブスクリプションリンクにはアカウント設定を識別できるトークンが含まれていることがあり、リンクを持つ人が同じノード情報を読み取れる可能性があります。通常のウェブリンクではなく、認証情報として管理しましょう。

  1. 対象サービスの管理画面にログインし、サブスクリプション、クライアント設定、または設定のインポート項目を探します。
  2. 利用するクライアントに合わせて対応形式を選びます。管理画面で汎用サブスクリプションと特定クライアント向け設定が分かれている場合は、クライアントに合う形式を優先してください。
  3. アドレス全体をコピーし、先頭や末尾、クエリパラメータが欠けていないか確認します。チャットアプリによる自動切り詰め、テキストの改行、余分な空白はインポート失敗の原因になります。
  4. そのままクライアントへ切り替えてインポートしてください。公開短縮URL、QRコード作成サイト、オンラインのテキスト処理ページを経由しないでください。
  5. インポート後にサブスクリプション名とノード一覧を確認し、そのうえで更新を実行します。ノードが表示されても、接続の検証まで完了したとは限りません。

自分の端末間で受け渡す必要がある場合は、管理下にあるローカルな方法や、信頼できるエンドツーエンド同期ツールを優先し、完了後に一時的な記録を削除してください。スクリーンショットにも注意が必要です。QRコード自体に完全なサブスクリプションアドレスを含められるため、周囲の文字を隠しただけではQRコードの内容は隠れません。

各プラットフォームのクライアントへのインポートにどんな違いがあるか

プラットフォームによってボタン名は異なりますが、基本的な流れは同じです。対応クライアントをインストールし、サブスクリプションを追加してアドレスを貼り付け、更新を実行し、ノードまたはポリシーグループを選択します。重要なのはボタンがどのメニューにあるかではなく、クライアントの対応範囲、システムプロキシの方式、バックグラウンド実行の制限です。

Windows と macOS

デスクトップクライアントには通常、サブスクリプション管理画面があり、複数の配信元を保存して手動更新できます。インポート後は動作モードも選択する必要があります。システムプロキシモードは、システムのプロキシ設定に従うアプリを主に制御します。仮想NICやトンネルモードはより広い範囲をカバーしますが、システム権限が必要で、ほかのネットワークツールと競合することもあります。

macOSのクライアントは、システム拡張、ネットワークフィルタ、スリープからの復帰の影響も受けます。復帰後もノードが接続済みと表示されるのにウェブページを読み込めない場合は、いったん切断して再接続し、システムに別のプロキシ設定が残っていないか確認してください。Windowsで同様の症状が出た場合は、クライアント終了後もシステムプロキシが有効なままになっていないか確認します。

Android と iOS

モバイルプラットフォームでは通常、システムが提供するVPNインターフェースを通じてトラフィックを制御します。サブスクリプションをインポートすると、システムからネットワーク設定の権限確認を求められます。クライアントがバックグラウンドに移行すると、省電力設定、バックグラウンド制限、ネットワーク切り替えが長時間接続に影響することがあります。Wi-Fiとモバイルデータ通信を切り替えた後に接続状態が戻らない場合は、サブスクリプションを何度も削除するのではなく、セッションを再確立してください。

モバイルクライアントの中にはクリップボードからリンクを認識できるものもあれば、サブスクリプション管理画面に手動で貼り付ける必要があるものもあります。カメラでQRコードを読み取る際は、自分のサービス画面に表示されたものか確認してください。他人が共有した不明な設定を読み取らないでください。サーバー、DNS、ルーティングの設定が想定と異なる可能性があります。

Linux とルーター環境

Linuxクライアントは、GUIを使う場合もあれば、コアプログラムと設定ファイルを組み合わせて動かす場合もあります。デスクトップ環境のシステムプロキシは、その設定に従うソフトウェアにのみ影響します。コマンドラインのプログラムでは、環境変数を個別に設定するか、透過プロキシや仮想NICの方式を使う必要があります。インポートに成功したのに端末からのリクエストがローカルの出口を通る場合は、トラフィックの制御範囲が異なることが原因であり、サブスクリプション内容が欠落しているとは限りません。

ルーター環境では、アーキテクチャ、カーネルの機能、DNS転送、ファイアウォールルールをより慎重に確認する必要があります。サブスクリプションをルーターにインポートすると、同じネットワークに接続するほかの端末にも設定が影響します。変更前に復元可能な設定を保存してください。初回の動作確認だけなら、ネットワーク全体を変更するより、まず1台の端末で接続テストを行うほうが問題を特定しやすくなります。

プラットフォーム別の確認点：デスクトップではシステムプロキシとトンネルモード、モバイルではシステム権限とバックグラウンド状態、Linuxとルーターではトラフィックの制御範囲を重点的に確認します。インポートメニューの違いは表面的な差にすぎません。

サブスクリプションの更新で変わるもの

サブスクリプションを更新すると、サーバー側の設定を再取得し、ノードの追加・削除、アドレスの変更、プロトコルパラメータ、グループ構成の変化がローカルに反映されます。ユーザーが作成したすべてのルールが自動で変更されるわけではなく、クライアント側のDNS、ログ、画面、起動設定まで置き換わるとは限りません。反映範囲はサブスクリプション形式とクライアントの実装によって異なります。

すべての環境に当てはまる決まった更新間隔はありません。ノードが正常に使えているなら、頻繁に更新する必要はありません。サービス画面で回線の調整が案内された場合、ノード一覧が画面と一致しない場合、既存ノードに継続して接続できない場合、またはクライアントを変更して設定を再解析したい場合に更新すると有効です。自動更新に対応している場合も、実際の利用頻度に合わせて有効にしてください。頻繁な更新を速度向上の手段にしないことが大切です。

更新の前後にはローカルで行った変更にも注意してください。クライアントによってはノード名や接続パラメータを編集できますが、次回のサブスクリプション更新で上書きされることがあります。長期的に保持したいルールは、クライアントが対応するローカルルール層、オーバーライド層、または独立した設定に保存し、サブスクリプションが管理するリモート項目を直接変更しないでください。

更新に失敗したときの確認順序

  1. サブスクリプションアドレスが現在のサービス画面に表示されたものか確認します。古いバックアップや、すでに取り消されたリンクを使っていないかも確認してください。
  2. リンクが途中で切れていないか、特に末尾のパラメータ、特殊文字、コピー時に混入した空白を確認します。
  3. いったん現在のプロキシ接続を切断してから再度更新し、誤ったノードがサブスクリプションのリクエストを妨げていないか切り分けます。
  4. クライアントがサーバーから返された形式に対応しているか確認します。管理画面に専用形式がある場合は、該当する入口から再度コピーしてください。
  5. クライアントのコアを更新してから、もう一度インポートします。古いコアでは新しいプロトコル項目を認識できないことがあります。
  6. それでも失敗する場合は、エラーメッセージを記録し、サービス提供元のサポート窓口で確認してください。完全なリンクを公開して送信してはいけません。

更新が成功したと表示されたのに一覧が変わらない場合、サーバー側の内容に変更がないか、クライアントのキャッシュがまだ更新されていない可能性があります。サブスクリプション管理画面に戻って更新時刻を確認し、ノード一覧を開き直してください。すべてのローカル設定を直接削除する方法は最後に検討します。カスタムのルール分岐やオーバーライドまで同時に消える可能性があるためです。

ルール分岐とDNSが結果に影響する理由

サブスクリプションのインポートが完了しても、すべてのトラフィックが同じノードを通るとは限りません。ルールモードでは、ドメイン、アドレス範囲、アプリ、ルールセットに応じて、プロキシ、直接接続、拒否のいずれかを決めます。グローバルモードはより多くの接続を現在のノードへ渡すため、「ルールに一致していないのか」を短時間確認する用途に向いています。ただし、長期的にどのモードを使うかは、アクセス先とローカルネットワークの要件に合わせて決めてください。

よくあるのは、ブラウザは正常にアクセスできるのに、特定のアプリだけ接続できないケースです。アプリがシステムプロキシに従っていない、クライアントが制御していないネットワークプロトコルを使っている、またはルール分岐で対象が直接接続と判定されている可能性があります。反対に、国内サイトまで明らかに遅くなった場合は、ルールの範囲が広すぎて、本来直接接続に向くトラフィックまで遠隔の出口を経由している可能性があります。

DNSの名前解決は、ルール判定の前またはその過程でも作用します。ドメインをローカルネットワークで解決し、実際の接続を遠隔ノードから行うと、解決結果と出口地域が一致しないことがあります。DNSリークとは通常、管理された経路で行うべき名前解決リクエストがローカルのリゾルバーへ送られ、検索対象が露出したり地域判定にずれが生じたりする状態を指します。サブスクリプションリンクの漏えいとは別の問題なので、それぞれ個別に対処してください。

出口を確認したい場合は、本站のネットワークチェックで現在のアドレスと基本的なネットワーク情報を確認できます。接続は成功するのにアクセスできない、ルールが機能しない、名前解決に異常があるといった場合は、問題診断の手順に沿って層ごとに確認してください。テストでは一度に1つの条件だけを変更します。たとえばノードだけ、または動作モードだけを切り替えることで、変化の原因を特定できます。

サブスクリプションリンクの漏えい後に行うこと

サブスクリプションリンクを公開ページ、共有ドキュメント、公開サポートチケット、コードリポジトリ、信頼できない変換ツールに貼り付けたことがある場合は、漏えいしたものとして扱ってください。公開メッセージを削除するだけでは不十分です。内容がキャッシュ、転送、収集されている可能性があるためです。サービス画面でサブスクリプションリンクをリセットするか、サポートに連絡して古いトークンを無効化し、新しいリンクを自分のクライアントへインポートしてください。

  1. 古いリンクの使用や拡散を止め、削除できる公開コピーを削除する。
  2. サービス画面でサブスクリプションの認証情報をリセット、無効化、または再生成する。該当項目がない場合はサポートチケットで依頼する。
  3. クライアントから古いサブスクリプションを削除し、新しいアドレスをインポートしてノードを更新する。
  4. 自分が所有するほかの端末も確認し、無効化済みの古いサブスクリプションをリクエストし続けないようにする。
  5. 公開したスクリーンショット、QRコード、設定バックアップに復元可能な古いアドレスが残っていないか確認する。

サブスクリプションリンクのリセットは、通常、設定配布の層で認証情報を変更するだけであり、クライアントが新しいアドレスを自動取得することを意味しません。古いリンクをインポート済みの端末では、1台ずつ置き換える必要があります。ある端末に一時的にアクセスできない場合は、安全に操作できるようになってから更新し、公開チャットの履歴で新しいリンクを送らないでください。

最終判断：サブスクリプションリンクは通常のダウンロードアドレスではなく、取り消し可能な設定用認証情報として扱いましょう。取得時はサービス画面を確認し、インポート時はクライアントに合う形式を選び、更新時はローカルルールを保護し、漏えいしたら古いリンクを直ちに無効化して再インポートします。

初心者向けトラブルシューティングの手順

「インポートしたのに使えない」という問題では、ソフトウェアを次々に変えるより、設定の配布、プロトコルの互換性、回線接続、トラフィックの制御、ルール分岐、DNS解決の順に確認するほうが効果的です。前の層を確認しないまま次の層をテストすると、結果を誤って判断しやすくなります。

ノード一覧が空の場合は、まずサブスクリプション形式とアドレスの完全性を確認します。ノードは存在するのにハンドシェイクに失敗する場合は、プロトコル対応、システム時刻、ネットワーク到達性を優先して確認します。接続は成功するのにアプリがノードを通らない場合は、制御モードとアプリのプロキシ設定を確認します。一部のウェブサイトだけに問題がある場合は、ルール分岐とDNSを確認してください。この順序ならクライアントを何度も削除するより早く、ローカルルールの消失も防げます。

初期設定で疑問がある場合は、本站の使い方ガイドでサービス画面からクライアントまでの基本手順を確認するか、回線一覧で地域と回線の種類を確認してください。ノード選びでは、地理的な近さだけを追い求める必要はありません。利用中の通信事業者の経路、接続方式、中継品質、アクセス先サービスの場所が実際の通信状況に影響します。