v2rayNとv2rayNGで「更新に失敗する」「空の内容が返る」「解析後のノード数が0になる」といった問題に対応します。まずダウンロード、解析、表示の3段階を切り分け、サブスクリプションURL、接続経路、レスポンス内容、グループフィルターを順に確認します。いきなりクライアントを削除したり、コア設定をむやみに変更したりする必要はありません。
まず失敗した段階を切り分ける
「サブスクリプションの更新失敗」は、単一の障害を指すものではありません。クライアントがサブスクリプションを更新するには、少なくともネットワーク接続、レスポンス取得、内容の判別、ノード解析、グループへの書き込み、フィルター適用の6段階を完了する必要があります。失敗した段階によって対処方法は大きく異なります。
ログに403、タイムアウト、名前解決エラーがある場合、問題は通常、取得段階で発生しています。「更新完了」と表示されたのに追加ノード数が0の場合は、サブスクリプション本文の形式、重複ノードの処理、グループフィルターの条件を確認します。
| 確認できる現象 | 優先して確認する項目 | 先に行わない操作 |
|---|---|---|
| 401、403、404が直ちに表示される | URLの有効期限、アカウント状態、クエリパラメータの完全性 | Coreの種類を切り替える |
| 10〜30秒待つとタイムアウトする | DNS、更新時のプロキシ経由、システム時刻 | 既存ノードを一括削除する |
| ダウンロード成功後に解析結果が0になる | レスポンス本文、エンコード方式、形式の互換性 | ノードの遅延を何度もテストする |
| ログではインポート成功だがリストが空 | 現在のサブスクリプショングループ、フィルター式、非表示状態 | クライアントを再インストールする |
サブスクリプションURLの期限切れ・欠落・コピーエラー
サブスクリプションURLは単なるパスではなく、末尾に認証パラメータ、端末識別子、有効期限などが含まれる場合があります。コピー時に1文字欠けたり、疑問符以降のクエリパラメータが抜けたり、改行が混入したりすると、サーバーからアクセス拒否や「存在しない」という応答が返ります。
チャット画面、QRコードの読み取り結果、折りたたみ表示のページからコピーする場合、表示されている部分だけを取得しがちです。URLの途中に空白がある場合や、末尾にピリオド、閉じ括弧、日本語の句読点が付いている場合は、それらが元のURLに含まれる文字かどうかを再確認してください。
グループ設定を開く
v2rayN 7.xのメイン画面で「サブスクリプショングループ」→「サブスクリプショングループ設定」を開き、問題のグループを選択します。同名のグループを新規作成しないでください。
URLをコピーし直す
サブスクリプションの提供元から完全コピーを使って取得し、先頭が有効なHTTPまたはHTTPS URLであること、改行、日本語の空白、余分な記号が含まれていないことを確認します。
古いURLを置き換える
入力欄の既存内容を削除してから貼り付け、古いURLの末尾に文字が残らないようにします。保存前に、疑問符以降のパラメータが完全か確認してください。
グループを個別に更新する
まず現在のグループだけを更新し、ログを確認します。すべてのサブスクリプションを同時に更新しないでください。個別に操作したほうが、具体的なエラーとレスポンス時刻を対応づけやすくなります。
HTTP 401または403は通常、サーバーがリクエストを受信したものの、そのURLにアクセス権がないことを示します。404はパスが変更されたか、コピーが不完全な場合によく発生します。410は、そのURLが明示的に停止された可能性を示します。これらのステータスコードが出たとき、ローカルポートやルーティングルールは通常、最初に確認すべき項目ではありません。
更新リクエストが利用可能なネットワークを経由していない
サブスクリプションURL自体が正常でも、クライアントの更新が到達できない直接接続経路を使っていると、タイムアウトになります。ブラウザーでページを開けても、クライアントのサブスクリプションリクエストが同じプロキシ、DNS、ネットワークインターフェースを使っているとは限りません。
v2rayNでは通常、プロキシ経由で更新する操作と、プロキシを経由せずに更新する操作を選べます。現在のネットワークからサブスクリプションサーバーへ直接接続できない場合は、まず利用可能なノードを起動してから、プロキシ経由で更新します。既存のノードがすべて利用できない場合は、そのURLへアクセスできるネットワーク環境で新しい設定を取得する必要があります。
エラー: The operation has timed out
原因と対処:制限時間内にレスポンスを取得できませんでした。まずシステム時刻が正しいことを確認し、利用可能と検証済みのノードを起動してから、「すべてのサブスクリプションを更新」に切り替え、リクエストが現在のプロキシを経由しているか確認します。
エラー: No such host is known
原因と対処:サブスクリプションのドメイン名を解決できていません。利用可能なDNSへ切り替え、ネットワークを切断して再接続し、クライアントのコアを再起動してから更新します。
エラー: The remote server returned an error: (403) Forbidden
原因と対処:サーバーが現在のリクエストを拒否しています。有効なサブスクリプションURLを再取得し、アカウント状態、URLの有効期限、クエリパラメータに変更がないことを確認してください。
エラー: An existing connection was forcibly closed by the remote host
原因と対処:通信中にリモート側またはネットワーク機器によって接続が閉じられました。更新方法やネットワークインターフェースを切り替え、スリープ復帰直後に無効な接続をそのまま使わないようにします。
ローカルリスニングが実際に起動しているかも確認します。v2rayNでは、10808をローカルSocksまたは混合リスニングポートとして使う構成が一般的です。古い設定ではHTTPリスニングが10809の場合もあります。実際のポートは、「設定」→「パラメータ設定」のローカルリスニング項目と起動ログを基準にし、古い解説だけで決めないでください。
ポートが別のプログラムに占有されていると、コアが正常に起動せず、現在のプロキシを使ったサブスクリプション更新もできません。まず下部ログに「address already in use」のような表示がないか確認し、占有しているプログラムを終了するかリスニングポートを変更して、保存後にコアを再起動します。
結論: ブラウザーでアクセスできてもクライアントで更新できるとは限らない
判断の根拠にするのは、クライアントログに記録されたリクエスト結果です。ブラウザー拡張機能、システムプロキシ、v2rayN内部の更新リクエストは、それぞれ異なる経路を使う可能性があります。ステータスコードとレスポンスサイズだけが、サブスクリプションリクエストが完了したかを直接示します。
Base64デコードエラーとレスポンス形式の非互換
一般的なサブスクリプション本文は、VMess、VLESS、Trojan、ShadowsocksのURIを並べたテキストの場合もあれば、テキスト全体をBase64エンコードしたものの場合もあります。サブスクリプション形式はサービスやクライアント間で完全に統一されているわけではないため、長い文字列だからといって必ずデコードできるとは限りません。
サーバーが実際にはログインページ、エラー説明、JSONメッセージを返している場合でも、クライアントがサブスクリプション形式として解析を試みることがあります。その結果、Base64の長さエラー、無効な文字、ノード数0が発生します。まずレスポンスの内容を確認し、文字列に手作業で文字を追加しないでください。
正常な確認ログの例
HTTP ステータス: 200
レスポンスタイプ: text/plain
レスポンスサイズ: 18.6 KB
内容の特徴: ノードURIのリストまたは完全なBase64テキスト
解析結果: 24件
フィルター後の表示: 18件
エラー: Invalid length for a Base-64 char array or string
原因と対処:本文が途中で切れている、エンコード対象外の文字が混入している、または返された内容がそもそもBase64ではありません。サブスクリプションを再取得し、欠けた末尾を手作業でつなぎ合わせないでください。
エラー: Invalid URI: The format of the URI could not be determined
原因と対処:デコード後のいずれかの行が、完全なノードURIになっていません。レスポンスに説明文が混入していないか確認し、クライアントを最新版に更新してから再解析します。
エラー: Sequence contains no matching element
原因と対処:クライアントがレスポンス内に認識可能なノードを見つけられませんでした。サーバーの出力形式がv2rayNまたはv2rayNGに対応していることを確認し、グループ説明だけが返されていないか確認してください。
- HTTP 200はリクエストが成功したことを示すだけで、本文が有効なサブスクリプションだとは限りません。
- レスポンスが数十バイトしかない場合は、エラーメッセージ、空のグループ、URLの期限切れを優先して疑います。
- 本文の先頭にウェブページのタイトルやログイン案内がある場合、Base64として処理を続けないでください。
- 単一のVMess、VLESS、Trojan、Shadowsocksリンクは手動インポートできますが、今後の自動更新に必要なサブスクリプションURLの代わりにはなりません。
- 同じサブスクリプションが旧版では解析でき、新版では解析できない場合は、ログを保存し、サーバーが非標準フィールドを使っていないか確認します。
グループフィルターですべてのノードが非表示になる
サブスクリプションの更新に成功したのにリストが空でも、必ずしも解析失敗とは限りません。v2rayNのサブスクリプショングループには、包含・除外フィルターを設定できます。条件はノード書き込み後にも適用されるため、式が厳しすぎるとすべてのノードが非表示になります。
たとえば「香港」のみを含める設定でも、ノード名が実際には「HK」になっている場合があります。また、除外条件に「残り」と入力しているのにすべてのノード名に通信量表示が含まれている場合や、フィルター式に不完全な正規表現文字が混入している場合も、最終的な表示数が0になることがあります。
| 更新記録 | 意味 | 次の手順 |
|---|---|---|
| 取得30、解析30、表示0 | ダウンロードと解析は正常で、フィルターが最も疑わしい | 包含・除外条件を一時的に空にする |
| 取得成功、解析0 | 本文の形式を認識できていない | レスポンス内容とエンコードを確認する |
| 解析20、追加0、更新20 | ノードはすでに存在し、既存レコードのみ更新された | 現在表示しているグループを確認する |
| グループAにはノードがあるが、現在のリストは空 | 画面で別のグループを表示している | 左側のサブスクリプショングループを切り替える |
フィルター条件を記録する
「サブスクリプショングループ」→「サブスクリプショングループ設定」を開き、まず現在の包含・除外条件をコピーしておきます。確認後に元へ戻しやすくなります。
包含条件を空にする
地域、倍率、プロトコルのキーワードを一時的に削除し、サブスクリプション名とURLだけを残します。保存後、そのグループだけを更新してください。
除外条件を空にする
期限切れ、残り通信量、テストノードを非表示にする条件を削除し、フィルターなしで完全なリストが表示されるか確認します。
ルールを1つずつ戻す
条件は1つずつ戻して更新し、ノード数の変化を記録します。24件から0件になった場合、最後に戻した条件が重点的に確認すべき項目です。
v2rayNGでも、現在のグループとサブスクリプションのフィルター状態を確認します。バージョンによってメニューの配置は変わる場合がありますが、原則は同じです。まずサブスクリプション全体を表示し、その後キーワードフィルターを1つずつ戻します。v2flyNGはv2flyコアを使用するため、リストが空のときも取得、解析、表示の段階を切り分けてください。
結論: 解析数と表示数は分けて確認する
ログ上の解析数が0より大きいのにメインリストが0の場合は、まずグループ選択とフィルター条件を確認します。解析数自体が0の場合に限り、レスポンス形式とエンコードを詳しく調べます。
決まった順序でサブスクリプションを復旧する
安定した復旧手順では、変更する要素をできるだけ減らします。DNS、ポート、コア、サブスクリプションURL、フィルタールールを同時に変更すると、障害が一時的に解消しても本当の原因を特定できません。
まず起動できる既存ノードを1つ残し、それを使ってプロキシ経由の更新を確認します。次にサブスクリプションURLだけを置き換え、解析数を確認してからフィルターを戻します。全工程で同じグループのログとノード数を確認してください。
コアの動作を確認する
下部ログを確認し、ローカルリスニングが起動していることを確認します。「設定」→「パラメータ設定」でCoreの種類とリスニングポートを確認し、ポート占有エラーがないことを確認してください。
利用可能なノードを残す
古いノードをすべて削除しないでください。実際の接続テストを完了して利用可能と確認できたノードを1つ選び、現在のプロキシ経路で接続を確立できるか先に確認します。
1つのグループだけ更新する
再取得した完全なURLを使い、問題のグループだけを更新します。HTTPステータス、レスポンスサイズ、解析数、更新時刻を記録してください。
2つの経路を比較する
直接接続ではタイムアウトするがプロキシ経由では成功する場合は、プロキシ経由の更新を使います。どちらの方法でも403が返る場合は、ポートを変更し続けるのではなく、URLの権限を確認してください。
フィルタールールを戻す
フィルターなしでノードが表示されることを確認してから、包含・除外条件を1つずつ戻します。更新のたびに解析数と表示数を照合してください。
実際の接続をテストする
ノードを1つ選び、実接続テストを実行します。遅延結果が出た後にシステムプロキシを有効にして普段使うサイトへアクセスし、サブスクリプション更新の成功だけでノードの利用可否を判断しないでください。
| 最終結果 | 確認できた結論 |
|---|---|
| URLを変更すると直ちに復旧した | 元のURLが期限切れ、途中で欠落、または権限無効だった |
| プロキシ経由の更新だけ成功した | 直接接続経路、DNS、またはネットワークインターフェースに制限がある |
| フィルターを空にすると復旧した | 包含・除外条件が厳しすぎた |
| HTTP 200だが解析結果が0 | レスポンス本文の形式が非互換、またはサブスクリプション内容ではない |
それでも失敗する場合に集める情報
上記の手順を完了しても更新できない場合は、どの段階で失敗しているかを特定できる情報を整理します。完全なサブスクリプションURLは公開しないでください。アクセスパラメータが含まれている可能性があります。プロトコル、ドメインの名前解決可否、HTTPステータス、本文サイズなど、完全な認証情報を含まない部分だけを記録します。
クライアントのバージョンも重要です。v2rayN、v2rayNG、v2flyNGの具体的なバージョン番号と、使用しているXrayまたはv2flyコアのバージョンを記録します。サブスクリプション解析は通常クライアントが行いますが、バージョン差によってフィールド認識、リダイレクト処理、グループ動作に影響する場合があります。
- クライアント名と完全なバージョン番号。たとえばv2rayN 7.xの具体的なマイナーバージョン。
- OSのバージョンと現在のネットワーク種別。
- 更新操作がプロキシ経由か、プロキシを経由していないか。
- エラーが発生した時刻、HTTPステータスコード、完全なエラー内容。
- レスポンスサイズ、解析数、更新数、最終表示数。
- 「設定」→「パラメータ設定」にあるCoreの種類とローカルリスニングポート。
- サブスクリプショングループの包含条件、除外条件、現在選択中のグループ。
現象: 同じURLが複数の端末で同時に使えなくなった
原因と対処:まずURLの期限切れ、アカウント状態の変化、サーバー側の異常なレスポンスを疑います。有効なURLを再取得し、各端末で個別にポートを変更しないでください。
現象: デスクトップでは成功するがAndroidでは空になる
原因と対処:両方のクライアントバージョン、サブスクリプショングループのフィルター、レスポンス解析ログを比較します。Android側が完全なURLを使っていることを確認し、まずフィルター条件を解除してから再更新してください。
現象: 更新は成功したがノードがすべて使えない
原因と対処:サブスクリプションの取得とノード接続は別の段階です。ノードの実接続テストを行い、サーバーアドレスの名前解決、システム時刻、通信パラメータ、ルーティング設定を確認してください。
サブスクリプション更新が復旧してもウェブページがプロキシを経由しない場合は、システムプロキシとルーティング設定を引き続き確認します。v2rayNではシステムプロキシの状態と現在のアクティブサーバーを確認できます。Androidではv2rayNGまたはv2flyNGが接続を開始していることを確認し、リアルタイムログにアウトバウンドエラーがないか確認してください。