「更新に失敗しました」「利用可能なサーバーがありません」と表示される場合や、更新後にグループが空になるv2rayNユーザー向けです。既存の設定を残したうえで、リンク、接続経路、応答内容、解析結果の順に確認します。最後にグループを1つだけ更新して復旧を確認し、プロキシやサブスクリプション、コアを同時に変更して原因が分からなくなるのを防ぎましょう。
まず確認：リクエスト失敗か、解析結果が空か
サブスクリプションの更新は、ノードへの接続テストではありません。クライアントはまずサブスクリプションURLにリクエストを送り、テキストを取得してから、サーバー項目として解析しグループに登録します。URLにアクセスできても、記載されたノードが使えるとは限りません。ノードに接続できても、サブスクリプションが有効とは限りません。ダウンロードの問題をプロトコルの問題と取り違えないよう、最初にどの段階で失敗したかを特定しましょう。
- 接続タイムアウト・名前解決エラー：応答を正常に取得できていません。まずネットワーク、DNS、更新時の接続経路を確認してください。
- HTTPエラーが表示される：サーバーから応答は返っています。認証情報、URLの有効期限、サーバー側の制限を確認してください。
- リクエストは完了したが、追加された項目がない：応答内容、サブスクリプション形式、グループのフィルターを確認しましょう。すぐにコアを切り替える必要はありません。
まずメイン画面のログまたは情報出力欄を開き、更新時刻、エラーの原文、対象グループを記録してください。デスクトップ版によってパネルの位置やメニュー名が多少異なる場合があります。以下では中国語UIで一般的な項目名を使っています。「サブスクリプショングループ設定」「プロキシ経由で更新」に相当する機能を探してください。
第1段階：設定を残してサブスクリプションURLを確認
グループ全体をすぐに削除しないでください。更新に失敗しても既存項目が残る場合がある一方、置き換え操作によってリストが空になることもあります。既存の利用可能なノードは、プロキシ経由で更新する際にも必要です。バックアップファイルやエクスポートした共有リンクには接続情報が含まれます。信頼できるローカル環境だけに保存してください。
-
既存の設定を残す
メイン画面でまだ使えるサーバーを選び、右クリックメニューから共有リンクをエクスポートしてコピーを保存します。設定フォルダー全体をバックアップする場合は、クライアントを終了してから、現在のインスタンスが実際に使用しているデータフォルダーをコピーしてください。プログラムファイルだけでは不十分です。
-
グループを確認する
「サブスクリプショングループ」→「サブスクリプショングループ設定」を開き、問題のあるグループを選択します。URLが現在のアカウントに対応しているか、更新が有効になっているかを確認してください。似た名前のグループが複数ある場合は、備考とURLを照合し、別のグループを更新しないよう注意しましょう。
-
URLをコピーし直す
サービス提供元のサブスクリプションページから、v2rayN用のURLをコピーし直して、古いURLと置き換えます。先頭が
https://か、空白や改行、全角引用符が混入していないか、クエリパラメーターがすべて残っているかを確認してください。 -
グループを1つだけ更新して再確認
保存後、対象のグループだけを更新し、ログと項目数を記録します。すべてのグループを作り直したり、ノードをまとめて変更したりすると、どの操作で状態が変わったのか判断しにくくなります。
第2段階：直接接続とプロキシ経由の更新を切り分ける
ブラウザーでサブスクリプションURLを開けても、確認できるのはブラウザーが使った通信経路です。ブラウザーはシステムプロキシを使う一方、クライアントの「プロキシを使わずに更新」は別の経路を使う場合があります。システムプロキシのオン・オフを切り替えただけでは、サブスクリプションの取得経路が変わるとは限りません。サブスクリプションのメニューから、対応する更新方法を選んでください。
- まず直接接続を試す：「サブスクリプショングループ」から、名前に「プロキシを使わずに更新」とある項目を選びます。直接接続でノードを取得できたら、その方法を使い続けてかまいません。サブスクリプション取得のためにルーティングを変更する必要はありません。
- 直接接続に失敗したらプロキシ経由を試す：利用可能と確認済みの既存ノードを選択してアクティブサーバーに設定し、コアが正常に起動したことを確認してから、名前に「プロキシ経由で更新」とある項目を選びます。
- プロキシ経由でも失敗する：アクティブなノードを使って、利用可能と確認済みのHTTPSページにアクセスしてみてください。通常のアクセスも失敗する場合は、更新を繰り返すのではなく、まずノードの接続を修復します。
- 使える既存ノードがない：信頼できる別のネットワークからサブスクリプションを取得するか、サービス提供元に一時利用できる単一ノードの共有リンクを発行してもらいます。リストが空の状態では、プロキシ経由の更新に必要な接続を確立できません。
プロキシ経由で更新する場合は、「設定」→「パラメーター設定」でローカルのリスナー設定を確認し、実際に使用中のポートを基準にしてください。ポートの競合、コアの未起動、クライアントが古いリスナーアドレスを参照していることなどが、ローカル接続の拒否につながります。他のPCのポート番号をそのまま使わないでください。また、このPCでの更新を直すために、リスナーアドレスをすべてのネットワークインターフェースに公開しないでください。
第3段階：ステータスコードとエラーの原文を確認
「失敗」という表示だけより、ステータスコードのほうが具体的な手掛かりになります。次の数値はHTTPのステータスを表すもので、テストの成功率ではありません。200はリクエストが正常に応答したことを示すだけなので、本文が本当にサブスクリプションかどうかも確認してください。
The operation has timed out.
原因と対処：制限時間内にリクエストが完了していません。直接接続が遮断されているか、プロキシが使えない可能性があります。同じURLのまま直接接続と利用可能なプロキシ経由の両方を試し、ログを比較してください。
Connection refused
原因と対処：接続先が接続を受け付けていません。エラーに表示された接続先がローカルのプロキシポートか、サブスクリプションサーバーかを確認します。ローカルアドレスならコアのプロセスとリスナーポートを、遠隔サーバーならサービスの稼働状況を確認してください。
Response status code does not indicate success: 403 (Forbidden).
原因と対処：サーバーがリクエストを拒否しています。token、アカウントの状態、アクセス元の制限、認証ページなどが原因として考えられます。サブスクリプションURLを取得し直し、提供元に制限を確認してください。このログだけでアカウントの期限切れと判断しないでください。
エラーメッセージはOSの言語設定やクライアントのバージョンによって変わることがあります。ステータスコードと接続先をあわせて判断してください。404ならパスが無効になっていないか確認します。429なら連続更新を止め、サーバーの再試行指示に従ってください。5xxなら時刻を記録してサービス提供元に問い合わせます。証明書エラーの場合は、システムの日付と時刻、証明書の信頼チェーンを確認してください。証明書検証を無効にして恒久的に回避するのは避けましょう。
第4段階：応答形式とBase64の内容を確認
「取得は成功したのに解析結果が空」になるよくある原因は、サーバーからログインページ、アカウント期限切れの案内、認証ページが返されていることです。こうしたページでもステータスコードが200になる場合があります。応答の原文を確認する場合は、信頼できるツールをローカルで使ってください。ブラウザー上の見た目とクライアントが受け取った本文は同じとは限りません。最終的にはクライアントのリクエスト結果を基準に判断してください。
| 応答の特徴 | 考えられる原因 | 次に行うこと |
|---|---|---|
<!DOCTYPE html>または<htmlで始まる | ログインページ、リダイレクト先、認証ページ | クライアント専用のサブスクリプションURLをコピーし直し、サーバー側のアクセス制限を確認する |
| 本文が空、またはアカウントに関する案内だけが表示される | APIから返せるノードがない、またはアカウントの状態が条件を満たしていない | プランの有効期限、残りの通信量、ノードの割り当て状況を確認する |
複数行のvmess://、vless://などのリンク | 一般的な共有リンクの一覧 | リンクを1つローカルで選び、インポートを試します。単一リンクの問題か、一括解析の問題かを切り分けてください。 |
| 長いエンコード済みテキスト | リスト全体がBase64でエンコードされている可能性がある | ローカルで一度デコードし、結果がウェブページや案内文ではなくノードリンクか確認する |
proxies:などのフィールドで構成されたYAMLテキスト | 別の設定形式であり、汎用の共有リンク一覧ではない | 提供元のページで、v2rayN用と明記されたサブスクリプション形式を選択する |
Base64はエンコード方式であり、ノードのプロトコルでも暗号化でもありません。一般的なサブスクリプションでは、複数の共有リンクをまとめたテキスト全体をエンコードします。また、VMessの共有リンク自体にも、エンコードされたノード設定が含まれている場合があります。そのため、外側のデータをデコードした結果がvmess://リンクでも正常です。すべての内容を何度もデコードして、サブスクリプション設定に貼り直す必要はありません。
- URLの欠落を確認：チャットアプリでの折り返し、コピー漏れ、URL内の
&の誤処理によって、実際のリクエスト先が変わることがあります。配布元のページから直接コピーし直してください。 - 文字の違いを確認：標準Base64とURLセーフな形式では使われる文字が異なり、末尾のパディングが省略されることもあります。デコードに失敗した場合は、まず配布元を確認してください。
+や/をむやみに削除したり、適当な文字を補ったりしないでください。 - 対応形式を確認：クライアントが対応するサブスクリプション形式はバージョンによって異なります。任意のYAMLやコアの完全なJSON設定を、汎用サブスクリプションとしてインポートできるとは限りません。
第5段階：解析失敗とリストの表示問題を切り分ける
ログにノードの取得・処理が完了したと表示されているのに、メイン画面が空白の場合は、まず現在のグループと検索条件を確認します。検索キーワード、グループの切り替え、サブスクリプション設定のフィルターによって、登録済みの項目が一時的に見えなくなることがあります。この場合、更新を繰り返しても解決しません。
- メイン画面の検索欄を空にし、更新したグループに切り替えてから、すべてのサーバーが表示対象になっているか確認してください。
- 「サブスクリプショングループ」→「サブスクリプショングループ設定」に戻り、対象グループにフィルターが設定されていないか確認します。元の設定を記録してから一時的に解除し、グループを1つだけ更新してください。
- 一部のリンクだけインポートできない場合は、リンクのプロトコル、トランスポート設定、必須項目を確認してください。サブスクリプション全体が無効だと決めつける必要はありません。
- 形式に問題がなく、古いクライアントで認識されない場合は、バックアップを取ってからv2rayNを更新し、同じ内容を使って再確認します。サブスクリプションの配布元とクライアントのバージョンを同時に変更しないでください。
復旧の確認と問い合わせ時の情報整理
復旧は2つに分けて確認します。サブスクリプションが安定して更新できること、そしてインポートしたノードのうち少なくとも1つで想定どおり接続できることです。まず対象グループに妥当な数の項目が表示されるか確認してから、ノードを1つ選んで接続をテストします。すべてのノードが使えない場合は、サーバーアドレス、ポート、プロトコル、トランスポート設定を調べてください。サブスクリプションURLを変更し続けても解決しません。
- 環境を記録：クライアントのバージョン、OS、失敗した時刻、対象グループ、直接接続かプロキシ経由かを記録します。
- 結果を記録：HTTPステータスコード、エラーの原文、応答の種類、更新前後の項目数、既存ノードが引き続き使えるかを記録します。
- 認証情報を隠す：token、サブスクリプションURL全体、ノードのパスワード、ユーザー識別情報を伏せます。問題の判断に必要なドメイン名とエラーの前後関係だけを残してください。
- 問い合わせ先を切り分ける：認証、空の応答、APIの制限についてはサブスクリプション提供元に問い合わせます。正しい形式の内容を現在のクライアントで解析できない場合は、必要最小限の情報に絞り、機密情報を除いた再現手順をまとめてください。
作業中は「一度に変更するのは1項目だけ」を基本にしましょう。まずURL、次に接続経路、その後に応答内容を確認し、最後にクライアントの互換性を調べます。すぐに復旧しなくても、漠然とした「サブスクリプションの失敗」を検証可能な段階まで絞り込み、無駄な操作を減らせます。