v2rayN、v2rayNG、v2flyNGで更新がタイムアウトする、更新後に一覧が空になる、一部のノードを解析できない場合に役立ちます。まず「サブスクリプションを取得できない」「エラー内容を取得している」「ノードを追加できたが起動しない」を切り分け、リンク、応答形式、リクエスト経路、クライアント、コアの順に確認しましょう。一度に変更するのは1項目だけにし、使えるノードは残しておきます。
まず確認：サブスクリプション更新はどこで止まる？
サブスクリプションの更新は、単なる接続テストではありません。クライアントがサブスクリプション URL にリクエストを送信し、エンコードとノード形式を判別してから、解析結果をグループに登録します。ノードが接続できるかどうかは、コアが設定を読み込み、サーバーに接続して初めて判断できます。そのため、「更新成功」でもすべてのノードが使えるとは限らず、「接続タイムアウト」もノード自体の障害とは限りません。
- 応答がない：まず、ドメインの名前解決、接続タイムアウト、証明書、リクエストの通信経路を確認します。
- 応答はあるが1件も登録されない：ログインページやエラーメッセージが返っていないか、サブスクリプション形式やフィルター条件を確認します。
- 一部のノードだけ表示されない：該当するプロトコル、個別ノードの情報、クライアントの解析対応状況を確認します。
- ノードは表示されるが起動できない：コアのログを確認します。これはサブスクリプションの取得だけの問題ではありません。
手順1：サブスクリプション URL とグループ設定を確認
サブスクリプション URL は通常、https:// で始まる完全な URL です。一方、vmess:// や vless:// は、個別ノードの共有リンクでよく使われる形式です。単体ノードのリンクをサブスクリプション URL 欄に入力すると、クライアントがネットワーク上のサブスクリプションとして処理できないことがあります。サービス提供元のアカウントページ、支払いページ、サブスクリプション URL はそれぞれ別の入口です。
-
グループを開く
v2rayNのメイン画面で「サブスクリプショングループ」→「サブスクリプショングループの設定」を開き、問題のグループを選択します。バージョンによってメニュー名が多少異なる場合があります。ノード編集画面ではなく、サブスクリプション URL を編集できる画面を開いてください。
-
URLをコピーし直す
サービス提供元のサブスクリプションページから、使用中のクライアントに対応した URL をコピーし直します。先頭のプロトコルと末尾のパラメーターを確認し、前後の空白や改行を取り除きます。URL内の
?、&、エンコードされた文字は手動で削除しないでください。 -
有効状態を確認
グループが有効になっていることを確認します。一時的にそのグループのノードフィルターを解除し、該当グループに切り替えて一覧を確認してください。「現在のグループに表示されない」状態を「すべてのサブスクリプションが空」と誤認するのを防げます。
-
個別に更新
保存後、「サブスクリプショングループ」から現在のグループだけを更新します。通知に表示される登録件数を記録し、サービス提供元のページに記載された利用可能なノードの範囲と比較してください。
Androidクライアントでは、まずサブスクリプショングループの編集画面で URL を確認し、メイン画面のメニューから「サブスクリプションを更新」を実行します。v2rayNGとv2flyNGの画面はバージョンによって異なります。デスクトップ版のメニュー手順をAndroid版にそのまま当てはめないでください。更新を何度も押すより、先に「サブスクリプション URL」欄を見つけることが重要です。
- サブスクリプショントークンを再発行すると、以前の URL がすぐに無効になることがあります。クライアントに保存した URL も差し替えてください。
- アカウントの期限切れや通信量の上限到達時、サーバーからノード一覧ではなくエラーメッセージが返されることがあります。
- キーワードフィルターですべてのノードが除外されている可能性があります。ノードが戻ったことを確認してから、フィルター条件を1つずつ追加してください。
手順2：返された内容がノード情報か確認
ネットワークリクエストの成功は、応答を受信したことを示すだけです。ブラウザーでサブスクリプション URL を開けても、クライアントが同じ内容を受け取るとは限りません。ブラウザーにはログイン状態が保持されている場合があり、サーバーがUser-Agentに応じて異なる形式を返すこともあります。特に「サブスクリプションのテキスト」と「アカウントのログインページ」を区別してください。
| 返された内容の特徴 | 考えられる原因 | 次の手順 |
|---|---|---|
| ログイン画面やWebページのタグが表示される | Webページの URL をコピーしたか、リクエストが認証ページにリダイレクトされた | サブスクリプションページから専用 URL をコピーし直し、アカウント状態を確認する |
| 長いエンコード文字列が表示される | Base64でエンコードされたノード一覧の可能性がある | 該当するサブスクリプション形式に対応したクライアントでインポートする。見た目だけで破損と判断しない |
| 各行がノードのプロトコルで始まる | プレーンテキストの共有リンク一覧の可能性がある | クライアントが該当プロトコルと各項目に対応しているか確認する |
| YAML形式の設定項目が表示される | 別の設定出力形式が選択されている | サービス提供元のページで、使用中のクライアントに対応したサブスクリプションを選択する |
| 本文が有効期限やアクセス権限の案内だけ | APIには接続できているが、アカウントまたはトークンが無効 | アカウント状態を確認するか、サブスクリプション URL を再発行する |
Base64は暗号化ではなくエンコード方式です。サブスクリプション全体が一度エンコードされている場合もあれば、VMessの個別共有リンクのペイロードが別途エンコードされている場合もあります。一方、VLESSの共有リンクでは通常、URLの各項目にパラメーターが記述されます。すべてのサブスクリプションを同じJSON形式だと考えないでください。また、「エンコードの修復」のために何度もデコードし、元の URL に上書きするのも避けてください。
手順3：ステータスコードとエラーからネットワークを確認
ステータスコードを見ると、「更新に失敗しました」よりも具体的に状況を判断できます。以下の数値はHTTPのステータスコードであり、速度テストの結果ではありません。ログにステータスコードが表示されていない場合は、元のエラーを記録し、サーバー停止と決めつけないでください。
エラー：401 Unauthorized
原因：現在の認証情報がAPIで受け付けられていません。トークンの有効期限切れなどが考えられます。対処：有効なサブスクリプション URL をコピーし直し、アカウント状態を確認してください。古い URL での再試行を繰り返さないでください。
エラー：403 Forbidden
原因：サーバーがリクエストを拒否しています。アクセス方針、アカウントの制限、リクエスト元などが関係している可能性があります。対処：サービス提供元の案内を確認し、サブスクリプションの入口とリクエスト方法を見直してください。この表示だけでパスワードの誤りと判断することはできません。
エラー：429 Too Many Requests
原因：リクエストがAPIのレート制限に達しました。対処：連続して更新ボタンを押すのをやめ、サーバーの案内に従って待ってください。応答にRetry-Afterが含まれている場合は、その待機時間を守ってください。
エラー：No such host is known.
原因：Windowsのネットワークリクエストで発生することがある、ドメインの名前解決エラーです。対処：まずサブスクリプションのドメインが欠けずにコピーされているか確認し、信頼できる別のネットワークでも試してください。ノードのパラメーターをすぐに変更しないでください。
エラー：certificate has expired or is not yet valid
原因：証明書の有効期間を検証できません。端末の時刻が不正確な場合と、サーバー証明書に問題がある場合があります。対処：まずシステム設定で日付と時刻を同期してください。時刻が正しいのに失敗する場合はサービス提供元に連絡し、証明書の検証を無効にしないでください。
タイムアウトは、制限時間内にリクエストが完了しなかったことを示すだけです。同じ端末、同じ URL のまま、自宅のネットワークとスマートフォンのテザリングを比較します。変更するのは毎回ネットワークだけにし、サブスクリプション形式やクライアントを同時に変えないでください。どちらのネットワークでも同じアカウントエラーが返る場合は、DNSを変更し続けるのではなく、URLまたはアカウントを確認してください。
手順4：直接接続とプロキシ経由の更新を比較
v2rayNのサブスクリプションメニューには、プロキシを使わない更新とプロキシ経由の更新があります。システムプロキシの有効・無効、サブスクリプションリクエストがプロキシを通るかどうか、TUNによる通信の取り込みは、それぞれ異なる設定です。特にTUNが有効な場合、「プロキシを使わない」リクエストでもシステムのルーティングの影響を受ける可能性があります。メニューの表示だけで実際の通信経路を判断しないでください。
-
まず直接接続を試す
「サブスクリプショングループ」で「プロキシを使わない」と表示された更新項目を選択します。成功した場合はその方法を記録し、ノードやコアは変更しないでください。
-
以前のノードを確認
直接接続に失敗した場合は、まだ使えるとわかっている以前のノードを選び、通常のWebページにアクセスできるか確認します。以前のノード自体が使えないと、プロキシ経由の更新もタイムアウトし続けることがあります。
-
次にプロキシ経由を試す
「プロキシ経由」と表示されたサブスクリプション更新を実行し、エラーがタイムアウトから具体的なHTTPステータスコードに変わるか比較します。それぞれ1回ずつテストすれば十分です。更新を何度も繰り返さないでください。
-
通信の取り込み設定を確認
TUNが有効な場合は、一時的に無効にして同じテストをもう一度行い、結果を記録します。テスト後は元の設定に戻してください。システムプロキシ、ルーティングモード、サブスクリプション URL を同時に切り替えないでください。
プロキシ経由で更新するには、利用できるプロキシの接続先が必要です。以前のノードがすべて使えず、プロキシ経由でしかサブスクリプションのドメインにアクセスできない場合、依存のループに陥ります。その場合は、サービス提供元に直接接続できる予備のサブスクリプション URL を問い合わせるか、APIに接続できるネットワークを使ってください。ルーティングを「グローバル」にしても、使えるノードが自動的に用意されるわけではありません。
- 直接接続は成功、プロキシ経由は失敗：現在のノードとプロキシのリクエスト経路を確認し、直接接続での更新を続けてください。
- 直接接続は失敗、プロキシ経由は成功：2つのリクエスト経路で結果が異なることを示しており、サブスクリプションのエンコード形式が変わったわけではありません。
- どちらも同じ権限エラーが返る：アカウント、トークン、APIのアクセス方針を優先して確認してください。
手順5：クライアントの解析とコアの互換性を切り分ける
通常、サブスクリプションはクライアントが先に解析し、その後、コアが読み込める設定を生成します。そのため、コアを更新しても、クライアントが認識できない共有リンクの問題は直らない場合があります。反対に、ノード一覧が表示されても、選択したコアがすべてのパラメーターに対応しているとは限りません。「更新済み」とだけ記録せず、クライアントとコアそれぞれのバージョンを控えてください。
| 症状 | まず確認する項目 | 対処方法 |
|---|---|---|
| すべてのリンクを認識できない | 出力形式とクライアントの解析対応状況 | クライアントに対応したサブスクリプションを選び、クライアントを更新して再確認する |
| 特定のプロトコルだけ読み込まれない | 個別のプロトコル、通信方式、安全性の設定 | 読み込めないノードの種類を記録し、サービス提供元に互換形式を問い合わせる |
| インポートは成功するがコアの起動に失敗 | 生成された設定とコアの対応範囲 | 起動ログを確認し、実際に使われているコアを特定する |
| 起動は正常だが接続がタイムアウトする | 接続先サーバー、ネットワーク、接続パラメーター | 単一ノードの接続をテストし、サブスクリプションの再インポートを繰り返さない |
v2rayNGはXrayコアを使用し、v2flyNGはV2Flyコアを使用します。v2rayNはデスクトップクライアントです。各ノードがどのコアを使うかは、クライアントの設定と起動ログで確認してください。「VLESSに対応」と「すべてのVLESSの組み合わせに対応」は同じではありません。たとえばREALITYを使うノードでは、Xrayの対応状況とバージョン要件を確認してください。プロトコル名だけを変更して、別系統のコアで動かそうとしないでください。
- 既存の設定をバックアップしてから、当サイトのクライアントページで使用中のOSに適したバージョンを入手してください。上書き後すぐにグループを空にしないでください。
- サブスクリプションの解析に失敗した場合は、まずクライアントを更新します。コアの読み込みエラーが出た場合にコアを確認し、2つの段階を混同しないでください。
- サービス提供元に問い合わせる際は、「VMessまたはVLESS、通信方式、安全性の設定、クライアントのバージョン、コアのバージョン」を記載してください。認証情報の全体を添付する必要はありません。
復旧後の確認と問い合わせ用の記録
更新が復旧したら、まずノード数と所属グループを確認し、ノードを1つ選んで実際にアクセスできるかテストします。遅延テストの成功で確認できるのは、そのテスト方法で応答があったことだけです。すべてのWebサイトやルーティングルールが正常とは限りません。まず通常のWebページへのアクセスを確認し、その後フィルター条件と自動更新の設定を1つずつ戻してください。
- 一覧を確認：復旧後のノード数を記録し、別のグループや古い検索結果を表示していないことを確認します。
- 更新経路を確認：今回成功した直接接続またはプロキシ経由の方法を記録し、自動更新で失敗した経路が使われないようにします。
- フィルターを戻す：キーワード条件を一度に1つだけ追加し、現在の一覧が再び空にならないことを確認します。
- リクエストの繰り返しを減らす：サービス提供元の案内に従って自動更新の間隔を設定し、頻繁な更新で障害の切り分けを代用しないでください。