サブスクリプションリンクとは？取得・インポート・更新方法

サブスクリプションリンクとは、クライアントがノード設定を取得するための入口です。サーバーアドレスやポート、通信パラメータを一つずつ入力する必要はなく、サービスパネルからリンクをコピーし、対応するクライアントに読み込ませます。設定の配布と更新を簡単にする仕組みであり、ネットワークプロトコルそのものでも、インポート後の接続を保証するものでもありません。

サブスクリプションリンクには通常、サブスクリプションを識別するパスやトークンが含まれます。クライアントがそのアドレスにアクセスすると、サーバーはテキスト、エンコードされたノード一覧、または特定クライアント向けの設定形式を返します。内容には回線名、プロトコルパラメータ、グループ情報などが含まれる場合がありますが、実際の項目はサーバーの出力とクライアントの対応範囲によって異なります。見た目が一般的なURLに似ていても、公開してよいウェブページのアドレスとは考えないでください。

サブスクリプションリンクはアカウントの認証情報として管理してください。スクリーンショット、ログ、クラウドクリップボード、公開掲示板などに完全なリンクが残る可能性があります。問題を調べる際は、ドメイン以降の識別情報を隠してください。

サブスクリプションリンクとノード設定の関係

手動設定では、単一ノードに必要なパラメータをクライアントへ一つずつ入力します。サブスクリプションでは、複数の設定をまとめて取得できます。クライアントに入口を保存しておけば、同じ入口へ再度アクセスし、サーバーが現在提供しているノード一覧を取得できます。回線名の変更、ノードの増減、パラメータの変更は、通常クライアントでサブスクリプションを更新して初めてローカルに反映されます。

「ウェブパネルでは変更されているのに、クライアントには古い一覧が表示される」ことがあるのはこのためです。パネルはサーバーの最新情報を表示しますが、クライアントが使っているのは前回保存したコピーかもしれません。クライアントの終了、ネットワークの切り替え、端末の再起動だけでは、サブスクリプションが自動更新されるとは限りません。自動更新の有無とタイミングは、クライアント設定とサービス通知を確認してください。

サブスクリプションでプロトコルの対応能力が変わるわけではありません

サブスクリプションは設定を届ける仕組みで、実際に接続を確立するのはクライアントに内蔵または呼び出されるネットワークコアです。サブスクリプションがクライアントで認識できないプロトコルや項目を返した場合、そのノードが表示されない、インポート時に形式エラーになる、表示されても起動できないといった結果になります。サブスクリプションURLの形式を変えることで互換性の問題が解決する場合はありますが、必要なコアを持たないクライアントが突然そのプロトコルに対応するわけではありません。

プロトコルまたは方式	サブスクリプションでの役割	インポート時の確認事項
Shadowsocks	設定には通常、サーバー、ポート、暗号化方式、認証情報が含まれます。	クライアントが、設定で指定された暗号化方式とプラグインパラメータに対応しているか。
VMess	サブスクリプションでは、認証情報、通信方式、関連する接続項目を配布できます。	クライアントのコアが、サーバーから出力された通信の組み合わせを理解できるか。
Trojan	設定は通常、TLS接続、接続先アドレス、認証情報を中心に構成されます。	サーバー名、証明書検証、通信パラメータが正しく解析されているか。
VLESS	サブスクリプションは、認証、通信層、安全性に関する各種パラメータをまとめて配布します。	プロトコル名だけで判断せず、クライアントのコアのバージョンと項目の対応状況も確認してください。
Hysteria2	設定にはQUICベースの接続パラメータと認証情報が記述されます。	現在のプラットフォーム用クライアントに対応するコアが統合されているか、ネットワークがその通信方式を許可しているか。
TUIC	サブスクリプションでは、QUICベースのノード設定を配布できます。	クライアントの実装、証明書設定、サーバー側のパラメータが互いに一致している必要があります。

