登録済みのノードは残したまま、「リクエストが届くか」「URLが有効か」「応答を解析できるか」の順に確認しましょう。サブスクリプションを追加済みで、手動更新または定期更新に失敗するv2rayNユーザー向けの記事です。原因を切り分け、プロキシ経由で更新する必要があるか、自動更新間隔を調整すべきか判断できます。
サブスクリプション更新失敗時の対処手順
サブスクリプショングループを削除したり、接続できているノードを消去したりしないでください。サブスクリプションの更新は、クライアントがサーバーにリクエストを送り、ノード一覧を取得する処理です。一方、ノードへの接続は、コアがプロキシサーバーに接続する処理です。この2つは別の経路のため、ノードが使えてもサブスクリプションURLにアクセスできるとは限りません。更新に成功しても、すべてのノードが利用できるとは限りません。
v2rayNのメイン画面で「サブスクリプショングループ」→「サブスクリプショングループの設定」を開き、問題のあるグループを選択して、URLとグループ名を確認します。バージョンによってメニュー名が多少異なる場合があります。以下では画面上の位置ではなく、「サブスクリプショングループの設定」や更新メニューの機能名を目印にします。
- 情報を記録する：クライアントのバージョン、更新時刻、使用中のネットワーク、エラーメッセージを記録します。スクリーンショットを撮る場合は、URL内のパストークンとクエリパラメーターを隠してください。
- テストするグループは1つにする：まず問題のあるグループだけを更新します。複数のグループをまとめて更新するとログが混在し、別のグループの結果をテスト結果と取り違えるおそれがあります。
- 最初に発生したエラーを確認する：メイン画面の情報欄を確認してください。詳しいログが必要な場合は、「設定」→「パラメーター設定」でログ関連の項目を探します。最後に表示された「更新失敗」だけで判断しないでください。
- 変更は一度に1項目だけ：まず直接接続とプロキシ経由での更新結果を比較し、次にURLと形式を確認します。定期更新の設定を変えるのは最後にしてください。
ネットワークのタイムアウト：直接接続とプロキシ経由を比較
タイムアウトは、ドメイン名の解決、接続の確立、応答待ちのいずれかで発生します。タイムアウトだけでは、サブスクリプションURLが無効だとは判断できません。まず「サブスクリプショングループ」メニューから「現在のサブスクリプションを更新（プロキシを使用しない）」と「現在のサブスクリプションを更新（プロキシを使用）」をそれぞれ試します。バージョンによっては「選択したサブスクリプション」などの名称になっています。重要なのは、リクエストがどちらの経路を使うか明確にすることです。
エラー：The operation has timed out.
原因と対処：待機時間内にリクエストが完了しませんでした。まず信頼できる別のネットワークで再試行し、直接接続とプロキシ経由での更新結果を比較してください。短時間に何度も更新をクリックしないでください。
エラー：No such host is known.
原因と対処：サブスクリプションのドメイン名を解決できません。ドメイン名の入力ミスと、現在のネットワークでのDNS名前解決を確認してください。同じURLが特定のネットワークだけで失敗する場合は、そのネットワークの名前解決経路を優先して調べます。
エラー：Connection refused
原因と対処：接続先のポートで接続が拒否されました。接続先はローカルプロキシかサブスクリプションサーバーの可能性があります。エラーに表示されたホスト名とポートを確認し、該当するサービスが待ち受けているか調べてください。
「プロキシを使用」を選ぶ前に、現在のノードでプロキシ経路が使えることを確認し、ローカルの待ち受けポートも調べてください。「設定」→「パラメーター設定」でローカルポートを確認します。たとえば、現在のインスタンスが実際に 127.0.0.1:10808 で待ち受けているなら、そのアドレスを確認してください。別の端末のポートをそのまま使わないでください。このポートはあくまで例です。実際の画面表示とログを基準にしてください。
システムプロキシ、サブスクリプション更新時のプロキシ、TUNによる通信の取り込みは、それぞれ別の設定です。システムプロキシを有効にしても、すべてのサブスクリプションリクエストが必ずプロキシ経由になるわけではありません。TUNを有効にしていると、「プロキシを使用しない」を選んでも、システムのルーティングによって通信が取り込まれる場合があります。直接接続と比較する場合は、一時的にTUNを無効にし、テスト後に元の設定へ戻してください。詳しくはシステムプロキシの設定とTUNモードの説明を参照してください。
結論：安定して更新できる経路を選ぶ
同じURLで直接接続は失敗し、プロキシ経由なら成功する場合は、プロキシ経由での更新を使いましょう。プロキシ経由が失敗し、直接接続なら成功する場合は、現在のノードとローカルの待ち受けを確認してください。どちらも失敗する場合は、URLとサーバーの応答をさらに調べます。クライアントをすぐに再インストールする必要はありません。
URLが無効な場合：HTTPステータスコードで原因を絞り込む
サブスクリプションURLをコピーするときは、スキーム、パス、クエリパラメーターをすべて含めてください。チャットアプリによる空白や改行、日本語の句読点の混入、末尾パラメーターのコピー漏れによって、別のリクエストになることがあります。サブスクリプションURLにはアクセス認証情報が含まれることが多いため、公開変換サイトに入力したり、スクリーンショットにURL全体を載せたりしないでください。
| 応答・状況 | まず確認する項目 | 次の対応 |
|---|---|---|
401 Unauthorized | アクセス認証情報がない、期限切れ、またはリセットされた | サービス提供元のアカウントページからサブスクリプションURLをコピーし直す |
403 Forbidden | アクセス制限、接続元の制限、またはアカウント権限 | アカウントの状態を確認し、制限内容をサービス提供元に問い合わせる |
404 Not Found | パスの誤り、旧URLの廃止 | ドメイン名だけでなく、新旧URLのドメイン名とパスを比較する |
429 Too Many Requests | サービスのリクエスト頻度制限を超過 | 連続操作をやめ、応答の指示またはサービス提供元のルールに従って待つ |
5xx | サーバー側または上位サービスの障害 | 時間をおいて再試行し、調査用に発生時刻とステータスコードを記録する |
ステータスコードで原因の範囲を絞り込めますが、サーバー側の説明に代わるものではありません。たとえば 403 は、プランの期限切れとは限らず、ネットワークの出口やリクエスト制限が原因の場合もあります。応答に Retry-After が含まれている場合は、ノードを次々に切り替えて更新するのではなく、指定された時間だけ待ってから再試行してください。
形式の不一致：サブスクリプション本文と共有リンクを見分ける
リクエストが 200 OK を返しても、サーバーから内容が正常に返されたことを示すだけです。内容がログインページ、セキュリティ確認ページ、JSON形式のエラーメッセージなら、ノードはインポートできません。更新結果に「利用可能なノードがありません」と表示されたら、プロトコルの対応状況を調べる前に、応答内容の種類を確認してください。形式エラーをすべてネットワークの問題と決めつけないようにしましょう。
- サブスクリプションURL：通常は
https://で始まり、クライアントが定期的にアクセスしてノード一覧を取得します。このプレフィックスだけでは、応答の形式は判断できません。 - Base64形式のサブスクリプション：複数の共有リンクをエンコードして返す形式が一般的です。Base64はエンコード方式であり、接続プロトコルではありません。サブスクリプションの内容を保護する機能もありません。
- 単一の共有リンク：
vmess://やvless://は通常、1つのノードを表します。HTTPサブスクリプションURLとしてリクエストするのではなく、クリップボードからのインポートなど、ノードのインポート機能を使ってください。 - 完全な設定ファイル：
inbounds、outboundsなどのフィールドを含むJSONは、拡張子だけで通常のサブスクリプションとして扱うことはできません。クライアントの適切なインポート方法と、コアが対応する形式を確認してください。
VLESSとVMessはプロキシプロトコルで、サブスクリプションはノード情報を配布する方法です。1つのサブスクリプションに複数のプロトコルが含まれる場合もあります。サービス提供元が複数のクライアント向け形式を用意している場合は、v2rayN対応と明記されたURLを選んでください。プロトコルの各フィールド、通信設定、安全性に関するパラメーターも含めて互換性が必要です。URLの先頭だけを書き換えて「プロトコル変換」することはできません。詳しくはプロトコル設定リファレンスを参照してください。
結論：クライアントのバージョンを変える前に、応答内容を確認する
応答がWebページの場合は、サブスクリプションURLを正しいものにするか、アクセス制限に対処してください。有効なノード一覧が返されるのに一部のノードだけ認識されない場合に限り、クライアントのバージョン、プロトコルのパラメーター、コアの対応範囲を確認します。
自動更新間隔：まず手動更新を成功させてから定期更新を有効にする
「サブスクリプショングループ」→「サブスクリプショングループの設定」を開き、対象のグループを選択して「自動更新間隔」の項目を探し、そのグループが有効になっているか確認します。定期更新を設定する前に、まず手動更新を一度成功させてください。そうしないと、同じエラーを設定した間隔で繰り返すだけです。
入力前に画面の単位を必ず確認してください。単位が「分」の場合、12時間は 720 と入力します。使用中のバージョンで単位が「時間」と表示される場合は 12 と入力してください。これらは設定例であり、すべてのサービスに推奨される更新頻度ではありません。サービス提供元が定める最短間隔を優先してください。また、値を 0 にしたときの動作は使用中のバージョンの説明を確認し、「即時更新」を意味する共通の設定だと決めつけないでください。
- グループの設定を保存し、手動更新を一度実行して、成功した時刻とグループ内のノード数を記録します。
- クライアントを起動したまま、端末をスリープさせずに次回の更新を確認します。スリープ中に更新が実行されなかっただけなのに、サブスクリプションが無効になったと誤解しないようにしてください。
- 使用中のバージョンに自動更新用のプロキシ設定がある場合は、動作確認済みの経路を指定します。手動更新で一度「プロキシを使用」を選んでも、定期更新にその設定が引き継がれるとは限りません。
- 起動後だけ更新に失敗する場合は、ネットワークとプロキシコアの準備ができているか確認してから、手動で再試行してください。更新間隔を急いで短くする必要はありません。
サブスクリプションの定期更新はクライアントの機能です。XrayやV2RayのアウトバウンドJSONに追加できる汎用フィールドではありません。設定場所を確認するにはサブスクリプション管理の説明を参照してください。コアの設定に更新間隔のフィールドを作り足さないでください。
更新成功後の確認とよくある質問
更新が再開したら、まずグループ内のノード数と名前を確認し、ノードを1つ選んで実際に接続できるかテストします。サブスクリプションの更新には成功したのにWebページを開けない場合は、ノードの接続状態、ローカルプロキシ、ルーティングの振り分けを調べてください。サブスクリプションを何度も更新する必要はありません。リクエストが実際にどのアウトバウンドを使うかは、ルーティングルールの設定を確認してください。
更新に失敗しても、以前のノードは使えますか？
以前のノードを残して、接続をテストできます。更新失敗と既存ノードの無効化は別の問題ですが、サービス側でノードが削除または変更されていると、接続できない場合があります。調査中にグループを消去しないのは、利用できる経路と比較に使う情報を残すためです。
更新に成功したのにノード数が0の場合は？
まずアカウントページに利用可能なノードが表示されているか確認し、次にサブスクリプションの形式、グループの絞り込み条件、応答内容を確認してください。ノード名のフィルターを設定している場合は、元の値を記録してから一時的に解除し、動作を試します。「成功」という表示だけで、サーバーからノードが返されたと判断しないでください。
サブスクリプションURLをHTTPに変更する必要はありますか？
接続方式を自己判断で安全性の低いものに変更しないでください。サブスクリプションにはアクセス認証情報やノード情報が含まれることが多いため、サービス提供元が正式に案内するHTTPSのURLを使ってください。証明書に問題がある場合は、システムの日付、ネットワーク環境、サーバー証明書を確認します。プロトコルを変更したり、証明書の検証を無効にしたりしないでください。
サービス提供元に問い合わせる際に伝える情報は？
失敗した時刻、クライアントのバージョン、直接接続とプロキシ経由のテスト結果、HTTPステータスコード、機密情報を伏せたエラーメッセージを伝えてください。サブスクリプショントークン、ノードのパスワード、共有リンク全体は公開の問い合わせに含めないでください。URLを再発行する必要がある場合は、サービス提供元のアカウントページから手続きしてください。