v2rayNのサブスクリプション更新に失敗する・ノードが表示されない原因と確認方法

アドレスの期限切れ、ネットワーク接続、形式の非対応、「プロキシ経由で更新」の設定など、更新失敗やノードが表示されない原因を順番に確認します。

この記事の要点

まず既存のノードを残し、問題を「アドレスへのリクエスト失敗」「内容を解析できない」「インポート後のノードが使えない」の3つに分けます。v2rayNの更新がタイムアウトする、サブスクリプションの一覧が空になる、更新方法を変えても失敗する場合に役立ちます。アドレス、ネットワーク、応答内容、インポート結果の順に確認すれば、再インストールや設定の誤削除を避けられます。

まず失敗した段階を確認:ダウンロードできないのか、解析できないのか

v2rayNのメイン画面でログまたは情報欄を開き、問題のサブスクリプショングループをもう一度更新して、発生時刻とエラー全文を記録します。すべてのサーバーを先に削除しないでください。既存ノードがまだ使える可能性があるほか、「プロキシ経由で更新」を試す際の接続経路としても必要です。

サブスクリプションURL ネットワークリクエスト 応答本文 形式の解析 ノードの登録

この5つの段階で、原因は異なります。ドメイン名を解決できない、接続がタイムアウトするといった問題はリクエスト段階です。内容を受信できても形式エラーになる場合は解析段階です。ノードが表示されているのに接続できない場合は、ノードの設定、コア、ルーティングを確認してください。サブスクリプションのダウンロード失敗として扱い続ける必要はありません。

手順1:サブスクリプションURL、有効期限、グループを確認

提供元のサブスクリプション管理ページから、完全なURLをコピーし直します。サブスクリプションは通常、認証情報を含むHTTPSのURLです。一方、vmess://やvless://は通常、個別ノードの共有リンクなので、クリップボードからインポートします。共有リンクをサブスクリプションURLとしてリクエストすると、URL形式エラーになる場合があります。

  1. 既存の設定を保存

    まずクライアントのバックアップまたはエクスポート機能で設定を保存します。ノードだけをエクスポートしても、サブスクリプショングループやルーティング設定は含まれないことがあります。バックアップ後、保存対象を確認してください。

  2. グループを開く

    メイン画面で「サブスクリプショングループ」→「サブスクリプショングループ設定」を開き、問題のグループを編集してURLを確認します。画面のバージョンによっては、編集ボタンを使うか、グループをダブルクリックして詳細を開きます。

  3. URLを貼り直す

    完全なURLをコピーし直し、先頭や末尾の空白、改行、クエリパラメーターの欠落がないか確認します。疑問符以降のトークンを手動で削除したり、Webページで省略表示されたURLを完全なリンクとして使ったりしないでください。

  4. 個別に更新

    まずはこのグループだけを更新します。現在の画面で全件更新しかできない場合は、ログから対象グループ名を探します。他のグループの成功表示を、対象グループが復旧した証拠と取り違えないようにしてください。

サブスクリプションURLの無効化とノードの期限切れは別の問題です。提供元がサブスクリプショントークンをリセットすると、古いノードが一時的に接続できても、旧URLはすぐに無効になることがあります。プランの期限切れや通信量の上限到達でも、リクエスト拒否、空の応答、案内ページが返される場合があります。具体的な応答は提供元によって異なります。

手順2:直接更新とプロキシ経由の更新を使い分ける

一般的なv2rayNの画面では、「サブスクリプショングループ」メニューから「すべてのサブスクリプションを更新(プロキシを使用しない)」または「すべてのサブスクリプションを更新(プロキシを使用)」を選べます。バージョンによっては、スイッチや類似の名称で表示されます。この設定はクライアントがサブスクリプションを取得する経路を切り替えるものです。サブスクリプション内の各ノードが、現在のノードを経由して接続するという意味ではありません。

