v2rayN、v2rayNG、v2flyNGでサブスクリプションをダウンロードできない、取得した内容を認識できない、更新後にノード一覧が空になるといった場合に役立つ確認手順です。まず現在使えるノードを残し、リンク、リクエスト経路、レスポンス本文、サブスクリプショングループを確認します。一度に変更する条件を一つに絞って比較すれば、ダウンロード・解析・表示のどの段階で問題が起きているかを切り分けられ、サブスクリプションの問題をノードの接続障害と誤認せずに済みます。
ダウンロード失敗・解析失敗・一覧が空の状態を切り分ける
サブスクリプションの更新は、ノードへの接続テストではありません。クライアントがサブスクリプションURLにリクエストを送り、返された内容を読み取り、ノード情報を認識してから、該当グループに登録します。どこか一つでも失敗すると画面上は「新しいノードがない」ように見えますが、対処法は原因によって異なります。
- ダウンロード失敗：ログにドメイン名の解決失敗、接続タイムアウト、証明書エラー、HTTPエラーが記録されます。この場合はリンクとネットワークを確認してください。VMessやVLESSのノード設定を先に変更する必要はありません。
- 解析失敗：クライアントは内容を受信できていますが、有効なノード情報として認識できていません。ログインページを受信した、形式が合わない、サブスクリプション本文が途中で切れているといった原因が考えられます。
- 一覧が空：サーバーが実際に空の内容を返している場合もあれば、検索条件、選択中のグループ、ノードのフィルターによって項目が表示されていない場合もあります。
- ノードはあるが接続できない：サブスクリプションの解析は少なくとも一部まで完了しています。ノード設定、システム時刻、サーバーの状態を確認してください。サブスクリプションの更新を繰り返す必要はありません。
手順1：コピーしたものがサブスクリプションURLか確認する
サブスクリプションURL、アカウント管理ページ、個別ノードの共有リンクはそれぞれ別のものです。サブスクリプションURLは通常 https:// で始まります。vmess:// や vless:// などはノードの共有リンクなので、クライアントの対応するインポート機能から読み込んでください。長い文字列をコピーできたからといって、サブスクリプションURLとは限りません。
-
元のURLをコピーする
サービス提供元のサブスクリプション画面からURLをコピーし直し、説明文や引用符、前後の空白が含まれていないことを確認してください。チャットに省略表示されたリンクはそのまま使えません。
-
クエリパラメーターを確認する
疑問符の後ろも含め、URL全体を確認します。サブスクリプションURLのアクセストークン、パラメーターの順序、署名は認証に使われている可能性があります。パラメーターを独自に削除したり、
&以降を切り落としたりしないでください。 -
有効な状態か確認する
アカウントページで、サブスクリプションの利用権限、有効期限、リンクが再発行されていないかを確認してください。リンクを再発行した場合は、新しいURLを元のグループに保存します。古いURLはすぐに無効になることがあります。
-
対象のグループだけ更新する
保存後、対象グループだけを更新して結果を記録してください。複数のサブスクリプションを同時に更新すると、ほかのグループのエラーが同じログに混ざり、原因を特定しにくくなります。
ブラウザーでURLを開けても、確認できるのはブラウザー経由で何らかのレスポンスを受け取れたことだけです。ブラウザーにはログインCookieが付いている場合や、クライアントとは異なるプロキシやDNSが使われている場合があります。そのため「ブラウザーで開ける」だけでは、クライアントが解析可能なサブスクリプション本文を取得できる証拠にはなりません。
手順2：プロキシ経由と直接接続のダウンロードを比較する
「サブスクリプションの更新時にプロキシを使うか」と「ノードにどのルーティングルールを適用するか」は別の設定です。サブスクリプションはクライアント内のHTTPリクエスト機能でダウンロードされる場合があり、プロキシコアのDNS、ルーティング、ルール分岐がそのまま適用されるとは限りません。コアのルーティングモードを切り替えるだけでは、サブスクリプションのリクエスト経路が変わらないことがあります。
Windows版v2rayN 6.xの一般的な画面では、「サブスクリプショングループ」メニューから「すべてのサブスクリプションを更新（プロキシを経由しない）」または「すべてのサブスクリプションを更新（プロキシを経由する）」を選び、結果を比較できます。ほかのバージョンでは、括弧の表記やメニュー名、グループ操作の場所が異なる場合があります。実際のメニューを確認してください。特定バージョンの更新方法がすべてのバージョンで標準とは限りません。
- まずプロキシを経由せずに試す：使用可能なノードがない場合や、ローカルプロキシが起動していない可能性がある場合に適しています。失敗したらエラーを記録し、すぐにグループを削除しないでください。
- 次にプロキシ経由で試す：選択中のノードで一般的なWebページにアクセスできることを確認してから、もう一度更新します。選択中のノード自体が使えない場合、そのノードを使って新しいサブスクリプションをダウンロードすることはできません。
- ローカルの待ち受けを確認する：ログに
127.0.0.1への接続拒否が表示される場合は、クライアントが実際に待ち受けているアドレスとポートを確認してください。10808、10809はトラブル対処中に見かけることのあるポート例にすぎません。すべてのバージョンがこの2つのポートを使う、またはHTTPとSOCKSを個別に待ち受けるとは限りません。 - ネットワークを一度切り替える：可能であれば、現在のネットワークと別の信頼できるネットワークで結果を比較してください。一方のネットワークだけで失敗する場合は、そのネットワークのDNS、アクセス制限、認証用ポータルを優先して確認します。
Androidでは、まずv2rayNGまたはv2flyNGの「サブスクリプショングループ設定」で保存済みURLを確認し、メニューから「サブスクリプションを更新」を実行します。メニュー名はバージョンによって異なる場合があります。使用中のバージョンにプロキシ経由で更新する設定があれば、同じように比較してください。その設定がない場合は、デスクトップ版のメニュー手順をAndroidに当てはめないでください。一度のテストで変更するのは、更新経路かネットワークのどちらか一つにします。
ステータスコードから認証・リダイレクト・ブロックを切り分ける
ログにHTTPステータスコードがある場合は、まずコードを確認し、次に本文を確認します。以下の数値はHTTPのステータスであり、速度測定の結果やクライアントのバージョン番号ではありません。200 が返っていても、本文がエラー説明やWebページであることがあります。
以下はHTTPステータス行と、リクエスト機能で表示されることのある実際のエラーメッセージです。クライアント、実行環境、画面の言語によって別の説明が付く場合もあります。文言だけで判断せず、どの段階でエラーが発生したかも確認してください。
HTTP 401 Unauthorized
原因と対処：有効な認証情報がリクエストに含まれていないか、トークンの有効期限が切れています。アカウントのサブスクリプション画面からURLをコピーし直し、そのインターフェースがログイン後のWebセッションでしか使えないものではないか確認してください。
HTTP 403 Forbidden
原因と対処：サーバーが現在のリクエストを拒否しています。権限、アクセス制限、保護ルールなどが関係している可能性があります。アカウントの状態を確認し、発生時刻、ステータスコード、アクセス方法をサービス提供元に伝えてください。403だけを根拠にアカウントの期限切れと決めつけないでください。
HTTP 407 Proxy Authentication Required
原因と対処：リクエスト経由のプロキシで認証を求められています。サブスクリプションサービス側の問題とは限りません。システムまたはネットワークプロキシの認証設定を確認するか、プロキシを経由しない更新方法と比較してください。
The operation has timed out.
原因と対処：リクエストが所定の時間内に完了しませんでした。名前解決、接続、読み込みのいずれかで停止している可能性があります。まずネットワークとダウンロード経路を比較し、前後のログも確認してください。タイムアウト時間を延ばすだけでは、無効なURLは直りません。
301 または 302 が返る場合は、最終レスポンスがログインページではないことを確認してください。429 の場合は更新を繰り返さず、サーバーの Retry-After の指示に従って待ちます。復旧を確認するために何度も更新ボタンを押すと、レート制限が長引くことがあります。
手順3：本文の形式と文字コードを確認する
サブスクリプションのダウンロードに成功しても解析エラーになる場合は、「実際に何を受信したか」を確認します。レスポンス内容を調べるのは、自分の端末など管理された環境に限り、ノード設定全体を外部ツールに貼り付けないでください。ノード情報にもアクセス用の認証情報が含まれる場合があるため、サブスクリプションURLと同様に扱う必要があります。
| レスポンスの特徴 | 考えられる内容 | 次の確認事項 |
|---|---|---|
<!DOCTYPE html> または <html で始まる |
ログインページ、エラーページ、ネットワーク認証ページ | サブスクリプションの元のページからURLを取得し直し、最終的なリダイレクト先とアクセス権限を確認する |
複数行の vmess://、vless:// などの共有リンク |
一般的なノード一覧の形式 | 使用中のクライアントバージョンが各リンク形式とそのパラメーターに対応しているか確認する |
| Base64形式のテキストが1つだけ | エンコードされたノード一覧の可能性 | レスポンスが完全か確認し、まずクライアントで解析する。必要な場合に限り、端末上でデコードして調べる |
| JSONまたはYAML形式のテキスト | 完全な設定ファイル、APIのエラーオブジェクト、または別の形式の可能性 | 拡張子だけで判断せず、現在のサブスクリプション取り込み機能で使える形式か確認する |
| 本文が空、または案内文だけ | 利用できる項目がない、またはサーバーがサービス上のエラーを返している | アカウントの権限、ノードの絞り込み条件、サーバー側の案内を確認する |
Base64をデコードできても、ノードをインポートできるとは限らない
Base64はエンコード方式であり、サブスクリプションプロトコルではありません。デコードできても、テキストが何らかのエンコード規則に従っているとわかるだけで、中のリンクが有効とは限りません。一般的なVMessの共有形式は、vmess:// に続けてJSONをBase64エンコードします。一方、VLESSの共有リンクでは識別情報、アドレス、通信パラメーターなどをURIに記述するため、同じ項目として扱うことはできません。
- 何度も全体をデコードしない：VLESSリンクのパーセントエンコードは、パス、備考、クエリパラメーターに使われる場合があります。全体をデコードして再構成すると、
&や#などの区切り文字の意味が変わり、リンクが壊れることがあります。 - 途中で切れていないか、書き換わっていないか確認する：コピー時の改行、全角の句読点、文字の欠落、
+が誤って空白に変換されることなどは、解析に影響します。不確かな本文を手作業で補うのではなく、まず元のURLからコピーし直してください。 - インポート方法を使い分ける：プロキシコアが特定の設定形式を読み込めても、クライアントのサブスクリプション機能がそれをノードに変換できるとは限りません。完全なJSON設定、個別ノードの共有リンク、サブスクリプション一覧は、それぞれ対応する機能から読み込んでください。
- 対応パラメーターを確認する：古いクライアントでは、一部の通信方式やセキュリティ関連パラメーターを認識できない場合があります。まず現在のバージョンを記録し、ダウンロードページで利用可能なクライアントを確認してください。インポートするためにTLS、SNIなどのセキュリティ設定を削除しないでください。
手順4：グループ、フィルター、保存結果を確認する
ログにダウンロード完了とノードの認識が記録されている場合は、ネットワークを変更し続けるのではなく、一覧の表示を確認します。v2rayNでは「サブスクリプショングループ」→「サブスクリプショングループ設定」を開き、選択中のグループのURLを確認します。v2rayNGとv2flyNGでは「サブスクリプショングループ設定」で該当項目を確認してください。保存ボタン、フィルター、更新操作はバージョンによって異なります。3つのクライアントで機能が完全に同じとは限りません。
- 検索を解除する：ノード検索欄を空にし、対象のサブスクリプショングループまたはすべてのノードを表示して、名前による絞り込みで一覧が空になっていないか確認します。
- フィルターを確認する：現在のバージョンにサブスクリプションの正規表現フィルターや、含める・除外する条件がある場合は、元の値を記録してから一時的にフィルターを解除し、更新を一度試してください。
- 保存を確認する：URLを変更した後、変更が保存されていることを確認します。編集欄に貼り付けただけで確定していない場合、更新時に古いURLが使われることがあります。
- 切り分けてテストする：必要に応じてテスト用グループを新しく作り、このサブスクリプションだけを登録して個別に更新します。まだ使えるノードを上書きしないよう、元のグループは残してください。
- 実際に操作しているプログラムを確認する：デスクトップにv2rayNが複数ある場合、どのプログラムと設定フォルダーを操作しているか確認してください。一方を変更して別の方を起動している可能性があります。
「システムプロキシを有効にする」「グローバルルーティング」「サブスクリプション更新時にプロキシを使用する」は、それぞれ別の設定です。最初の設定はシステムプロキシに従うアプリに影響し、2つ目はプロキシコアが受け取った接続の送信先選択に影響します。最後の設定が、サブスクリプションのダウンロード方法に直接関係します。トラブル対処では変更した設定を具体的に記録し、複数の項目をまとめて「プロキシをオンにした」と表現しないでください。
再テストのチェックリストと問い合わせ時の情報
変更後は対象グループだけを一度更新します。復旧したかどうかは、更新ログ、ノード一覧、実際の接続結果を合わせて確認してください。エラーがなくても有効なノードがあるとは限らず、ノードが表示されてもすべてのサーバーに接続できるとは限りません。サブスクリプションが復旧した後も特定のノードがタイムアウトする場合は、別の接続問題として対処してください。
- アカウントページや個別ノードのリンクではなく、完全なサブスクリプションURLを保存したことを確認した。
- アカウントの権限、URLの再発行状況、編集後に保存したかを確認した。
- 直接接続と、使用可能なプロキシ経由で更新した結果をそれぞれ記録した。または、使用中のバージョンに該当する設定がないことを記録した。
- 「使えない」とだけ書かず、HTTPステータス、エラーメッセージの全文、失敗した段階を記録した。
- 受信した本文がHTMLのログインページではなく、現在のインポート機能に適した形式であることを確認した。
- 検索、グループ選択、サブスクリプションのフィルターによって一覧が空になっていないことを確認した。
- 元の設定をバックアップし、再テスト時にDNS、プロキシ、ルーティング、サブスクリプション形式を同時に変更していない。
基本的なインポート手順はクイックスタートを参照してください。ローカルの待ち受け、システムプロキシ、ルーティングの問題をさらに切り分けたい場合は、トラブルシューティングガイドをご覧ください。まず問題がどの段階で起きているかを特定し、その段階に関係する設定だけを変更するほうが、サブスクリプションを何度も削除して作り直すより、状況や検証結果を保ちやすくなります。