v2rayNのサブスクリプション更新に失敗する原因と対処法｜リンク切れ・証明書エラー・自動更新設定

1. サブスクリプション更新に失敗したら、まず停止箇所を確認

サブスクリプションの更新とは、クライアントがURLにリクエストを送り、内容をダウンロードしてノード一覧に変換する処理です。VMessやVLESSノードへの接続テストでも、Xrayコアの更新でもありません。既存ノードで接続できても、そのノードへの通信経路が使えることを示すだけで、サブスクリプションサーバーに現在アクセスできるとは限りません。

メイン画面の情報またはログ欄を開き、まず1つのグループだけ更新してください。エラーが発生した時刻、選んだ更新方法、エラー前後のログを記録します。DNSの変更、ノードの切り替え、サブスクリプションURLの変更を同時に行うと、復旧しても何が有効だったのか判断できません。以下はエラーの段階を見分けるための例です。実際の表示は実行環境やクライアントのバージョンによって異なります。

2. URL切れとHTTPステータスコードを確認：サブスクリプショングループの設定

「サブスクリプショングループ」→「サブスクリプショングループの設定」を開き、失敗したグループのURLを確認します。画面によってはグループをダブルクリックするか、編集ボタンから開きます。どちらの場合も、対象グループのURL欄を確認してください。サービス提供元が案内する完全なサブスクリプションURLを使い、アカウントのログインページ、プランの案内ページ、ブラウザーのアドレス欄に表示された管理画面のURLは使わないでください。

1. URLをコピーし直す：パスとクエリパラメーターを含めて保持し、前後の空白や改行、チャットアプリが付加した句読点がないか確認します。ランダムな文字列に見えるトークンも削除しないでください。
2. アカウントの状態を確認する：プランの期限、サブスクリプショントークンの再発行、サービス提供元によるドメイン移行の有無を確認します。クライアントを再起動しても、古いURLは有効になりません。
3. 対象のグループだけを編集する：元のURLを記録してから置き換えて保存し、そのグループを手動で更新します。既存のノードは削除しないでください。
4. URLと形式を区別する：リクエストが成功してもノードが表示されない場合は、管理画面でv2rayNに対応したサブスクリプション形式が提供されているか確認します。任意の設定ファイルをノード用サブスクリプションとして使えるわけではありません。

サブスクリプションURLにはアカウントのトークンが含まれることがあるため、パスワードと同じように扱ってください。公開フォーラムや見知らぬオンライン変換サイトに貼り付けないでください。ログを共有する場合は、URL全体、クエリパラメーター、ノードの認証情報を伏せます。応答内容を確認する場合もローカル環境で行い、ブラウザーに表示された個人用サブスクリプションの画面を公開しないでください。

3. ネットワークのタイムアウト：直接接続とプロキシ経由の更新を比較

ブラウザーでサービス提供元のトップページを開けても、サブスクリプションURLにアクセスできるとは限りません。トップページとサブスクリプションAPIでドメインやアクセス制限が異なることがあり、ブラウザーだけ別のプロキシを使っている場合もあります。v2rayNのサブスクリプション更新でプロキシを使うかどうかは、更新操作のオプションで確認してください。システムプロキシの設定だけでは判断できません。

1. まずプロキシを使わずに試す：「サブスクリプショングループ」メニューから、該当する「プロキシを使わずに更新」を選び、現在のグループだけ更新します。タイムアウト、名前解決の失敗、HTTPステータスコードのどれが発生するか記録してください。
2. プロキシノードが使えることを確認する：残しておいたノードから、実際にインターネットへ接続できるものを選び、コアが起動していることを確認します。ノードが一覧にある、またはテスト結果が表示されるだけでは、サブスクリプションのリクエストが成功するとは限りません。
3. 次にプロキシ経由で試す：「プロキシ経由」と表示されたサブスクリプション更新を選び、同じURLで結果を比較します。バージョンによって更新方法の選択肢が更新メニューにまとめられていることがあるため、実際の画面表示に従ってください。
4. ネットワーク条件を切り分ける：どちらの方法でも失敗する場合は、許可されている範囲で別のネットワークに切り替えて試します。ルーティングとDNSを同時に変更せず、条件を一つずつ切り替えてください。

ローカルポートも実際の設定を確認してください。たとえば、ローカルのプロキシ待ち受けポートが10808に設定されていて、別のプログラムが10809を参照している場合、接続先は一致していません。これはポート不一致の例であり、特定の既定値に統一する指示ではありません。「設定」→「パラメーター設定」でローカルの待ち受けに関する項目を確認し、ログでポートの待ち受けが正常に開始しているか調べます。ポートの競合やコアの終了も、プロキシ経由の更新に失敗する原因になります。

• 直接接続は失敗し、プロキシ経由は成功する：使えるノードを残し、以後はプロキシ経由で更新します。サブスクリプショングループの自動更新で使われる更新方法も確認してください。
• 直接接続は成功し、プロキシ経由は失敗する：現在のノード、プロキシポート、接続元の制限を確認します。サブスクリプションURLを急いで変更する必要はありません。
• どちらもタイムアウトする：サブスクリプションのドメイン、サービスの稼働状況、現在のネットワークを確認してから、DNSの変更を検討します。
• どちらも同じ認証エラーになる：プロキシノードを何度も切り替えるのではなく、アカウントまたはトークンの状態を優先して確認してください。

