サブスクリプションを追加済みで、更新のタイムアウト、空のリスト、定期更新が反映されないといった問題が起きているv2rayNユーザー向けです。まず手動で一度更新し、URL・通信経路・コンテンツのどこに問題があるかを切り分けます。その後、サブスクリプショングループの更新間隔を設定しましょう。何度も再試行したり、すべてのノードを削除したりしても原因の特定にはなりません。
サブスクリプション更新の流れ：ダウンロード成功とインポート成功は別
サブスクリプションURLは通常、アクセストークン付きのHTTPSリンクです。v2rayNがURLにリクエストを送り、テキストを取得して、対応するノード情報をクライアント設定に変換します。サブスクリプション自体はプロキシプロトコルではありません。1つのサブスクリプションにVMessやVLESSなど複数のプロトコルのノードが含まれる場合があります。また、URLにアクセスできても、各ノードの接続が保証されるわけではありません。
切り分けでは、結果を3種類に分けて考えます。応答がない、エラー応答が返る、内容は取得できたがノードを解析できない、の3つです。最初の2つはURLとネットワークを、3つ目は形式を確認します。メイン画面のノード接続ログとサブスクリプションのダウンロード通知は別のものです。コアの接続エラーだけを見て、サブスクリプションサーバーの障害と判断しないでください。
- 記録する情報：問題のあるグループだけを更新し、時刻・リクエスト方法・ステータスコード・エラー全文を記録します。
- 使える項目を残す：現在接続できるノードを記録し、原因を調べている間はサブスクリプショングループをすべて削除しないでください。
- URLを保護する：ログを共有する際は、トークン・ユーザー識別情報・URLのクエリパラメーターを隠してください。サブスクリプションURL全体から設定を取得されるおそれがあります。
リンク切れ：認証エラーとサーバーのアクセス制限を見分ける
サブスクリプショントークンの再発行、プランの期限切れ、アカウントの停止などにより、以前のURLからノードを取得できなくなることがあります。URLをコピーする際に末尾のパラメーターが欠けたり、サブスクリプションURLではなくWebページのURLを使ったりした場合も、同様の問題が起こります。サービス提供元のアカウントページからv2rayN用の最新URLをコピーし、グループに登録されているURLと照合してください。チャット履歴から同じ古いURLを何度も貼り直すのは避けましょう。
これらはHTTPステータスコードの一般的な意味であり、アカウント状態を断定できるものではありません。サーバーが403をアクセス制限に使う場合もあれば、200を返しながらエラーメッセージを表示する場合もあります。ステータスコードだけでなく、応答本文とアカウントへの通知も確認してください。
エラー：401 Unauthorized
原因：サーバー認証に失敗しています。古いトークンや、コピーが不完全なURLでよく発生します。対処：アカウントページから最新のサブスクリプションURLを取得し、該当グループのURLを置き換えて、手動更新を一度だけ実行します。
エラー：403 Forbidden
原因：サーバーが現在のリクエストを拒否しています。アカウント権限、接続元IPアドレス、アクセス方針などが関係している可能性があります。対処：アカウント状態とサービス提供元のお知らせを確認してください。他の条件に問題がなければ、直結とプロキシ経由で結果を比較します。
エラー：429 Too Many Requests
原因：同じアカウントまたは接続元からのリクエストが、サーバーの頻度制限を超えています。対処：更新ボタンを連続して押すのをやめてください。応答に Retry-After が含まれる場合は、指定された時間だけ待ってから自動更新間隔を長くします。
ネットワーク障害：直結とプロキシ経由を個別に確認する
v2rayNのサブスクリプションメニューには通常、「プロキシを使わずに更新」と「プロキシ経由で更新」の2種類があります。バージョンによって「現在のサブスクリプションを更新」「すべてのサブスクリプションを更新」など表示が異なる場合があります。切り分けでは現在のグループを選び、大量のリクエストを同時に送らないようにしてください。ここで選ぶのはサブスクリプション取得時の通信経路であり、インポート後の全ノードに恒久的な接続先を指定するものではありません。
| 結果 | まず確認すること | 次の対応 |
|---|---|---|
| 直結は成功、プロキシ経由は失敗 | 現在のプロキシ出口またはローカルプロキシが利用できない | まずプロキシを使わずに更新し、その後ノード接続を個別に確認する |
| 直結は失敗、プロキシ経由は成功 | ローカルネットワークからサブスクリプションサイトへの経路に問題がある | 使えるノードを残し、プロキシ経由で更新する |
| どちらもタイムアウト | URL・名前解決・サービス状態、または両方の通信経路に問題がある | ドメイン名・システム時刻・サービスのお知らせを確認し、別のネットワークでも試す |
| どちらも同じ認証エラーが返る | アカウントまたはURLに問題がある可能性が高い | URLを再取得し、プロキシ設定を何度も切り替えない |
ドメイン名を解決できない場合は、サブスクリプションのホスト名に誤りがないか確認し、システムのDNS設定とネットワークを調べてください。HTTPS証明書のエラーが出た場合は、端末の日付・タイムゾーン・システムの信頼済み証明書を確認します。証明書検証を無効にして回避するのは避けてください。接続タイムアウトは、制限時間内にリクエストが完了しなかったことを示すだけで、DNSの問題とは限りません。
プロキシの依存ループ：更新に必要なノードがすでに使えない
よくある依存ループは、サブスクリプションサイトへのアクセスにプロキシが必要なのに、現在のプロキシノードが使えず、利用可能なノードを取得するにはサブスクリプションの更新が必要、という状態です。このとき「プロキシ経由で更新」を繰り返しても、同じ使えない出口を経由します。これは更新に必要な通信経路が行き詰まった状態であり、必ずしもパケットレベルのルーティングループを意味しません。
-
現在のノードを確認する
メイン画面で現在選択中のサーバーを確認し、実際に接続できるかを先にテストします。遅延の数値が表示されるだけでは不十分です。接続先にアクセスできることまで確認しないと、サブスクリプションを取得できるとは限りません。
-
直結で更新を試す
「サブスクリプショングループ」メニューで、現在のグループに対してプロキシを使わずに更新します。成功したら新しい項目をテストしてから、使用するサーバーを切り替えてください。
-
利用可能な出口を確保する
直結でアクセスできない場合は、以前保存した利用可能なノードに切り替えるか、サブスクリプションサイトにアクセスできるネットワークに変更してから、プロキシ経由で更新します。
-
ローカルの待ち受け設定を確認する
「設定」→「パラメーター設定」を開き、ローカルプロキシの待ち受け設定と動作状態を確認します。ブラウザーでプロキシポートを手動指定している場合は、現在の設定と一致させてください。他の端末のポート番号をそのまま使わないでください。
結論：まず利用可能な通信経路を確保する
サブスクリプションURL、プロキシノード、ネットワーク経路は一度に一つだけ変更してください。使える出口がない状態で自動更新間隔を短くしても、失敗するリクエストが増えるだけです。手動更新が成功してから定期更新を有効にしましょう。
形式エラー：200の応答でもノードが含まれるとは限らない
サブスクリプションサーバーが 200 OK を返すのは、HTTPリクエストが成功したことを示すだけです。本文はログインページ、アクセス確認ページ、プランの期限切れ通知、または実際のサブスクリプションテキストかもしれません。v2rayNが解析できるのは、対応するノード形式やサブスクリプション形式です。ダウンロードできるファイルなら何でも読み込めるわけではありません。
- HTMLが返された：本文が
<!DOCTYPE html>または<htmlで始まる場合は、WebページのURL、ログインページ、アクセス確認ページを取得していないか確認してください。 - 本文が空：アカウントで利用できるノードが残っているか、サブスクリプションが無効になっていないかを確認し、サーバーのメンテナンス告知も確認してください。
- 形式が合わない：サービス提供元がv2rayN対応と明記しているサブスクリプションURLを選んでください。他のクライアント専用の設定を、汎用のノードサブスクリプションとして直接読み込まないでください。
- 一部の項目だけ失敗する：現在のクライアントとコアが、該当するプロトコルや通信パラメーターに対応しているか確認してください。VLESSの項目にREALITYなどのパラメーターが含まれる場合は、それに対応したコアも必要です。
Base64はテキストのエンコード方式であり、暗号化ではありません。また、エンコードされた内容が有効であることも保証しません。手動でデコードすると構造の確認には役立ちますが、期限切れのトークンや未対応のパラメーターは修復できません。サブスクリプション全体を不明なオンライン変換サイトに送信しないでください。サービス提供元に問い合わせる場合は、エラー文と内容の種類を示す情報を、機密部分を隠して伝えましょう。
v2rayNの自動更新間隔：サブスクリプショングループごとに設定
自動更新の間隔は通常、全グループ共通の固定周期ではなく、サブスクリプショングループごとに保存されます。ここでは「自動更新間隔（分）」という項目がある画面を例に説明します。デスクトップ版や画面のバージョンによって句読点やボタンの位置が異なる場合があるため、項目の横に表示される単位を確認してください。スケジュールを設定する前に一度手動更新すると、定期実行の問題とダウンロードの問題を切り分けやすくなります。
-
グループ設定を開く
メイン画面の「サブスクリプショングループ」→「サブスクリプショングループ設定」を開き、変更するグループを選んで編集します。メモとサブスクリプションURLを確認し、名前が似た別のグループを変更しないようにしてください。
-
更新間隔を入力する
「自動更新間隔（分）」を探し、正の整数を入力します。たとえば
720は12時間、1440は24時間です。これは設定例であり、クライアントの既定値ではありません。サービス提供元が最短間隔を指定している場合は、その条件を優先してください。 -
保存して確認する
「OK」または保存ボタンをクリックし、グループを開き直して入力した値が保存されていることを確認します。次に、そのグループを手動更新して、URLと現在の通信経路が機能することを確認してください。
-
次回以降の結果を確認する
クライアントを起動したまま設定した周期が経過するのを待ち、更新通知またはログの時刻を確認します。現在の画面に自動更新時のプロキシ設定がある場合は、成功を確認できた経路を選んでください。定期更新が直近の手動更新方法を必ず引き継ぐとは限りません。
一般的な実装では、間隔を 0 にすると定期更新は無効になります。操作前に、使用中のバージョンの項目説明も確認してください。パソコンの電源が切れている、スリープ中、またはクライアントが終了している間は、クライアント内の更新処理は実行されません。起動後にすぐ更新されるかどうかもバージョンの実装によるため、OSのスケジュール機能と同じものとして扱わないでください。
| 利用状況 | 間隔の例 | 設定の考え方 |
|---|---|---|
| ノードの変更が少ない | 1440分（24時間） | 不要なリクエストを減らし、臨時の変更は手動で更新する |
| できるだけ早く同期したい | 720分（12時間） | サービス提供元が許可する範囲で更新頻度を上げる |
| 更新の問題を調査中 | 定期更新を一時的に無効にする | ログの混在やアクセス制限を避けるため、手動テストは一度に1回だけ実行する |
保存後も自動更新されない場合は、正しいグループを編集したか、間隔が正の数か、クライアントが起動し続けているか、ログ上で更新処理は実行されたもののダウンロードに失敗していないかを確認してください。テストのために間隔を1分にして、そのまま使い続けないでください。同じサブスクリプションを複数の端末で使うと、リクエスト頻度がサーバー側で合算される場合もあります。
更新復旧後の確認：ノード・通信経路・更新間隔
更新成功の通知は復旧の第一歩にすぎません。サブスクリプション更新は設定を同期しますが、ノードが使えるかどうかは別途テストが必要です。また、ルーティングはその後の通信経路を決めるもので、更新に成功しただけで意図した動作になるわけではありません。復旧後は必要最低限の確認を行い、調査中に加えた一時的な変更を元に戻しましょう。
- グループを確認：対象グループに想定した項目が追加され、別グループのノードを更新結果と取り違えていないことを確認します。
- 接続を確認：新しいノードを選び、実際の接続テストを行ってから、ブラウザーで目的のサイトにアクセスします。
- プロキシを確認：システムプロキシ、または実際に使用する通信の取り込み方法を確認します。ノードが正常でも、アプリの通信がプロキシを通っていない場合があります。
- 更新間隔を確認：テスト用に設定した間隔を予定の値に戻し、次回の更新に使える接続を少なくとも1つ確保します。
引き続き原因を調べる場合は、サイト内のトラブルシューティングにあるネットワークとプロキシの確認方法をご覧ください。サービス提供元へ問い合わせる際は、発生時刻・HTTPステータスまたはエラー文・直結とプロキシ経由の比較結果を伝え、サブスクリプショントークン全体は送らないでください。