サブスクリプションの更新失敗は、すべてのノードが無効になったことを意味しません。クライアントが更新を行うには、ドメイン名の解決、サーバーへの接続、HTTPレスポンスの受信、本文の読み込み、エンコードの識別、共有リンクの解析、ローカル設定への書き込みを完了する必要があります。どこか1つが中断すると、画面には「更新に失敗しました」「解析エラー」「有効なサーバーが見つかりません」などと表示されることがあります。

切り分けの際は、既存のノードを先に削除したり、クライアントを何度も再インストールしたりしないでください。現在の設定とログを残したうえで、失敗がネットワークリクエスト段階なのか、コンテンツ解析段階なのかを確認します。この区別だけで、確認範囲を数十項目から2〜3項目に絞れます。

この記事の概要

この記事は、v2rayN、v2rayNG、v2flyNGでVMessやVLESSなどのサブスクリプションを更新する際に、タイムアウト、空のリスト、形式エラー、HTTPステータス異常が発生した方に向けたものです。「URLの有効性 → アドレスの完全性 → レスポンス形式 → クライアントのバージョン → ネットワーク経路 → レスポンス本文」の順に確認すれば、既存ノードを変更せずに原因箇所を特定できることが多いでしょう。

失敗した段階を特定する：リクエスト、レスポンス、それとも解析か

サブスクリプションの更新は3段階に分けられます。第1段階はリクエストです。クライアントがサブスクリプションのドメインを解決し、サーバーへ接続します。第2段階はレスポンスです。サーバーがステータスコード、レスポンスヘッダー、本文を返します。第3段階は解析です。クライアントが本文からVMessやVLESSなどの共有リンクを識別し、有効な項目をサブスクリプショングループへ書き込みます。

「タイムアウト」「ホスト名を解決できない」「接続が拒否された」は、通常リクエスト段階のエラーです。「401」「403」「404」「500」はレスポンス段階に該当します。「有効なサーバーがありません」「サポートされていない形式です」「Base64のデコードに失敗しました」は解析段階のエラーです。まず元のエラーメッセージを書き留め、ポップアップのタイトルだけで判断しないでください。

  • リクエスト段階：DNS、ネットワーク到達性、システム時刻、現在のプロキシ経由で更新する必要があるかを確認します。
  • レスポンス段階：URLの有効期限、アクセス権限の変更、サーバーのリダイレクトや一時的な障害を確認します。
  • 解析段階：返された本文が想定したサブスクリプション形式か、クライアントが含まれるプロトコル項目に対応しているかを確認します。
  • 書き込み段階：サブスクリプショングループが有効か、同名ノードが除外されていないか、更新後に正しいグループへ切り替わっているかを確認します。
200
正常なHTTPステータスコード
10秒
初回接続時の確認時間
10808
一般的なローカルSOCKSポート
10809
一般的なローカルHTTPポート

原因1・2：URLの期限切れまたは入力ミス

最も多いのは、URL自体がすでに無効になっているケースです。サブスクリプションURLには通常、アカウントや設定セットを識別する長い文字列が含まれています。サーバー側でURLが変更された、古いリンクが無効化された、アクセス期限が調整されたなどの理由で、旧URLは401、403、404を返したり、案内ページへリダイレクトされたりします。この場合、クライアントは接続できても、解析可能なノードデータを取得できません。

2つ目は、コピーが不完全なケースです。チャット画面での自動改行、ブラウザーでの部分選択、末尾に付いたピリオド、パラメーター内の & のエスケープなどによって、実際のリクエストURLが変わります。特に ?token=、&type=、パーセントエンコードを含む長いURLは、1文字欠けただけでもまったく異なるレスポンスになることがあります。

エラー：Response status code does not indicate success: 401

原因と対処：サーバーが現在の認証情報を拒否しています。サブスクリプションの有効期限を確認し、元の管理ページから完全なURLをコピーし直してください。

エラー：The remote server returned an error: 403 Forbidden

原因と対処：URLは有効ですが、アクセス条件を満たしていません。リンクが変更されていないか確認し、ブラウザーの履歴に残った古いURLを使い続けないでください。

エラー：Response status code does not indicate success: 404

