V2Rayのサブスクリプション解析に失敗する原因と確認項目：URL・エンコード・クライアントのバージョン

まずダウンロード失敗と内容の解析失敗を切り分け、購読URL、HTTPレスポンス、エンコード形式、プロキシ経路、クライアントのバージョンを順に確認します。v2rayN、v2rayNG、v2flyNGで更新後に一覧が空になる、ノードが一部欠落する、形式エラーが出る場合に役立ちます。

サブスクリプションの更新は単独の操作ではなく、一連の処理で構成されています。クライアントは保存済みURLを読み込み、直接接続またはローカルプロキシ経由でHTTPSリクエストを送信します。サーバーから本文を受け取ると、Base64、共有リンク一覧、構造化設定のいずれかとして認識し、最後にVMessやVLESSなどの項目を該当する購読グループへ書き込みます。どこか一つでも失敗すると、画面には「更新失敗」またはノード数0としか表示されないことがあります。

調査の初めから全設定を削除しないでください。まず更新時刻、レスポンス状態、ログのキーワードを確認し、「リクエストで内容を取得できなかった」のか「取得できたが解析できなかった」のかを判断します。前者は通常、DNS、プロキシ、証明書、アクセス権、HTTPステータスに関係します。後者では、レスポンスがウェブページだった、エンコードが壊れていた、現在のバージョンが対応していないプロトコル項目だった、というケースがよくあります。

以下では、リスクの低い確認から順に進めます。既存のノードを先に上書きすることはありません。v2rayN 7.14.3のメニュー構成を基準にしていますが、細かなバージョンによって表示位置は変わる場合があります。ただし、購読グループ、ログ、パラメータ設定の3種類の入口は基本的に共通しています。Androidでは、v2rayNGまたはv2flyNGの購読設定とログ画面から同様に確認できます。

一つのグループだけ失敗し、他のグループが正常なら、通常は全体のネットワーク設定を変更する必要はありません。まずそのURLの有効期限、権限、レスポンス形式を確認します。すべてのグループが同時に失敗する場合は、ネットワーク、システム時刻、ローカルプロキシのポート、ファイアウォールによる通信ブロックを優先して確認してください。

購読URLには、アカウントを識別するパスやクエリパラメータが含まれていることがよくあります。コピー時に1文字欠ける、末尾の空白まで保存する、改行位置までしかコピーしないといった操作で、サーバーのレスポンスは変わります。有効期限や端末制限があるURLでは、ドメインにアクセスできても、古いURLに対して401、403、404や案内ページが返されることがあります。

ブラウザでURLを開けても、クライアントで更新できるとは限りません。ブラウザはログイン状態を保存していたり、別のシステムプロキシを使っていたりする可能性があります。一方、クライアントは通常URLへ直接リクエストを送り、本文を購読形式として解析します。逆に、ブラウザに長い文字列が表示されても内容が正しいとは限らず、サーバーがテキストを返したことしか分かりません。

さらに確認する必要がある場合は、信頼できる環境でレスポンスのステータス、本文の先頭、バイト数を確認します。通常の購読はステータス200を返し、本文にはデコード可能なテキスト、プロトコル接頭辞で始まる複数行のリンク、またはクライアントが明確に対応する構造化データが含まれます。本文の先頭がHTMLタグ、ログイン案内、認証コードの説明、ゲートウェイエラーの場合、問題はサーバーのレスポンスにあり、VMessやVLESSのノードパラメータではありません。

従来型の購読では、複数行の共有リンク全体をBase64エンコードすることがあります。クライアントは本文を取得してデコードし、行ごとにvmess://やvless://などの項目を認識します。一方、エンコードされていない共有リンク一覧を直接返す購読もあります。そのため「Base64ではない」こと自体は必ずしもエラーではなく、重要なのはクライアントが実際のレスポンス形式を認識できるかどうかです。

