v2rayNのサブスクリプション更新に失敗する原因と自動更新間隔の設定

この記事の要点

サブスクリプションのタイムアウトや認証エラー、更新後にノードが表示されない、定期更新が動かないといった問題でお困りのv2rayNユーザー向けです。まずダウンロード失敗と解析失敗を切り分け、URL、通信経路、証明書を確認します。手動更新が成功したら、グループごとに適切な自動更新間隔を設定し、連続更新で問題を悪化させないようにしましょう。

サブスクリプション更新に失敗したら、まず処理が止まった箇所を特定

サブスクリプションの更新は、ノードの速度測定とは別の処理です。v2rayNはまずサブスクリプションURLにリクエストを送り、応答を取得してからノード情報を解析し、グループを更新します。ノードに接続できても、サブスクリプションのサイトにアクセスできるとは限りません。また、ダウンロードに成功しても、応答内容をクライアントが認識できるとは限りません。

サブスクリプションURLを読み込むサブスクリプションサービスに接続する応答内容をダウンロードするノード情報を解析するグループ一覧を更新する

トラブル対処では、失敗した時刻、選択中のグループ、更新方法、ログに最初に記録されたエラーを控えてください。画面の「更新失敗」は結果にすぎません。次の対処を決めるには、DNSの名前解決エラー、HTTPステータスコード、TLSエラー、解析エラーなどの確認が必要です。更新ボタンを連続で押すとログが重複し、サーバー側の頻度制限にかかる場合もあります。

応答をまったく取得できない：DNS、ネットワーク経路、プロキシの待ち受け、接続タイムアウトを確認します。
401、403、404が返る：サブスクリプションの認証、アカウントの状態、URLが変更されていないかを確認します。
ダウンロード完了と表示されるのにノードがない：応答がログインページやエラーページではないか、対応していないサブスクリプション形式ではないか確認します。
定期更新だけ失敗する：プログラムが起動しているか、PCがスリープしていないか、自動更新時にネットワークが利用可能か確認します。

サブスクリプションURLが無効な場合：認証エラーと応答形式を切り分ける

サービス提供元のアカウントページからサブスクリプションURLをコピーしてください。手作業で文字列を選択するより、コピー用ボタンの利用がおすすめです。URLの前後に空白や改行、日本語の句読点が入っていないことを確認し、アカウント管理ページやQRコード画像のURLを使わないでください。最近サブスクリプショントークンを再発行した場合、以前のURLはすぐに無効になっている可能性があります。

応答	考えられる原因	次の対処
HTTP 401	認証情報がない、トークンが無効または取り消されている	アカウントページからURLを再取得し、認証状態を確認する
HTTP 403	アクセス制限、アカウント権限、またはセキュリティルールによる拒否	サービス提供元に制限内容を確認する。ノードを何度も切り替えるだけでは解決しません
HTTP 404	パスが間違っているか、以前のサブスクリプション用URLが廃止されている	URL全体を確認し、現在案内されている入口を使用する
HTTP 429	リクエスト頻度がサーバーの制限を超えている	連続更新をやめ、Retry-Afterの指示に従って待つ
HTTP 5xx	サブスクリプションサービスまたは上流側の一時的な障害	以前のノードを残したまま、時間をおいて再試行し、サービスのお知らせを確認する
HTTP 200だが、Webページが返される	ログインページ、認証ページ、またはエラーメッセージが正常な応答として返されている	URLとクライアントが対応する形式を確認し、応答本文を調べる

ステータスコードは原因を絞り込む手がかりですが、403だけで契約期間切れと断定したり、200だけで正常と判断したりはできません。ブラウザーにはログインCookieが残っていたり、クライアントとは異なるプロキシ経路を使っていたりすることがあります。そのため、「ブラウザーで開ける」だけでは、クライアントがダウンロードや解析をできる証明にはなりません。

形式の問題が疑われる場合は、v2rayN向けと明記されたサブスクリプションURLを使ってください。Base64形式の共有リンク一覧と、コアが使うJSON設定ファイルは用途が異なります。有効なJSONファイルでも、インポート可能なノードサブスクリプションとは限りません。まず形式を確認し、クライアントの更新を検討するのはその後にしてください。応答内容をむやみに書き換えるのも避けましょう。

判断のポイント：応答を確認してから解析に進む

応答がログインページやアクセス拒否ページなら、コアを切り替えても通常は解決しません。まずURLと認証を修正してください。有効なノード情報を取得できてから、クライアントの形式対応を確認します。

プロキシ経由で更新する：使えないノードに依存しない

v2rayNの手動サブスクリプション更新には、通常「プロキシ経由」と「プロキシを経由しない」の2種類があります。バージョンによってメニューの場所や表記が多少異なるため、メイン画面の「サブスクリプショングループ」メニューで該当する項目を確認してください。ここで選ぶのはサブスクリプションのダウンロード経路であり、ノード一覧の並び順ではありません。

対象のグループを選択する

