サブスクリプションURLとは?ノードとの違い
VPNのサブスクリプションURLとは、通常、アクセス認証情報を含む設定用URLです。クライアントはこのURLからノード一覧や設定一式を取得します。インストーラーでも、開くだけで接続できるウェブページでもありません。対応するクライアントにURLをインポートし、接続先を選んで接続を有効にすることで、利用できるようになります。
サブスクリプションは設定の取得元、ノードは個別の接続先と考えると分かりやすいでしょう。サービス側でノードのアドレスが変更されたり、接続先が追加されたりした場合、変更を反映するには通常、クライアントでサブスクリプションを再取得する必要があります。一度URLをインポートしても、ローカルの一覧がサーバーと常に同期されるとは限りません。自動更新の有無はクライアントの設定によります。
| 名称 | 主な役割 | よくある誤解 |
|---|---|---|
| サブスクリプションURL | クライアントにノード一覧や設定ファイルを取得させる | ブラウザーで開けば、自動的に接続が有効になる |
| 単一ノードのURL | 特定の接続先と認証情報を指定する | 単一ノードをインポートすれば、サブスクリプション全体の変更も自動で反映される |
| プロキシルール | どの通信を直接接続し、どの通信をプロキシ経由にするかを決める | ノード一覧さえあれば、すべてのアプリが必ずプロキシを使う |
| クライアント | 設定を読み込み、システムの権限に応じて対象の通信を処理する | どのクライアントでも同じ形式のサブスクリプションとプロトコルに対応している |
サブスクリプションURLの入手先
サービスのアカウント画面から取得してください。出所の分からない共有URLは使わないようにしましょう。ShunVPNをご利用の場合は、クライアントのダウンロードページからログインし、画面の案内に従ってサブスクリプションと対応クライアントを確認できます。アカウントの作成にメールアドレスは不要です。利用可能な接続先があるかどうかは、アカウントの状態と画面の案内をご確認ください。ログインと支払いは別の手順です。
コピーするときは、アカウント画面にあるコピー機能やインポート機能を使うのがおすすめです。手動で選択すると、末尾のパラメーターが抜けたり、空白や改行が混ざったりすることがあります。クライアント別に形式が用意されている場合は、「サブスクリプション」と書かれたものを適当に選ばず、使用中のアプリに対応した項目を選んでください。
QRコードにも同じサブスクリプションURLが含まれている場合があります。QRコードを使っても、情報を安全に管理する必要がなくなるわけではありません。スクリーンショットやクリップボードの履歴、同期ノートに認証情報が残ることもあります。サポートを依頼するときは、エラーメッセージと必要なクライアント情報だけを共有し、URL全体やQRコード、設定ファイルは見せないでください。
クライアントへのインポートと設定の確認
ボタン名はクライアントによって異なりますが、基本的な流れは同じです。リモート設定を追加し、内容を取得して、その設定を有効にしてから接続を開始します。以下は全体の流れを把握するための手順です。必要な権限については、使用するOSとクライアントのドキュメントを確認してください。
- 対応状況を確認。クライアントが対応する設定形式とプロトコルを確認します。Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICは、それぞれ異なるプロトコルまたはプロトコル方式です。いずれかに対応していても、すべてに対応しているとは限りません。サブスクリプションのファイル形式も、クライアントとの互換性が必要です。
- リモートサブスクリプションを追加。クライアントの設定、サブスクリプション、またはプロファイルの画面で、URLからインポートする項目を選び、URL全体を貼り付けます。識別しやすい名前をローカルで付けても構いませんが、URL内の認証パラメーターは変更しないでください。
- 内容を取得して確認。ダウンロードまたは更新を実行し、解析エラーが表示されないこと、ノード一覧を開けることを確認します。インポートに成功したのは設定を読み込めたという意味であり、個々の接続先に接続できることを保証するものではありません。
- 設定と接続を有効化。インポートした設定と接続先を選び、OSの案内に従って許可します。システムプロキシとTUNモードでは通信の処理方法が異なります。すべてのオプションを有効にする必要はなく、マニュアルに沿って設定してください。
- 実際のアクセスを確認。アクセスしたいウェブサイトやアプリでテストし、クライアントの接続ログも確認して、通信が想定したルールに一致しているか調べます。問題があれば、まず状況を記録し、ルールやDNS、ノードを同時に変更せず、一つずつ設定を見直してください。
WindowsとmacOSでは、通常、システムプロキシの設定はプロキシ設定に従うアプリにのみ適用されます。一部のコマンドラインツールでは、プロキシの環境変数を別途設定する必要があります。TUNモードでは、追加の権限やルーティング設定が必要になる場合があります。モバイル端末のクライアントは通常、OSのVPNインターフェースを使って通信を処理しますが、どの通信が対象になるかは、アプリの実装や設定によって異なります。
そのため、ステータスバーに接続中の表示があっても、目的のアプリが想定した接続先を使っているとは限りません。プラットフォーム別の手順は、クイックスタートガイドをご覧ください。他のOS向けの権限設定をそのまま適用しないでください。
更新のタイミングと反映される内容
すべてのサービスに共通する決まった更新間隔はありません。初回インポート後、接続先変更のお知らせを受け取ったとき、ノードが消えているとき、または以前のノードで接続できない状態が続くときは、手動で更新するとよいでしょう。クライアントが自動更新に対応している場合は、公式の案内を確認して有効にできます。「速度を保つ」ために何度も更新する必要はありません。
サブスクリプションの更新は通常、設定を再ダウンロードする操作です。通信量の追加やプランの有効期間の延長ではありません。ShunVPNの月額プランは、利用開始日を基準に毎月リセットされます。データパッケージは使い切るまで有効で、期限はありません。これらのアカウント上のルールと、サブスクリプションの更新は別のものです。設定を更新しても、プランのルールは変わりません。
サブスクリプションに含まれる内容も確認しましょう。ノードのみを提供するものもあれば、プロキシグループやルール、DNS設定を含むものもあります。リモート設定を更新すると、ローカルで直接編集した内容が上書きされることがあります。カスタムルールを継続して使う場合は、クライアントが対応するオーバーライドやマージ機能を使い、優先順位も確認してください。
まずサブスクリプションの同期が成功したことを確認し、その後で接続先とローカルネットワークを確認してください。同じ設定を何度も更新しても、アクセス回線の混雑、接続先ウェブサイトの障害、プロキシルールの誤判定は通常解決しません。
インポート失敗・ノードが空・接続失敗の対処法
まず、どの段階で失敗したのかを切り分けましょう。URLから内容を取得できない、クライアントが内容を読み取れない、ノードは表示されるが接続できない、という問題はそれぞれ異なります。すべてを「サブスクリプションの不具合」とまとめると、原因を特定しにくくなります。
- ✅ 取得に失敗する:アカウント画面からURLをコピーし直し、空白が混ざっていないか、リセット済みでないかを確認します。現在のネットワークからサブスクリプションURLにアクセスできるかも確認してください。証明書エラーが出た場合は、まずシステム時刻を確認し、証明書の検証を無効にしないでください。
- ✅ 解析に失敗する:サブスクリプションの形式、クライアントのバージョン、プロトコルの対応状況を確認します。ブラウザーでURLを開けても、クライアントが返された内容を解析できるとは限りません。返される内容がログインページやエラーページの場合もあります。
- ✅ 一覧が空:新しい設定が有効になっているか、更新ログに成功と表示されているか、アカウント画面でリソースが利用不可と案内されていないか確認します。インポート画面が閉じただけで成功と判断しないでください。
- ✅ ノードはあるがアクセスできない:選択中の接続先やプロキシモード、アプリがシステムプロキシに従うかどうかを確認します。ほかのプロキシやVPNツールが同時に動作していないかも確認してください。
- ✅ 一部のウェブサイトだけ不調:プロキシルールのログとDNS設定を確認し、ドメインの名前解決と通信の出口が想定どおりかを調べてから、接続先プラットフォーム側の制限を確認します。
DNSリークとは、本来想定した経路で管理されるべきドメインの名前解決が、別の経路で行われる状態です。サブスクリプションを使えば自動的に解消するわけではありません。名前解決の動作は、OSやブラウザーのセキュアDNS、クライアントのモードと設定にも左右されます。出口アドレスが変わったかだけで判断せず、実際の名前解決ログを確認してください。
また、サブスクリプションの形式と回線の種類は別のものです。IEPL専線、中継、直接接続は、通信経路や接続方式を指し、インポート画面で選ぶプロトコルではありません。サブスクリプションURLを取得しても、専線が使われているとは限らず、具体的な速度や特定プラットフォームへのアクセスが保証されるわけでもありません。
URLが漏えいした場合のリセットと再設定
URLが公開ページや見知らぬ変換ツール、他人の端末に保存されていると分かったら、できるだけ早くアカウント画面でサブスクリプションのリセット、トークンの再発行などのセキュリティ項目を探してください。該当する項目が見つからない場合は、お問い合わせ窓口で対処方法を確認しましょう。URLの文字を変えれば古いURLが無効になると考えて、自己判断で変更しないでください。
リセット後、新しいURLをコピーし、各端末に登録してあるリモートサブスクリプションを置き換えてから更新します。古いURLを更新しても、新しい認証情報には切り替わりません。クライアントがインポート後に設定全体を保存している場合は、設定名だけでなく、古い認証情報が残っていないかも確認してください。
「古いURLから設定を取得できないこと」と「古い設定で接続できないこと」は区別が必要です。システムによっては、サブスクリプションのトークンとノードの認証情報を別々に管理しているため、URLをリセットしても、すでに取得済みのノードを使う権限が取り消されるとは限りません。リセット操作の対象範囲を確認し、必要に応じてサービス提供元に関連する認証情報の対応を依頼してください。アカウントのパスワード変更がサブスクリプションのリセットと同じだと決めつけないでください。
対処後は、公開されたスクリーンショットや共有履歴を削除し、アカウントの使用量に異常がないか確認して、普段使う端末の設定も新しいものに切り替えます。今後サポートを依頼するときは、エラー内容やOS、クライアントのバージョンを伝え、設定全体は送らないでください。サブスクリプションの問題はエラー情報から原因を特定できることが多く、認証情報を渡す必要はありません。