同じサブスクリプションに複数のプロトコルが含まれる場合もあれば、1種類だけの場合もあります。プロトコル名だけから回線品質を判断することはできません。接続体験は、利用場所のネットワーク、通信経路、出口側の負荷、接続先、利用時間帯などにも左右されるため、プロトコルのラベルだけでなく、自分の利用環境で確認してください。

パネルから取得して安全に保存

VPNPWはメールアドレスなしでアカウントを作成でき、ユーザー名とパスワードでパネルにアクセスできます。対象プランを利用すると、サブスクリプションの入口と利用可能な設定がパネルに表示されます。複数のクライアント形式がある場合は、URLの長さや項目数ではなく、現在使うクライアントに明確に対応した形式を選んでください。

アカウントパネルにログインし、現在のプランがサブスクリプションを取得できる状態か確認します。
サブスクリプションまたはクライアント関連のエリアを開き、形式名とプラットフォームの説明を確認します。
現在のクライアントに対応する完全なリンクをコピーし、手動選択で先頭や末尾の文字を欠落させないようにします。
そのままクライアントへ切り替えてインポートし、公開ウェブページ、オンラインデコードツール、共有ドキュメントには貼り付けないでください。
インポート後にサブスクリプション名とノード一覧を確認し、手動更新を1回実行して、クライアントが入口へ再度リクエストできることを確認します。

✅ リンクはログイン後の正式なパネルから取得し、現在のアカウントに対応しています。
✅ 選択した形式は、OS名だけで推測したものではなく、クライアントの説明と一致しています。
✅ インポート前後に、完全なリンクをスクリーンショット、問い合わせ本文、公開コードリポジトリへ載せていません。
✅ クライアントが失敗を示した場合は、エラーの種類を記録し、リンクを繰り返し公開して助けを求めていません。
❌ 信頼できない変換サイトへサブスクリプションリンクを送り、解析を依頼しないでください。

判断：ブラウザーでリンクを開けることは、サブスクリプション形式が正しいことを意味しません。ブラウザーに文字化け、テキストのダウンロード、短い文字列が表示されても、リンクが無効とは限りません。対応するクライアントにインポートし、クライアントが示す応答状態と解析結果を確認してください。

プラットフォームごとのインポートの違い

デスクトップクライアントには通常、「URLからインポート」「サブスクリプションを追加」などの入口があり、サブスクリプション名や更新設定を入力できます。モバイル端末では、クリップボードの認識、システムの共有メニュー、アプリ内の入力欄からインポートする場合があります。Linuxクライアントはさらに差が大きく、グラフィカルインターフェースを備えるものもあれば、設定ファイルやコマンドラインを中心とするものもあります。サブスクリプションの変換やコアの起動を別のコンポーネントが担当する場合もあります。

WindowsとmacOSでは、インポート後にアクティブな設定、ノード、またはプロキシグループを選ぶ必要があることが一般的です。サブスクリプションを一覧に追加しただけでは、システム通信がクライアント経由になったとは限りません。iOSとAndroidでは、システム設定のネットワーク構成作成リクエストを確認する場合もあります。このシステム表示は端末側のネットワーク経路を構築するためのもので、サービスアカウントの利用状態とは別のものです。

共通のインポート確認手順

クライアントで新しいサブスクリプションの配信元を作成し、完全なURLを貼り付けます。
保存後に手動で更新し、ネットワークリクエストの失敗なのか、内容の解析失敗なのかを確認します。
ノードが現在の設定に追加されていることを確認します。別の設定グループにインポートされていないか注意してください。
ノードまたはプロキシグループを選択し、システムプロキシ、仮想ネットワークアダプター、またはクライアントが提供する同等の接続方式を有効にします。
IP確認ページで出口を確認し、直接接続が必要な接続先とプロキシが必要な接続先を個別にテストします。

パネルでサブスクリプションの入口をコピー
→ クライアントでサブスクリプションを追加
→ 手動で更新をリクエスト
→ ノードとプロキシグループを解析
→ 現在の設定を選択
→ 接続方式を有効化
→ 出口とルール分岐の結果を確認

