v2rayN、v2rayNG、v2flyNGで「更新に失敗する」「追加後に一覧が空になる」ときの確認手順を紹介します。ダウンロード失敗と解析失敗を切り分け、URL、レスポンス本文、Base64、ノード情報を確認。最後にノードを1つだけ追加して原因の範囲を絞り、サブスクリプションの問題をコアやDNSの障害と取り違えないようにします。
まずは切り分け：リクエスト・解析・接続の失敗
サブスクリプションの更新はいくつかの段階に分かれています。クライアントがURLへリクエストし、サーバーが内容を返し、クライアントが形式を判別してノードを作成した後、コアがノード設定を使って接続します。一覧が空でも、表示できる項目がなかったというだけで、サーバーが停止しているとは限りません。特に「更新は成功したがノードがない」場合は、グループの選択やフィルター、空のレスポンス、すべての項目が除外された可能性もあります。
| 症状 | まず確認すること | 今は避けること |
|---|---|---|
| タイムアウト、ドメインの名前解決に失敗 | サブスクリプションのドメイン、現在のネットワーク、更新時にプロキシを経由しているか | ノードのプロトコルを何度も変更する |
| 内容は取得できるが、形式エラーが表示される | レスポンス本文、エンコード方式、クライアントが対応する形式 | Webページの本文をノードとして追加する |
| 更新後に一覧が空になる | レスポンスが空でないか、グループやフィルターの状態、サブスクリプションの利用権限 | 既存ノードをすべて削除する |
| ノードは表示されるが接続できない | ノードのパラメーター、コアの対応状況、セキュリティ層、サーバーの状態 | Base64だけを原因として調べ続ける |
現在の設定をバックアップし、更新時に表示されたメッセージをすべて記録してください。使えるノードがある場合は、再試行のために既存グループを削除しないでください。テスト用グループを新しく作れば結果を比較しやすく、更新時の問題が普段の利用に影響するのも防げます。
URLを確認：サブスクリプションURLと単一ノードの共有リンクは別物
サブスクリプションURLは通常、https://で始まるリソースのURLです。一方、ノードの共有リンクはvmess://、vless://、trojan://などで始まります。前者はサブスクリプショングループに追加して更新し、後者はクライアントの共有リンク読み込み機能から追加します。ノードのリンクをサブスクリプションURL欄に入力すると、クライアントに拒否されたり、リクエスト時に失敗したりすることがあります。
-
URLをコピーし直す
サービス提供元のサブスクリプション画面からURL全体をコピーし、ローカルのテキストエディターに貼り付けて前後を確認します。誤って含まれた引用符、改行、日本語の句読点を取り除き、クエリパラメーターは手動で削除しないでください。
-
追加画面を確認する
v2rayNでは通常、「サブスクリプショングループ」→「サブスクリプショングループの設定」→「追加」から登録します。メモとURLを入力して保存してください。バージョンによって表示名が多少異なるため、単一ノードの編集画面ではなく、サブスクリプショングループの編集画面を選びます。
-
個別に更新する
「サブスクリプショングループ」に戻り、「選択したサブスクリプションを更新（プロキシを使用しない）」を実行してテストします。画面に「現在」ではなく「選択した」と表示されている場合は、追加したテスト用グループが選択されていることを確認してください。
-
結果を記録する
更新時刻、表示されたメッセージ、ノード数に変化があったかを記録します。Androidでは、v2rayNGの「サブスクリプショングループの設定」でURLを確認し、メイン画面のメニューから「サブスクリプションを更新」を実行します。
クエリ文字列内の&、=、%は、トークンやパラメーターの一部である可能性があります。「余計に見える」という理由で削除しないでください。Webページのソースや転送されたメッセージからコピーしたURLに、文字列として&が含まれている場合は、元のコピー用ボタンから取得し直してください。HTMLエスケープ後の文字列を実際のURLとして使わないようにしましょう。
レスポンス本文を確認：HTTP成功でも有効とは限らない
信頼できるローカル環境でレスポンスを確認する際は、ステータスコードと本文の両方を確認します。ブラウザーでログインページを開けても、サイトにアクセスできることしか分かりません。クライアントに必要なのは、認識可能なノードデータです。Web認証画面、ログインへのリダイレクト、エラーメッセージが返される場合、ステータスコードが200でも解析できないことがあります。また、ブラウザーにはログインCookieが送信されている場合があるため、ブラウザーでアクセスできてもクライアントのリクエストが成功するとは限りません。
- 本文がHTMLタグで始まる：たとえば
<!DOCTYPE html>が先頭にある場合、Webページが返された可能性が高いため、Base64のデコードを続けないでください。 - 本文がJSON形式のエラーオブジェクト：まずエラーの内容を確認してください。拡張子やレスポンス形式がデータファイルらしく見えても、ノード一覧だと決めつけないでください。
- 本文が空：サブスクリプションが有効か、プランの利用権限やサービス提供元の状態を確認します。ネットワーク機器によってレスポンスが途中で切断されていないかも確認してください。
- ステータスコードが429：リクエストの頻度が高すぎる状態です。続けて更新せず、サービス提供元の案内またはレスポンスに記載された待ち時間に従ってから再試行してください。
ポイント：エンコードを調べる前に本文を確認
ログインページ、アクセス拒否、空のレスポンスが返された場合、再エンコードしても有効なノードは作成できません。まずサブスクリプションへのアクセス条件を解決してから、クライアントでの解析を試してください。
Base64の確認：エンコードの層を見極め、むやみに文字を補わない
よく使われるサブスクリプション形式の一つは、複数行の共有リンク全体をBase64でエンコードする方式です。デコードせず、共有リンクのテキストをそのまま返すサブスクリプションもあります。また、VMessの共有リンク自体にもBase64でエンコードされたJSONが含まれることがよくあります。そのため、サブスクリプションを1回デコードした後にvmess://が見えても、正常な場合があり、デコード失敗とは限りません。形式を受け付けるかどうかは、クライアントのサブスクリプション解析機能によります。
- 標準Base64：文字セットには
+と/が含まれ、末尾にパディング用の=が付く場合があります。 - URLセーフ形式：前述の2文字を
-と_に置き換えます。自動判別できるかどうかは解析機能によって異なります。 - 長さを確認：無視できる空白を除いた長さを4で割った余りが2または3なら、パディングが省略されているだけの可能性があります。余りが1の場合は、内容が不完全か、Base64以外の形式である可能性が高いです。
- デコードできても有効とは限らない：デコードに成功しても、結果がクライアント対応のノードデータである必要があります。Base64はエンコード方式であり、データを秘匿するものではありません。
改行を許容するかどうかは実装によって異なります。空白を除去するサブスクリプション解析機能もあれば、厳密にデコードする画面もあります。まず元の内容を保存し、コピーしたデータでローカル確認してください。ノードURI内の文字を一括置換したり、すべての=を削除したりしないでください。コピー時に内容が途中で切れていた場合、パディングを足しても見た目が変わるだけで、失われたデータは復元できません。
illegal base64 data at input byte 0
原因：Webページのように山括弧で始まる内容をエンコード済みデータとして扱うなど、GoのBase64デコーダーが先頭で文字セットに含まれない文字を検出しています。
対処法：レスポンスの先頭と元の形式を確認します。Webページが返されている場合はリクエスト先を修正し、パディングを追加し続けないでください。クライアント上では簡略化された「解析失敗」とだけ表示されることがあります。
unexpected end of JSON input
原因：JSONパーサーが空の内容、または最後まで届いていないデータを読み取っています。VMess共有データをデコードした後、フィールドを解析する段階で発生することがあります。
対処法：内容を完全な形で取得し直し、デコード結果が途中で切れていないか確認してください。括弧を手動で1つ追加してノード設定を推測しないでください。
プロトコルの互換性：デコードできてもノードを作成できるとは限らない
サブスクリプション形式への対応と、コアのプロトコル対応は別の問題です。GUIクライアントがサブスクリプションを独自のノード設定に変換してから、コアに渡して実行します。v2rayNGはXrayコア、v2flyNGはV2Flyコアを使用します。v2rayNでは、現在実際に選択されているコアを確認してください。どちらのクライアントもVMessを認識できるからといって、対応する通信パラメーターやセキュリティ層の組み合わせまで同じとは限りません。
| 確認項目 | 確認する内容 | よくある影響 |
|---|---|---|
| サーバーのポート | 1～65535の整数であること。443はよく使われますが、固定値ではありません | 未設定または範囲外の場合、追加できないことがあります |
| 認証情報 | VMessとVLESSではUUIDを確認し、その他のプロトコルでは仕様に沿ってパスワードを確認 | 認証情報が誤っていても追加できることがありますが、認証に失敗します |
| 通信パラメーター | 通信方式、WebSocketのパス、Hostなどがサーバー側の設定と一致していること | 未対応のフィールドは失われる場合があり、入力ミスがあれば接続に失敗します |
| セキュリティ層 | TLSのserverName、REALITYの公開鍵・shortIdと関連設定 | クライアントの解析機能とコアの両方が対応している必要があります |
REALITYはセキュリティ層の仕組みであり、独立したアウトバウンドプロトコルではありません。ノード名を「REALITY」に変えただけで対応が完了したと考えないでください。サービス提供元がクライアント別のサブスクリプションURLを用意している場合は、現在のクライアント向けと明記された形式を選びます。構造化設定ファイルも、共有リンクの一覧としてそのまま読み込めるとは限りません。
- テスト用グループに元のサブスクリプションを残したまま、サービス提供元が提供する完全な共有リンクを1つだけ個別に追加します。
- 単一ノードは追加できるのにサブスクリプション全体の読み込みに失敗する場合は、外側のエンコード、サブスクリプションのレスポンス形式、内容の途中切れを優先して確認してください。
- 特定の種類のノードだけ表示されない場合は、そのプロトコルや通信フィールドへの対応状況を確認します。必須パラメーターを削除して無理に追加しないでください。
- ノードは表示されるものの、コアの起動時にエラーが出る場合は、コアの設定ログを確認してください。「設定に非対応」と「ネットワーク接続の失敗」を切り分けます。
サブスクリプションの有効期限と更新経路：最後に条件を絞って再テスト
サブスクリプションURLの無効化とノードへの接続失敗は、必ずしも連動しません。トークンをリセットすると古いURLはすぐに無効になる一方、キャッシュ済みのノードは引き続き表示されることがあります。プランの期限切れ時に空の一覧、案内文、アクセス拒否のどれを返すかはサービス提供元によって異なります。古いURLを何度も読み込むより、アカウントの有効期限、残りの利用権限、最新のURLを確認しましょう。
サブスクリプションへのリクエストが通るネットワーク経路も個別に確認する必要があります。「プロキシ経由で更新」は、現在のプロキシが使えることが前提です。使用中のノードが無効だと、更新が依存関係のループに陥る可能性があります。反対に、サブスクリプションのドメインに直接接続できず、動作確認済みのノードがある場合は、プロキシ経由での更新が有効です。一度に切り替える条件を1つに絞れば、何が結果に影響したかを判断できます。
- 直接接続を1回テスト：v2rayNの「サブスクリプショングループ」で、プロキシを使用しない更新を実行し、表示内容を記録します。続けて何度もクリックしないでください。
- プロキシ経由を1回テスト：選択したノードで接続できることを確認してから、「選択したサブスクリプションを更新（プロキシを使用）」を実行します。メニューの表記はバージョンによって異なります。
- システム時刻を確認：日付が大きくずれていると、HTTPS証明書の有効期限の判定に失敗することがあります。証明書の検証を無効にせず、システムの自動時刻合わせを有効にしてください。
- 表示対象を確認：正しいグループに切り替え、検索語とフィルター条件を解除します。一覧に表示されないからといって、データが追加されていないとは限りません。
ポイント：失敗した段階に応じて情報を伝える
解決しない場合は、クライアント名とバージョン、更新時刻、リクエストの状態、個人情報を伏せたエラー内容をサービス提供元に伝えてください。直接接続とプロキシ経由での更新結果の違いも説明し、サブスクリプショントークンやノードの認証情報は送らないでください。
再テストに成功したら、ノードのフィールドが揃っているか、コアが起動するか、実際に接続できるかを確認してください。この3段階でそれぞれ「サブスクリプションを解析できる」「設定を実行できる」「接続できる」ことを検証します。更新成功の表示だけで確認を終えないでください。追加手順を確認する場合はサブスクリプションの使い方をご覧ください。形式を変換する場合は、認証情報を信頼できないサービスに渡さないよう、先にサブスクリプション変換時の注意点を確認してください。