v2rayNのサブスクリプション更新に失敗したら、まず「サーバーにリクエストが届いていない」「サーバーに拒否された」「取得した内容をインポートできない」のどれに当たるかを切り分けましょう。サブスクリプションを追加済みのデスクトップユーザー向けに、ログ、URL、証明書、プロキシ経由の通信、自動更新設定を順に確認する方法を解説します。既存のノードは残したまま、条件を変えて比較してください。
1. 更新の仕組みを把握し、失敗箇所を特定する
サブスクリプションの更新とは、クライアントがURLにリクエストを送り、応答を取得してノード一覧を解析する処理です。ノードへの接続テストとは異なります。以前のノードが使えるのは、保存済みの設定で接続できているということにすぎず、サブスクリプションURLが有効とは限りません。また、ダウンロードに成功しても、すべてのノードが使えるとは限りません。
メイン画面でログまたは情報出力欄を開き、サブスクリプショングループを1つだけ更新して、そのリクエストに対応するエラーを記録します。すべてのグループを一度に更新すると、複数URLのタイムアウト、証明書、解析に関する情報が混在しやすくなります。「更新失敗」とだけ表示される場合は、最後の行だけで判断せず、前後の例外情報も確認してください。
- クライアントの「バージョン情報」画面で、完全なバージョン番号、OS、失敗した時刻を記録し、該当する画面や手順を確認できるようにします。
- 古いノードと現在のグループ設定は残します。サーバーをすべて削除したり、アプリを何度もリセットしたりしないでください。
- 今回の更新がプロキシ経由だったかを記録します。各テストで変更する条件は1つにして、ログを比較してください。
- スクリーンショットを共有するときは、サブスクリプションURL全体、クエリパラメーター、アカウント情報、ノードの認証情報を隠してください。
2. URL切れやHTTPステータスコードを確認する
「サブスクリプショングループ」→「サブスクリプショングループの設定」を開き、失敗したグループを編集してURLを確認します。デスクトップ版によってメニュー名が多少異なる場合があります。URLと自動更新の設定があるグループ編集画面を探してください。URLにはサービス提供元が案内するサブスクリプション用のものを使います。アカウントのログインページ、注文ページ、ノード紹介ページでは代用できません。
| 応答内容 | まず確認すること | 次の対処 |
|---|---|---|
401 Unauthorized | アクセス情報が無効、または認証情報が不足 | アカウントページから現在のサブスクリプションURLを取得し、トークンがリセットされていないか確認します。 |
403 Forbidden | アクセス制限、アカウントの状態、またはリクエストの遮断 | アカウントの状態とサービス提供元の案内を確認します。403だけを根拠に、サブスクリプションの期限切れと決めつけないでください。 |
404 Not Found | URLのパスが誤っている、または古い接続先が廃止されている | URL全体をコピーし直し、パスやクエリパラメーターが欠けていないか確認します。 |
429 Too Many Requests | 更新頻度が高く、レート制限に達している | 連続した再試行をやめ、サービス提供元の案内または応答に記載された再試行時刻まで待ちます。 |
5xx | サブスクリプションサービスまたは上流側で障害が発生している | しばらくしてから再試行し、ステータスコードと発生時刻をサービス提供元に伝えます。 |
200 OKなのにインポートできない | 応答の内容形式が合っていない | 返された内容がクライアントで認識できるサブスクリプション形式か確認します。ログイン画面や認証ページが返されている場合もあります。 |
URLをコピーし直すときは、前後の空白や改行、途中で欠けたクエリパラメーターがないか確認してください。疑問符以降を勝手に削除したり、エラーを避けるためにHTTPSをHTTPに変更したりしないでください。サービス提供元がサブスクリプションをリセットした直後は、古いURLが使えなくなっていても、以前のノードにはしばらく接続できることがあります。矛盾ではありません。
判断のポイント:ステータスコードに応じて応答の問題を切り分ける
401、404、429が表示されたら、まずURL、認証、更新頻度を確認します。ノードのプロトコルを変更しても、これらの応答は解決しません。同じURLでも直結とプロキシ経由で結果が異なる場合に限り、リクエスト経路を比較してください。
3. 証明書エラー:時刻、信頼チェーン、ネットワークの遮断を確認する
サブスクリプションURLがHTTPSの場合、クライアントはサーバー証明書を検証します。この処理は通常、サブスクリプションの解析より先に行われます。そのため、証明書エラーをVMess、VLESS、Trojanノードの設定変更で解決しようとしないでください。以下はエラー詳細に表示されることがある英語の文言です。具体的な表示はシステムや実行環境によって異なります。
エラー:The SSL connection could not be established
原因と対処:TLS接続に失敗したことを示す概要で、証明書の期限切れだけを意味するものではありません。詳細な例外を開き、まずシステム時刻を確認してから、信頼チェーン、名前の一致、ハンドシェイクの中断を切り分けます。
エラー:RemoteCertificateNameMismatch
原因と対処:接続先のホスト名と証明書に記載された名前が一致していません。サービス提供元が案内した元のドメイン名に戻し、名前解決で得たIPアドレスに置き換えないでください。別のサイトへリダイレクトされていないかも確認します。
エラー:RemoteCertificateChainErrors
原因と対処:証明書チェーンの検証に失敗しています。有効期間、中間証明書の不足、信頼されていない発行元などが原因として考えられます。システム時刻とOSの更新状態を確認してください。正常な複数のネットワークでも失敗する場合は、サービス提供元にエラーを伝え、証明書の設定を確認してもらいます。
- Windows:「設定」→「時刻と言語」→「日付と時刻」を開き、日付、タイムゾーン、時刻の同期状態を確認します。
- macOS:「システム設定」→「一般」→「日付と時刻」を開き、時刻の自動設定が有効か確認します。
- 管理対象ネットワーク:ネットワークでHTTPS検査が行われている場合は、管理者に信頼設定を確認してもらってください。出所不明のルート証明書はインストールしないでください。
- 公衆ネットワーク:ネットワークのログイン認証を済ませてからサブスクリプションを更新します。Web認証が必要なネットワークでは、通常のHTTPSリクエストが遮断される場合があります。
ブラウザーでURLを開けることは、あくまで参考情報です。ブラウザーとクライアントでは、プロキシ経路、キャッシュ、証明書の処理方法が異なることがあります。ブラウザーで一時的に証明書警告を無視しても解決にはなりません。証明書の検証を無効にする設定も、サブスクリプション更新の標準的な対処法として使わないでください。
4. タイムアウトやネットワーク接続エラー:直結とプロキシ経由を比較する
リクエストのタイムアウトは、制限時間内に処理が完了しなかったことを示し、URLが無効になったとは限りません。ドメイン名の名前解決失敗、接続の遮断、プロキシコアの未起動、サーバーの応答遅延なども、画面上では更新失敗として表示されることがあります。同じグループを直結とプロキシ経由で別々にテストし、DNS、ルーティング、ポートを同時に変更しないでください。
- プロキシを使わずに更新:「サブスクリプショングループ」メニューから、対象グループの「プロキシを使用せずに更新」を選び、結果とエラー発生時刻を記録します。
- プロキシが使えるか確認:接続できる既存ノードを選び、コアが正常に起動していることを確認してから、実際にWebページを開いて動作を確認します。TCP遅延の数値だけでは、プロキシ経路全体が使える証拠になりません。
- プロキシ経由で更新:同じメニューから「プロキシ経由で更新」を選び、同じグループを更新します。画面によっては操作がサブメニューにまとめられています。「プロキシ経由」か「プロキシを使用しない」かで区別してください。
- 結果を比較:直結では失敗し、プロキシ経由では成功する場合は、直結時のネットワーク経路を確認します。プロキシ経由では失敗し、直結では成功する場合は、選択中のノード、ローカルの待ち受け、関連するルーティング設定を確認してください。
システムプロキシの設定は、システムのプロキシ設定に従うアプリの通信経路を決めます。一方、サブスクリプションメニューの更新方法は、そのリクエストに使う経路を選択します。別々の設定なので、ブラウザーがプロキシを使っているかだけで、クライアント内部のサブスクリプション取得経路を判断することはできません。
ローカル接続が拒否される場合は、「設定」→「パラメーター設定」で待ち受けの設定を確認します。たとえば、実際のプロキシ入口が127.0.0.1:10808の場合、プロキシを手動指定するソフトで、無効になった10809を使い続けることはできません。ポート番号は確認用の例であり、すべてのバージョンの既定値ではありません。また、入口がHTTP、SOCKS、混合プロキシのどれを受け付けるかも確認してください。
5. 更新に成功してもノードが表示されない:応答形式とグループ設定を確認する
サーバーが成功応答を返しても、クライアントが内容を解析できない場合があります。アカウントのログインHTML、Web認証画面、空の応答、別の設定方式のファイルなどがよくある例です。ブラウザーでサブスクリプションURLを開いてテキストが表示されても、それがv2rayNで読み込めるノード一覧とは限りません。
- 取得元を確認:WebページのURLではなく、対象クライアント用のサブスクリプションURLをコピーしたか確認します。サブスクリプションを見知らぬオンライン変換ツールにアップロードしないでください。
- エラーの種類を確認:「リクエスト失敗」と「有効なサーバーが見つからない」などの解析結果を区別します。後者の場合は、応答内容とクライアントが対応する形式を確認してください。
- 表示範囲を確認:メイン画面で別のグループが選択されていないか確認し、検索条件をクリアして、グループ内のノード絞り込み設定も確認します。
- クライアントの互換性を確認:現在のバージョン番号を記録し、サービス提供元が指定するサブスクリプション形式と照合します。アップグレード前に設定をバックアップし、形式の確認をせずにコアを何度も切り替えるのは避けてください。
v2rayNはデスクトップクライアントで、V2RayとXrayはプロキシコアに関連するプロジェクトです。サブスクリプションの取得と解析は通常クライアント側で処理されます。ログでノード設定やコアの起動失敗が示された場合に限り、コアの対応範囲を確認してください。コアを切り替えても、ログインページを返すサブスクリプションURLは修復できません。
6. 自動更新間隔:単位、保存状態、実行条件を確認する
手動更新が安定して成功してから、自動更新を設定します。「サブスクリプショングループ」→「サブスクリプショングループの設定」を開き、対象のグループを編集して、自動更新の間隔と利用可能な更新オプションを確認してください。バージョンによって項目の位置や単位、プロキシ更新の設定場所が異なるため、別バージョンの画面にある数値をそのまま入力しないでください。
- 単位を確認:6時間ごとに更新する場合、単位が時間なら
6、分なら360を入力します。これは設定例です。サービス提供元が定める更新頻度の制限を優先してください。 - 無効化の方法を確認:自動更新を止めるときは、画面のスイッチ、または項目の説明に記載された値を使います。確認せずに
0を「即時更新」または「無効」の意味だと決めつけないでください。 - 保存後に再確認:編集画面を閉じてから開き直し、間隔が保存されていることを確認します。メニューから一度だけ「プロキシ経由で更新」を実行しても、自動更新の経路が常に同じ設定に変更されたとは限りません。
- 実行条件を確認:自動更新には通常、クライアントが起動していてネットワークが使えることが必要です。PCがスリープ中、アプリが終了している、またはプロキシ出口が使えない場合、予定どおりに更新されるとは限りません。
- 次回のログを確認:次の予定時刻以降にリクエストの記録があるかを確認し、その後に解析が成功したかを確認します。ノード一覧に変化がないだけでは、自動更新が実行されなかったとは判断できません。
おすすめの手順:手動更新の成功を確認してから定期更新を再開
トラブルシューティング中は自動再試行による影響を減らし、直結とプロキシ経由で各1回ずつ更新した結果を残します。利用できる経路と応答形式を確認してから間隔を設定してください。429が返された場合は、更新間隔を短くして失敗分を取り戻そうとせず、まずレート制限に対処します。
7. サブスクリプション更新に関するよくある質問
古いノードは使えるのに、サブスクリプションが期限切れと表示されるのはなぜ?
ノード接続用の認証とサブスクリプションURL用の認証は、別々に管理されている場合があります。古いノードは残したままアカウントページを開き、サブスクリプションの状態と現在のURLを確認してください。トークンがリセットされていたら、対象グループのURLだけを更新して再試行します。
ブラウザーでは開けるのに、クライアントではタイムアウトするのはなぜ?
まず両者の通信経路が同じか確認してください。ブラウザーはシステムプロキシ経由でも、サブスクリプション更新はプロキシを使わない設定になっている場合があります。同じグループで両方の更新方法を試し、クライアントのログを比較します。
自動更新を設定したのに、翌日実行されていないのはなぜ?
クライアントが終了していないか、PCが長時間スリープ状態になっていなかったかを確認します。次にグループの設定を開き直し、保存された値と単位を確認してください。ログにリクエストがあるかも確認します。リクエストが失敗している場合は、ステータスコードや証明書情報をもとに調べてください。
ログを添えて問い合わせるとき、何を残せばよい?
クライアントのバージョン、OS、失敗時刻、ステータスコード、例外の種類、プロキシ経由かどうかを残してください。サブスクリプションURL全体と応答内のノード情報は隠します。URLが公開されてしまった場合は、サービス提供元のページでリセットしてから使い直してください。