原因と対処：リクエスト先のパスが存在しません。ドメイン以降のパス、スラッシュ、クエリパラメーター、コピー時に抜けた末尾文字を重点的に確認します。

  1. サブスクリプション設定で編集画面を開き、元の情報と照らし合わせながら、URLの先頭、ドメイン、パス、クエリパラメーターを1文字ずつ確認します。
  2. URLの先頭と末尾にあるスペース、改行、日本語の句読点を削除します。URLの途中にあるパーセントエンコードは変更しないでください。
  3. 提供元から新しいサブスクリプションURLが案内されている場合は、新しいサブスクリプショングループを作成してテストします。すぐに、元に戻せる旧グループを上書きしないでください。
  4. 401、403、404が返る場合、DNSやポート、コアを切り替え続けても通常は解決しません。まずURLとアクセス権限を確認してください。

原因3：レスポンスのエンコードがクライアントの想定と異なる

サブスクリプションに単一の標準ファイルがあるわけではありません。一般的な形式には、Base64でラップされた複数行の共有リンク、直接返されるプレーンテキストのリンク一覧、クライアント種別に応じてサーバーが生成する専用構造などがあります。VMessの共有項目にはエンコードされたJSONデータが含まれることが多く、VLESSは通常URI形式で、クエリパラメーターによってトランスポート、セキュリティ層、サービス名などを表します。

問題は「リクエストには成功したが、コンテンツの種類が違う」場合によく起こります。たとえば、リクエストパラメーターに応じてサーバーが別のクライアント用設定を返す、URLが実際にはログインページを指している、リバースプロキシがエラーページをHTTP 200で返す、本文が案内文だけになっている、といったケースです。ステータスコードが正常でも、サブスクリプションとして利用できるレスポンスだとは限りません。

レスポンスの特徴 クライアントでの表示 優先して確認する項目
複数行の vmess://、vless:// 通常はそのまま認識可能 リンクが完全か、プロトコル項目が現在のコアに対応しているか
アルファベット、数字、エンコード文字が連続する長い文字列 クライアントがBase64のデコードを試行 本文が途中で切れていないか、前後に案内文が混ざっていないか
<html またはWebページのタイトルで始まる 解析失敗または有効なノードなしと表示 ログインページ、エラーページ、アクセス案内ページへリダイレクトされていないか
共有リンクを含まない構造化設定 リストが空、または形式がサポートされていないと表示 サブスクリプション種別のパラメーターを誤って選んでいないか、現在のクライアントに合う形式か
本文の長さが0 更新完了後もノード数が0 サーバー側の生成タスク、キャッシュ、上流データソース

結論：HTTP 200はサブスクリプションが有効である証明ではない

リクエストに成功したのに追加ノード数が0の場合は、ローカルの待ち受けポートを変え続けるのではなく、本文の種類と先頭数十文字を確認してください。

原因4：クライアントのバージョンが古い、またはコアの機能が合わない

サブスクリプションの解析はクライアントが行い、ノード接続はV2RayまたはXrayコアが実行します。クライアントのバージョンが古いと、新しく追加されたクエリパラメーター、トランスポートの組み合わせ、サブスクリプション項目を認識できないことがあります。コアのバージョンが古い場合は、ノードをリストへ取り込めても、起動時に未知の項目、無効な設定、サポートされていないトランスポート設定などが報告されます。

v2rayNはデスクトップ環境で使用し、複数のコアやサブスクリプショングループを管理できます。v2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。3つのクライアントは、画面構成、初期値、プロトコルの対応範囲が完全に同じではありません。同じサブスクリプションを1つのクライアントで取り込めても、すべてのノードが別のコアで起動できるとは限りません。

v2rayN 7.x
デスクトップ版の確認基準
v2rayNG 1.10.x
Android版Xrayクライアントの確認基準
2層
クライアントによる解析とコアによる実行
  • まったく取り込めない：まずクライアント本体を更新し、サブスクリプショングループを作り直します。
  • 取り込めるが起動できない：コアのログを開き、unknown field、invalid config などのキーワードを確認します。
  • 一部のノードだけ消える：消えたノードのプロトコル、トランスポート方式、セキュリティパラメーターを比較し、クライアントのフィルター対象になっていないか確認します。
  • 更新後も古いリストが表示される：現在のサブスクリプショングループを更新しているか確認し、備考による重複排除やフィルター規則が有効になっていないか確認します。

アップグレード前に、現在のバージョン番号とサブスクリプショングループ名を記録します。アップグレード後はまずテストグループを更新し、ノード数、備考、プロトコル種別が想定どおりか確認してからメイングループを処理します。これにより、バージョン変更とサブスクリプション提供元の変更を区別できます。

原因5：現在のネットワークからサブスクリプションサーバーへ直接接続できない