クライアントが「単一ノードをインポート」と「サブスクリプションを追加」の両方に対応している場合、混同しないでください。単一ノードのインポートでは、その時点の1項目だけが保存され、以後サブスクリプション一覧の変更には追随しません。サブスクリプションの追加ではリモートの入口が保持され、後から再取得できます。単一ノードを一時的に試すことに問題はありませんが、長期利用では自動更新されるサブスクリプションではないことを理解しておく必要があります。

あるクライアントから書き出したローカル設定を、別のクライアントへそのままインポートできるとは限りません。書き出しファイルには、ローカルのルール、ポート、プラットフォーム固有の項目が混在する場合があります。クライアント間で移行する際は、サービスパネルが提供する互換性のあるサブスクリプション形式を改めて利用するのが基本です。

サブスクリプションを更新して古い設定を確認する

サブスクリプションの更新とは、クライアントがリモートアドレスへ再度アクセスし、返された結果でローカル設定を更新することです。自動更新の頻度はクライアント設定で決まり、サーバー側のメンテナンス予定はサービス通知を確認します。すべてのクライアントに共通する固定間隔はないため、特定ソフトの初期値を一般的なルールと考えないでください。

回線一覧が明らかに古い、ノード名がパネルと一致しない、またはサービス通知で設定の更新を求められた場合は、まず手動更新を試します。更新に失敗したら、リクエスト段階と解析段階を分けて確認してください。リクエストの失敗は、ネットワーク到達性、リンクの状態、システム時刻に関係することが多く、解析の失敗は形式の非互換、返却内容の異常、クライアントコアの項目未対応を示す可能性があります。

現象	優先して確認する項目	対処の方向性
サブスクリプションのリクエストがタイムアウトする	現在のネットワークからサブスクリプションのドメインへアクセスできるか、システムプロキシがループしていないか。	利用可能なネットワークへ切り替え、誤ったプロキシ接続を一時停止して再試行します。
権限がない、またはリンクが無効と表示される	リンクが完全か、アカウントパネルで新しい入口が発行されていないか。	パネルに戻って再度コピーし、古いスクリーンショットのアドレスを使い続けないでください。
インポート後に一覧が空になる	クライアントが返却形式に対応しているか、内容がウェブページとして処理されていないか。	対応するサブスクリプション形式を選び、必要なら互換性のあるクライアントへ切り替えます。
更新は成功したのに古いノードが表示される	誤ったサブスクリプショングループを更新していないか、クライアントがキャッシュを保持していないか。	アクティブな設定を確認し、クライアントの仕組みに従って設定を再読み込みします。
ノードは表示されるが接続できない	プロトコルコア、通信パラメータ、ローカルネットワーク、システム時刻。	まず接続ログのエラー分類を確認し、その後ノードとネットワークを個別に検証します。

サブスクリプションを削除して再追加すると、一部のローカルキャッシュの問題を切り分けられますが、最初に行うべき手順ではありません。先にサブスクリプション名、クライアントの種類、エラー情報を記録すると、原因を特定しやすくなります。すぐに削除すると、ローカルルールや選択状態が失われ、比較可能だった状況も消える可能性があります。

判断：「更新成功」は、クライアントがサブスクリプションの内容を取得して受け入れたことを示すだけです。すべての回線が現在のネットワークに適していることや、第三者サービスへのアクセスが許可されることを意味しません。更新、接続、接続先の検証は分けて行ってください。

ルール分岐とDNSを確認する

サブスクリプションをインポートした後、クライアントはどのリクエストをプロキシ経由にし、どれを直接接続にするか判断します。一般的な基準には、ドメイン、IP範囲、アプリのプロセス、事前設定されたルールセットがあります。グローバルプロキシは短時間の切り分けに便利ですが、本来直接接続すべきローカルサービスまで迂回させる可能性があります。日常利用にはルール分岐が向いていますが、マッチングの順序とフォールバックの設定を確認してください。

