サブスクリプションURLとクライアントの関係
サブスクリプションURLの基本的な使い方は、ユーザーパネルにログインし、クライアントに対応したURLをコピーして、クライアントにインポートし、サーバーリストを更新してから接続を有効にする流れです。これはインストーラーでもログイン用のWebページでもありません。URLをブラウザーに貼り付けても、端末がサーバーに接続されるわけではありません。
クライアントがサブスクリプションURLにアクセスすると、サーバー名やアドレス、認証情報などの設定を取得します。返される内容はサーバーリストだけの場合もあれば、プロキシグループ、振り分けルール、DNS設定を含む場合もあり、形式によって異なります。クライアントは内容を解析し、選択されたモードに応じて通信を転送します。
「サブスクリプション形式」と「接続プロトコル」は区別が必要です。Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICはそれぞれ異なるプロキシプロトコルまたはプロトコル体系であり、同じサブスクリプションファイルを指すものではありません。特定のプロトコルに対応したクライアントでも、すべてのサブスクリプション形式を解析できるとは限りません。プロトコル、設定形式、クライアントのコアを適合させる必要があります。ここで挙げたのは一般的な概念であり、VPNEFがすべてのプロトコルを提供しているという意味ではありません。
形式を確認してからインポートしましょう。まずは、現在のクライアント向けにパネルで案内されている方法を使ってください。インポートできても、設定が読み込まれたことを示すだけです。サーバーへの接続とアプリの通信が意図した経路を通っているかも確認しましょう。
ユーザーパネルでサブスクリプションURLを取得する
VPNEFのサブスクリプションは、ログイン後に取得できます。ユーザーパネルにアクセスし、クライアントやサブスクリプションに関する項目を開いてください。実際に表示される案内と取得方法に従ってください。メールアドレスは不要で、ユーザー名とパスワードでアカウントを作成できます。サービスのトップページ、アカウントのログインページ、プランページのURLをサブスクリプションURLとして使わないでください。
- ログイン後、プランの状態と残りの通信量を確認してください。アカウントにログインできても、サーバーを利用できる状態とは限りません。
- 利用中のクライアント名とプラットフォームを確認してください。パネルに複数の形式が表示される場合は、URLの見た目で判断せず、利用中のクライアントに対応するものを選んでください。
- パネルのコピー機能でURL全体を取得してください。疑問符以降を手動で削除したり、認証情報を書き換えたりしないでください。
- クライアントのサブスクリプションまたは設定管理画面を開き、「URLからインポート」や「リモート設定を追加」などの機能を使います。
- 設定を取得したらサーバーリストを確認し、パネルの案内に従って接続を有効にしてください。エラーの内容はトラブルシューティング用に控えておき、URL全体は公開しないでください。
クリップボードからインポートするようクライアントに求められた場合は、コピーしたばかりのサブスクリプションURLがクリップボードにあることを確認してください。別の設定情報を誤って使わないようにしましょう。端末間でURLを受け渡す際は、信頼できる非公開の方法を使い、不要になった中継記録は削除してください。
各プラットフォームでのインポートと有効化
クライアントによってボタン名は異なりますが、通常はリモート設定の追加、更新、設定の選択、プロキシの有効化という流れです。追加しただけで終わらせないでください。設定がリストにある状態と、実際に適用されている状態は異なります。
| プラットフォーム | インポート方法 | 有効化後の確認項目 |
|---|---|---|
| Windows / macOS | 設定管理でサブスクリプションURLを追加し、更新後に選択して使用 | システムプロキシまたは仮想ネットワークアダプターが有効か確認し、他のプロキシソフトの影響を除外する |
| iOS | パネルに表示される有効な取得方法からクライアントを入手し、案内に従ってインポート | システムによる接続許可を確認し、クライアントに戻って設定と接続状態を確認 |
| Android | リモートサブスクリプションを追加するか、クライアント対応のインポート方法を使用 | システムの接続許可を確認し、アプリごとのプロキシ設定とバックグラウンド実行の制限を確認 |
| Linux | GUIクライアントまたは利用するコアの要件に沿って設定を読み込む | 起動ログ、プロキシ環境変数、またはルーティングの引き継ぎ方法を確認 |
iOS以外ではログイン後にクライアントを取得できます。iOS向けの実際の取得リンクは、有効なプランの状態に応じてパネルで管理されます。パネルのダウンロードページを利用し、不明な転載サイトからアプリを入手しないでください。アプリだけを入れ替えても、サブスクリプション設定を移行しなければ、以前のサーバーリストが自動的に復元されることはありません。
デスクトップのシステムプロキシは通常、システムのプロキシ設定に従うアプリにのみ適用されます。コマンドラインツールやバックグラウンドサービス、一部のアプリでは、個別にプロキシを設定するか、クライアント対応の仮想ネットワークアダプターを使う必要があります。モバイル端末ではアプリごとのプロキシが有効になっている場合があり、ブラウザーは接続できても、別のアプリは通常のネットワークを使っていることがあります。トラブル時はサーバーを何度も切り替えるのではなく、まず通信経路を確認してください。
どのくらいの頻度で更新する?変化を確認し、むやみに再取得しない
サブスクリプションの更新は、リモート設定を再取得する操作です。Webサイトにアクセスするたびに行う必要はありません。接続に問題がなく設定にも変更がなければ、手動で何度も更新する必要は通常ありません。クライアントに自動更新機能がある場合は、説明に従って有効にしてください。パネルに固定の更新間隔が示されていない場合、自分で決めた間隔をサービスの要件とみなさないでください。
パネルにサーバー変更の案内が表示された場合、クライアントのリストとパネルの内容が一致しない場合、古いサーバーが継続して使えない場合、またはサブスクリプションURLを変更した直後は、手動での更新が適しています。プランを変更した場合も、まずパネルの状態を確認し、案内に従って更新してください。何度更新しても、アカウントの無効化や通信量の使い切り、クライアントとプロトコルの非互換は解決できません。
- ✅ 初回インポート後、設定を取得できたことを確認し、追加した設定を選択します。
- ✅ 設定やサーバーの変更通知を受け取ったら、手動で更新し、現在選択中の設定が引き続き有効か確認します。
- ✅ 更新前に独自のルールを保存し、リモート設定によってローカル設定が上書きされるか確認します。
- ❌ 「サブスクリプションを更新」を、プランの更新、通信量のリセット、あらゆる接続問題の解決方法と考えないでください。
VPNEFの月間プランの通信量は、利用開始日を基準に毎月リセットされます。クライアントで更新した日時を基準にリセットされるわけではありません。通信量パックは使い切るまで有効で、期限はありません。また、サブスクリプションを更新しても容量は補充されません。途中でプランをアップグレードした場合、差額は残り日数分に換算されます。プランの料金計算とクライアント設定の更新は別の仕組みです。料金と容量はプランページでご確認ください。
インポート失敗と接続失敗は分けて確認する
URLの取得に失敗する、または設定を解析できない
まず、どの段階でエラーが起きたか確認してください。接続タイムアウトは、サブスクリプションURLに一時的にアクセスできない可能性があります。認証エラーの場合はパネルに戻り、URLが変更されていないか、アカウントが正常な状態かを確認してください。解析エラーの場合は、形式が一致しているかを優先して確認しましょう。エラーページに表示された短い文言だけで、サービス全体が利用できないと判断しないでください。
コピーしたURLが途中で切れている、前後に空白がある、またはWebページのURLをサブスクリプションURLとして使っていると、インポートに失敗することがあります。クライアントに未知の項目や非対応プロトコルを指摘された場合は、バージョンとコアの対応状況を確認し、パネルの案内に従ってクライアントを更新するか、互換性のある形式を選んでください。エラーを回避するために証明書検証を安易に無効化しないでください。
サーバーは表示されるのにアプリから接続できない
設定が選択されているか、プロキシが有効か、サーバー認証が正常か、対象アプリの通信がプロキシ経由になっているかを順に確認してください。次に、ルールによって対象ドメインが直接接続になっていないか、DNSの名前解決が現在の設定に沿っているかを確認します。OSの暗号化DNS、ブラウザーのセキュアDNS、クライアントのDNS設定は相互に影響する場合があるため、利用中のモードに応じて確認してください。
DNSリークとは、指定した経路で処理される想定の名前解決リクエストが、別のリゾルバーやネットワーク経路を通じて送信されることです。出口IPアドレスが変わっただけでは、DNSも想定どおりに処理されているとは確認できません。一方で、ルール設計上のローカル名前解決を、すべて問題とみなすべきでもありません。ネットワーク診断で出口を確認し、クライアントのログとあわせてDNSや振り分けの状態を調べてください。ログを共有する前に、認証情報を削除してください。
URL漏えい時の対処手順
有効なサブスクリプションURLを第三者が入手すると、含まれているサーバー認証情報を読み取られ、アカウントの通信量を消費される可能性があります。同時接続台数に制限がない場合でも、サブスクリプションを公開・配布してよいわけではありません。URL全体が公開画像やグループチャット、コードのコミット履歴に掲載された場合は、認証情報が漏えいしたものとして扱ってください。ローカルのクライアント設定を削除するだけでは不十分です。
- 公開されている内容を削除し、画像、履歴バージョン、共有ファイルも確認してください。表示内容を削除すれば拡散を抑えられますが、コピー済みのURLを無効にはできません。
- パネルでサブスクリプションのリセットや認証情報の管理機能を探してください。明確な手続きが見つからない場合は、パネルのチケットからサポートに連絡し、古い認証情報をどのように無効化できるか確認してください。
- 新しいURLを取得したら、すべての自分の端末で古いサブスクリプションを置き換えて更新してください。サブスクリプションの表示名を変更しても、リモートの認証情報は変わりません。
- 不審な通信量の使用とアカウントの状態を確認してください。アカウントのパスワードも漏えいした場合は、別途変更してください。パスワードを変更すれば古いサブスクリプションも必ず無効になる、と考えないでください。
古いURLを再取得しても、認証情報の無効化にはなりません。利用できなくなるかどうかは、サーバー側の認証情報が変更されたか、エクスポート済みのサーバー認証情報も同時に無効化されたかによります。不明な場合はパネルのサポートチケットから確認してください。第三者にテストしてもらうために、サブスクリプションURL全体を公開しないでください。
日常の管理で大切なのは、設定を有効な状態に保ち、認証情報を非公開にすることです。クライアントに合った形式を選び、実際に変更があったときに更新し、通信経路を確認しながら問題を切り分けましょう。URLが漏えいした場合は、ローカルの記録を削除するだけでなく、サーバー側の認証情報を対処してください。