サブスクリプションサーバーとノードサーバーは別の接続先です。既存ノードに接続できても、サブスクリプションのドメインへ直接接続できるとは限りません。逆に、サブスクリプションの更新に成功しても、すべてのノードが利用できるとは限りません。DNS汚染、ドメイン解決の失敗、ネットワーク出口の制限、証明書の時刻エラー、接続タイムアウトなどにより、リクエストが名前解決やハンドシェイクの段階で止まることがあります。

ローカルに利用可能なノードがある場合は、「直接接続で更新」と「プロキシ経由で更新」の結果を比較できます。v2rayNのサブスクリプショングループメニューには通常、2種類の更新方法があります。プロキシ経由でのみ更新に成功する場合、問題はサブスクリプション形式ではなく、現在の直接接続経路にある可能性が高いでしょう。

  1. 現在の接続を保持する

    サーバーリストを先に空にしないでください。接続できることを確認済みのノードを1つ選び、コアが動作していることを確認してローカルポートを記録します。

  2. 直接接続で更新をテストする

    v2rayNのメイン画面で「サブスクリプショングループ」→「すべてのサブスクリプションを更新（プロキシを使用しない）」を開き、10秒以内に出る最初のログとHTTPステータスを確認します。

  3. プロキシ経由で更新する

    利用可能なノードへの接続を維持したまま、「サブスクリプショングループ」→「すべてのサブスクリプションを更新（プロキシ経由）」を実行します。成功した場合は、ローカルDNSと直接接続のルートを引き続き確認します。

  4. プロキシポートを確認する

    「設定」→「パラメーター設定」を開き、ローカルの待ち受けポートが現在のコアと一致しているか確認します。一般的なSOCKSポートは10808、HTTPポートは10809ですが、実際の画面に表示される値を優先してください。

  5. システム時刻を確認する

    日付、タイムゾーン、自動時刻合わせを正しい状態に戻します。システム時刻のずれが大きいと、TLS証明書の検証に失敗し、ログに証明書がまだ有効でない、または期限切れであるというメッセージが表示されることがあります。

エラー：The operation has timed out

原因と対処：リクエストが制限時間内に完了していません。直接接続での更新とプロキシ経由での更新を比較し、DNS、ルート、サブスクリプションサーバーへの到達性を確認します。

エラー：No such host is known

原因と対処：サブスクリプションのドメインを解決できません。システムのDNSキャッシュを消去し、信頼できるDNSへ切り替えてからクライアントを再起動してテストします。

エラー：The SSL connection could not be established

原因と対処：TLSハンドシェイクが完了していません。まずシステム時刻を調整し、ネットワーク上の中間機器が証明書を置き換えたり接続を中断したりしていないか確認します。

原因6：サーバーが空の本文または空のノード集合を返す

空のレスポンスと形式エラーは異なります。形式エラーはクライアントが内容を受信したものの理解できない状態です。空のレスポンスは、本文の長さが0、またはサーバーが生成したノード集合自体に項目がない状態を指します。クライアントに「更新成功」と表示されてもノードが追加されないことがあり、「有効なサーバーが見つかりません」と明確に報告される場合もあります。

空の集合になる主な原因には、サブスクリプション生成タスクが完了していない、アカウントに利用可能なノードがない、サーバー側のフィルター条件ですべての項目が除外された、上流データが一時的に空になっている、キャッシュが古い空の結果を返している、といったものがあります。この場合、ローカルのコアを何度切り替えても不足しているデータは生成されません。

エラー：Failed to parse subscription content

原因と対処：本文は存在しますが、クライアントが認識できる形式ではありません。Webページ、案内文、または一致しない設定形式が返されていないか確認します。

エラー：No valid server was found

原因と対処：解析後に有効なノードが得られていません。レスポンスが空でないか、ノードのプロトコルがサポートされているか、フィルター規則ですべての項目が除外されていないかを確認します。

エラー：Subscription content is empty

原因と対処：サーバーが空の本文を返しています。サーバー側でサブスクリプションが再生成されるまで待つか、アカウントに利用可能な設定が残っているか提供元へ確認します。

  • 更新前後のノード数を記録します。常に0の場合は、まずサーバー側の生成結果を確認してください。
  • 備考キーワードによるフィルター、プロトコルフィルター、重複排除ルールを一時的に無効にしてから、テストグループを更新します。
  • 案内文が返された場合は、記載されたステータス情報に従って対応します。案内ページをサブスクリプションとして取り込み続けないでください。
  • 同じURLが異なるネットワークでも空の内容を返す場合、問題はローカルDNSよりもサーバー側にある可能性が高いでしょう。

