まず「サブスクリプションをダウンロードできない」「ダウンロード後に解析できない」「ノードを追加できたが接続できない」を切り分けましょう。この記事では、v2rayNまたはv2rayNGで更新エラーが出る場合に、URL、通信経路、レスポンス内容、形式の対応状況の順に確認します。利用中のノードは残し、一度に変更する項目を一つに絞ると、どの操作で解決したか判断しやすくなります。
失敗した段階を特定し、再インストールは後回しに
サブスクリプションURLはノード設定を取得するための入口であり、ノードそのものではありません。クライアントがURLにリクエストを送り、返された内容をノード情報に変換した後、コアがその情報を使って接続します。前半で失敗した場合はサブスクリプションの取得や解析を確認し、最後の段階で失敗した場合にノード接続を調べます。画面に「サービスが起動しました」と表示されても、ローカルサービスが起動したことを示すだけで、サブスクリプションサーバーや接続先ノードが利用可能とは限りません。
| 表示される現象 | まず確認する項目 | この段階では変更不要 |
|---|---|---|
| しばらく待つとタイムアウトし、内容を取得できない | ドメインの名前解決、直接接続またはプロキシ経由の通信、サービスへの到達性 | ノードの通信設定 |
| 401、403、404が返る | 認証トークン、サブスクリプションURL、サーバー側のアクセス制限 | ローカルの待ち受けポート |
| 内容は取得できるが解析エラーになり、ノードが1件も追加されない | 本文がノード設定か、出力形式が対応しているか | システムプロキシの設定 |
| 更新は成功しノードもあるが、Webページを開けない | ノード接続、システムプロキシ、ルーティング、DNS | サブスクリプションの再インポートを繰り返す |
操作した時刻、グループ名、ログで最初に表示されたエラーを記録してください。その後に表示される「利用可能な設定がありません」は、先行するダウンロード失敗の結果かもしれません。エラーの文言はバージョンによって異なります。特定のメッセージだけを検索するのではなく、どの段階で失敗したかを確認しましょう。
サブスクリプションURL、アカウントの状態、レスポンス本文を確認
まずサブスクリプション提供元のアカウントページで、契約が有効か、通信量を使い切っていないか、サブスクリプションURLが変更されていないかを確認します。アカウントにログインできても、サブスクリプションを利用できるとは限りません。トークンを再発行した場合、クライアントに保存された古いURLはすぐに無効になることがあります。契約を更新しただけでは、古いURLの問題が解決しない場合もあります。
-
URLの種類を確認
提供元のページで、v2rayNまたはv2rayNG向けのサブスクリプションURLを選びます。アカウントのログインページや購入ページ、QRコード画像のURLをコピーしないでください。ノード単体の共有リンクもサブスクリプションURLとは異なります。
-
URLをコピーし直す
ページのコピー機能を使って、クライアントに登録済みの古いURLを全体ごと置き換えます。先頭が
https://か、末尾に空白や改行、日本語の句読点が紛れ込んでいないか確認します。クエリパラメーターはそのまま残し、途中を切り詰めないでください。 -
認証状態を確認
サブスクリプションがリセット、停止、またはアクセス制限されていないか確認します。401や403が返る場合は、トークンと提供元のアクセスルールを確認してください。更新ボタンを短時間に何度も押すのは避けましょう。
-
レスポンス本文を確認
信頼できるローカル環境でレスポンスを確認できる場合は、設定テキストが返っているか、ログインページやアクセス確認ページ、期限切れの案内になっていないかを見ます。ブラウザーでページを開けても、クライアントが解析できるとは限りません。
HTTPステータスコードが200でも、エラーページが返っている場合があります。「サブスクリプションの期限切れ」が通常のテキストで返されたり、ログインが必要なページへ転送されたりすることもあります。クライアントはその内容を解析しようとするため、形式エラーのように見えます。ここでコアを何度も切り替えても解決しません。まずサブスクリプション側から正しい内容が返る状態に戻してください。
更新時の通信経路を切り替え、プロキシ依存のループを避ける
サブスクリプションの更新は、直接接続する方法と、既存のプロキシを経由する方法があります。直接接続でサブスクリプションのドメインにアクセスできない場合は、プロキシ経由を試せます。ただし、プロキシノード自体が使えないと、プロキシ経由の更新も失敗します。「新しいノードを取得するために新しいノードが必要」という状態です。テスト時は、動作確認済みの設定を少なくとも1つ残し、先にグループを空にしないでください。
v2rayN：まず1つのグループで試す
-
グループのURLを確認
メイン画面の「サブスクリプショングループ」→「サブスクリプショングループ設定」を開き、対象グループを編集してURLを確認し、保存します。メニュー名はバージョンによって多少異なることがあります。グループのURLを保存する編集画面を探してください。
-
まず直接接続で更新
「サブスクリプショングループ」メニューから「現在のサブスクリプションを更新（プロキシを使用しない）」を選びます。対象グループだけをテストし、ほかの無効なサブスクリプションのログと混ざらないようにします。バージョンによって一括更新しか選べない場合は、グループ名で結果を確認してください。
-
次にプロキシ経由で更新
直接接続で失敗した場合は、動作確認済みのノードを1つ選んでから「現在のサブスクリプションを更新（プロキシを使用）」を選びます。利用可能なノードがない場合は、提供元から有効なノード単体の設定を取得するか、接続可能なネットワークに切り替えてください。
-
エラーの変化を比べる
2回の結果を記録します。直接接続ではタイムアウトし、プロキシ経由では成功する場合、2つの通信経路の到達性が異なります。どちらも同じ403を返す場合は、認証、アクセス制限、サーバーのレスポンスを重点的に確認してください。
v2rayNG：停止時と接続時を分けて試す
サイドメニューの「サブスクリプショングループ設定」を開いて対象グループを編集し、URLを保存してからメイン画面に戻ります。右上のメニューから「サブスクリプションを更新」を選びます。バージョンによって「プロキシを使用しない」「プロキシを使用する」を選べる場合は、それぞれ試してください。更新方法が1つしかない場合は、実際のリクエスト経路をログで確認します。接続ボタンの状態だけで判断しないでください。
- 停止状態：接続を停止してから1回更新し、現在のトンネルを使わない場合の結果を確認します。
- 接続状態：動作確認済みのノードを選び、接続を開始してから更新します。実際にプロキシ経由になるかどうかは、アプリの動作、ルーティング、アプリごとのプロキシ設定にも左右されます。
- ネットワークを比較：同じURLがWi-Fiでは失敗し、モバイルネットワークでは成功する場合は、まず現在のネットワークの名前解決やアクセス制限を確認します。サブスクリプションの内容をすぐに変更する必要はありません。
結論：本文を取得できる通信経路を見つける
どれか1つの更新経路で有効なノードを取得できたら、まずその経路を維持して更新を完了します。この段階でルーティング、DNS、コアを同時に変更する必要はありません。一度に多くの項目を変えると、到達性の問題を形式の問題と誤認しやすくなります。
エラーメッセージから通信・認証・解析の問題を切り分ける
以下はネットワークリクエストや解析ログに表示されることがあるエラーの例です。すべてのバージョンで同じ文言が表示されるとは限りません。前後のURLのドメイン、ステータスコード、発生した段階とあわせて確認してください。サブスクリプションサーバーへの接続失敗と、プロキシノードへの接続失敗は別の問題です。
エラー：401 Unauthorized
原因と対処：サーバーが現在のリクエストの認証情報を受け付けていません。アカウントページから有効なサブスクリプションURLをコピーし直し、トークンが再発行されていないか確認します。WebサイトのログインパスワードをURLに直接追加しないでください。
エラー：403 Forbidden
原因と対処：サーバーがアクセスを拒否しています。アカウントの状態、アクセス元の制限、アクセス確認が原因の可能性があります。まず提供元の案内を確認し、直接接続とプロキシ経由の結果を比較してください。403だけではサブスクリプションの期限切れとは断定できません。
エラー：404 Not Found
原因と対処：リクエスト先のパスが存在しないか、サーバーが無効なURLを隠すためにこのステータスを返しています。URLが完全にコピーされているか、接続先が移転していないかを確認し、アカウントページからURLを取得し直してください。APIのパスを推測して入力しないでください。
エラー：429 Too Many Requests
原因と対処：リクエスト頻度が制限されています。連続での更新をやめ、サーバーの案内に従って待ちます。レスポンスにRetry-Afterが含まれている場合は指定された時間待ち、複数の端末で自動更新が同時に行われていないか確認してください。
エラー：Connection refused
原因と対処：接続先のポートが接続を受け付けていません。ログで接続先がローカルプロキシかサブスクリプションサーバーか確認します。ローカルのループバックアドレスの場合は、クライアントのサービスが起動していることと、更新リクエストのポートが現在の待ち受けポートと一致していることを確認してください。
エラー：Invalid length for a Base-64 char array or string.
原因と対処：一部の解析環境では、内容を想定したBase64形式でデコードできないことを示します。レスポンス本文がWebページやエラー案内、途中で切れたテキストでないことを確認し、クライアントに適したサブスクリプション形式を取得してください。文字をむやみに追加しないでください。
たとえば、エラーが 127.0.0.1:10808 を示している場合は、まずローカルプロキシの待ち受けを確認します。サブスクリプションのドメインと 443 ポートを示している場合は、リモートのHTTPSリクエストを確認してください。10808はあくまで確認例であり、すべての環境で使われるポートではありません。クライアントに表示される実際のローカル待ち受けポートを確認してください。
- ドメインの名前解決に失敗：まず端末がインターネットに接続されていることを確認し、サブスクリプションのドメインを名前解決できるか調べます。ドメインをIPアドレスに置き換えるとHTTPS証明書との照合に失敗することがあるため、通常の対処方法としては推奨しません。
- 証明書エラー：端末の日付、時刻、タイムゾーンを確認します。また、現在のネットワークでポータルへのログインが必要か確認してください。証明書検証を無効にして問題を回避しないでください。
- リクエストがタイムアウト：直接接続、プロキシ経由、別のネットワークで結果を比較します。待ち時間を延ばすだけでは、誤ったURLや接続できない通信経路は解決しません。
ダウンロードできても解析に失敗する場合：形式とパラメーターの対応状況を確認
サブスクリプションは設定の配布方法であり、決まったプロトコル形式を指すものではありません。レスポンスには、エンコードされた共有リンク一覧のほか、クライアントが対応する別の構造化設定が含まれる場合もあります。ファイルの拡張子やサブスクリプションボタンの名称だけでは、互換性を判断できません。現在のクライアントに対応すると提供元が明記している形式を優先してください。
| レスポンスの内容 | 見分けるポイント | 対処方法 |
|---|---|---|
| HTMLページ | <html、ログイン案内、アクセス確認が含まれる | URL、認証、転送先を確認し、正しいサブスクリプションレスポンスを取得する |
| 共有リンク一覧 | デコードすると vmess:// や vless:// などの接頭辞が見える | リンクが途中で切れていないか確認し、クライアントがプロトコルとパラメーターに対応しているか調べる |
| ほかのツール専用の設定 | 本文の構造が現在のクライアントのインポート要件と異なる | ファイルの拡張子だけを変えず、提供元のページで対応する出力形式を選ぶ |
| 本文が空、または期限切れの案内 | 設定がなく、アカウントの状態や案内テキストだけがある | サブスクリプションの利用権を回復するか、提供元に出力の修正を依頼する |
VMessとVLESSはプロトコル、REALITYは接続のセキュリティに関わる仕組みであり、同じ「サブスクリプション形式」として扱うことはできません。v2rayNは設定を解析・管理し、コアを呼び出すデスクトップクライアントです。v2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。パラメーターが利用できるかは、クライアントがインポートできることと、コアが実行できることの両方が条件です。ノード名だけで判断しないでください。
- すべてのノードをインポートできない：まず本文全体の形式と認証ページを確認します。ノードごとに設定を変更しないでください。
- 一部のノードだけ表示されない：該当するプロトコル、通信方式、新しいパラメーターに対応しているか確認します。更新履歴を見て、クライアントの更新が必要か判断してください。
- ノードのインポート後に起動できない：コアのログで設定エラーを確認します。共有リンクを解析できても、生成されたすべてのパラメーターを現在のコアが受け付けるとは限りません。
- 同じサブスクリプションが古いクライアントでのみ失敗する：バックアップを取ってから、サイトのダウンロードページでOSに合ったクライアントを選んで更新し、再度確認します。パラメーターを推測で入力したり、分からない項目を削除して無理にインポートしたりしないでください。
結論：ノード単体の設定で形式と接続の問題を切り分ける
提供元が同じノードの共有リンクを提供している場合は、元のグループを残したまま単体でインポートできます。単体では使えるのにサブスクリプション全体のインポートに失敗する場合は、出力内容とグループのインポート処理を重点的に確認します。どちらも失敗する場合は、そのノードのパラメーターが対応しているか確認してください。
復旧後に動作を確認してから、古い設定を整理
「更新成功」と表示されたら、対象グループにノードが追加されていることを確認し、そのうち1つを選んで実際に接続します。更新成功は取得とインポートの完了を示すだけで、提供元のすべてのノードが接続できるとは限りません。遅延テストもWebアクセスを保証するものではないため、普段使うアプリで正常に通信できるか確認してください。
-
インポート結果を確認
グループ名、ノード一覧、最終更新時刻を確認します。追加数が0でも、変更がない場合と本文が空の場合があります。ログと既存の一覧をあわせて判断してください。
-
実際に接続できるか確認
ノードを選択してサービスを起動します。デスクトップでブラウザーにシステムプロキシを使わせるには、v2rayNの「システムプロキシ」で「システムプロキシを自動設定」を選び、普段使っているHTTPSページを開いて確認してください。
-
復旧時の操作を記録
直接接続とプロキシ経由のどちらで成功したか、使用したネットワーク、サブスクリプションURLを変更したかを記録します。新しい設定が使えると確認してから、重複したグループや古いURLを整理し、すぐに戻せる状態を保ってください。
解決しない場合、問い合わせに必要な情報
- クライアント名、画面に表示されるバージョン、OS。「最新版」とだけ書かないでください。
- ダウンロード、解析、接続のどの段階で失敗したか、ログで最初に表示された関連エラー。
- 直接接続での更新、プロキシ経由での更新、別のネットワークでのテスト結果。
- 設定、Webページ、空の本文のどれが返されたか。構造の説明にとどめ、サブスクリプションの内容全体は送らないでください。
- 問題が発生する前に、ネットワークの変更、サブスクリプションの再発行、プロキシポートの変更、クライアントの更新を行ったか。
最後に、問題に応じた問い合わせ先を選びます。認証エラー、空のサブスクリプション、サーバー側の形式異常はサブスクリプション提供元に確認してください。ローカルポートの接続拒否、クライアントの解析対応、コアの設定エラーは、端末側の設定を引き続き確認します。状況を具体的に伝えるほど、再インストールを繰り返して解決を試みる必要がなくなります。