v2rayNでサブスクリプションを更新すると、まずURLへリクエストを送り、レスポンスの内容を判定してサーバー情報を解析し、最後に対応するサブスクリプショングループへ結果を書き込みます。画面に「更新に失敗しました」とだけ表示される場合、どの段階でも問題が起きている可能性があります。更新ボタンを繰り返し押すだけでは原因を絞れないため、まず表示されたメッセージと主要ログを確認するのが効果的です。
サブスクリプションのタイムアウト、空のリスト、解析エラー、更新後もノードが変わらない問題に悩むv2rayNユーザー向けの記事です。URLとレスポンス状態を確認してから、ネットワーク経路、ポート、形式、システム時刻を調べ、最後に適切な自動更新間隔を設定します。
どの段階で失敗しているかを確認する
サブスクリプション更新は、単に「ファイルをダウンロード」するだけの処理ではありません。v2rayNは、ドメイン名の解決、HTTPS接続の確立、レスポンスの取得、コンテンツ形式の判定、共有リンクの解析、ローカルグループの更新まで行います。エラーが出ても、すぐに既存サーバーを削除しないでください。グループを削除すると利用可能だった記録は失われますが、リモートURLが直るわけではありません。
- v2rayNのメイン画面でサブスクリプショングループの更新操作を開き、問題のあるグループだけを更新します。複数のURLを同時にリクエストしてログが混ざるのを防げます。
- エラー全文をコピーし、発生時刻を記録します。続いてログ画面を開き、ステータスコード、タイムアウト、証明書、アドレスの競合、解析エラーを重点的に確認します。
- 既存ノードに接続できるか確認します。旧ノードは使えるのに更新だけ失敗する場合、通常はサブスクリプションのリクエスト経路に問題があり、プロキシコア自体が壊れているとは限りません。
- 複数のサブスクリプションが同時に失敗する場合は、まず端末のネットワーク、システム時刻、プロキシポートを確認します。1つのグループだけ失敗する場合は、そのURLの有効性と形式から調べます。
エラー：The request was canceled due to the configured HttpClient.Timeout
原因と対処：設定された時間内に完全なレスポンスを受信できませんでした。まずネットワーク経路を切り替え、プロキシ経由と直接接続の両方で更新を試します。
エラー：Response status code does not indicate success: 404
原因と対処：リモートパスが存在しないか、サブスクリプションURLが変更されています。サービスのページに戻って完全なURLをコピーし直し、パスを手入力で補わないでください。
原因1：サブスクリプションURLが無効、またはコピーが不完全
サブスクリプションURLには、長いパスやアクセス用パラメータが含まれていることがあります。チャット画面での折り返し、末尾への空白の混入、疑問符より前までしかコピーしていないことなどで、サーバーがエラーページを返す場合があります。ステータスコードで原因を素早く切り分けられます。401または403は認証状態、404はパスの不存在、410はリソースの撤回を示すことが一般的です。
v2rayNのサブスクリプショングループ設定でURLを貼り直し、途中で切れた内容を直接編集しないでください。「サブスクリプショングループ」に関する管理画面を開き、対象グループを選んでURLの先頭と末尾を確認します。URLは1行に保ち、正しいHTTPSアドレスで始め、末尾に日本語の句読点、改行、余分な引用符を付けないでください。
- 更新後のノード数が0：リモート側が空のサブスクリプション、ログインページ、案内ページなどのHTMLを返している可能性があります。
- 古いノードは残るが新しいノードがない：同名の別サブスクリプショングループを更新していないか確認します。
- ブラウザーでは開けるのにクライアントでは失敗する：ブラウザーにはログイン状態が保持されていても、v2rayNのリクエストでは自動的に引き継がれない場合があります。
- コピーし直すとすぐ復旧する：古いURLの期限切れ、パラメータの更新、コピー途中での欠落が原因であることが多く、クライアントの再インストールは不要です。
エラー：Response status code does not indicate success: 403
原因と対処：サーバーが現在のリクエストを拒否しています。URLの認証が無効になったか、アクセス条件が変わった場合によく起こります。サブスクリプションURLを取得し直し、アカウント側の契約状態を確認してください。
エラー：Unexpected character encountered while parsing value: <
原因と対処：レスポンスがHTMLタグで始まっており、解析可能なサブスクリプションデータではありません。URLがログインページやエラー案内ページへリダイレクトされていないか確認します。
原因2：ネットワーク経路、DNS、更新方法の不一致
サブスクリプションサーバーとノードサーバーは別の接続先です。ノードが一時的に使えても、サブスクリプションのドメインに現在のネットワーク経路からアクセスできるとは限りません。逆に、サブスクリプションを更新できても、すべてのノードに接続できるとは限りません。「サブスクリプションの取得」と「ノードへの接続」を分けてテストしてください。
直接接続で更新がタイムアウトする場合は、まず利用可能なノードに接続し、サブスクリプション設定でプロキシ経由の更新を有効にして再試行します。プロキシ経由で失敗する場合は、その設定を無効にして直接接続を試します。2つの結果から、問題がローカルの直接接続経路にあるのか、現在のプロキシの外向き接続にあるのかを判断できます。
| テスト結果 | 考えられる原因 | 次の手順 |
|---|---|---|
| 直接接続は失敗、プロキシは成功 | ローカルの直接接続経路またはDNS解決の異常 | プロキシ経由の更新を維持し、端末のDNSとネットワーク経路を確認 |
| 直接接続は成功、プロキシは失敗 | 現在のノードが利用できない、またはプロキシポートが待ち受けていない | 利用可能なノードへ切り替え、ローカルの待ち受けポートを確認 |
| どちらも404を返す | サブスクリプションのパスが無効 | 完全なURLを取得し直す |
| どちらもタイムアウトする | ドメイン解決、リモートサービス、またはシステムネットワークの異常 | ネットワークを変更して、もう一度単独でテスト |
結論：直接接続とプロキシ経由の更新を比較する
同じURLを2つの経路で試した結果は、更新ボタンを連打するより原因を判断する材料になります。片方の経路だけ失敗する場合は、その経路を優先して修復します。両方が同じステータスコードを返す場合は、まずURL自体を確認してください。
原因3：ローカルプロキシポートの競合、または待ち受け未起動
v2rayNがプロキシ経由でサブスクリプションを取得するには、ローカルプロキシポートが待ち受け状態になっている必要があります。一般的な設定では10808がローカル混合プロキシポートとして使われますが、古い設定では10808と10809を別々に使う場合もあります。ポート番号は固定ルールではないため、現在のインストール環境で「設定」→「パラメーター設定」に表示される内容を基準にしてください。
別のプログラムが同じポートを使用すると、コアを起動できず、システムプロキシが古いポートを指したままになることがあります。その結果、サブスクリプションのリクエストが接続拒否や長時間待機になります。まずメイン画面とログでコアの起動状態を確認し、システムプロキシが実際に向いているアドレスを照合します。
[Warning] subscription update failed
System.Net.Http.HttpRequestException: Connection refused (127.0.0.1:10808)
[Error] failed to start listener
listen tcp 127.0.0.1:10808: bind: address already in use- 「設定」→「パラメーター設定」を開き、現在のローカルプロキシポートを記録します（例：10808）。
- ログに
address already in use、connection refused、または待ち受け開始の失敗がないか確認します。 - ポートを使用しているプログラムを終了するか、v2rayNのローカルポートを未使用の番号へ変更します。たとえば10808から10818へ変更します。
- 設定を保存してコアを再起動し、システムプロキシを設定し直します。システムプロキシが古いポートを使い続けていないことを確認してください。
- まず通常のWebページへのリクエストをテストし、その後に1つのサブスクリプショングループだけを更新します。複数の要因を同時に持ち込まないためです。
エラー：No connection could be made because the target machine actively refused it
原因と対処：サブスクリプションのリクエスト先となるローカルプロキシポートが待ち受けていません。コアを起動し、プロキシ経由の更新で使うポートがパラメーター設定と一致しているか確認します。
エラー：bind: address already in use
原因と対処：ローカルポートが別のプロセスに使用されています。そのポートを解放するか、v2rayNの待ち受けポートを変更し、保存後にコアを再起動してください。
原因4：サブスクリプションの形式とクライアントの解析範囲が一致しない
よくあるサブスクリプションのレスポンスには、base64でまとめられた共有リンク一覧、1行ずつ並んだVMessまたはVLESSの共有リンク、サーバー側が生成するクライアント専用データがあります。ネイティブV2Ray JSON設定とサブスクリプションの集約データは同じ構造ではありません。JSON設定はinbounds、outbounds、ルーティング、DNSを含む完全な構成を記述し、サブスクリプションは通常、サーバー項目をまとめて配布するために使われます。
v2rayNは一般的な共有リンクとサブスクリプションの集約形式を認識できますが、レスポンスがWebページ、圧縮データ、空のテキスト、または別のパーサー向けの専用形式の場合は解析に失敗することがあります。Android版のv2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。コアの違いがあるからといって、すべての外側のサブスクリプション形式を相互利用できるわけではありません。
| レスポンスの特徴 | 意味 | 対処方法 |
|---|---|---|
| 長い英数字と等号で構成されている | base64でまとめられた内容の可能性 | 元の内容を維持し、手動で改行したり末尾の文字を削除したりしない |
| 各行がvmess://またはvless://で始まる | 共有リンクの一覧 | 各レコードが完全か確認する。特にクエリパラメータと名前部分を確認 |
| 中括弧で始まり、inbounds、outboundsを含む | 完全なJSON設定 | 設定のインポートとして扱い、サブスクリプションの集約データと決めつけない |
| <htmlまたは<!DOCTYPEで始まる | Webページまたはエラーページ | ログインへのリダイレクト、アクセス権限、サブスクリプションURLを確認 |
| レスポンスの長さが0 | リモート側が空の内容を返している | しばらく待って再試行し、サーバー側のサブスクリプションに有効なサーバーがあるか確認 |
結論：ダウンロード成功と解析成功は別
ステータスコード200は、サーバーが内容を返したことを示すだけです。更新後もノードが0件の場合は、ローカルプロキシポートを調整し続けるのではなく、レスポンスの種類とサブスクリプション形式を確認します。
原因5：システム時刻のずれによる証明書接続エラー
HTTPS接続では、証明書の有効期間とドメインを検証します。PCの時刻、日付、タイムゾーンが大きくずれていると、証明書がまだ有効でない、または期限切れと判定されることがあります。この問題は複数のサブスクリプションURLに同時に影響し、ブラウザーの証明書警告、システムへのログイン異常、その他のHTTPSリクエスト失敗を伴う場合があります。
まずシステムの日付と時刻の設定を開き、自動同期を有効にして、タイムゾーンが現在地と一致していることを確認します。同期後はv2rayNを完全に終了し、再起動して1つのサブスクリプションだけを更新します。時計の表示だけを直してタイムゾーンを修正しないと、数時間のずれが残る場合があります。
エラー：The remote certificate is invalid according to the validation procedure
原因と対処：証明書の検証に失敗しました。まずシステム時刻とタイムゾーンを同期し、サブスクリプションのドメインと証明書の対応を確認します。
エラー：certificate has expired or is not yet valid
原因と対処：端末の時刻が大きくずれているか、リモート証明書が有効期間外です。まず端末の時刻を補正してください。複数の端末で同時に起きている場合は、サーバー側の対応を待ちます。
- 年、月、日、現在のタイムゾーンを確認します。タスクバーの時分だけを確認しないでください。
- システム時刻を同期したら、ネットワーク接続を再確立し、以前失敗したHTTPSセッションを再利用しないようにします。
- 1つのサブスクリプションドメインだけで証明書エラーが出る場合は、URLが別のドメインへリダイレクトされていないか確認します。
- 複数の一般的なHTTPSアドレスで同時に異常が起きる場合は、まずシステム時刻、ネットワークの遮断・検査、本端末の証明書環境を確認します。
自動更新の間隔はどう設定する？
更新トラブルを解決してから自動更新を設定します。頻度は高ければよいわけではありません。サーバー一覧は通常、分単位では変わらず、短すぎる間隔は失敗ログを増やし、ネットワーク復旧直後に処理を繰り返す原因にもなります。個人利用の多くでは12時間または24時間で十分です。
v2rayN 7.12.5では、サブスクリプショングループの管理画面から対象グループを編集し、自動更新を設定できます。共通パラメーターは「設定」→「パラメーター設定」で確認します。7.xのバージョンによってメニュー名が少し異なる場合があるため、現在の画面に表示されるサブスクリプショングループ設定を基準にしてください。変更後は手動更新を1回行い、URL、ネットワーク経路、解析が正常であることを確認します。
- まず対象グループを手動で更新し、現在のURLからサーバー情報が正常に返ることを確認します。
- 通常は12時間ごとに更新し、サーバーの変更が少ない場合は24時間に設定します。
- 複数のサブスクリプショングループをすべて極端に短い間隔に設定しないでください。起動後に大量のリクエストが同時発生するのを防げます。
- プロキシ経由で更新する場合は、自動タスクの実行中にコアが起動しており、対応するローカルポートが待ち受けていることを確認します。
- 更新後は1～2個のノードをランダムに選び、遅延と接続をテストします。ノード数だけで結果を判断しないでください。
サブスクリプションの更新がいつもタイムアウトする場合は？
まず既存の利用可能なノードに接続し、プロキシ経由の更新に切り替えて再試行します。それでもタイムアウトする場合は、ネットワークを変更し、サブスクリプションのドメインを解決できるか確認します。
更新は成功したのに、なぜノード一覧が変わらない？
現在表示されているサブスクリプショングループを更新したか確認し、リモート側で新しいレコードが実際に公開されているか調べます。ノード数が同じでも、更新が実行されていないとは限りません。
更新後、以前のノードは先に削除すべき？
削除する必要はありません。新しいサブスクリプションを解析できることを確認するまで古い記録を残し、その後で重複ノードを整理します。一時的に使える接続先を失わずに済みます。
プロキシ経由の更新で10808への接続に失敗する場合は？
「設定」→「パラメーター設定」でローカルポートを確認し、コアが起動していることを確かめます。実際のポートが10818なら、10808へリクエストし続けることはできません。
毎日1回、手動で更新する必要はある？
必要ありません。手動更新に成功したら、よく使うグループを12時間または24時間ごとの自動更新に設定し、定期的に失敗ログを確認すれば十分です。
完全な切り分けは「まずURL、次に経路、その後にポート、形式、最後に時刻」の順で行います。1つのグループだけが失敗する場合はURLと形式から調べ、すべてのグループが同時に失敗する場合はネットワーク、ポート、システム時刻を優先して確認します。エラー全文とテスト結果を残しておくと、関係のない設定を何度も変更せずに済みます。