現在の状況まず試す操作確認する結果
現在のネットワークからサブスクリプションのドメインに直接アクセスできるプロキシを使わずに更新Webページが開くかだけでなく、返された内容も確認
直接接続はタイムアウトするが、使えるノードがある使えるノードを起動してからプロキシ経由で更新ローカルプロキシの待ち受け設定とリクエストログを確認
既存のノードがすべて使えないまず直接接続、または信頼できる別のネットワークで試す同じ使えないノードに依存して更新するのを避ける
プロキシ経由では403、直接接続では正常一時的に直接接続を使い、提供元の制限を確認接続元IPアドレスやアクセス地域の制限を確認

ブラウザーでサブスクリプションを開けても、クライアントから直接接続できるとは限りません。ブラウザーがシステムプロキシを使っている場合や、提供元にログインした状態が残っている場合があります。クライアントのリクエストでは、同じプロキシ、Cookie、リクエストヘッダーが使われるとは限りません。結果を比較する前に、実際の通信経路が同じか確認してください。

プロキシ経由で更新する場合は、まずプロキシのコアが起動していることを確認します。「設定」→「パラメーター設定」でローカルの待ち受けポートを確認してください。項目名はバージョンによって変わるため、現在の設定に表示されている値を使います。たとえば、HTTPまたは混合プロキシが127.0.0.1:10808で待ち受けている場合、更新リクエストからそのポートに接続できる必要があります。実際のポートが異なる場合は設定値を使い、例をそのままコピーしないでください。

手順3:エラーの内容からネットワーク障害を絞り込む

以下はネットワークリクエストでよく見られる英語のエラーメッセージです。実際の文言はOS、実行環境、v2rayNのバージョンによって異なります。原因を特定するのではなく、失敗した段階を見分けるための手掛かりとして使ってください。同じタイムアウトでも、接続先から応答がない、ローカルのファイアウォールが遮断している、プロキシ経路に問題があるなど、複数の原因が考えられます。

エラー:No such host is known

原因:サブスクリプションのドメイン名を解決できていません。URLの入力ミス、ドメインの無効化、現在のDNS名前解決の異常などが考えられます。

対処:ドメイン名全体を確認し、信頼できる別のネットワークでも名前解決を試します。プロキシ経由で更新する場合は、プロキシ側の名前解決経路も確認してください。

エラー:Connection refused

原因:接続先から拒否されています。プロキシ経由で更新している場合は、ローカルのプロキシポートで待ち受けていない可能性もあります。

対処:エラーに記載されたホスト名とポートを確認します。接続先がローカルの場合は、コアが起動しているか、待ち受けポートが設定と一致しているかを確認してください。

エラー:The operation has timed out

原因:制限時間内にリクエストが完了しませんでした。このエラーだけでは、サブスクリプションの期限切れとは判断できません。

対処:直接接続と利用可能なプロキシをそれぞれ試し、提供元の稼働状況を確認します。同じURLを信頼できる別のネットワークでも再テストしてください。

エラー:The SSL connection could not be established

原因:TLSハンドシェイクまたは証明書の検証に失敗しています。システム時刻のずれ、証明書チェーンの異常、ネットワークによる遮断などがよくある原因です。

対処:システムの日付、時刻、タイムゾーンを合わせ、ドメイン名と証明書エラーの詳細を確認します。証明書検証を無効にして問題を隠さないでください。

エラーの原因がローカルの待ち受けポートにある場合、DNSを変更しても起動していないコアは直りません。提供元から認証エラーが返されている場合も、タイムアウト時間を延ばして権限が戻るわけではありません。まずエラーがどの段階で起きているかを確認し、該当する設定だけを変更してください。

手順4:HTTPリクエストの成功とサブスクリプション内容の正しさは別

ステータスコードはサーバーがリクエストをどう処理したかを示すもので、本文がv2rayNで解析できるとは限りません。特にHTTP 200の場合、ノード一覧だけでなく、ログインページ、認証ページ、期限切れの案内、空の文字列が返ることもあります。ブラウザーに文字が表示されたとしても、応答を受け取れたことが分かるだけで、サブスクリプションが有効だとは確認できません。

200
リクエスト成功後も本文の形式を確認
403
リクエスト拒否。権限とアクセス方針を確認
429
リクエストが制限されています。更新の連続実行を停止