ルールは通常、クライアントが定めた優先順位で実行されます。1つのドメインが複数の条件に一致する場合、結果はルールの順序、ルールセットの読み込み状態、DNSが返したアドレスなどに左右されます。ルール分岐を変更した後は、対象ドメイン、そのリソースドメイン、ログインに必要な関連サービスを個別にテストしてください。トップページが開くかどうかだけで、全体のアクセスが正常とは判断できません。

DNSリークがサブスクリプションに関係しても、サブスクリプションだけでは決まらない理由

サブスクリプションにDNSの推奨設定やクライアントのテンプレートが含まれる場合はありますが、最終的な名前解決の経路は、OS、クライアントのモード、ブラウザーのセキュアDNS設定、ルール分岐にも左右されます。DNSリークとは一般に、指定した解決経路で処理したい問い合わせが、システムの既定リゾルバーや別のインターフェースから送信される状態を指します。問い合わせ先が外部に露出したり、DNSの結果と選択した出口が一致しなくなったりする可能性があります。

✅ クライアントで想定したDNSモードが有効か、設定更新後も有効なままか確認します。
✅ プロキシ経由にしたいドメインの名前解決リクエストが、先にある直接接続ルールに奪われていないか確認します。
✅ ブラウザー独自のセキュアDNS設定が、クライアントの設定を迂回していないか確認します。
✅ 回線を切り替えた後に出口と名前解決の結果を再確認し、古いキャッシュだけで判断しないようにします。
❌ 「ウェブページが開く」ことを、DNS経路が想定どおりである証拠とみなさないでください。

切り分けでは、まず変数を減らします。一時的にクライアント推奨の基本設定を使い、サブスクリプション、ノード、出口が機能することを確認してから、カスタムDNSとルール分岐を段階的に戻します。基本設定では正常でカスタム設定で失敗する場合、問題は通常、ルールの順序、名前解決の経路、ローカルの上書き設定にあり、サブスクリプションリンクそのものではありません。

直接接続・中継・IEPLのラベルをどう見るか

回線名に「直接接続」「中継」「IEPL」と表示されている場合、それらはサブスクリプション形式ではなく、通信経路の説明として捉えてください。直接接続は通常、利用者のネットワークから海外の出口ノードへ直接接続することを示します。中継は、まず中間の接続拠点へ入り、その後の経路で出口へ到達する方式です。業界でIEPLは通常、国境を越える通信を運ぶ専用線リソースを指しますが、具体的な接続範囲、制御方法、最終出口はサービス側の設計によって異なります。

サブスクリプションはこれらの名称をクライアントに表示できますが、名称だけで物理的なネットワーク構成を証明することはできません。特定の回線が中継を経由するか、入口がどのように制御されるか、出口がどこにあるかは、サービス提供者の回線情報で確認する必要があります。利用者側では、実際の接続先、利用場所のネットワーク、利用時間帯を基準に検証し、ラベルを低遅延や安定性の保証と同一視しないことが適切です。

直接接続は経由する区間が少ない一方、利用地域の通信事業者ネットワークから海外出口までの品質に左右されます。中継は前半の経路を変えられますが、接続と制御の工程が増えます。IEPL系の回線は搬送経路を重視する場合がありますが、第三者サイトへのアクセスでは最終的に出口ネットワークを通過します。3つの方式に、利用環境を離れて適用できる共通の優先順位はありません。

選び方：まず接続先と必要な出口を確認し、実際のネットワークと普段の利用時間帯で、到達性、応答、継続的な通信性能を比較します。ラベルはテスト範囲を絞るために使い、テストの代わりにはしません。

リンク漏えい後の対処

サブスクリプションリンクが漏えいすると、第三者が含まれているノード設定を読み取り、許可なくサブスクリプションを利用したり、サーバー側の安全対策が作動したりする可能性があります。後から公開メッセージを削除しても、リンクがキャッシュ、通知のプレビュー、ログ、履歴に残る場合があります。そのため、元の投稿を削除するだけでは安全な状態に戻ったとはいえません。

