このチェックリストは、v2rayN、v2rayNG、v2flyNGで発生するサブスクリプションのダウンロード失敗、更新後にノードが空になる問題、解析エラー、古いノードが置き換わらない問題に対応します。リンクとHTTPレスポンスを確認してから、直接接続またはプロキシ経由の更新に切り替え、レスポンス本文、Base64エンコード、共有リンク形式を確認します。最後にグループのキャッシュを整理し、コアの接続を検証します。
まず失敗した段階を確認する
サブスクリプションの更新は、単一の操作ではありません。クライアントはサブスクリプションURLの読み取り、ドメインの名前解決、TCPとTLS接続の確立、HTTPレスポンスの取得、本文形式の判定、共有リンクの分割を行い、最後にノードをサブスクリプショングループへ書き込みます。画面に表示される「更新失敗」は、この一連の処理が完了しなかったことを示すだけで、ノードサーバー自体が利用できないと直接証明するものではありません。
確認時は、クライアントがレスポンス本文を取得できたか、本文からノードを生成できたかの2点を先に見ます。レスポンスがまったくない場合は、ドメインの名前解決、ネットワーク経路、証明書、HTTPステータスが原因である可能性が高いです。内容をダウンロードできたのにノード数が0の場合は、エンコード、形式、または現在のクライアントが認識できないプロトコル項目を疑います。
HTTP 200は、サーバーが内容を返したことを示すだけで、有効なサブスクリプションであることまでは保証しません。ログインページ、エラー説明、期限切れの通知も200ステータスで返る場合があります。一方、301や302も必ずしも障害ではありません。ただし、リダイレクトが連続したり、別ドメインへ転送されたり、転送先で追加認証が必要になったりすると、クライアントが更新を中止することがあります。
決められた順序でサブスクリプションリンクと更新方法を確認する
サブスクリプションリンクには、アカウントや契約状態を識別する長いパラメータが含まれることがあります。コピー時に1文字欠ける、末尾の句読点まで含める、チャットツールで改行されるといったミスで、サーバーはエラー内容を返します。元の管理ページから完全なURLをコピーし直し、見た目が似ているという理由で手入力しないでください。
完全なリンクを確認する
クライアントのサブスクリプショングループ設定にURLを貼り直し、先頭が
https://またはサービスが明示的に提供するhttp://であることを確認します。途中にスペースや改行がなく、末尾に日本語の句点や読点がないことも確認してください。まず直接接続で更新する
v2rayNで「サブスクリプショングループ」→「すべてのサブスクリプションを更新（プロキシを使用しない）」を開きます。現在のネットワークからサブスクリプションのドメインへ直接アクセスできる場合、直接接続により、失効したノードや誤ったシステムプロキシによる循環依存を切り分けられます。
次にプロキシ経由で更新する
直接接続がタイムアウトする場合は、接続できることを確認済みの古いノードを選択してから、「サブスクリプショングループ」→「すべてのサブスクリプションを更新」を実行します。プロキシ経由の更新には、現在稼働しているコアが必要です。まだダウンロードできていない新しいノードを、この処理に使うことはできません。
グループの有効状態を確認する
「サブスクリプショングループ」→「サブスクリプショングループの設定」を開き、対象グループが有効になっていることを確認します。また、URLをメモ、別名、自動更新間隔の欄に誤って入力していないか確認してください。
グループを個別に更新する
複数のサブスクリプションがある場合は、まず対象グループだけを更新します。1本のリンクだけの異常か、すべてのリクエストが失敗しているのかを切り分けやすくなり、同名ノードによって結果が分かりにくくなることも防げます。
ノードの変化を記録する
更新後、対象グループのノード数と更新時刻を比較します。成功と表示されたのに数が0の場合は本文形式を確認します。数が正常なのに接続できない場合は、ノードのパラメータとルーティングを引き続き確認してください。
v2rayNGとv2flyNGでは、画面のバージョンによってメニュー名が多少異なりますが、操作の流れは同じです。「サブスクリプショングループの設定」でURLを編集し、メイン画面に戻って「サブスクリプションを更新」を実行します。更新前に、対象グループを選択していることを確認してください。現在のノードの接続状態を更新するだけではありません。
実際のエラーからネットワークとサーバーの問題を特定する
「更新できない」という表示より、エラーの原文のほうが原因の特定に役立ちます。v2rayNのメイン画面にあるログ欄、またはv2rayNGやv2flyNGのログ画面で、サブスクリプションリクエスト付近の情報を確認してください。以下の文言は、システム言語や実行環境によって多少異なる場合がありますが、判断の方向性はほぼ同じです。
エラー: The remote name could not be resolved
原因と対処：サブスクリプションのドメインを名前解決できていません。まずドメインの綴りを確認し、利用可能なシステムDNSへ切り替えて、クライアントを終了・再起動してから再試行します。1つのドメインだけで失敗する場合は、サブスクリプションの入口が変更されていないかも確認してください。
エラー: The operation has timed out
原因と対処：制限時間内にリクエストが完了していません。接続、TLSハンドシェイク、レスポンスのダウンロードのいずれかで停止している可能性があります。直接接続とプロキシ経由の更新をそれぞれ試し、選択した古いノードで実際に接続を確立できることを確認してください。
エラー: Response status code does not indicate success: 403
原因と対処：サーバーが現在のリクエストを拒否しています。サブスクリプション管理ページからURLをコピーし直し、識別パラメータがまだ有効か確認してください。ブラウザーで開いても権限または有効期限に関する通知が表示される場合は、先にサブスクリプション側の状態を解決します。
エラー: Too many redirects
原因と対処：URLが複数のページ間で繰り返し転送されているか、古い入口がログイン必須のページへ転送されています。ブックマークした古いURLを使い続けず、サブスクリプション本文を直接返す入口を取得し直してください。
エラー: The SSL connection could not be established
原因と対処：TLSハンドシェイクが完了していません。システムの日付、タイムゾーン、証明書環境を確認し、端末の時刻が大きくずれていないようにします。TLS 1.2またはTLS 1.3のネゴシエーション失敗は、中間ネットワーク機器の干渉が原因の場合もあります。
エラー: An existing connection was forcibly closed
原因と対処：接続確立後に、リモート側または中間ネットワークによって接続が途中で切断されています。直接接続とプロキシ経由を切り替えて比較し、HTTPSを監視・介入するローカルのネットワークフィルタリング機能を一時停止して再テストしてください。
すべてのサブスクリプションドメインを名前解決できない場合は、まず端末のネットワークとDNSを確認します。1つのサブスクリプションだけが403、ログインページ、期限切れの説明を返す場合は、そのリンクまたはサービス側の状態に問題がある可能性が高いです。クライアントの再インストールを繰り返して、この判断の代わりにしないでください。再インストールでは、無効になったアクセスパラメータは修復できません。
ダウンロード成功後もノードが空の場合に解析と形式を確認する
レスポンスを取得したクライアントは、内容がBase64でエンコードされた共有リンクの集合なのか、1行ずつ並んだプレーンテキストの共有リンクなのか、それとも別の構造なのかを判定する必要があります。一般的な共有リンクは vmess://、vless://、trojan://、ss:// で始まります。本文が実際にはWebページだったり、非対応の設定ファイルだったり、エラー通知だけだったりすると、更新時に解析エラーが表示されるか、完了後のノード数が0になることがあります。
| レスポンスの特徴 | 考えられる意味 | 対処の方向性 |
|---|---|---|
先頭に <!doctype html> または <html がある |
Webページ、ログインページ、エラーページが返されています | サブスクリプションの直接URLを取得し直し、リダイレクトと認証状態を確認する |
全体が英字、数字、+、/、= で構成されている |
標準Base64でエンコードされた内容の可能性があります | 長さ、パディング、デコード後のテキストを確認し、二重にデコードしない |
| 複数行がプロトコルスキームで始まる | プレーンテキストの共有リンク一覧の可能性があります | 各行が完全で、プロトコルと項目が現在のクライアントに対応していることを確認する |
| JSONまたはその他の構造化フィールドだけがある | API情報または専用設定形式の可能性があります | サービス側が提供するV2Ray汎用サブスクリプション形式に切り替える |
| 本文が期限、権限、リクエスト頻度に関する通知になっている | リクエストは成功したものの、サービス側の状態に問題があります | 有効期限、権限、リクエスト頻度の問題を解決してから再取得する |
Base64は、入力3バイトごとに4文字のエンコード文字へ変換され、末尾に0個、1個、または2個の = パディング文字が付く場合があります。サービスによってはパディングを省略しますが、自動対応できる解析器もあります。本文が途中で切れていたり、空白が混入していたり、コピー時に文字が欠けていたりすると、見た目がBase64らしくても正しくデコードできないことがあります。
有効な共有リンクの例：
vmess://エンコードされた内容
vless://識別情報@サーバーアドレス:ポート?パラメータ
trojan://識別情報@サーバーアドレス:ポート?パラメータ
ss://エンコードまたはユーザー情報@サーバーアドレス:ポート- デコード後は、元の本文とまったく同じ長いエンコード文字列ではなく、1つ以上の完全な共有リンクが得られるはずです。
- 各リンクには、プロトコルスキーム、サーバーアドレス、ポート、必要なパラメータがすべて含まれている必要があります。ポートまたはアドレスが欠けていると、接続可能なノードを作成できません。
- VMessの共有内容には通常JSONデータが含まれます。JSONが途中で切れていたり、引用符のエスケープが壊れていたり、フィールドの型が誤っていたりすると、インポートに失敗します。
- VLESSとTrojanでは、重要なパラメータがクエリ文字列に置かれることがよくあります。疑問符以降をコピーし忘れると、トランスポート層、TLS、REALITYの設定が変わる可能性があります。
- あるWebツールでサブスクリプション本文をデコードできても、クライアントがすべてのプロトコルパラメータに対応しているとは限りません。クライアントのログと生成結果を基準に判断してください。
更新方法、システムプロキシ、ローカルポートの相互作用
「プロキシ経由で更新」は通常、クライアントで現在利用可能なプロキシ経路をサブスクリプションリクエストにも使うことを意味します。v2rayNでよく使われるローカルSOCKSリスニングポートは 10808 ですが、この値はパラメータ設定で変更できます。ポートが変更されている、コアが起動していない、またはシステムプロキシが古いポートを参照している場合、プロキシ経由の更新はすぐに接続を拒否されるか、タイムアウトまで待ち続けることがあります。
コアの稼働状態を確認する
まずメイン画面で古いノードを1つ選択してコアを起動し、ログに正常なリスニング情報が表示されるか確認します。稼働中のローカルプロキシがない場合は、プロキシ経由の更新を選択しないでください。
ローカルポートを確認する
「設定」→「パラメータ設定」を開き、ローカルSOCKSまたは混合リスニングポートを確認します。
10808に設定されている場合、そのプロキシを利用するブラウザーやシステム設定も同じポートを指定する必要があります。プロキシループを排除する
サブスクリプションのドメインがルーティングルールによって、すでに失効したプロキシのアウトバウンドへ送られていると、更新処理が古いノードで停止することがあります。その場合は、まずプロキシを使わずに更新するか、利用可能と確認済みのノードへ一時的に切り替えてください。
システム時刻を確認する
日付、タイムゾーン、時刻同期が正しいことを確認します。大きな時刻のずれはHTTPS証明書の有効期限判定に影響し、形式エラーではなくTLS接続エラーとして現れることがあります。
リスニングプロセスを再起動する
ポート、DNS、コアの種類を変更した後は、コアを停止して再起動します。古いプロセスがリスニングポートを解放したことを確認してから、グループを1つだけ再更新してください。
エラー: Connection refused 127.0.0.1:10808
原因と対処：リクエストはローカルホストの 10808 への接続を試みていますが、そのポートをリッスンしているプロセスがありません。コアを起動するか、サブスクリプションの更新方法をプロキシなしに変更してください。リスニングポートを変更済みの場合は、呼び出し側の設定も合わせて修正します。
エラー: address already in use
原因と対処：リスニングポートが別のプロセスに使用されているため、コアが正常に起動していません。重複して起動しているクライアントを終了するか、「設定」→「パラメータ設定」で未使用のポートに変更して再起動してください。
ルーティングモードも結果に影響します。サブスクリプションのドメインが直接接続に設定されている場合、「プロキシ経由で更新」を選んでも、必ずプロキシを通るとは限りません。実際の経路は、クライアントの更新処理と現在のルーティングルールによって決まります。確認中は一度に1つの変数だけを変更し、直接接続、プロキシ、ノード切り替え後の結果をそれぞれ記録してください。DNS、ポート、ルーティング、コアの種類を同時に変更するのは避けます。
更新成功後も接続できない場合の二次確認
サブスクリプションの更新成功は、ノード情報がクライアントへ書き込まれたことを示すだけで、すべてのノードで接続を確立できることを意味しません。更新後の接続失敗は、サブスクリプションの解析問題と分けて扱います。まず新しいノードが対象グループに含まれていることを確認し、次にコアのログを読み、ドメインの名前解決、ポート接続、TLSパラメータ、ユーザー識別情報、ルーティング出口のどこで失敗しているかを判断します。
- 選択中のノードを確認：更新完了後、対象グループ内の新しいノードを手動で選択します。削除済みまたは名前変更された古い項目を使い続けないでください。
- コアを再起動：サブスクリプションによって現在のノードパラメータが置き換えられた場合は、コアを停止して再起動し、新しい設定を完全に読み込ませます。
- アドレスとポートを確認：サーバーのドメインを名前解決できる必要があります。ポートは
1～65535の有効範囲内で、空の値としてコピーされていないことを確認してください。 - トランスポートパラメータを確認：WebSocket、gRPC、TCPなどのトランスポート方式は相互に代用できません。パス、ホスト名、サービス名などの項目はサーバー側の設定と一致している必要があります。
- セキュリティパラメータを確認：TLS、REALITY、SNI、フィンガープリント、公鍵に関する項目は、サブスクリプションが提供した元の値を維持してください。ノード名が似ているからといって、別の設定からコピーしないでください。
- ルーティングルールを確認：カスタムのgeosite、geoip、ドメインルールによって、テスト対象が直接接続、ブロック、誤ったアウトバウンドへ送られることがあります。ログで実際に適用された出口を確認してください。
- クライアントのコアを区別する：v2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。両者では一部の拡張パラメータの対応範囲が異なるため、同じサブスクリプション内のすべてのノードが両方のコアで使えるとは限りません。
最終チェックリスト
前述の確認で原因を特定できない場合は、次の順序でもう一度実行してください。この順序では、まず確認しやすいリンクとリクエストの問題を除外し、その後に解析、ポート、ノード設定を確認します。サブスクリプション自体が無効なのにクライアントの調整を繰り返す事態を避けられます。
URLをコピーし直す
元のサブスクリプション管理ページから完全なリンクをコピーし、古い入力を削除してから貼り直します。スペース、改行、末尾の句読点を確認してください。
2種類の更新方法を比較する
まずプロキシを使わずに更新し、次に利用可能と確認済みの古いノードを選択してプロキシ経由で更新します。2回のエラーが一致するか記録してください。
ステータスと本文を確認する
レスポンスが200、リダイレクト、認証エラー、タイムアウトのどれなのかを確認し、本文がサブスクリプション内容、ログインページ、サービス側の通知のどれに当たるか判断します。
エンコード形式を検証する
Base64が途中で切れていないか、デコード後に完全なVMess、VLESS、Trojan、Shadowsocksの共有リンクが生成されるか確認します。
リスニング設定を確認する
「設定」→「パラメータ設定」にあるローカルポートを確認し、コアが起動していて、呼び出し側が古いポートを使い続けていないことを確認します。
ノードを1つだけ検証する
更新後のノードを1つ選択し、コアを再起動してログを確認します。名前解決、接続、TLS、トランスポート、ルーティングの結果をそれぞれ確認してください。
サブスクリプション提供元へ問い合わせる場合は、発生時刻、HTTPステータス、クライアント名、直接接続とプロキシ経由の更新結果の比較、識別パラメータを隠したエラー画面のスクリーンショットを伝えます。完全なサブスクリプションURLや完全なノード共有リンクは送らないでください。失敗した段階に近い情報ほど、リンク切れ、サーバーのレスポンス異常、クライアントの解析非互換を区別しやすくなります。