メイン画面で、確認したいサブスクリプショングループを選択します。「サブスクリプショングループ」→「サブスクリプショングループの設定」でURLを確認し、失敗しているグループだけを変更してください。一度に複数の条件を変えると、原因を特定しにくくなります。
まずプロキシを使わずに更新する

「サブスクリプショングループ」→「すべてのサブスクリプションを更新（プロキシを経由しない）」を実行し、応答やエラーを記録します。他にもグループがある場合、それらも更新されます。頻度制限にかからないことを先に確認してください。
プロキシが使えることを確認する

接続可能なノードを選択し、コアが起動していることを確認してから、「すべてのサブスクリプションを更新（プロキシ経由）」を実行します。ノードの遅延測定に成功しても、プロキシ経由でサブスクリプションサービスにアクセスできるとは限りません。
2つの結果を比較する

プロキシなしでは失敗し、プロキシ経由なら成功する場合は、直接接続の経路を確認します。どちらも同じ認証エラーになる場合は、ルーティングルールではなくURLやアカウントを優先して確認してください。

「プロキシ経由」で更新するには、ローカルの待ち受けと外部への接続が利用可能である必要があります。例示されたポートを実際の設定と混同しないでください。現在の待ち受けポートが10808なのに、確認ツールが10809へ接続すると、接続拒否になることがあります。現在の設定と起動ログに記録されたプロトコル、アドレス、ポートを確認してください。HTTPプロキシとSOCKSプロキシも、任意に使い分けることはできません。

以前のノードがすべて使えず、サブスクリプションへのアクセスにもプロキシが必要なら、依存関係の循環が起きています。サブスクリプションサービスにアクセスできる別のネットワークを使うか、サービス提供元に直接接続用のURLがないか問い合わせてください。サブスクリプションの認証エラーを解決するために、VMessやVLESSなどのプロトコルを何度も切り替えるのは避けましょう。問題が起きている処理段階が異なります。

時刻と証明書：TLSエラーを確認する順番

HTTPSリクエストでは、証明書チェーン、ドメイン、有効期間の検証が必要です。システム時刻が大きくずれていると、有効な証明書がまだ有効でない、または期限切れと判定される場合があります。Windowsでは「設定」→「時刻と言語」→「日付と時刻」を開き、日付、タイムゾーン、自動設定を確認してから、「今すぐ同期」をクリックしてください。

エラー：The SSL connection could not be established, see inner exception.

原因：TLSハンドシェイクまたは証明書の検証に失敗しています。詳しい原因は内部例外を確認してください。

対処：まずシステム時刻を同期し、証明書チェーン、ドメイン、ネットワーク内のHTTPS検査ソフトを確認します。詳しい調査に備えて内部例外を保存してください。

エラー：No such host is known.

原因：サブスクリプションのドメインを名前解決できません。URLの入力ミス、または現在のDNSが応答を返せない可能性があります。

対処：サービス提供元が現在案内しているドメインを確認し、別のネットワークでも試します。必要に応じてnslookupで名前解決を確認してください。

エラー：Connection refused

原因：接続先のポートで接続が拒否されています。プロキシ経由で更新している場合は、ローカルのプロキシが起動していない可能性もあります。

対処：ログから拒否されたのがローカルポートかリモートサービスかを確認し、コアの実行状態とポート設定を調べます。

これらはネットワークスタックで発生することがあるエラーメッセージです。OS、クライアントのバージョン、画面表示言語によって異なる表現になる場合があります。最上位の「リクエスト失敗」だけでなく、詳細を展開して内部例外を確認することが重要です。

w32tm /query /status

上記のWindowsコマンドは、時刻サービスの状態と直近の同期情報を確認するもので、サブスクリプション設定は変更しません。時刻同期自体に失敗する場合は、ネットワークとシステム時刻サービスを先に確認してください。企業ネットワークのHTTPS検査によって証明書チェーンが変わる場合は、ネットワーク管理者が案内する証明書の導入手順に従ってください。

特定のサブスクリプションドメインだけで証明書エラーが発生する：サイトの証明書の有効期限とドメイン名の一致を確認し、サービス提供元に問い合わせます。
複数の通常のHTTPSサイトでエラーが発生する：システム時刻、システム更新、信頼済み証明書、ネットワーク検査ソフトを確認します。
ブラウザーでは正常だがクライアントでは失敗する：プロキシ経路と信頼環境を比較します。これだけで証明書の問題を除外することはできません。
エラー回避のために証明書検証を無効にしないでください。サブスクリプションURLには認証情報が含まれており、検証を省略すると情報漏えいや応答内容の改ざんリスクが高まります。

自動更新間隔：まず手動更新を成功させてから定期更新を有効にする

自動更新は、設定した間隔でサブスクリプションのリクエストを繰り返す機能です。誤ったURLや使えないプロキシを修復するものではありません。まず手動更新を行い、ノード数とグループの内容が適切であることを確認します。その後、「サブスクリプショングループ」→「サブスクリプショングループの設定」で対象グループを編集し、「自動更新間隔」に関する項目を探してください。