結論：空のリストでは、まずデータソースを確認し、コアを先に変更しない

ノード数が通常の値から突然0になり、リクエストのステータスが200のままの場合は、まずテストグループを作成してレスポンス本文を確認します。空の結果で、まだ使用できるローカルリストを上書きしないようにしてください。

完全な確認手順：コストの低い項目から始める

適切な切り分け順序では、最も一般的で検証しやすく、ローカル状態をほとんど変更しない項目から確認します。サブスクリプションURL、クライアントのバージョン、DNS、コアを同時に変更しないでください。復旧しても、本当の原因を特定できなくなります。

  1. 元のエラーを記録する

    更新ログを開き、最初の失敗に対応するエラー本文、時刻、HTTPステータスコード、更新方法を記録します。タイムアウト、アクセス拒否、解析失敗を区別してください。

  2. URL全体を確認する

    「サブスクリプショングループ」→「サブスクリプショングループ設定」を開き、URLの前後のスペース、ドメイン、パス、パラメーターを確認して、元の情報と1項目ずつ照合します。

  3. テストグループを作成する

    独立したグループを新規作成してURLを貼り付け、フィルター規則は一時的に無効にします。更新後、ノード総数とVMess、VLESSなどのプロトコル分布を記録します。

  4. ネットワーク経路を比較する

    直接接続での更新とプロキシ経由での更新をそれぞれ実行します。後者だけが成功する場合は、DNS、システム時刻、直接接続のルートを確認します。

  5. クライアントを更新する

    保守が継続されているv2rayN、v2rayNG、v2flyNGのバージョンを使用していることを確認し、対応するコアがサブスクリプション内のプロトコルとトランスポート項目を認識できるか確認します。

  6. レスポンス内容を確認する

    サーバーが共有リンクの一覧、またはクライアントが認識できるエンコード済みコンテンツを返していることを確認します。ログインページ、エラーページ、案内文、空の本文ではないことも確認してください。

サブスクリプション更新がタイムアウトしたら、まずクライアントを再インストールすべきですか？

必要ありません。まずログで、タイムアウトがドメイン解決、TCP接続、TLSハンドシェイクのどこで発生したか確認します。そのうえで「すべてのサブスクリプションを更新（プロキシを使用しない）」と「すべてのサブスクリプションを更新（プロキシ経由）」の結果を比較してください。

ブラウザーではサブスクリプションURLを開けるのに、なぜクライアントでは解析失敗になりますか？

ブラウザーで開けることは、サーバーが何らかの内容を返したことを示すだけです。ページ本文がログインページ、エラー案内、別の設定形式になっていないか確認してください。HTTP 200だけでは、v2rayN、v2rayNG、v2flyNGが認識できる内容だとは証明できません。

更新後にノード数が0になりました。古いノードは残せますか？

元のグループを先に上書きしないでください。テストグループを作成して更新し、フィルター規則を無効にします。テストグループも0の場合は、レスポンス本文とサーバー側のノード集合を確認してから、古い設定を置き換えるか判断します。

同じサブスクリプションをv2rayNGでは取り込めるのに、v2flyNGでは一部のノードが消えます。なぜですか？

消えたノードが使用するプロトコル項目、トランスポート方式、セキュリティパラメーターを比較します。2つのクライアントは異なるコアを採用しているため、対応範囲や初期処理が一致しない場合があります。判断には該当するコアのログを使用してください。

プロキシ経由なら更新できますが、プロキシを無効にすると失敗します。サブスクリプションを変更すべきですか？

通常、先にサブスクリプションを変更する必要はありません。この結果は、URLと形式が大きく問題ない可能性を示します。直接接続時のDNS、システム時刻、ネットワークルート、現在のネットワークからサブスクリプションのドメインへ到達できるかを確認してください。

最後に最小限の検証をもう一度行います。旧グループを残してテストグループを新規作成し、完全なURLを使用し、フィルターを無効にします。まず直接接続で更新し、次にプロキシ経由で更新して、最初のログとノード数を記録します。これで問題をURL、ネットワーク、形式、バージョン、サーバー側データの5つの範囲のいずれかに絞れます。

サブスクリプションが復旧したら、無効なグループを削除して現在アクティブなノードを選び直します。切り分け中にルーティングモード、システムプロキシ、TUN設定を変更した場合は、元の設定へ戻して再接続し、現在のコアプロセスに最終的なルールを読み込ませます。