v2rayN、v2rayNG、v2flyNGのサブスクリプション更新時のトラブル対処を解説します。まずリクエストの失敗と内容の解析失敗を切り分け、URL、応答形式、更新経路、システム時刻を確認します。設定の修正、購読URLの再取得、提供元への問い合わせのどれが必要か判断できるようになり、既存ノードをむやみに削除せずに済みます。
まず切り分ける：取得に失敗したのか、取得後の解析に失敗したのか
サブスクリプションの更新は、単に「インポート」するだけではありません。クライアントが購読URLへリクエストを送り、応答を取得した後、形式を判別してノードを解析し、該当グループに登録します。どの段階で失敗しても、画面には「更新失敗」やインポート件数0とだけ表示されることがあります。まず更新結果やログを開き、最初に記録された具体的なエラーを確認しましょう。
V2RayとXrayは通信を処理するコアであり、購読URLの管理や内容のインポートは通常、GUIクライアントが担当します。そのため、サブスクリプションの解析失敗はコアの起動失敗を意味しません。インポート済みのノードが使える場合は残しておき、更新の問題をきっかけに設定全体を作り直すのは避けましょう。
| 状況 | まず確認する項目 | 今は対応不要 |
|---|---|---|
| タイムアウト、ドメイン名の解決失敗 | ネットワーク、DNS、更新時にプロキシを経由したか | ノードの暗号化パラメーター |
| HTTP 401 または 403 | アクセス認証情報、アカウントの状態、アクセス制限 | ローカルのノード順序 |
| HTTP 200だが解析に失敗 | 応答本文がログインページやエラーページではないか | ステータスコードだけで内容が有効だと判断すること |
| 更新は成功したがノードが0件 | サブスクリプションの内容、形式の互換性、グループのフィルター | グループをすべて削除すること |
| インポートは成功したが接続がタイムアウト | ノードのパラメーター、コアのログ、接続経路 | サブスクリプションの更新を何度も繰り返すこと |
購読URLを確認：期限切れ、途中で切れている、コピー時の誤り
購読URLはアカウントページのURLでも、単一ノードの共有リンクでもありません。アカウントページはブラウザーのログイン状態を必要とすることが多く、クライアントから直接アクセスするとログイン画面が返る場合があります。単一ノードのリンクは通常、プロトコル名で始まります。定期更新用の購読URL欄ではなく、クライアントのクリップボードからのインポート機能を使ってください。
-
現在の設定を保持する
失敗したグループ名と更新時刻を記録し、使えるノードは残しておきます。バックアップをエクスポートする場合は、管理下にあるローカルフォルダーに保存し、認証情報を含むファイルを公開チャットに送らないでください。
-
URLをコピーし直す
提供元のアカウントページから購読URLを全体コピーします。先頭が
https://か、末尾が途中で切れていないか、前後に空白・改行・引用符・全角句読点が混入していないか確認してください。 -
グループのURLを確認する
v2rayNでは「サブスクリプショングループ」→「サブスクリプショングループ設定」から対象グループを編集し、URL欄を確認します。バージョンによってメニュー名は多少異なります。似た名前の別グループではなく、失敗したグループを編集していることを確認してください。
-
アカウントの状態を確認する
サブスクリプションの期限や利用上限、URLが再発行されていないか確認します。URLを再発行すると古いアドレスは通常使えなくなります。新しいURLは、実際に使っているすべてのクライアントに反映してください。
-
対象グループだけを更新する
まず選択中のグループだけを更新し、返されたエラーとインポート件数を記録します。成功を確認してから他のグループを更新すれば、複数の接続先で同時にエラーが発生してログの対応関係が分からなくなるのを防げます。
更新がタイムアウトする：直結とプロキシ経由を比較する
ブラウザーでアカウントページを開けても、クライアントが購読URLを取得できるとは限りません。ブラウザーはシステムプロキシやログイン状態を使っていたり、異なるDNS経路を通ったりする場合があります。一方、サブスクリプション更新では直結かプロキシ経由かを個別に選ぶことがあります。まず経路だけを切り替えて2回比較し、DNS、ルーティング、ノードのパラメーターは同時に変更しないでください。
- 直結で更新：v2rayNの「サブスクリプショングループ」メニューから「すべてのサブスクリプションを更新（プロキシを使用しない）」を選びます。選択したグループだけを更新できるバージョンでは、まず対象グループだけを試してください。
- プロキシ経由で更新：動作確認済みのノードを選択してコアを起動し、「すべてのサブスクリプションを更新（プロキシを使用）」を選びます。システムプロキシを有効にしただけでは、クライアントの購読リクエストが必ずプロキシ経由になるとは限りません。
- Androidで確認：v2rayNGのサイドメニューにある「サブスクリプショングループ設定」で登録元を確認し、メイン画面のメニューから「サブスクリプションを更新」を実行します。更新がプロキシ経由かどうかは、使用中のバージョンの設定とログで確認してください。VPNアイコンだけでは判断できません。
- 結果を比較：直結では失敗し、プロキシ経由では成功する場合、購読サイトへの直結経路に問題がある可能性があります。どちらも同じ401を返す場合は、ノードを切り替え続けるのではなく、アカウントまたはURLを優先して確認してください。
ローカルプロキシのポート番号は、クライアントの設定画面に表示された値を確認してください。たとえば実際の待ち受けポートが 10808 なら、他のプロキシ設定も古い 10809 のままにしないでください。ここに挙げたポートはローカル待ち受けの例であり、すべてのバージョン共通の既定値でも、リモートノードのポートでもありません。
HTTPは成功しているのに解析できない：本文と形式を確認
HTTP 200はサーバーが成功応答を返したことを示すだけで、本文がサブスクリプションである保証はありません。ログインページ、アクセス確認ページ、アカウントの期限切れを知らせるページも、ステータスコードが200の場合があります。エラーにBase64やJSON、認識可能なノードが見つからないといった記載がある場合は、すぐにクライアントを再インストールせず、まず応答内容の種類を確認してください。
| 本文の特徴 | 考えられる内容 | 対処方法 |
|---|---|---|
<!DOCTYPE html> または <html で始まる | 想定されたサブスクリプションではなくWebページ | クライアント専用の購読URLを取得し直す |
複数行の内容が vmess:// または vless:// で始まる | ノード共有リンクの一覧 | クライアントが各プロトコルとパラメーターに対応しているか確認する |
| ひと続きのエンコード文字列 | Base64でエンコードされたリンクの一覧である可能性 | 完全な内容かローカルで確認し、見た目だけで有効と判断しない |
| JSON、またはインデントされた設定テキスト | 完全な設定ファイル、または別の形式の可能性 | 提供元で、使用中のクライアントに対応したサブスクリプション形式を選ぶ |
| 応答が空、または案内文だけが表示される | アカウントの状態に問題があるか、サーバーからノードが提供されていない | 応答内容とアカウントの状態を提供元に確認する |
Base64はエンコード方式であり、ノードのプロトコルではありません。一般的なVMess共有リンクではノード情報がリンク内にエンコードされていますが、VLESS共有リンクは構造が異なります。URLをデコードできたからといって、含まれるすべてのプロトコル、トランスポート層、安全性に関するパラメーターに現在のクライアントが対応しているとは限りません。
サブスクリプション内の改行をすべて削除したり、不足しているように見える文字を補ったりしないでください。エンコード形式によって改行やパディング文字の扱いは異なり、途中で切れた内容は文字を機械的に補っても復元できません。まず元の応答を取得し直し、提供元で選択されている出力形式を確認するのが確実です。一部のノードだけインポートに失敗する場合は、失敗したプロトコルとトランスポートの種類を記録し、クライアントと対応するコアのバージョンを確認してください。
- v2rayNはデスクトップ向けの設定管理クライアントです。ノードが使えるかどうかは、選択したコアとそのバージョンの対応状況によって異なります。
- v2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。アプリ名が似ているだけで、設定に完全互換性があるとは限りません。
- コア用の完全な設定ファイルとGUIクライアント用のサブスクリプションは、インポート対象が異なります。「JSONを正常に解析できた」場合でも、クライアントがサーバー一覧に変換できるとは限りません。
エラーの内容に応じて対処する：すべてを解析失敗として扱わない
以下は、一般的なネットワークツールや実行環境で表示されるエラーの例です。クライアントでは日本語訳やドメイン名、例外のスタック情報が追加される場合があります。原因の切り分けでは、エラーの重要な部分を記録してください。最初に発生した低レベルのエラーを優先して対処しましょう。後続の「更新失敗」は、単なる結果のまとめであることがよくあります。
エラー：Could not resolve host
原因：購読ドメイン名を解決できず、応答内容の解析に進む前にリクエストが失敗しています。
対処：URLのドメイン名を確認し、同じネットワークで他のWebサイトにアクセスできるか試してから、直結とプロキシ経由の更新結果を比べます。購読ドメインの問題を解決するために、ノードのUUIDを変更しないでください。
エラー：Connection refused
原因：接続先が接続を明示的に拒否しています。ローカルプロキシが待ち受けていない場合や、リモートサーバーのポートが開いていない場合があります。
対処：ログを確認し、拒否された接続先がローカルのループバックアドレスか購読サイトかを切り分けます。ローカルプロキシの場合はコアを起動してポートを確認し、リモートの場合は提供元にサービスの状態を確認してください。
エラー：certificate has expired
原因：証明書の有効期間の確認に失敗しています。リモート側の証明書切れのほか、PCの日付が大きくずれている可能性もあります。
対処：まずシステム時刻を正しく設定してから再試行します。それでも失敗する場合は、証明書の修正を提供元に依頼してください。証明書の検証は無効にしないでください。
エラー：Invalid length for a Base-64 char array or string.
原因：デコーダーに渡されたテキストが要件を満たしていません。内容の欠落、Webページの取得、インポート形式の不一致などがよくある原因です。
対処：購読URLをコピーし直し、応答がログインページでないことを確認して、クライアントに適した形式を選びます。末尾に等号を追加すれば必ず直る、というわけではありません。
HTTP 429は通常、リクエスト頻度が制限されていることを示します。更新ボタンを連続して押さないでください。応答に Retry-After が含まれている場合は、その指定に従って待ちます。HTTP 403もサブスクリプションの期限切れとは限りません。接続元のネットワーク、クライアントのリクエスト内容、アクセス方針が関係している場合もあるため、提供元にリクエスト記録を確認してもらいましょう。
システム時刻とクライアントの状態：必要な範囲だけ修正する
時刻のずれがまず影響するのはHTTPS証明書の検証であり、Base64の構文ではありません。時刻が原因で正しい応答を取得できなかった場合に限り、その後の更新や解析の失敗として現れることがあります。段階を分けて考えれば、「解析失敗」という表示だけを見てノードの設定を誤って変更せずに済みます。
- 時刻を同期：Windowsでは「設定」→「時刻と言語」→「日付と時刻」を開き、時刻の自動設定を確認して同期します。Androidではシステム設定の「日付と時刻」で自動設定を確認してください。メーカーによってメニューの場所は異なります。実際の日付と時刻を確認することが重要です。タイムゾーンを変更するだけでは、システム時計のずれは修正できません。
- バージョンを記録：クライアントと現在使用中のコア、それぞれのバージョンを記録します。サブスクリプションのインポートとコアによる接続は別の処理のため、片方のバージョンだけでは問題を再現しにくくなります。
- 個別に検証：元のグループを残したままテスト用グループを作成し、同じ登録元から更新します。テスト用グループで正常に更新できる場合は、元のグループの有効状態、URL、フィルター条件、一覧の表示範囲を確認してください。
- 設定の書き込みを確認：ログにノードを検出したと表示されても一覧が変わらない場合は、別のグループを選択していないか、設定フォルダーに書き込みできるか確認します。Windowsでは、保護されたフォルダーや別のプロセスが使用中のファイルが保存を妨げることがあります。
- 必要に応じて更新：形式の互換性に問題があると確認できたら、設定をバックアップしてからクライアントと対応コンポーネントを更新します。互換性のない古いフォルダーに新しいコアのファイルを直接混在させないでください。
更新に成功したら、ノードへの接続も確認してください。サブスクリプションに「12件のノードを正常にインポート」と表示されても、それは一覧の解析と登録が完了したことを示すだけです。この件数例は、ノードが実際に使えることを保証するものではありません。接続に失敗する場合は、サブスクリプションのエンコードではなく、コアのログ、サーバーアドレス、ポート、トランスポートのパラメーターを確認してください。
よくある質問と問い合わせ時のチェック項目
ブラウザーでは購読URLを開けるのに、クライアントでは失敗するのはなぜですか？
まず、ブラウザーにノード情報が表示されているのか、アカウントページが表示されているのか確認します。次に、クライアントの直結とプロキシ経由の更新結果を比べてください。ブラウザーとはログイン状態やプロキシ経路が異なることがあります。ブラウザーでファイルをダウンロードできた場合も、その形式が使用中のクライアントに対応しているか確認が必要です。
更新後に一覧が空になりました。すべてのノードが使えなくなったのでしょうか？
まず検索条件を解除し、選択中のグループとフィルター規則を確認してから、更新結果でノードが検出されたか確認します。応答が空、形式が非対応、一覧がフィルターされているなどの理由で空になることがあります。これだけでサーバー側のノードがすべて使えなくなったとは判断できません。
スマートフォンでは更新できるのに、PCではできません。サブスクリプションを買い直す必要がありますか？
まず、両方の端末で同じ有効な購読URLを使っているか確認し、ネットワーク、更新経路、システム時刻、クライアントが対応する形式を比べます。提供元がクライアントごとに異なる内容を返す場合もあります。一方で更新に成功しても、もう一方が同じ本文を取得した証明にはならず、原因の範囲を絞り込めるだけです。
証明書の検証を無効にして使ってもよいですか？
サブスクリプション更新の対処として、証明書検証を無効にするのは避けてください。まず時刻を同期し、ネットワーク上のHTTPS検査や認証ページの有無を調べたうえで、証明書チェーンや有効期間の問題を提供元に修正してもらいましょう。購読URLには認証情報が含まれるため、通信相手の認証は特に重要です。
原因を特定できない場合は、単に「使えない」と伝えるのではなく、具体的な失敗リクエストをもとに問い合わせます。以下の情報があれば、次に確認すべき内容を判断しやすくなります。機密情報は、提供元が指定する安全な連絡手段だけで送ってください。
- 環境：OS、クライアントのバージョン、現在使用中のコアの種類とバージョン。
- 発生範囲：失敗するのは1つのグループか、すべてのグループか。既存ノードには接続できるか。
- 比較結果：直結とプロキシ経由での更新結果、ネットワークを切り替えたときに変化するか。
- 応答：発生時刻、HTTPステータスコード、最初に表示されたエラーの原文、本文がWebページかサブスクリプションのテキストか。
- 情報のマスキング：購読URL全体、アクセストークン、ノードのパスワードや識別情報を削除し、設定フォルダー一式は送らないでください。