バージョンによって項目の場所、単位、実行タイミングが異なる場合があります。入力前に画面の説明を確認してください。単位が分の場合、6時間は360、24時間は1440と入力します。単位が時間なら、それぞれ6と24です。単位の異なる項目に、推奨間隔の数値をそのまま入力しないでください。

360分

6時間、よく使うグループの推奨開始間隔

1440分

24時間、予備グループの推奨開始間隔

1日4回

6時間ごとに更新した場合の理論上の頻度

上記は設定例と時間換算であり、クライアントの初期値や実際の更新回数を示すものではありません。実行回数はプログラムの稼働時間、スリープ、ネットワークの復帰、バージョンごとの実装にも左右されます。サービス提供元が更新頻度を指定している場合は、その制限を優先してください。ノードが長期間安定しているグループを、情報を新しく保つためだけに数分おきに更新する必要はありません。

グループの用途	推奨間隔	調整する条件
通常利用	6～12時間	サービス提供元によるノード変更が少ない場合は、24時間まで延長可能
予備回線	24時間	予備回線に切り替える前に、手動で一度更新する
トラブル対処中	定期更新を一時停止	手動更新の成功を確認してから再開し、繰り返しのリクエストでログが見にくくなるのを防ぐ

推奨：頻度を下げ、短い間隔での再試行をトラブル対処の代わりにしない

通常使うグループは6時間、予備グループは24時間を目安に設定します。429や継続的な認証エラーが発生したら、自動更新を一時停止してください。問題を解決してから元の間隔に戻します。

停止方法は現在の画面の説明に従ってください。バージョンによっては0で自動更新を無効にできますが、専用の切り替えスイッチがある場合もあります。保存後にグループの編集画面を開き直し、設定値が保持されていることを確認してください。また、自動更新で直近の手動更新時に選んだプロキシ方法が使われるとは限りません。使用中のバージョンの設定説明とログで確認しましょう。

グループと更新結果：フィルターで結果が隠れていないか確認する

サービス提供元ごとに「通常利用」「予備回線」などの独立したグループを作るのがおすすめです。更新間隔を分けられるうえ、どの配信元で問題が起きたかも判別しやすくなります。「すべてのサブスクリプションを更新」では一部だけ成功する場合があります。最後に表示されたメッセージだけで判断せず、グループごとに確認してください。

グループ名を明確にする：用途が分かる名前を付け、メモにサブスクリプションURLやトークン全体を書かないでください。
有効状態を確認する：対象グループが無効になっていないこと、自動更新の設定が保存されていることを確認します。
一時的にフィルターを解除する：更新後にノードが表示されない場合は、検索語やグループの絞り込みで結果が隠れていないか確認します。
ノード数を確認する：ノード数の変化は、サーバー側での削除、重複排除、フィルタリングによる場合があります。応答内容と合わせて判断してください。
ノードを選び直す：更新によってノードの項目が変わる場合があります。現在選択中のノードが有効か確認し、実際に接続してテストしてください。

PCがスリープ中、プログラムが終了している、またはネットワークが切断されている場合、デスクトップクライアントがサーバーのスケジュールタスクのように動き続けることは期待できません。復帰後すぐに更新を再実行するかどうかはバージョンの実装によります。必要なときに対象グループを手動更新し、間隔の設定値だけで判断せず、ログで実際の実行時刻を確認してください。

サブスクリプションの更新に成功したのに、ノードに接続できないのはなぜですか？

更新成功は、サブスクリプションの内容を取得して処理できたことを示すだけです。ノードへの接続には、サーバーへの到達性、アカウントの利用枠、プロトコルとセキュリティ設定、使用中のコアの対応状況なども関係します。まず使用中のノードを確認し、接続ログを調べてください。ノードの接続問題をサブスクリプションのダウンロード失敗と混同しないようにしましょう。

自動更新でルーティングルールはリセットされますか？

通常のノードサブスクリプションが更新するのは、主にグループ内のサーバー情報です。クライアント設定全体を置き換える処理ではありません。ルーティングルールは別の設定項目です。追加の設定インポート機能やテンプレート機能を使っている場合は、その影響を個別に確認し、変更前にバックアップを取ってください。

サービス提供元への問い合わせには、どのような情報が必要ですか？

失敗した日時とタイムゾーン、クライアントの実際のバージョン、対象グループ、プロキシを使わない更新かプロキシ経由か、HTTPステータスコード、機密情報を伏せたエラー内容を伝えてください。サブスクリプションURL全体を公開の掲示板に投稿しないでください。認証情報の確認が必要な場合は、サービス提供元の非公開サポート窓口を利用します。

トラブル対処後は、少なくとも3点を確認してください。対象グループを手動更新できること、使用中のノードが正常に使えること、自動更新の設定が保存されていることです。さらに、プログラムを起動したままネットワークが正常な状態で、次の定期更新ログを確認すれば、一連の動作を検証できます。