漏えいに気づいたら、元のリンクの拡散を止め、パネルにログインしてリセットまたは再発行の入口があるか確認します。リセット後は、自分が管理するすべてのクライアントから古いサブスクリプションを削除し、新しいリンクをインポートします。パネルに操作項目がない場合は、漏えいした状況をサポートのチケットで説明してください。ただし、チケットの件名や通常本文に完全なアドレスを再掲せず、サポート手順に従って必要な情報だけを伝えます。

公開ページ、スクリーンショット、共有ドキュメントから完全なリンクを削除します。
アカウントパネルからサブスクリプションの入口をリセットするか、チケットサポートへ連絡します。
各端末から古いサブスクリプションの配信元を削除し、無効化したアドレスへのバックグラウンドリクエストを止めます。
新しい入口をインポートして設定を更新し、現在使用しているのが新しいサブスクリプションであることを確認します。
自動化スクリプト、バックアップ、同期ツールに古いリンクが残っていないか確認します。

サブスクリプションリンクとユーザー名・パスワードは役割が異なりますが、どちらも公開には適していません。サポート担当者が調査する際は、クライアント名、プラットフォーム、エラー表示、発生段階のほうが役立つことが多いです。まずこれらの状況を伝え、必要な認証情報は管理された手順に従って補足するほうが、完全なリンクを直接送るより安全です。

よくある質問と最終確認

サブスクリプションリンクは複数の端末にインポートできますか？

VPNPWは同時接続できる端末数に制限がありませんが、各端末で対応するクライアントを使用し、アカウントとサービスのルールを守る必要があります。端末ごとに異なるクライアント形式を使える場合もありますが、デスクトップから書き出したローカルファイルがモバイル端末に適しているとは限りません。

サブスクリプションを更新すると、カスタムルールは上書きされますか？

クライアントがリモート設定とローカルの上書きをどのように分けて管理するかによります。ローカルルールを独立して保存するクライアントもあれば、設定を再読み込みする際に関連項目を置き換えるクライアントもあります。変更前にクライアントの設定階層を確認し、復元できるローカルコピーを保存してください。

ノード名は表示されるのに、選択しても通信できないのはなぜですか？

ノードが一覧に表示されるのは、サブスクリプションの内容が解析されたことを示すだけです。そのノードが現在のプロキシグループに属しているか、クライアントの接続方式が有効か、システム通信がクライアントに入っているか、プロトコルコアが起動できるかも確認してください。接続ログを確認するほうが、何度もインポートをやり直すより効果的です。

サブスクリプションリンクはいつ再コピーすべきですか？

パネルで新しい入口が明確に発行された場合、元のリンクをリセットした場合、リンクが漏えいした場合、またはサービス通知で交換を求められた場合は、再度コピーしてください。通常のノード変更なら、まずサブスクリプションを更新すればよく、毎回削除して作り直す必要はありません。

設定が完了したら、以下の結果リストで確認を終えます。「リンクが有効」「ノードに接続できる」「ルール分岐が想定どおり」を分けて確認し、異なる段階の問題を混同しないようにします。

✅ クライアントがサブスクリプションをリクエストして解析でき、返却内容を通常のウェブページとして誤認していません。
✅ 現在のアクティブ設定は正しいサブスクリプショングループに由来し、ノードの選択が反映されています。
✅ 出口確認の結果が、選択した回線の目的地と一致しています。
✅ 直接接続先とプロキシ接続先に、それぞれ想定した経路でアクセスできています。
✅ DNSの問い合わせ経路、ブラウザー設定、クライアントのルールに明らかな矛盾がありません。
✅ 完全なサブスクリプションリンクが、公開スクリーンショット、ログ、共有ドキュメントに含まれていません。

サブスクリプションリンクの中心的な価値は、設定をまとめて配布し、更新できることです。正式なパネルから取得し、対応するクライアントへインポートし、リクエストと接続を段階的に検証し、漏えいした場合は速やかに入口をリセットしてください。