v2rayN、v2rayNG、v2flyNGで購読を更新できない、更新後のノード数がゼロになる、またはウェブページの内容だけが取得される場合に適用できます。確認は、状況の記録、リンクの検証、レスポンス形式の確認、アクセス制限の確認、ネットワーク問題の切り分け、クライアント設定の再確認という順番で行います。最終的に、購読元、通信経路、ローカルクライアントのどこに問題があるかを分類できます。
まずエラーを記録し、6ステップの順番で確認する
更新に失敗したからといって、すぐに購読を削除したり、クライアントを再インストールしたり、ノードを何度も切り替えたりしないでください。購読URLには通常アカウントトークンが含まれており、リンクにアクセスできるか、サーバーがどの内容を返すか、クライアントがどの方法でリクエストするかによって結果が決まります。エラーの原文、発生時刻、使用中のネットワーク、クライアントのバージョンを先に保存しておくと、後で比較できます。
有効な切り分けには、再現可能な条件を整える必要があります。同じ購読リンクを固定し、現在のネットワークと別の信頼できるネットワークでそれぞれテストしてください。同じネットワークでは、クライアントからのリクエストとブラウザーからのリクエストを比較します。一度に変更する変数を1つだけにすれば、原因がサーバー、DNS、プロキシ経路、クライアントの解析処理のどこにあるか判断できます。
状況を記録
エラー全文をコピーし、クライアント名、バージョン、発生時刻、ノード数の変化、使用ネットワークを記録します。現時点では元の設定を上書きしないでください。
リンクを検証
URLが完全か、期限切れでないか、301または302リダイレクトが発生していないかを確認し、最終レスポンスが200であることを確認します。
本文を確認
返された内容が共有リンクの一覧、Base64テキスト、または対応する構造化設定であり、ログインページ、認証ページ、エラーページではないことを確認します。
制限を確認
購読元がUser-Agent、アクセス回数、アカウント状態、入口URL、接続元ネットワークを制限していないか確認します。
ネットワークを切り分け
DNSと接続ネットワークを変更し、誤ったシステムプロキシを無効にして、ドメイン汚染、透過リダイレクト、ローカルプロキシのループを切り分けます。
クライアントを再確認
購読グループを再編集し、リンクに空白が混入していないことを確認します。クライアントを更新し、コアの種類とローカルポートの競合も確認してください。
ステップ1・2：エラー状況とリンクの有効性を確認
まず「ダウンロードできない」のか「ダウンロード後に解析できない」のかを分けます。タイムアウト、ドメイン解決失敗、接続拒否は通常ダウンロード段階で発生します。ノード数がゼロ、形式エラー、無効な文字の出現は解析段階で起こることが多く、両者の対処方法は異なります。「購読が無効」とだけ考えてはいけません。
購読URLを確認するときは、先頭のプロトコル、ドメイン、パス、クエリパラメーターを重点的に確認します。コピー時によくある問題は、末尾のトークンが欠けている、チャットアプリが改行を自動挿入する、URLの前後に空白がある、表示テキストまで実際のリンクと一緒に貼り付けている、といったものです。購読トークンはアクセス認証情報と同じため、公開解析サイト、公開ログ、スクリーンショットに載せないでください。
ブラウザーでリンクを開けても、クライアントで必ず更新できるとは限りません。ブラウザーはCookieを自動送信したり、リダイレクトを処理したり、サーバーの案内ページを表示したりします。一方、クライアントはレスポンス本文を受け取り、そのまま解析器に渡します。ページにダウンロード動作が現れたかだけでなく、最終ステータスコード、レスポンスタイプ、本文の先頭も記録してください。
エラー: The operation has timed out
原因と対処:設定時間内に接続が完了しませんでした。DNSが応答しない、ネットワークに到達できない、サーバーが接続を遮断しているなどの可能性があります。まずタイムアウトの基準を10秒に設定し、別のネットワークで再試行して、システム時刻が正しいか確認してください。
エラー: Response status code does not indicate success: 404 (Not Found)
原因と対処:購読パスが存在しません。入口URLの変更、トークンのリセット、コピー漏れなどがよくある原因です。購読サービスのページに戻ってURLを再生成し、パスを手入力で推測しないでください。
エラー: Response status code does not indicate success: 410 (Gone)
原因と対処:サーバーがリソースの取り消しを明示しています。購読リンクを再生成するか、アカウント状態を確認してください。ローカルクライアントで更新を繰り返しても、このURLは復旧しません。
| 確認結果 | 優先して判断すること | 次に行う操作 |
|---|---|---|
| ステータスコード200、本文はノードデータ | ダウンロード成功。形式とクライアント解析を確認 | 本文の1行目、エンコード、共有リンクのプレフィックスを確認 |
| ステータスコード301または302 | 入口URLでリダイレクトが発生 | 最終URLが想定ドメインにあり、トークンが失われていないことを確認 |
| ステータスコード401または403 | 認証情報、UA、アクセスポリシーによる制限 | トークンを確認し、購読元が求めるクライアント条件を確認 |
| ステータスコード404または410 | パスが無効、またはリソースが取り消されている | サーバーから購読URLを再取得 |
| ステータスコード200、本文はHTML | ログインページ、認証ページ、エラーページが返されている | リダイレクト、アカウント状態、ネットワークによるリダイレクトを確認 |
ステップ3：返却内容とBase64エンコードが正常か確認
購読のダウンロードに成功すると、クライアントは内容の特徴から形式を判別します。本文は複数行の vmess://、vless://、trojan://、ss://共有リンクの場合もあれば、テキスト全体をBase64エンコードした内容の場合もあります。構造化設定を返すサービスもありますが、対応可否はバージョンやインポート方法によって異なります。
Base64の失敗は、必ずしもノードパラメーターの誤りを意味しません。通信中に空白が挿入されたり、改行規則が変わったり、末尾のパディング文字が失われたりすると、デコーダーが特定のバイト位置で停止します。別のよくあるケースは、本文が実際にはHTMLで、先頭が <!doctype html> になっていることです。それをクライアントが購読データとしてデコードしようとすると、エンコードに関係するように見えるエラーが発生します。
正常なプレーンテキスト購読の先頭例：
vless://ユーザー識別子@node.example.net:443?type=tcp&security=tls#サンプルノード
trojan://アクセスパスワード@edge.example.net:443?security=tls#予備ノード
追加確認が必要なレスポンスの先頭：
<!doctype html>
{"error":"token expired"}
Access denied- 空白を除去した本文も空の場合：サーバーが空の購読を返している可能性があります。まずアカウントに利用可能なノードがあるか確認してください。
- デコード後に通常の案内文だけが表示される場合：購読サービスがサービス側のエラーを返しており、クライアントのプロトコル解析問題ではありません。
- 共有リンクのプレフィックスは正しいのに単一ノードのインポートに失敗する場合：ポート、ユーザー識別子、通信方式、TLSパラメーター、URLエンコードを引き続き確認してください。
- 一部のノードだけ消える場合：サーバー側の配信ポリシーが変わったか、旧バージョンのクライアントが新しいフィールドを認識できない可能性があります。
エラー: base64: illegal data at input byte
原因と対処:レスポンスに無効な文字が含まれている、内容が途中で切れている、またはそもそもBase64テキストではありません。まず本文の先頭を確認し、購読元から完全なリンクをコピーし直してください。トークンを含む原文をオンラインツールにアップロードするのは避けてください。
エラー: invalid character '<' looking for beginning of value
原因と対処:解析器は構造化データを想定していましたが、HTMLタグで始まるウェブページを受け取りました。最終リダイレクト先、ログイン状態、サーバーの認証ページを確認してください。
エラー: failed to parse subscription content
原因と対処:本文はダウンロードできていますが、クライアントが対応する購読形式として認識できませんでした。ウェブページの案内文でないことを確認し、クライアントを現行の安定版に更新して再試行してください。
結論：まず本文の先頭100文字を確認
ステータスコードが200なのに解析に失敗する場合、何度も更新を繰り返すより本文の先頭を確認する方が診断に役立ちます。HTML、エラーオブジェクト、アクセス案内が見つかったら、すぐに購読元の確認へ進めます。先にルーティングやノードパラメーターを変更する必要はありません。
ステップ4：UA、認証、リクエスト頻度の制限を確認
User-Agentの略称がUAで、リクエストを送信したクライアントを識別するために使われます。購読元によってはUAに応じて形式を変えたり、登録済みのクライアント識別子だけにアクセスを許可したりします。ブラウザーでは正常なのに、v2rayNやv2rayNGの更新だけが403になる場合、UAポリシーは確認すべき変数の1つです。
v2rayNでは「購読グループ」→「購読グループ設定」に進み、対象グループを選択して購読URLとUser-Agentの項目を確認します。値を変更するのは、購読サービスが明確に指定している場合だけにしてください。ブラウザーの識別情報を適当に入力すると、サーバーがウェブ版を返し、解析器がHTMLを受け取る原因になります。
認証エラーは、トークンの期限切れ、アカウント状態の変化、同時リクエストの過多、短時間での更新回数制限によっても発生します。「すべての購読を更新」を連続してクリックすると、429レスポンスが増えます。頻度制限に遭遇したら、ローカルポートを変更するのではなく、再試行を止めてサーバーが定めた時間帯を待ってください。
エラー: Response status code does not indicate success: 403 (Forbidden)
原因と対処:サーバーが権限のないリクエストと判断しました。トークン、UA、接続元ネットワーク、アカウントポリシーが関係している可能性があります。購読サービスの説明を確認し、購読グループでは指定されたUAを使用してください。
エラー: Response status code does not indicate success: 429 (Too Many Requests)
原因と対処:短時間のリクエスト回数が制限を超えています。自動更新と手動での連続操作を停止し、10〜30分待ってから1回だけリクエストしてください。
エラー: token expired
原因と対処:購読トークンの期限が切れているか、サーバー側でリセットされています。購読URLを再生成し、クライアントに保存されている古いリンクを削除してください。バックグラウンドタスクが無効な入口へリクエストし続けるのを防げます。
ステップ5：DNS、システムプロキシ、ローカルネットワークを切り分け
同じ購読がモバイルネットワークでは更新でき、家庭用ブロードバンドではタイムアウトする場合、まずDNSと接続経路を確認します。ドメインが誤ったアドレスに解決される、ネットワーク機器が古いレコードをキャッシュしている、透過リダイレクトで案内ページに転送されるといった原因で、クライアントが想定外のサーバーへ接続することがあります。この場合、VMess、VLESS、Trojanのノードパラメーターを変更しても意味がありません。障害はノード一覧をダウンロードする前に発生しているためです。
システムプロキシが 127.0.0.1:10809 を指していて、対応するコアがまだ起動していない場合、購読リクエストは直接接続に失敗することがあります。購読更新に現在のプロキシが必要なのに、使用中のノード自体が無効だと、「購読をダウンロードするためにノードが必要で、ノードを得るために購読が必要」という依存関係に陥ります。一時的に直結で更新するか、接続を確認済みの予備設定を使ってください。
- まず購読ドメインの現在の名前解決結果を記録し、その後、別の信頼できるDNSへ切り替えます。複数のネットワーク設定を同時に変更しないでください。
- システムの日付、時刻、タイムゾーンが正しいことを確認してください。大きなずれがあると、TLS証明書の有効期間判定に失敗します。
- ローカルポートが他のプロセスに使用されていないか確認します。v2rayNで一般的なSOCKSポートは10808、HTTPポートは10809ですが、実際の値は「設定」→「パラメーター設定」のローカルリスニング設定に従います。
- ブラウザー拡張機能以外のシステムレベルのプロキシ設定を一時的に無効にして、購読への直結リクエストをテストし、プロキシループを切り分けます。
- 現在のブロードバンドとAndroidのモバイルネットワークで、それぞれ1回ずつテストします。片方のネットワークだけが失敗する場合は、DNS、ゲートウェイ、ネットワーク側の制限を優先して確認してください。
| 比較テスト | 結果 | 可能性の高い障害箇所 |
|---|---|---|
| 同じリンクで、ブロードバンドは失敗し、モバイルネットワークは成功 | 購読元自体は利用可能 | ブロードバンドのDNS、ゲートウェイキャッシュ、接続元ネットワークの制限 |
| 同じネットワークで、ブラウザーは成功し、クライアントは403 | 通信経路は基本的に到達可能 | UA、Cookie、リダイレクト、クライアントのリクエストポリシー |
| すべてのネットワークで410が返る | サーバーが明確に取り消している | 購読URLが無効 |
| システムプロキシを無効にすると復旧 | 直結経路は正常 | ローカルポート、プロキシループ、使用中ノードの無効化 |
結論：DNSを何度も変更するより、ネットワーク間で比較する方が早い
同じリンクを2つのネットワークで比較すれば、サーバー障害とローカル経路障害を直接切り分けられます。両方で失敗するなら購読元を確認し、片方だけが失敗するならクライアント設定は維持したまま、そのネットワークを重点的に調べてください。
ステップ6：クライアント設定、バージョン、コアの状態を再確認
最初の5ステップで購読URLが有効、本文形式が正しい、ネットワークに到達可能であることを確認したら、クライアントのローカル状態を確認します。まず購読の編集画面を開き、リンクの前後に空白がないか、グループが有効か、自動更新タスクが古いURLを参照していないかを確認してください。表示名だけを上書きしないでください。古いトークンが元のグループに残っている可能性があります。
v2rayNでは「購読グループ」→「購読グループ設定」→グループを選択→アドレスを編集の順に進み、保存後に「現在の購読を更新」で1回だけテストします。コア関連の設定は「設定」→「パラメーター設定」→「Coreタイプ」にありますが、購読のダウンロードで401、403、404が出る場合はコアを切り替える必要はありません。これらのステータスは購読サーバーが返したものです。
v2rayNGではサイドメニューから「購読グループ設定」を開き、現在の項目を編集して有効状態を確認した後、メイン画面に戻って購読を更新します。v2flyNGはv2flyコアを使用するため、対応するコアの動作が必要なAndroid設定に適しています。同じ購読を特定の旧バージョンだけが認識できない場合は、まずクライアントを更新し、サーバーが新しいプロトコルフィールドを配信しているか比較してください。
既存項目をバックアップ
現在利用できるノード名、購読グループ、ルーティング設定を記録し、確認作業中に接続可能な予備設定を上書きしないようにします。
グループを再作成
一時的な購読グループを新規作成し、再取得した完全なURLを貼り付けて、この項目だけを有効にしてテストします。
1回だけ更新
現在のグループを1回だけ更新し、ステータスコード、所要時間、更新前後のノード数を記録します。
ポートを確認
10808、10809、またはカスタムのリスニングポートが使用中でないことを確認し、システムプロキシの指定ポートとクライアントの実際のリスニングポートが一致していることを確認します。
クライアントを更新
現行の安定版v2rayN、v2rayNG、v2flyNGで再テストし、旧式の解析器が新しいフィールドを認識できない可能性を排除します。
エラー: address already in use
原因と対処:ローカルのリスニングポートが別のプロセスに使用されています。重複起動しているクライアントを終了するか、「設定」→「パラメーター設定」で未使用のポートに変更し、システムプロキシも合わせて変更してください。
エラー: no valid profile found
原因と対処:購読更新後に利用可能な設定が生成されていません。返された本文が空でないか確認し、共有リンクにサーバー、ポート、認証情報のパラメーターが完全に含まれていることを確認してください。
結果から問題の所在を特定する方法
401、403、404、410、429が複数のネットワークと複数のクライアントで一貫して発生する場合、問題は通常、購読元またはアカウントポリシーにあります。購読サービスの管理者へ連絡する際は、発生時刻、ステータスコード、クライアント名、ネットワーク種別だけを伝え、完全なトークンは送らないでください。
ブラウザーと別のクライアントの両方で同じ本文を取得でき、特定の旧バージョンだけが解析に失敗する場合は、クライアントのバージョン、購読形式の互換性、単一共有リンクのフィールドを重点的に確認します。ネットワークを変更するとすぐ復旧する場合は、すべてのノードを再構築せず、DNS、システムプロキシ、接続ネットワークに集中してください。
最後にノード接続を確認します。購読の更新に成功したことは、ノード一覧がクライアントに書き込まれたことを示すだけで、すべてのサーバーに接続できるとは限りません。1つのノードを選び、アドレス解決、ポート到達性、TLSドメイン、通信方式、ルーティングを確認してください。これらは接続段階の問題であり、購読ダウンロード段階とは分けて記録します。
最終判断：ステータスコード、本文、ネットワーク間の結果で原因を特定
ステータスコードはサーバーがリクエストを受け付けたか、本文は解析器が実際に受け取った内容を、ネットワーク間の結果は障害がローカル経路に限定されるかを示します。3つの証拠が一致してから設定を変更すれば、有効な購読を削除したり、クライアントを何度も再インストールしたりせずに済みます。