4. 証明書エラー：時刻を合わせてTLSの信頼チェーンを確認

HTTPSのサブスクリプションでは、サーバー証明書が検証されます。システムの日付や時刻がずれていると、正常な証明書でも「有効期間前」や「期限切れ」と判定されることがあります。サーバー証明書の期限切れ、ドメイン名の不一致、証明書チェーンの不足も接続を妨げます。ブラウザーとクライアントでは信頼環境が異なる場合があるため、ブラウザーで開けても、クライアントのログを確認する必要があります。

1. システム時刻を確認する：Windowsの場合、「設定」→「時刻と言語」→「日付と時刻」を開き、タイムゾーンと時刻の自動設定を確認してから「今すぐ同期」を実行します。その後、サブスクリプションをもう一度更新してください。
2. サブスクリプションのドメインを確認する：HTTPSのURLに含まれるドメインを、手動でIPアドレスに置き換えないでください。証明書は通常ドメイン名に対して発行されるため、IPアドレスに変えると名前が一致しないことがあります。
3. ネットワーク認証を確認する：公衆ネットワークでログインが必要な場合は、先に認証を済ませてください。認証ページへリダイレクトされたリクエストが、証明書エラーやHTMLページの応答として現れることがあります。
4. 組織ネットワークのポリシーを確認する：管理対象の端末では、組織の証明書によってHTTPSを検査している場合があります。信頼設定について管理者に確認し、入手元が不明なルート証明書はインストールしないでください。
5. サーバー側の問題を確認する：端末の時刻が正しく、別のネットワークでも同じ証明書エラーが発生する場合は、エラーの詳細と発生時刻をサービス提供元に伝えてください。

ノード設定の「証明書の検証をスキップ」は、該当ノードへの接続に関する設定であり、HTTPSのサブスクリプション取得を直す汎用オプションではありません。サブスクリプションURLをHTTPに変更すると通信の保護も失われるため、恒久的な対処として使わないでください。正しい確認順は、時刻、ドメイン、信頼チェーンです。最後にサーバー側で証明書を修正します。

5. 自動更新の間隔とプロキシ設定

手動更新に成功してから、自動更新を設定します。「サブスクリプショングループ」→「サブスクリプショングループの設定」を開き、対象グループを編集して、自動更新間隔と、そのバージョンにあるプロキシ経由の更新オプションを確認してください。項目の場所や単位、自動更新の仕組みはバージョンによって異なる場合があります。一度手動で「プロキシ経由の更新」に成功しても、自動更新でも同じ方法が使われるとは限りません。

• 単位を確認してから数値を入力する：単位が分の場合、6時間は360です。単位が時間の場合は6と入力します。これは換算例です。実際の間隔はサービス提供元の案内に従ってください。
• 無効になる条件を確認する：0を「継続的に更新する」という意味だと決めつけないでください。無効を表すかどうかは項目の説明で確認します。自動更新を有効にするには、画面で受け付けられる正の数を設定してください。
• プロキシの設定を確認する：グループの編集画面に「プロキシ経由で更新」がある場合は、成功を確認した方法を選んで保存します。そのバージョンに更新メニューの選択肢しかない場合は、自動更新の実際の設定とログを確認し、メニューをクリックした結果だけで判断しないでください。
• 保存後に実行されるか確認する：保存した時刻を記録し、クライアントを起動した状態でネットワークが使えるときに、その後のログを確認します。クライアントを終了している間や端末がスリープしている間に、デスクトップアプリが通常どおりタスクを実行することは期待できません。
• 再試行の頻度を抑える：429や明確な頻度制限が表示されたら、連続して再試行するのをやめてください。複数の端末で同じサブスクリプションを使っている場合は、リクエストが重なることも考慮します。

手動更新は安定して成功するのに自動更新のログが出ない場合は、正しいグループを編集したか、間隔が保存されているか、プログラムが起動したままかを確認してから、タスクの設定を調べます。自動タスクがリクエストを送信して失敗している場合は、ログに記録されたネットワーク方式で再テストしてください。「実行されていない」と「実行後に失敗した」を混同しないようにします。

6. よくある質問と復旧後の確認

復旧後は、サブスクリプションを取得して解析できることと、選択したノードに正常に接続できることをそれぞれ確認してください。前者はサブスクリプション管理、後者はノード設定、コア、システムプロキシ、ルーティングに関わります。どちらかに問題が残る場合は、トラブルシューティングを参照してください。接続先とルーティングの関係を整理するには、設定ガイドをご覧ください。

• ログで対象グループの更新完了を確認でき、ダウンロードや解析のエラーが残っていない。
• グループに想定したノードが残っており、フィルター条件と配布元が一致している。
• 実際に接続でき、自動更新の方法と間隔が保存されている。
• 共有するスクリーンショットやログから、サブスクリプショントークンとノードの認証情報を隠している。