サブスクリプション更新に失敗したときの対処法｜原因別チェックと自動更新の設定

まず、どの段階で失敗したかを確認する

サブスクリプション更新は、単に「ノードをダウンロードする」だけではありません。クライアントはサブスクリプションURLを読み取り、ネットワークリクエストを送信し、サーバーの応答を受け取り、返された形式を判別して、VMessやVLESSなどの設定を解析し、最後に結果を該当するサブスクリプショングループへ書き込みます。どこか1つでも中断すると、画面には「更新に失敗しました」とだけ表示されることがありますが、対処法はそれぞれ異なります。

まずクライアントのログを開き、サブスクリプションを手動で1回更新します。v2rayNではメイン画面のログ欄でリクエスト結果を確認できます。ログ欄が表示されない場合は、「設定」→「パラメーター設定」にあるログ関連の項目を確認してください。v2rayNGでは左上のメニューからログ画面を開き、その後サブスクリプショングループに戻って更新します。最初に表示されたエラーを記録し、その後に発生した連鎖的なエラーだけを見ないようにします。

ログにHTTPステータスすら表示されない場合は、ネットワーク、ドメイン名の解決、既存のプロキシ経由が必要かどうかを重点的に確認します。401、403、404が返っているなら、リクエストはサーバーに到達しています。リンクの権限と有効期限を確認してください。ステータスが200でも、その後にデコード失敗や有効な設定が0件と表示される場合は、返却内容、形式の互換性、サブスクリプショングループのルールに問題がある可能性が高いです。

エラーメッセージから主な原因を特定する

エラー文はクライアントのバージョンやシステム言語によって多少異なりますが、キーワードはほぼ共通しています。タイムアウト、接続拒否、HTTPステータス、解析失敗は、それぞれ異なる層の問題を示します。サブスクリプションが正常に書き込まれる前に、ノードのプロトコルを変更する必要はありません。VMess、VLESS、TLS、ルーティング分岐の設定は、まだ接続に関与していないためです。

ログに証明書名の不一致、証明書の期限切れ、ハンドシェイク失敗などが表示される場合は、システムの日付、時刻、タイムゾーンも先に確認してください。システム時刻のずれにより、設定をダウンロードする前にHTTPSサブスクリプションのリクエストが終了することがあります。証明書検証を無効にして問題を回避しないでください。実際のドメイン名や時刻設定の誤りを隠してしまいます。

最短手順で基本チェックを行う

基本チェックでは、条件を一つずつ切り分けます。元のサブスクリプショングループを残し、リンクが完全か確認したうえで、直接接続による更新とプロキシ経由の更新をそれぞれ試し、解析結果を確認します。すべての設定を削除すると、サブスクリプション更新に使える既存ノードまで失われ、更新前後のログも比較しにくくなります。

1. 元のリンクをコピーする

   サブスクリプション管理画面から完全なURLをコピーし直します。プレーンテキストの入力欄に貼り付け、先頭、パス、クエリパラメーター、末尾の文字を確認してください。チャットツールによる改行や途中切れを防げます。

2. グループのURLを確認する

   v2rayNでは「サブスクリプショングループ」→「サブスクリプショングループ設定」と進み、該当グループを編集します。v2rayNGでは左上のメニューから「サブスクリプショングループ設定」を開き、該当項目のURLが新しくコピーしたアドレスと一致しているか確認します。

3. まず直接接続で更新する

   システムプロキシの状態は変えず、プロキシを経由しない更新を1回実行します。時刻、HTTPステータス、最初のエラーを記録してください。サーバー側の頻度制限を招かないよう、短時間に連続してクリックしないでください。

4. 次にプロキシ経由で更新する

   利用可能であることを確認済みの設定を選択してコアを起動し、その後プロキシ経由で更新します。プロキシ経由では成功し、直接接続では失敗する場合、現在のネットワークでは既存のプロキシ経由でサブスクリプションURLへアクセスする必要があります。

5. 解析された件数を確認する

   更新完了後、対象グループに設定が表示されているか、更新時刻が変わっているかを確認します。成功と表示されても件数が0の場合は、形式の互換性、グループのフィルター、サーバーの出力を確認し、レイテンシーのテストを続けないでください。

6. 2回連続で確認する

   少なくとも1分間隔を空けて、手動更新をもう1回実行します。2回とも完了し、ノード一覧が異常に空にならなければ、ネットワークリクエスト、解析、書き込みの流れが復旧したと判断できます。

直接接続とプロキシ経由のどちらで更新するか判断する

「サブスクリプション更新でプロキシを使うか」は、クライアントがサブスクリプションファイルをダウンロードするときの経路を決めるもので、サブスクリプション内のノードが最終的にVMessかVLESSかとは直接関係ありません。直接接続は現在のネットワークからサブスクリプションのドメインへアクセスできる場合に適しています。プロキシ経由の更新には、すでにインポート済みで正常に接続できる設定が必要です。

プロキシ経由の更新には起動順序があります。まず既存の設定を選択してコアを起動し、その後サブスクリプションのリクエストをローカルプロキシポートへ通します。一般的なローカル待受アドレスは127.0.0.1ですが、ポートは現在のクライアント設定を基準にしてください。一部の設定では10808が使われますが、チュートリアルにこの数字が出てきたからといって、無理に同じポートへ変更しないでください。他のプログラムがポートを使用していると、コアが正常に起動せず、プロキシ経由の更新も失敗します。

