v2rayNでサブスクリプションを更新するとタイムアウトやHTTPエラーが表示される、または更新が完了してもノードが追加されない場合に役立つチェックリストです。まずリクエストの失敗と解析の失敗を切り分け、レスポンス本文、更新経路、クライアント識別情報、グループのフィルター設定を確認します。一度に変更するのは1項目だけにし、使えるノードを誤って消さないよう、元の設定と個人情報を伏せたログを保管してください。
どの段階で失敗しているか確認する
サブスクリプションURLから取得できるのはノード設定の一覧であり、そのまま接続できるノードではありません。v2rayNはまずURLにリクエストを送り、レスポンスの形式を判別してから、ノードを該当するグループに登録します。ノードへの接続可否はその後の問題です。サブスクリプションを取得できても接続先サーバーに到達できるとは限らず、既存ノードで通信できてもURLが有効とは限りません。
メイン画面の「サブスクリプショングループ」メニューを開き、まずは確認対象のグループだけを更新します。WPF版とDesktop版、バージョンによってメニュー名が多少異なる場合があります。以下では「現在のサブスクリプションを更新（プロキシを使用しない）」と「現在のサブスクリプションを更新（プロキシを使用する）」のように、通信経路を明確に区別する操作を基準に説明します。システムプロキシの切り替えを、更新経路の設定の代わりにしないでください。
| 表示される症状 | まず確認する箇所 | 次に行うこと |
|---|---|---|
| しばらく待つとタイムアウトする | DNS、ネットワーク経路、プロキシの出口 | 直結とプロキシ経由の更新を比較する |
| HTTP 401 または 403 | トークン、アクセス制限、リクエストヘッダー | アカウントとサブスクリプション専用URLを確認する |
| HTTP 200だが解析結果が空 | レスポンス本文と形式の互換性 | Webページや空の内容が返っていないか確認する |
| インポート成功と表示されるが一覧が空 | グループの選択、検索、フィルター | 対象グループに切り替えて検索をクリアする |
| ノードはあるが、すべて接続に失敗する | ノード設定または実行中のコア | 接続とコアのログを確認する |
URLの有効性：ログインページや無効なトークンを除外する
サブスクリプション提供元のアカウントページから「サブスクリプションURL」をコピーしてください。アカウント管理ページ、プランの説明ページ、ブラウザーでログインした後のURLは使用できません。URLのクエリパラメーターにはアクセス用トークンが含まれていることが多く、1文字欠けても別のリクエストになります。「サブスクリプショングループの設定」に貼り付けたら、先頭や末尾に空白、改行、日本語の引用符が混ざっていないか確認してください。特に、疑問符以降を手作業で削除しないでください。
-
現在の設定をバックアップする
クライアントのバックアップ機能を使用してください。設定フォルダーをバックアップする場合は、v2rayNを終了してから実際のデータフォルダーをコピーします。利用できるノードが残っている場合は、すべてのグループを先に削除しないでください。
-
サブスクリプションURLを確認する
「サブスクリプショングループ」→「サブスクリプショングループの設定」を開き、対象グループを編集します。提供元のページからURL全体をコピーし直し、エラーが出ているグループを編集していることも確認してください。
-
アカウントの状態を確認する
サブスクリプションの有効期限が切れていないか、トークンがリセットされていないか、提供元がURLの更新を求めていないか確認します。トークンをリセットした場合、古いURLが無効になるのは正常です。古いURLで何度も再試行しないでください。
-
レスポンスの内容を確認する
信頼できるローカル環境で、レスポンスのステータスと本文の種類を確認します。ログインフォーム、認証画面、プランのページが表示される場合は、ページを保存してインポートするのではなく、クライアント向けのサブスクリプションAPIを提供元に問い合わせてください。
ブラウザーでURLを開けるかどうかは、あくまで参考情報です。ブラウザーにはログインCookieが保存されている場合や、異なるプロキシが使われている場合、Webページの認証を自動で通過している場合があります。v2rayNのリクエストでは同じ条件がそろうとは限りません。また、HTTP 200はリクエストが成功レスポンスを受け取ったことを示すだけで、本文にノードが含まれることまでは保証しません。
Base64とノード形式：内容があっても解析できるとは限らない
一般的なサブスクリプションの本文は、複数の共有リンクを並べたテキストをBase64でエンコードしたものです。インターフェースによっては、リンクが平文で返される場合もあります。Base64は暗号化ではなく、エンコード方式です。デコードできても、本文が期限切れの通知、エラーの説明、クライアントが認識できない設定形式である可能性があります。デコード後の内容も確認してください。
- サブスクリプション全体のエンコード：デコード後は通常、共有リンクが1行ずつ並びます。確認はローカルで行い、結果全体を他人に送らないでください。
- VMess共有リンク：
vmess://に続く従来形式の共有データは、それ自体にBase64の層が含まれる場合があります。サブスクリプション全体のエンコードとは別の層です。 - VLESS共有リンク：
vless://は通常、URI形式でアドレスやパラメーターを表します。リンク全体を機械的にBase64としてデコードしないでください。 - 形式が一致しない：別の設定システム向けのYAML、WebページのHTML、エラーを示すJSONは、拡張子を
.txtに変えてもv2rayNにインポートできるサブスクリプションにはなりません。
同じレスポンスの一部だけインポートできる場合は、失敗した項目のプロトコル、トランスポート設定、クライアントの解析対応を確認してください。1件もインポートできない場合は、まずAPIが正しい形式を返しているか確認し、その後でエンコードの問題を調べます。最初からコアの設定を変更する必要はありません。クライアントがサブスクリプションのテキストを解析できていない場合、XrayやV2Rayのコアを切り替えても、Webページがダウンロードされる問題は通常解決しません。
| 本文の特徴 | 意味 | 対処方法 |
|---|---|---|
<!DOCTYPE html> または <html | Webページが返されている | サブスクリプションAPI、ログイン要件、Web保護を確認する |
| JSON形式のエラーオブジェクト | APIが処理エラーを返している | エラーの説明を読み、アカウントやトークンを確認する |
| 本文が空、または空白のみ | 解析できるデータがない | ノードが実際に割り当てられているか提供元に確認する |
| 複数行のプロトコル共有リンク | 解析可能な平文のサブスクリプションの可能性がある | プロトコルの対応状況と項目の完全性を確認する |
| 長いエンコード済みテキスト | サブスクリプション全体がBase64でエンコードされている可能性がある | ローカルでデコードして内容を確認し、見た目だけで判断しない |
更新経路：直結とプロキシ経由を別々に試す
「プロキシを使用せずに更新」と「プロキシ経由で更新」は、サブスクリプションサーバーへのネットワーク経路を切り替える操作であり、サーバー上のサブスクリプション内容を変更するものではありません。直結でAPIにアクセスできない場合は、プロキシの出口を使うとリクエストが成功することがあります。一方、APIがプロキシの出口を制限していたり、特定のネットワークからのアクセスだけを許可していたりする場合は、直結のほうが使えることもあります。
-
まず直結で試す
対象グループを選択し、「サブスクリプショングループ」メニューからプロキシを使用しない更新を実行します。エラーの発生時刻とステータスコードを記録し、何度も続けてクリックしないでください。
-
既存のノードを確認する
使用可能なノードを残している場合は、まずそのノードを選び、コアが起動していることを確認してから、アクセス可能なWebページを実際に開いてみてください。ノードを選択しただけでは、ローカルプロキシが使用できるとは限りません。
-
プロキシ経由に切り替える
プロキシ経由の更新を実行し、結果を比較します。この方法だけ成功する場合は、サブスクリプションの形式より直結時のネットワーク経路に問題がある可能性が高いでしょう。
-
変更する要素を1つに絞る
どちらの方法でも失敗する場合は、まずURLを変更せずに、エラーが同じかどうかを比較します。DNS、User-Agent、ノードのパラメーターを一度に変更すると、どの変更が有効だったのか判断できなくなります。
プロキシ経由の更新には、ローカルの待ち受けポートが必要です。「設定」→「パラメーター設定」を開き、現在のローカルインバウンドの待ち受け設定を確認してください。たとえば実際の待ち受け先が127.0.0.1:10808の場合、テストツールでもそのポートと対応するプロキシプロトコルを指定します。10808は確認用の例にすぎず、すべてのバージョンや設定で固定された値ではありません。リモートノードのポートで代用することもできません。
エラー：Connection refused
原因と対処：接続先がリクエストを拒否しています。ログの接続先が127.0.0.1のローカルプロキシポートなら、コアが起動しているか、ポートが現在の設定と一致しているかを確認してから、プロキシ経由の更新を再試行してください。リモートアドレスが示されている場合は、該当するリモートサービスを確認します。
エラー：No such host is known.
原因と対処：ホスト名を解決できません。サブスクリプションのドメインを完全にコピーしたか確認し、リクエスト経路で実際に使用されているDNSを調べてください。ノードのSNIを変更しても、サブスクリプションのドメイン名が解決できない問題は直りません。
エラー：A task was canceled.
原因と対処：タイムアウトやキャンセルによってリクエストが終了した可能性があります。このメッセージだけでAPIが無効だとは判断できません。前後のログからタイムアウトかどうかを確認し、直結とプロキシ経由の両方を試してください。
User-AgentとHTTPステータスコード：APIの要件を確認する
User-Agentは、リクエストヘッダーでクライアントを識別する項目です。サブスクリプションAPIによっては、これをもとに出力形式を選択したり、アクセスを制限したりします。「サブスクリプショングループ」→「サブスクリプショングループの設定」から対象グループを編集し、現在のバージョンに「User-Agent」欄があれば、まず初期値を維持するか、提供元が指定した値を入力します。この欄がない場合は、識別文字列をサブスクリプションURLの末尾に付けないでください。
User-Agentの変更は万能な解決策ではありません。ブラウザーの識別情報を設定するとWebページが返される場合があり、誤ったクライアント識別情報ではサーバーが互換性のない内容を返すこともあります。変更するのは一度に1つのグループだけにし、更新後にステータスコードと本文の種類を比較してください。改善しなければ元の値に戻します。Web認証が表示される場合は、認証の回避を試みず、クライアント向けの適切なAPIを提供元に問い合わせてください。
エラー：Response status code does not indicate success: 403 (Forbidden).
原因と対処：サーバーが現在のリクエストを拒否しています。トークン、接続元のIPアドレス、リクエストヘッダーなどの制限が考えられます。まずサブスクリプションの権限とURLを確認し、User-Agentは提供元の指示に従って確認してください。403だけを根拠に原因を1つに決めつけないでください。
エラー：Response status code does not indicate success: 404 (Not Found).
原因と対処：指定したリソースが見つかりません。無効なリソースを意図的に隠しているAPIもあります。アカウントページからサブスクリプションURLを取得し直してください。URLのパスを推測したり、パラメーターを自己判断で削除・変更したりしないでください。
エラー：Response status code does not indicate success: 429 (Too Many Requests).
原因と対処：リクエスト頻度の制限に達しています。手動での連続クリックをやめ、頻繁に実行される自動更新も一時停止してください。レスポンスに記載されたRetry-After、または提供元の案内に従って待ってから再試行します。
上記は一般的なHTTPクライアントのエラー表示です。実際の大文字・小文字や補足文は、バージョンによって異なる場合があります。「更新に失敗しました」という一文だけを切り取るより、数値のステータスコードを記録するほうが役立ちます。5xxが返された場合は、通常、APIや上流サービスの状態を確認します。ローカルのプロトコルを何度切り替えても、サーバーエラーが直接解決するわけではありません。
グループとフィルター：更新に成功してもノードが表示されない場合
リクエストと解析の両方に成功しているのに一覧が空の場合、表示範囲が合っていない可能性があります。まず、更新したサブスクリプショングループに切り替えて検索欄をクリアし、ノード名の絞り込みが設定されていないか確認してください。次に「サブスクリプショングループの設定」に戻り、現在のバージョンにある「更新を有効にする」、フィルターキーワード、正規表現フィルター、重複排除の各設定を確認します。切り分けの際は元の値を記録し、フィルター条件を一時的に解除してください。
- 更新対象を確認：同じ名前のグループは取り違えやすいため、グループのメモとサブスクリプションURLの両方を照合してください。別のグループを編集したり、更新したりしていないか確認します。
- 名前フィルターを確認：正規表現の対象範囲が広すぎる場合や、意図しない空白が含まれている場合は、すべてのノードが除外されることがあります。まずフィルターをクリアし、インポート数を確認してください。
- 重複排除と更新失敗を区別：重複排除によって追加数がレスポンス内の項目数より少なくなることがありますが、ダウンロードに失敗したとは限りません。更新ログとグループ内の合計数を比較してください。
- 更新対象になっているか確認：グループの更新が無効になっていると、すべてのサブスクリプションを更新する操作で対象外になる場合があります。そのグループが更新対象に含まれていることを確認してください。
よくある質問と確認のポイント
ブラウザーではサブスクリプションをダウンロードできるのに、v2rayNでは失敗するのはなぜですか？
まず、両方が同じネットワーク出口を使っているか比較し、ブラウザーがダウンロードしたものが本当にノードのテキストか確認してください。ブラウザーにはログインCookieが付与されている場合があります。本文がログインページや認証ページなら、クライアント専用のサブスクリプションURLを使用してください。その後で、提供元が指定するUser-Agentを確認します。
ノードがすべて消えた場合でも、プロキシ経由で更新できますか？
プロキシ経由で更新するには、動作するプロキシの接続先が必要です。まずローカルのバックアップから動作確認済みの設定を復元するか、提供元が案内する別の正規の接続方法を利用してください。利用できる接続手段がない場合は、直結を試すか、アクセス可能なサブスクリプションAPIを提供元に問い合わせてください。システムプロキシを有効にするだけでは接続できません。
v2rayNGではインポートできるのに、デスクトップ版が壊れているということですか？
そうとは限りません。まず、同じURLかどうかだけでなく、両方が同一のレスポンスを取得しているか確認してください。接続出口、User-Agent、APIによる振り分けが異なる場合があります。レスポンスが同じなら、各クライアントが対象のプロトコルやトランスポート設定に対応しているか比較します。v2rayNGはXrayコア、v2flyNGはv2flyコアを使用しますが、サブスクリプション解析の互換性はクライアントのバージョンも含めて判断する必要があります。
更新後にノードは表示されますが、接続テストがすべて失敗します。サブスクリプションを変更し続けるべきですか？
まずサブスクリプションの変更を止めてください。コアが起動できるか確認し、システム時刻、ノードのアドレスとポート、TLSの設定を確認したうえで、接続時のコアログを読みます。サブスクリプションの更新とノードへの接続は別々の段階です。ノード一覧が作成されているなら、具体的なノードとネットワーク経路を中心に調べてください。
適切に再確認するには、更新操作が終了したかだけでなく、「リクエストが成功した」「本文を解析できた」「グループにノードが追加された」の3点を確認します。それでも問題を報告する場合は、v2rayNの実際のバージョン、使用している画面、OS、更新方法、HTTPステータスコード、個人情報を伏せたエラーメッセージを添えてください。ノードのアカウント情報、サブスクリプショントークン、レスポンス本文全体はログと一緒に公開しないでください。
- 同じグループを続けて確認する間はURLとフィルター条件を固定し、検証する要素を1つだけ切り替えてください。
- 更新に成功したら対象グループでノードを確認し、選んだノードが接続できるかを別に検証してください。
- 問題が解決したら、適切な自動更新スケジュールに戻し、復元できるローカルバックアップを保管してください。