応答を確認する場合は、必ずローカル環境内で行います。本文が<!DOCTYPE html>または<htmlで始まる場合、ノード一覧ではなくWebページが返されている可能性があります。ログイン案内や人間確認の説明だけが含まれている場合は、ページ全体をインポート機能に渡さず、提供元から正しいサブスクリプションURLを取得してください。

手順5:Base64、プロトコル形式、解析結果が空になる問題を確認

一般的なサブスクリプションでは、複数行の共有リンクを返すか、それらのリンク全体をBase64でエンコードしています。Base64は暗号化ではなく、エンコード方式です。デコードした内容にノードのパスワード、識別情報、アドレスがそのまま含まれることがあります。解析エラーを解決するために、完全なサブスクリプションを不明な変換サービスにアップロードしないでください。

確認できた内容考えられる問題対処方法
複数行のvmess://またはvless://リンク一部のリンクが破損している、またはパラメーターに互換性がない完全なリンクを1つ選んでローカルでインポートし、全体の失敗か個別の失敗かを切り分ける
長いエンコード文字列Base64形式のサブスクリプション、または途中で切れた内容の可能性元のURLをコピーし直し、クライアントから応答全体を取得
YAML設定または別形式のJSON設定別形式向けのサブスクリプションURLを選んでいる可能性提供元でv2rayNに対応したURLを選ぶ。拡張子の変更だけで形式を変換しない
本文が空、または空白文字のみ提供元からノードが返されていない、またはアクセス状態に問題があるプラン、ノードの割り当て、アカウントの状態を確認し、提供元に問い合わせる
Webページのタグ、認証画面、ログイン案内サブスクリプションが別ページへリダイレクトされた、またはアクセスを遮断された最終的なURLとアクセス方針を確認し、正しいサブスクリプションURLを取得

リンクを1つずつクリップボードからインポートできても、サブスクリプション全体の解析結果が空になる場合は、返された内容が完全か、案内文が混在していないか、提供元で選択したエクスポート形式が適切かを確認します。特定のバージョンで一部の形式を認識できても、すべてのバージョンや配布画面で同じ方法が使えるとは限りません。

新しいプロトコルパラメーターだけを認識できない場合は、設定をバックアップしてからv2rayNの更新を検討します。クライアントはサブスクリプションの取得、リンクの解析、設定の生成を行い、コアは実際のプロキシ接続を担います。Xrayコアを更新しても、クライアントのサブスクリプション解析機能が直るとは限りません。一方、インポート済みのノードを起動した際に設定の互換性エラーが出る場合は、使用中のコアとパラメーターの対応状況を確認してください。

最後に確認:更新後のグループとノードをチェック

成功の表示が出たら、対象グループのノード数を確認し、検索語、グループの絞り込み、表示条件で一覧が隠れていないかを確認します。ノード数が提供元の想定と異なる場合は、提供元が利用可能な回線を減らしていないか、ログに一部の項目の解析失敗が記録されていないかを確認してください。

  1. 対象グループを確認:検索条件をクリアして更新したグループを選択し、新規ノードと既存ノードが想定どおりに変化しているか確認します。
  2. ノードを1つテスト:ノードを選択して接続を開始し、クライアントの接続テスト、または実際のアクセスで確認します。TCPポートに接続できるだけでは、プロキシ認証や通信方式が正常とは限りません。
  3. 影響範囲を確認:すべてのノードで失敗する場合は、コアの起動ログ、システム時刻、ローカルプロキシを優先して確認します。一部のノードだけ失敗する場合は、該当する回線の状態を確認してください。
  4. 成功した方法を記録:今回成功した更新方法を保存しておけば、次回のトラブル時に比較できます。毎回すべての設定をリセットする必要はありません。

復旧しない場合は、再現に必要な情報を提供元に送ります。v2rayNの完全なバージョン番号、OS、発生時刻とタイムゾーン、直接接続とプロキシ経由それぞれの結果、HTTPステータスコード、機密情報を伏せたログを伝えてください。URLはドメイン名と必要なパス情報だけを残し、トークン、ノードの認証情報、アカウント情報を削除します。「サブスクリプションが使えない」とだけ伝えるより、具体的なリクエスト記録のほうが原因を特定しやすくなります。

V2Rayクライアントをダウンロード