クライアントに利用可能な設定が1つも残っていない場合、プロキシ経由の更新で、直接アクセスできないサブスクリプションURLの問題を解決することはできません。その場合は、サブスクリプション管理画面から、まだ有効な単一設定または新しいサブスクリプションURLを取得します。インポート後に接続できることを確認してから、グループ全体を更新してください。「更新失敗」と「ノード接続失敗」を混同しないことも重要です。前者は設定の取得段階、後者は設定が存在した後に発生します。

v2rayN・v2rayNGの自動更新を設定する

自動更新は、サブスクリプション内容が定期的に変更される場合に便利ですが、間隔は短ければよいわけではありません。頻繁なリクエストは失敗ログを増やし、サーバー側のアクセス制限を招くこともあります。まずは1440分、つまり1日1回に設定するのが一般的です。サーバーが更新周期を明示している場合は、その案内に従って調整してください。トラブルシューティング中は自動更新を一時的に無効にし、手動更新を連続して成功させることをおすすめします。

1. v2rayNでグループを設定する

   メイン画面で「サブスクリプショングループ」→「サブスクリプショングループ設定」を開き、管理するグループを選択して編集します。自動更新間隔の欄に、例として1440分と入力します。サブスクリプションURLとグループの有効状態を確認して保存してください。

2. 更新経路を確認する

   メイン画面に戻り、サブスクリプショングループのメニューから手動更新を1回実行します。現在のネットワークでプロキシが必要な場合は、対応するプロキシ経由の更新コマンドを使い、クライアントのコアが起動していることを確認してください。

3. v2rayNGでグループを設定する

   左上のメニューを開き、「サブスクリプショングループ設定」に進み、対象のサブスクリプションを編集して自動更新を有効にします。バージョンによっては、更新間隔が「設定」内のサブスクリプション関連項目に配置されています。現在の画面に表示される項目名を基準にしてください。

4. バックグラウンド実行を許可する

   Androidのアプリに対するバックグラウンド実行とネットワーク権限を確認します。クライアントがバックグラウンドに移った直後にシステムがプロセスを制限すると、予定された更新は次回アプリ起動時まで実行されないことがあります。

5. 更新時刻を確認する

   更新周期を1回過ぎたら、グループの更新時刻とログを確認します。スケジュールタスクが起動しただけでは解析成功とは限りません。ノード数が妥当で、既存グループが空の結果で上書きされていないことも確認してください。

• 1日1回の更新なら1440分、12時間ごとなら720分と入力します。
• 数分おきには設定しないでください。サブスクリプション内容がそこまで頻繁に変わることは通常ありません。
• 端末が長時間オフライン、クライアントが起動していない、またはバックグラウンド通信が制限されている場合、予定されたタスクは次回起動時まで遅延することがあります。
• 複数のサブスクリプショングループを手動でテストする場合は、時間をずらすと、どのアドレスが失敗したかをログから判断しやすくなります。

更新成功なのに一覧が空になる場合の対処

HTTP 200はサーバーが正常に内容を返したことを示すだけで、内容が解析可能なノード一覧であるとは限りません。ログインページ、案内文、空の内容、またはクライアントがまだ認識できない新しい形式が返されることがあります。この場合、ネットワークリクエスト自体は完了しているため、DNSを何度も切り替えても通常は解決しません。

サブスクリプションの種類が一致しているかも確認してください。標準的なノードサブスクリプションには、エンコードされた複数の共有リンクが含まれることが一般的です。一方、構造化設定ファイルが返される形式もあります。クライアントが誤った種類として読み込むと、ダウンロード成功後に解析が失敗します。エンコード文字を手動で削除したり、テキストを独自に補ったりしないでください。1文字の変化でも内容全体が壊れる可能性があります。

v2rayNとv2rayNGが異なるネットワークで同じURLを解析できず、HTTPステータスがどちらも200の場合は、サーバー側の出力形式に原因がある可能性が高いです。反対に、1台だけ失敗する場合は、その端末のクライアントバージョン、グループフィルター、システム時刻、ネットワーク権限を優先して確認します。

• 対象グループが有効になっており、誤った包含・除外キーワードが設定されていないことを確認します。
• 返却内容がHTMLのログインページ、アクセス案内、空のレスポンスではないことを確認します。
• 古いパーサーが新しいフィールド構成を認識できない可能性があるため、クライアントを更新してから再インポートします。
• ノード一覧が空になった直後にローカル設定をすべて上書きせず、比較用に元のグループを残してください。

復旧を確認し、再発を防ぐ

復旧後の確認では、リクエスト、解析、接続の3つの層をすべて確認します。まずサブスクリプション更新を2回連続で完了させ、次に対象グループの設定数と更新時刻が妥当か確認し、最後にその中から1つを選んでコアを起動します。サブスクリプションを更新できても、すべてのノードが接続できるとは限りません。1つのノードが失敗しても、サブスクリプションURLが再び無効になったとは限りません。

接続段階で失敗する場合は、ノードのアドレス、ポート、通信方式、TLS、SNI、システム時刻を確認します。ルーティング分岐は接続確立後のトラフィック経路を決めるだけで、通常は404、403、サブスクリプション形式のエラーを修復しません。問題を層ごとに切り分ければ、サブスクリプション、コア、ルーティングルールを同時に変更して、どの変更が効果をもたらしたか分からなくなる事態を避けられます。

• 手動更新が2回連続で成功し、ログに新しいHTTPエラーや解析エラーがない。
• サブスクリプショングループの更新時刻が変わり、ノード一覧が意図せず0件になっていない。
• 自動更新間隔がサーバーの推奨値を下回っておらず、通常は1440分から設定を始める。
• クライアント起動後のローカル待受ポートが正常で、ポート使用中の警告が表示されない。
• 後のプロキシ経由更新とトラブル比較に使える、接続テスト済みの設定を少なくとも1つ残している。