v2rayNでサブスクリプションを更新するとリクエストに失敗する、読み込み件数がゼロになる、サーバー一覧が空になる場合に役立つチェックリストです。まず現在の設定を残し、グループのURL、更新経路、サーバーからの応答を確認してから、形式とフィルター条件を調べます。目的は不具合の発生箇所を特定することであり、サブスクリプションを何度も削除したり、クライアントを再インストールしたりすることではありません。
1. サブスクリプション更新の失敗とノード接続エラーの違い
サブスクリプションの更新では、クライアントがURLにアクセスして設定データを取得し、認識できるサーバー情報をグループに登録します。一方、ノードへの接続では、その設定を使ってコアがプロキシ接続を確立します。この2つは別々のリクエストです。Webページが開けてもサブスクリプションAPIにアクセスできるとは限らず、更新に成功してもすべてのノードが接続できるとは限りません。
まず更新ログの最初に記録された具体的なエラーを確認します。ドメイン名の解決失敗、タイムアウト、HTTPステータスコードが表示される場合は、まずネットワークリクエストを確認します。リクエスト完了後に読み込み件数がゼロなら、応答内容と形式を確認します。ログ上の読み込み件数がゼロでないのに一覧が空の場合は、先にフィルターを解除します。最後に表示される「更新完了」だけを見て、成功と判断しないでください。
- リクエスト失敗：まだ有効な応答本文を取得できていません。VMessやVLESSのノード設定を変更しても、通常は解決しません。
- 読み込み件数ゼロ：データは取得できていますが、ログインページや案内文、現在のクライアントが認識できない設定である可能性があります。
- ノードに接続できない：一覧にはノードが登録されています。サーバーの状態、接続設定、ルーティングを別途確認してください。接続の問題をサブスクリプション更新で解決しようとしないでください。
2. サブスクリプショングループとURLを確認する
まず「サブスクリプショングループ」→「サブスクリプショングループの設定」を開き、エラーが発生したグループを確認します。画面構成はデスクトップ版、WPF版、バージョンによって異なりますが、確認するのはグループ名、サブスクリプションURL、グループのフィルター設定です。複数のグループを使っている場合は、対象のグループだけを更新すると、操作とログを対応させやすくなります。
-
現在の状態を記録する
クライアントのバージョン、対象グループ名、登録済み項目数を記録します。バックアップが必要な場合は、クライアントのバックアップ機能を使ってください。バックアップファイルに認証情報が含まれることがあるため、自分で管理できる安全な場所に保存します。
-
URLを確認する
「サブスクリプショングループ」→「サブスクリプショングループの設定」を開き、対象グループを編集します。サービス提供元のトップページやアカウント画面のURL、個別ノードの共有リンクではなく、サブスクリプションURL全体が貼り付けられていることを確認してください。
-
URLを再取得する
サービス提供元のアカウントページにログインし、サブスクリプションが有効であることを確認してから、v2rayN用のURLをコピーし直します。前後の空白や改行は削除し、疑問符以降のクエリパラメーターは残してください。トークンを自分でデコードしたり書き換えたりしないでください。
-
対象グループだけを更新する
「サブスクリプショングループ」メニューに戻り、現在のバージョンで利用できる対象グループの更新操作を選びます。一括更新しかできない場合は、対象グループのログを確認してください。他のグループが成功したことだけを根拠に、対象グループも正常だと判断しないでください。
-
結果を記録する
操作時刻、更新経路、エラーの原文、読み込み件数を記録します。一度に変更する条件は1つにして、その都度更新してください。URL、DNS、プロキシを同時に変更すると、どの変更が効果をもたらしたのか分からなくなります。
3. 直結更新とプロキシ経由更新を比較する
v2rayNでは、バージョンによってサブスクリプションの更新方法を「プロキシを使用しない」「プロキシを使用する」に切り替えられます。まず「サブスクリプショングループ」メニューに表示される選択肢を確認し、該当する経路を選んでください。システムプロキシのアイコンを切り替えただけで、サブスクリプションの通信経路も変わったと判断しないでください。更新リクエストの経路は、クライアント独自の設定で決まる場合があります。
| テスト条件 | 結果 | 次の対応 |
|---|---|---|
| プロキシを使わずに更新 | 項目の読み込みに成功 | この経路を使い、以前のプロキシが使えなくなっていないか確認する |
| プロキシを使わずに更新 | タイムアウトまたは接続切断 | 利用可能と確認できているノードで、プロキシ経由の更新を試す |
| プロキシ経由で更新 | ローカル接続が拒否された | コアの稼働状態と実際の待ち受けポートを確認する |
| どちらの経路でも失敗 | 同じステータスコードまたはエラーメッセージ | URLのアクセス権、アカウントの状態、サーバーからの応答を確認する |
プロキシ経由で更新する前に、現在のノードが実際に使えることを確認してください。使えないノード経由で更新しようとすると、「ノードを復旧するには更新が必要だが、更新には使えないノードが必要」という悪循環に陥ります。利用できるノードがない場合は、まず直結か、信頼できる別のネットワークを試してください。更新のために、使えない接続を何度も起動する必要はありません。
- ログに
127.0.0.1:10808などのローカルアドレスが表示される場合は、「設定」→「パラメーター設定」でローカルの待ち受け設定を確認してください。ポート番号は例です。現在の設定に合わせて確認してください。 - HTTPとSOCKSは異なるプロキシプロトコルです。見慣れたポート番号だからといって、相互に置き換えられるわけではありません。旧バージョンでは別々のポートで待ち受ける場合があり、新しいバージョンでは混合ポートが使われる場合があります。
- TUNモード、ほかのプロキシソフト、環境変数によっても、実際の通信経路が変わることがあります。比較テストでは、これらの状態も記録してください。「プロキシを使用しない」を選んでも、システムレベルで通信が別の経路に振り分けられていないとは限りません。
4. HTTPステータスコードとエラー内容を確認する
エラーメッセージは英語の場合も、クライアントによって翻訳される場合もあります。「更新失敗」という表示だけでなく、ステータスコード、ホスト名、内部例外を記録してください。以下の数字は通信プロトコルのステータスコードであり、速度測定の結果ではありません。200はHTTPリクエストが成功したことを示すだけで、有効なサブスクリプションが返された証拠にはなりません。
エラー：Response status code does not indicate success: 403 (Forbidden).
原因と対処：サーバーにアクセスを拒否されています。トークンの無効化、アカウントの権限、アクセス制限などが考えられます。サブスクリプションURLを再取得し、アカウントの状態を確認してください。ブラウザーとクライアントで結果が異なる場合は、クライアントからのリクエストが遮断されていないか、サービス提供元に確認してください。
エラー：Connection refused
原因と対処：接続先から接続を拒否されています。接続先がローカルのループバックアドレスなら、プロキシコアと待ち受けポートを確認してください。接続先がリモートサーバーなら、サーバー側のサービスが稼働しているか確認します。すべてのケースをローカルのポート競合と決めつけないでください。
エラー：The SSL connection could not be established, see inner exception.
原因と対処：TLS接続の確立に失敗していますが、外側のメッセージだけでは具体的な原因を特定できません。システムの日付、タイムゾーン、内部に記録された証明書エラーを確認し、ネットワークの認証ページやHTTPS検査の影響も調べてください。証明書の検証を恒久的に無効化して、問題を覆い隠さないでください。
429が表示された場合は、連続した更新を停止し、サーバーの案内に従って待ってください。5xxの場合は発生時刻を記録し、APIの状態をサービス提供元に確認します。ドメイン名の解決エラーでは、まずサブスクリプションURLのドメイン名に誤りがないか確認し、その後で現在のネットワークのDNSを調べます。DNSを変更しても、アカウントの期限切れやトークンの無効化は解決しません。
5. サブスクリプションの読み込み件数がゼロの場合：応答形式を確認する
サブスクリプションURLにアクセスすると、共有リンクの一覧や、共有リンクをエンコードしたデータが返されることがあります。VMessとVLESSはプロキシプロトコル名で、サブスクリプションは設定をまとめて配布する仕組みです。クライアントごとの設定ファイルは共通ではありません。任意の設定テキストをサブスクリプション欄に貼り付けても、自動変換されるとは限りません。
| 応答内容の特徴 | 考えられる原因 | 対処方法 |
|---|---|---|
| ログインフォーム、ページタイトル、HTMLタグ | アカウントページのURLをコピーした、または認証ページにリダイレクトされた | サブスクリプション専用のURLをコピーし直し、ネットワーク認証を完了する |
| 期限切れ、上限到達、アクセス拒否の案内 | APIから案内文が返された | アカウントの権限とサービス提供元の案内を確認する |
| 空の本文、または項目が空の一覧 | アカウントにノードが割り当てられていない、またはAPIに問題がある | アカウント画面のノード一覧とサブスクリプションの生成状態を確認する |
| 別形式の設定ファイル全体が返された | エクスポート形式とクライアントが一致していない | サービス提供元がv2rayN対応と案内している形式を選ぶ |
| 共有リンクの一部だけが読み込まれない | 一部の項目に必要なフィールドがない、またはクライアントのバージョンが未対応 | 個別の解析エラーを確認し、クライアントのバージョンを調べる |
ブラウザーでのアクセスは参考情報にとどめてください。ブラウザーにはアカウントのログイン状態が保持されている場合があり、別のプロキシ経路を使っている可能性もあります。クライアントが同じCookieを送信するとは限りません。ブラウザーにアカウント画面が表示されても、クライアントからサブスクリプションAPIにアクセスできる証拠にはなりません。応答を確認する際は、ページが「開けたか」ではなく、最終的に返されたコンテンツの種類と本文に注目してください。
6. ログでは読み込み成功なのにサーバー一覧が空の場合
この場合、サブスクリプションURLをすぐに変更するのではなく、まず表示条件を確認してください。選択中のグループ、検索語、グループのフィルター設定が同時に適用されていることがあります。特にサービス提供元がノード名を変更すると、以前のキーワード条件に一致しなくなり、サブスクリプションからノードが消えたように見える場合があります。
- 検索条件を消去：サーバー一覧の検索欄を空にし、特定の地域や古いノード名だけに絞り込まれていないか確認します。
- グループを切り替える：更新したグループを選択します。必要に応じて全グループ表示に切り替えて、別の空グループを表示したままになっていないか確認してください。
- フィルターを確認する：「サブスクリプショングループ」→「サブスクリプショングループの設定」で、対象グループのフィルターフィールドを確認します。元の値を記録してから、一時的に空にしてください。フィルター設定によっては読み込み結果に影響するため、確認には再更新が必要です。
- 件数を照合する：更新ログの読み込み件数と、画面に表示される件数をそれぞれ記録します。前者がゼロでなく後者がゼロなら、まずフィルターを確認してください。両方ともゼロなら、応答内容と形式の確認に戻ります。
フィルターを解除すると項目が表示されても、ノードを有効にした際に接続できない場合は、サブスクリプションの問題と接続の問題を分けて記録してください。その場合は、ノードのアドレス、ポート、トランスポート、TLSの設定がサービス提供元の案内と一致しているか確認します。サブスクリプショングループを削除し続ける必要はありません。
7. 再テストの記録とサービス提供元への問い合わせ
修正後は対象グループだけをもう一度更新し、ログに読み込み結果が記録されていることを確認します。フィルターを解除して項目を表示したら、ノードを1つ選んで実際にアクセスできるかテストしてください。一覧が復旧しただけでは、ノードに接続できることの確認にはなりません。
- v2rayNの完全なバージョン番号、OS、使用しているデスクトップ版またはWPF版を記録します。
- エラーの発生時刻、対象グループ、直結とプロキシ経由のどちらで更新したか、TUNが有効かどうかを記録します。
- 最初に発生したエラー、HTTPステータスコード、読み込み件数を、機密情報を伏せた状態で共有します。サブスクリプショントークン全体は送信しないでください。
- ネットワークを変更したか、URLを再取得したか、同じURLからWebページや空の本文が返されるかを伝えます。
- サービス提供元がサブスクリプション形式を更新している場合は、対応するクライアントのバージョンを確認してから、アップグレードが必要か判断します。「最新版」という表示だけを見て原因を決めつけないでください。
基本設定を見直す場合は、チュートリアルに沿ってサブスクリプションの読み込み方法とプロキシ設定を確認してください。操作を再現できる形で記録しておくと、「すべてのサブスクリプションを更新」を何度も押すより原因を特定しやすく、APIのレート制限にかかるリスクも減らせます。