このチェックリストは、v2rayN、v2rayNG、v2flyNGで購読のダウンロードに失敗する、解析エラーが出る、更新後にノードが空になる場合に役立ちます。確認する順番は、リンク、レスポンス内容、エンコード形式、更新経路、プロトコル互換性、ローカル環境の6段階です。各手順の後にもう一度更新して結果を記録すれば、問題がクライアント、ネットワーク、購読サービスのどの層にあるかを特定しやすくなります。
まず失敗している段階を確認する
「購読が使えない」といっても、原因は1つではありません。クライアントが購読を更新するには、アドレスの読み取り、名前解決、接続の確立、レスポンスの受信、内容のデコード、ノードの認識という少なくとも6つの段階を完了する必要があります。前半4段階で失敗すると、タイムアウト、接続拒否、HTTPステータスエラーが表示されることが多く、後半2段階ではリクエストが成功したように見えるのにノード数が0になることがあります。
確認を始める前に、元の購読グループを残し、連続して削除・作り直し・ノードの一括変更をしないでください。v2rayN 7.xでは、まずメイン画面のログ領域を開き、「購読グループ」→「すべての購読を更新」を実行します。Androidでは、v2rayNGまたはv2flyNGの購読グループ画面で対象グループだけを更新し、表示されたエラー全文を記録してください。
どの段階かを判断するには、2つの結果を確認します。リクエストが有効なレスポンスを取得できたか、そしてレスポンスからノードが生成されたかです。ログが接続段階で止まる場合は、まず4番目の更新経路と6番目のローカル環境を確認します。数千バイトの内容を受信したのにノードがない場合は、2番目のレスポンス形式、3番目のエンコード形式、5番目のプロトコル互換性を優先して確認してください。
1番目：購読リンクが完全か、有効期限内か確認する
購読アドレスで最も多い問題は、コピーが途中で切れていることです。クエリパラメータ付きのリンクには、疑問符、等号、複数のパラメータが含まれることがあります。チャットアプリの改行、ブラウザーでの省略表示、手動選択によって末尾のトークンが欠ける場合があります。1文字足りないだけでも、サーバーは未認証、空の内容、通常のエラーページを返すことがあります。
v2rayN 7.xでは「購読グループ」→「購読グループの設定」を開き、対象グループを選択してアドレスを確認します。入力欄に表示された先頭と末尾だけで判断せず、全選択して再コピーし、取得元のページと1文字ずつ比較してください。v2rayNGとv2flyNGでも購読グループの編集画面を開き、アドレスの前後にスペース、日本語の引用符、改行がないことを確認します。
エラー：The remote server returned an error: (401) Unauthorized
原因と対処：購読トークンが無効、期限切れ、またはコピー途中で欠けています。完全な購読アドレスを再取得し、既存グループのアドレスを置き換えてから更新してください。
エラー：unsupported protocol scheme
原因と対処：アドレスに正しい通信プロトコルのプレフィックスがないか、先頭にスペースが混入しています。有効なHTTPSアドレスで始まっていることを確認し、アドレスの両端の空白を削除してください。
エラー：404 Not Found
原因と対処：リクエスト先のパスが変更されたか、アドレスが途中で切れています。購読管理ページから完全なアドレスを再コピーし、古いアドレスを手作業で補完しないでください。
- 購読アドレスが1行のテキストで、先頭と末尾にスペースがないことを確認する。
- 疑問符以降のクエリパラメータが完全か確認し、特に等号の後ろのトークンを欠かさない。
- 現在の購読が有効期限内で、サーバー側で新しいアドレスが発行されていないことを確認する。
- まずアドレスだけを置き換え、既存ノードは削除しない。更新に失敗しても元の設定を残せる。
リンクがQRコード経由の場合も、スキャン後に実際のテキストを確認してください。QRコードには購読アドレスではなく、単一のVMessまたはVLESSノードが含まれていることがあります。単一ノードのリンクを購読入力欄に入れると、一部のクライアントでは形式エラーになり、別のクライアントでは更新に成功しても購読グループを作成できない場合があります。
2番目：サーバーが購読内容を返しているか確認する
リンクを開けるからといって、返された内容が正しいとは限りません。購読サーバーがログインページ、期限切れの案内、アクセス頻度制限ページ、リダイレクトページを返すことがあります。ブラウザーでは正常に見えても、クライアントが必要としているのはノードリンク一覧または所定形式のデータです。HTMLを購読テキストとして解析すると、文字エラーやノード0件が発生します。
ブラウザーで購読アドレスを開いて結果を確認できますが、アドレスを公開したり、完全なトークンを公開ページに貼り付けたりしないでください。有効なレスポンスは通常、連続したエンコード済みテキスト、または複数行のプロトコルリンクです。「ログイン」「プランの期限切れ」「リクエストが多すぎます」などの表示が出る場合は、アカウント状態を確認するか、制限が解除されるまで待ってください。
有効な複数行購読の構造例：
vmess://エンコード済みノードデータ
vless://ユーザー情報@server.example.net:443?security=tls&type=ws
購読内容ではないことが明らかなレスポンス：
<html>
<title>Sign in</title>
</html>| 確認結果 | 判断できる問題 | 次の手順 |
|---|---|---|
| 401または403が返る | トークンが無効、権限が失効、またはアクセス条件を満たしていない | 購読アドレスを再生成して古いアドレスと置き換える |
| 404が返る | 購読パスが変更された、またはリンクが途中で切れている | 元の管理ページから完全なリンクを再コピーする |
| 429が返る | 短時間に更新しすぎている | 連続更新を止め、10～30分空けて再試行する |
| HTMLページが返る | ログイン、期限切れ、ブロックページへリダイレクトされている | ページの案内に対応し、クライアントのコアを変更し続けない |
| テキストが返るがサイズが0バイト | サーバー側の生成処理に異常がある、または現在のグループが空 | サーバー側で、購読に有効なノードが少なくとも1つ含まれていることを確認する |
リダイレクトにも注意してください。購読アドレスによっては、まず301または302を返して一時ダウンロードアドレスへ転送します。途中の転送で追加認証が必要になると、クライアントが最終内容を取得できない場合があります。この場合は、ブラウザーのアドレスバーから転送後の一時リンクをコピーするのではなく、サーバーが直接提供するクライアント用購読アドレスを使ってください。
3番目：エンコード方式と改行形式を確認する
サーバーが内容を返しているのに解析に失敗する場合は、エンコードを重点的に確認します。一般的な購読は、複数行のノード一覧をBase64エンコードしたものです。一方で、改行区切りのVMess、VLESSなどのリンクを直接返すサービスもあります。クライアントは外側の形式を判別してから、各行のプロトコルフィールドを解析します。外側に余分なWebタグがある、内部の文字が1つ欠けている、改行形式が異常であるといった状態でも、一覧全体のインポートに失敗することがあります。
購読内容をワープロソフトで編集してからインポートしないでください。引用符の自動置換、段落記号の挿入、改行の変更によってURIが壊れます。オフライン診断が必要な場合はUTF-8のプレーンテキストとして保存し、各ノードリンクを1行に1つだけ置き、行頭に番号、箇条書き記号、スペースがないことを確認してください。
エラー：illegal base64 data at input byte
原因と対処：外側のエンコードが途中で切れている、スペースが混入している、またはクライアントが正しく認識できない変種が使われています。元のレスポンスを再取得し、エンコード済みテキストを手作業でつなぎ合わせないでください。
エラー：invalid character '<' looking for beginning of value
原因と対処：クライアントがHTMLページをJSONまたは購読データとして読み込んでいます。2番目の確認に戻り、レスポンスページとHTTPステータスを確認してください。
エラー：failed to parse subscription content
原因と対処：購読の外側の形式、または特定の行がクライアントの認識できる構造に一致していません。まず、既知の有効なノードを1つだけ含むテスト購読をインポートし、パーサー自体が動作することを確認してください。
- レスポンスの先頭に
<htmlまたは<!doctypeがある：これはWebページであり、購読データではありません。 - デコード後の各行がプロトコル名で始まる：空行以外の説明文が含まれていないか確認する。
- 特定の1行だけインポートに失敗する：その行だけを一時的に削除してテストし、問題がそのノードのフィールドにないか確認する。
- すべての行が失敗する：外側のエンコード、文字コード、クライアントが対応する購読形式を優先して確認する。
「ノード数が0」になる原因は、サーバーがクライアントの種類に応じて異なる形式を返している場合にもあります。管理ページにv2rayN、v2rayNG、汎用購読の選択肢がある場合は、現在のクライアントに対応する種類を選んでください。他のソフト用の設定形式をそのままV2Rayクライアントに解析させないでください。
4番目：購読の更新経路を切り替える
購読リクエストは現在のプロキシ経由でも、直接接続でも実行できます。現在のネットワークから購読ドメインへ直接接続できない場合、直接更新ではタイムアウトします。逆に、選択中のノードがすでに使えない場合は、プロキシ経由の更新も失敗します。特定の方式を固定で選ぶのではなく、現在の接続状態に応じて比較テストを行うのが正しい方法です。
既存ノードを確認する
まず、クライアント内に起動可能な古いノードが残っているか確認します。古いノードが接続できる場合は現在の設定を残し、先に一覧を消去しないでください。
コアの状態を確認する
v2rayNのメイン画面でコアが起動しているか確認し、ログに表示されるローカル待受ポートを確認します。一般的なSOCKSインバウンドは10808ですが、現在の設定に表示される値を優先してください。
まず直接接続で更新する
「購読グループ」→「すべての購読を更新」を実行し、プロキシを経由しない更新方式を選択して、所要時間とエラー原文を記録します。
次にプロキシ経由で更新する
接続できることを確認済みのノードに接続し、プロキシ経由で購読を更新します。2回目に成功した場合、問題は購読ドメインへの直接接続経路にあります。
2回の結果を比較する
直接接続とプロキシの両方で失敗する場合は、アドレスとサーバーのレスポンスを確認します。プロキシ経由だけが失敗する場合は、現在のノード、コアの状態、10808など実際の待受ポートを確認してください。
v2rayNの「システムプロキシ」スイッチと、「購読をプロキシ経由で更新するかどうか」は完全に同じ判断項目ではありません。システムプロキシは他のアプリのリクエスト送信方法を制御しますが、購読更新はクライアント自身が設定に従って開始する場合があります。ブラウザーでWebページを開けるかだけで更新経路を判断せず、クライアントログに記録された実際の接続方式を基準にしてください。
5番目：クライアントのバージョン、コア、プロトコル互換性を確認する
購読をダウンロードしてデコードできても、含まれるすべてのノードを現在のコアで利用できるとは限りません。VMessとVLESSは異なるプロトコルで、ノードにはTLS、Reality、WebSocket、gRPCなどの通信設定が組み合わされることもあります。古いクライアントや互換性のないコアでは、新しいフィールドを含むノードがスキップされたり、インポート後に起動できなかったり、コアのログに不明な設定項目が表示されたりします。
デスクトップ版のv2rayNでは、「設定」→「パラメータ設定」→「Coreタイプ」を開き、現在の選択を確認します。VLESS、RealityなどXray関連の設定が含まれる場合は、該当フィールドを認識できるXrayコアを使用し、v2rayNとコアを同時期の安定版に更新してください。メインプログラムだけを置き換え、明らかに古いコアファイルを残すのは避けてください。
エラー：unknown field
原因と対処：設定に現在のコアが認識できないフィールドが含まれています。クライアントと対応するコアを更新し、v2rayNの「設定」→「パラメータ設定」→「Coreタイプ」で選択を確認してください。
エラー：failed to load config files
原因と対処：ノードはインポートされていますが、生成されたコア設定の検証に失敗しています。直後に表示されるフィールドエラーを確認し、該当するプロトコル、トランスポート、セキュリティパラメータを特定してください。
エラー：unknown transport protocol
原因と対処：ノードのトランスポート形式が現在のバージョンでサポートされていないか、購読フィールドの記述に誤りがあります。まずコアを更新し、その後、購読の提供元にノードテンプレートを確認してもらってください。
- v2rayN：デスクトップ版では、まずメインプログラムのバージョンを確認し、次に実際に有効なCoreタイプとコアログを確認する。
- v2rayNG：Android版はXrayコアを採用しているため、VLESS、Realityなどのフィールドを含む購読の確認に適している。
- v2flyNG：Android版はv2flyコアを採用しているため、特定のXray拡張フィールドがある場合に直接互換すると決めつけない。
- 同じ購読で一部のノードは正常、一部は失敗する：通常はノードのプロトコルまたはトランスポート構成が異なるのであり、購読アドレス全体が無効になったわけではない。
判断時は「購読の解析」と「ノード接続」を分けて考えてください。ノードが一覧に表示されているなら、ダウンロードと基本的な解析は完了している可能性が高いです。その後にハンドシェイク失敗、サーバーアドレスの名前解決失敗、接続タイムアウトが起きた場合は、購読リンクを変更し続けるのではなく、ノードと経路の確認に進みます。
6番目：ローカルのネットワーク、時刻、グループキャッシュを整理する
最初の5項目に問題がない場合は、ローカル環境を確認します。端末の時刻が大きくずれるとTLS証明書の検証に失敗することがあります。DNSが異常なアドレスを返すと購読ドメインに接続できず、セキュリティソフトやファイアウォールがクライアントのコアによる通信を阻止することもあります。古いグループキャッシュによって、更新後のノードが期待どおり置き換わらない場合もあります。
まずシステムの日付、時刻、タイムゾーンを合わせ、クライアントを完全に終了して再起動します。その後、現在のネットワークと別の利用可能なネットワークでそれぞれテストしてください。同じ購読が別のネットワークでは5秒以内に更新でき、元のネットワークでは約30秒でタイムアウトし続けるなら、問題は購読のエンコードではなく、DNS、ゲートウェイ、ネットワーク出口にある可能性が高いです。
購読の更新がいつもタイムアウトする？
まずタイムアウトした時刻を記録し、直接接続とプロキシ経由の更新を切り替えてください。どちらも一定時間後に失敗する場合は、購読ドメインの名前解決結果、システム時刻、ファイアウォールの送信ルールを確認します。
更新は成功したのにノード一覧が空のまま？
対象の購読グループを開き、返されたノード数を確認するとともに、フィルター条件が有効になっていないか確認します。一時的に名前フィルターとプロトコルフィルターを解除し、もう一度更新して元の一覧を確認してください。
PCでは更新できるのに、Androidでは更新できない？
v2rayNGまたはv2flyNGで同じ完全なアドレスを貼り直し、ネットワーク通信を書き換えるプライベートDNS設定を無効にして比較してください。端末の日付とタイムゾーンも正確か確認します。
ネットワークを変えるとすぐ復旧するのはなぜ？
購読リンクとクライアントの解析は、おそらく正常だと考えられます。元のネットワークに戻ったら、DNS、ゲートウェイの制限、購読ドメインへの接続経路を重点的に確認し、すべてのノードを作り直す必要はありません。
購読グループをすぐ削除する必要はある？
まず古い設定をエクスポートまたは保持し、アドレスが有効でキャッシュに問題があると確認できた場合だけテストグループを新規作成します。テストグループへのインポートが成功してから、古いグループを削除するか判断してください。
- システム時刻：標準時刻との差は1分以内に抑え、タイムゾーンも正しく設定する。
- DNSの比較：ネットワークを切り替えて購読ドメインを再度名前解決し、接続可能なアドレスが返るか確認する。
- ファイアウォールの確認：v2rayNのメインプログラムと実際のコアプロセスによる送信接続を許可する。
- ポートの確認：10808などのローカルポートが他のプロセスに使用されていないことを確認し、具体的な値はログを基準にする。
- グループの確認：フィルター条件を解除し、新しいノードが名前、プロトコル、グループのルールで非表示になっていないか確認する。
テストグループを作成するときは同じアドレスを使い、そのグループを1回だけ更新します。テストグループは正常なのに古いグループだけ空の場合、問題は古いグループの設定またはキャッシュに集中しています。2つのグループの結果が完全に同じなら、サーバーのレスポンスとネットワーク経路に戻って確認し、グループを何度も作り直す必要はありません。
修正後は4つの結果で検証を完了する
修正の完了基準は「ポップアップが出ない」ことではありません。購読リクエスト、ノード生成、コア起動、実際の接続という4層すべてが通ることを確認します。まず対象グループを更新してノード総数を記録し、ノードを1つ選んでコアを起動します。ローカル待受ポートを確認したら、ネットワーク接続が必要なアプリでリクエストを実行し、コアログに新しい送信記録が出るか確認してください。
| 検証レベル | 合格基準 | 失敗時に戻る手順 |
|---|---|---|
| 購読リクエスト | 401、404、429、タイムアウトがなく、レスポンス内容が空でない | 1番目、2番目、または4番目 |
| ノード生成 | 更新後のノード数が0より多く、名前とプロトコルを確認できる | 3番目または5番目 |
| コア起動 | ログにインバウンドポートの待受開始が表示され、設定フィールドのエラーがない | 5番目または6番目 |
| 実際の接続 | アプリのリクエストによる送信ログが記録され、3回連続のテスト結果が安定している | ノード、経路、またはシステムプロキシの設定 |
購読が復旧しても特定のノードだけ接続できない場合、購読を更新し続けないでください。同じグループ内の別の2ノードを選んで個別にテストします。3ノードすべてが失敗する場合は、ローカルのコアとネットワークを確認し、1ノードだけが失敗する場合は、そのノードのアドレス、ポート、経路の状態に問題がある可能性が高いです。
完全なトラブル対処記録には、クライアント名とバージョン、コアの種類、更新時刻、エラー原文、直接接続とプロキシ経由の2回の結果、返されたノード数を含めます。これらをまとめて確認することで、「リンクの期限切れ」「サーバーエラー」「クライアント非互換」「ローカルネットワークの遮断」を正確に区別でき、「購読が使えない」の一言だけで設定を何度も変更する事態を避けられます。