VMessの単一ノードリンクと購読全体には、それぞれ別のエンコード層が含まれる場合があります。旧式のVMessリンクでは、プロトコル接頭辞の後にエンコード済みJSONが置かれることがあります。VLESSは通常、URIのクエリパラメータで通信方式、暗号化層、サーバー名を表します。提供元が不完全なエスケープや途中で切れたエンコード文字列を生成した場合、または現在のクライアントが新しいフィールドに対応していない場合、一部のノードだけが失われることも、購読全体の解析が止まることもあります。

上記の3種類の先頭部分は、それぞれBase64らしきテキスト、平文の共有リンク、エラーを返すウェブページを示します。実際の確認では形式の特徴だけを見て、アクセス用トークンを含む購読本文全体を公開デコードサイトへ送信しないでください。購読URL自体にノード一覧を読み取る権限があるため、アカウント情報として扱う必要があります。

購読リクエストは直接接続でも、現在のプロキシ出口経由でも送信できます。プロキシ経由で更新する場合、クライアントには起動して通信できる既存ノードが必要です。現在のノードが無効だと購読リクエストも止まり、「接続するには更新が必要だが、更新には現在の接続が必要」という循環に陥ります。この場合は、プロキシを使わない更新入口で確認するのが最も簡単です。

ローカルポートはクライアントの実際の設定を基準にしてください。v2rayNでは10808がよく使われますが、設定変更、構成の移行、複数インスタンスの同時実行によって変わることがあります。システムプロキシに127.0.0.1:10808と残っているからといって、クライアントが現在もそのポートを待ち受けているとは限りません。

ルーティングルールによって購読ドメインが利用できない出口へ送られることもあります。たとえばドメイン一致後に削除済みの出口タグが指定されていると、通常のウェブページは開けても、そのドメインへのリクエストだけが失敗し続けます。直接接続で一時的に更新できた場合は、ルーティング設定に戻り、ドメインルール、ルールの順序、出口タグを確認してください。何度も切り替えて使い続けるのは避けます。

Androidでも確認の考え方は同じです。v2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。購読のダウンロードはクライアントが行い、ノード接続の段階で該当コアが処理します。購読の取得時点ですでに403やエラーページが返されている場合、Coreタイプを切り替えてもサーバーのレスポンスは変わりません。

クライアントが古い場合、すべての購読が失敗するとは限りません。新形式のノードが欠落したり、一部のクエリパラメータが無視されたり、インポート後に有効な設定を生成できなかったりします。購読提供元がフィールド名、通信方式の組み合わせ、出力構造を変更すると、旧バージョンの解析器が対応できないことがあります。アップデート後も元のグループを残し、同じURLを対象に再更新して、ノード数とログの変化で判断してください。

v2rayNの「設定」→「パラメータ設定」→「Core タイプ」は、特定のプロトコル設定をどの種類のコアで実行するかを決める項目です。ノードの起動や設定生成には影響しますが、すべての購読解析エラーを直す共通スイッチではありません。ログにレスポンス状態、ダウンロードのタイムアウト、Base64失敗が明確に出ている場合は、まず上流側の問題を処理してください。

Androidでは、v2rayNGとv2flyNGでコアの系統が異なる点に注意してください。どちらも一般的な共有リンクを読み込めますが、新しく追加されたフィールドへの対応時期は異なる場合があります。購読を移行する際は、一覧に含まれるプロトコルと通信パラメータを確認してから、適合するクライアントを選びます。URLを保存できるかどうかだけで互換性を判断しないでください。

一度の更新で「成功」と表示されただけでは、問題が完全に解決したとは限りません。グループの更新時刻、ノード数、ノードのフィールド、実際の接続を同時に確認します。元々24個のノードが更新後に3個しか残っていない場合、購読側で一覧が変更された可能性も、解析器が残り21個をスキップした可能性もあります。この場合は、成功通知よりログに記録された項目ごとの警告が重要です。

ネットワークを変更するとすぐ復旧し、元のネットワークでは失敗し続ける場合は、DNS、アクセス方針、出口ルートを重点的に確認します。URLを再生成して復旧した場合は、古いトークンまたはパスが無効になっています。クライアントのアップデート後だけ復旧した場合は新しいバージョンを維持し、他の購読グループにも旧解析器がスキップした項目がないか確認してください。