サブスクリプションの更新失敗、インポート後のノード数が0、以前のノードは使えるのに更新できないといった問題に対応します。まず失敗箇所がダウンロード・解析・ノード接続のどこかを切り分け、リンク、レスポンス、クライアント設定、ネットワークを確認して具体的な対処法を判断します。
まず失敗した段階を特定する
「サブスクリプションが使えない」原因は一つではありません。クライアントが更新を実行するには、サブスクリプションURLの読み取り、DNSとTLS接続の確立、レスポンス本文のダウンロード、エンコードの判別、ノード情報の解析、ローカル設定への書き込みという少なくとも6段階を順に完了する必要があります。ノードが一覧に書き込まれて初めて、サーバーへの接続とプロトコルのハンドシェイクに進みます。
更新をクリックしてすぐにURL形式のエラーが出る場合は、サブスクリプションリンクを確認します。数秒後にタイムアウトが表示される場合は、ネットワーク、DNS、サーバーの応答を確認します。更新成功と表示されてもノード数が0なら、返却内容と解析形式を確認してください。ノードは表示されるのに遅延テストがすべて失敗する場合、問題はサブスクリプション解析の外にあります。ノードのパラメーター、サーバー状態、ローカルルーティングを確認します。
| 確認できる症状 | 問題の段階 | 優先して確認する項目 |
|---|---|---|
| 更新直後にエラーが出る | リンク読み取りの段階 | リンクの前後、プロトコルの接頭辞、スペース、改行 |
| 約10〜30秒後にタイムアウトする | ネットワーク通信の段階 | DNS、TLS、システム時刻、プロキシ方式 |
| 成功と表示されるがノードが0件追加される | 内容解析の段階 | レスポンス本文、Base64エンコード、クライアントのバージョン |
| ノードはあるが遅延テストに失敗する | ノード接続の段階 | アドレス、ポート、プロトコルパラメーター、サーバー状態 |
結論：まずノード数とエラー発生時刻を記録する
更新前後でノード数が変わらず、すぐにエラーが出る場合は、まずリンクを確認します。ノードが消えたり、更新後に0件と表示されたりする場合は、まずレスポンス内容を確認してください。解析の成功を確認する前に、ローカルのSOCKSポートを何度も変更しないでください。
サブスクリプションリンクが完全で、リクエスト可能か確認する
サブスクリプションURLをコピーする際によくあるのは、チャット画面で末尾が切れる、先頭に説明文が付く、途中に全角文字が混ざるといった問題です。有効なURLは通常 https:// で始まり、長いパス、クエリパラメーター、アクセストークンを含むことがあります。クエリパラメーター内の疑問符、等号、区切り記号もURLの一部なので、ドメインだけを残さないでください。
まずリンクをプレーンテキストエディターに貼り付け、前後に引用符、スペース、改行がないことを確認します。URL内のアクセストークンが購読権限を直接左右する場合があるため、サブスクリプションURLを公開オンラインデコードサイトに入力しないでください。レスポンスを確認する場合は、信頼できるネットワーク環境でローカルのブラウザーまたはクライアントログを使用します。
元のURLを確認する
配布元からサブスクリプションURLを完全な形でコピーし、先頭が
https://で、末尾にピリオド、閉じ括弧、スペースがないことを確認します。リンクを単独で開く
ローカルのブラウザーでURLを開きます。正常なら長いエンコード文字列、テキストファイル、または構造化されたサブスクリプションデータが表示されます。ログインページや認証ページはノードのサブスクリプション本文ではありません。
ステータスレスポンスを確認する
401または403が表示される場合は、アクセストークンの期限切れやアクセス制限が考えられます。404はパスが存在しないことを、429は短時間にリクエストが集中したことを示します。更新を一旦停止してから再試行してください。
サブスクリプションを保存し直す
v2rayN 7.xで「サブスクリプショングループ」→「サブスクリプショングループ設定」を開き、古いURLを削除して貼り直します。その後、「サブスクリプショングループ」→「すべてのサブスクリプションを更新」を実行します。
エラー：The remote server returned an error: (403) Forbidden
原因と対処：サーバーが現在のサブスクリプションリクエストを拒否しています。トークンの期限切れ、アクセス元の制限、リクエスト頻度の上限がよくある原因です。有効なURLを再取得し、制限が解除されてから更新してください。
エラー：Invalid URI: The hostname could not be parsed
原因と対処：プロトコルの接頭辞がない、ドメインが不完全、またはスペースが混入しています。URLを完全な形でコピーし直し、プレーンテキストエディターで前後の文字を整えます。
エラー：The operation has timed out
原因と対処：制限時間内にクライアントが完全なレスポンスを取得できませんでした。まずブラウザーでアクセスできるか確認し、DNS、システムプロキシ、現在のネットワークを確認します。
レスポンス内容とエンコード形式を確認する
従来型のサブスクリプションでは、複数のノードURLを1行ずつ並べ、テキスト全体をBase64でエンコードすることがあります。デコードすると、通常は vmess:// や vless:// で始まる記録を確認できます。JSONやクライアント専用形式を直接返すタイプもあります。クライアントが対応する形式を認識できて初めて、本文をノード一覧に変換できます。
ブラウザーでサブスクリプションURLを開けても、ダウンロード段階が基本的に動作していることしか確認できません。現在のクライアントが解析できるとは限らない点に注意してください。HTMLのログインページ、エラー内容のJSON、空の本文、途中で切れたBase64文字列が返ると、HTTPリクエストは成功と表示されても、最終的にノードが0件になることがあります。
行単位で解析できる内容の例：
vless://[email protected]:443?encryption=none&security=tls&type=ws#Example-VLESS
引き続き確認するレスポンス：
<html><title>Sign in</title>...</html>
{"error":"subscription expired"}
空の本文、または数十バイトしかないエラーテキスト- デコード後は、各ノードに明確なプロトコル接頭辞があり、通常は1件につき1行で記録されています。
- VMessリンクの本体には、さらにBase64エンコードされた部分が含まれることがあります。デコード後のJSONは完全な構文でなければならず、フィールドの引用符や末尾の括弧が欠けると解析に失敗します。
- VLESSリンクでは、URIパラメーターを使って通信方式とセキュリティ設定を指定します。URL内の
&区切り、パーセントエンコード、フラグメント名をリッチテキストエディターで置き換えないでください。 - レスポンスがJSONと表示されているのに実際にはWebページが返る場合は、ノードのプロトコルを手作業で書き換えるのではなく、アクセス認証やサブスクリプション配布元の設定を確認してください。
- レスポンス本文のサイズが突然数十KBから1KB未満に減った場合、完全なノード一覧ではなくエラー説明が返っている可能性が高いです。
エラー：Failed to parse subscription content
原因と対処：本文はダウンロードできたものの、対応するサブスクリプション形式として認識できません。HTML、エラーJSON、不完全なエンコードが返っていないか確認し、現在も保守されているクライアントで再解析してください。
エラー：Invalid character in a Base-64 string
原因と対処：エンコード文字列にスペース、HTMLタグ、コピー時に混入した不可視文字が含まれています。元のレスポンスを再ダウンロードし、整形済みのページからコピーし直さないでください。
エラー：Unexpected end when deserializing object
原因と対処：JSONが末尾まで届く前に途切れています。レスポンスのダウンロードが不完全だったか、元データの生成に失敗した可能性があります。再リクエストしてレスポンスサイズを比較し、異常が続く場合はサブスクリプションを再生成してください。
クライアントのバージョン、グループ、更新方法を確認する
同じサブスクリプションを一方のクライアントではインポートできるのに、別のクライアントでは空になる場合、対応するプロトコルフィールド、コアの系統、クライアントのパーサーのバージョンが関係していることがあります。v2rayNはデスクトップ環境向け、v2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。3つはサブスクリプションの入口や設定の互換範囲が完全に同じではないため、アプリ名だけで解析結果が一致すると判断できません。
調査時は、クライアントの完全なバージョン番号とコアのバージョンを記録します。端末がv2rayN 6.xのままで、別の端末が7.xを使っている場合は、まず同じメジャーバージョンで再テストしてください。Android側もv2rayNG 1.9.xとv2flyNG 1.8.xを区別します。バージョン番号は解析能力の比較に使うため、「最新版」とだけ書かず、実際にインストールされているバージョンを記録します。
現在のバージョンを記録する
クライアントの「バージョン情報」または「About」画面を開き、クライアントのバージョン、Coreの種類、コアのバージョンを記録します。ノード名だけを比較しないようにしてください。
サブスクリプショングループを確認する
v2rayN 7.xで「サブスクリプショングループ」→「サブスクリプショングループ設定」を開き、URLが有効なグループに登録されていることを確認します。グループ名は有効性を判断する基準ではありません。
更新方法を切り替える
まず通常更新を実行します。現在のネットワークで既存ノードを経由しないとURLを読み取れない場合は、クライアントが提供するプロキシ経由の更新を使います。2つの方法で短時間に連続してリクエストしないでください。
フィルター条件を確認する
ノード一覧のキーワードフィルターを解除し、すべてのサーバーを表示します。サブスクリプションが書き込まれていても、名前のフィルターで隠れていると一覧が空に見えることがあります。
現在のコアを再起動する
更新が成功したら設定を保存して現在のコアを再起動し、ノード数とログを確認します。設定ウィンドウを閉じるだけでは、実行中の設定が再読み込みされない場合があります。
| クライアント | 記録する項目 | 重点確認項目 |
|---|---|---|
| v2rayN 7.x | クライアントのバージョン、Coreの種類、サブスクリプショングループ | グループの有効状態、更新方法、キーワードフィルター |
| v2rayNG 1.9.x | アプリのバージョン、Xrayコアのバージョン | サブスクリプショングループ、バックグラウンド通信権限、解析ログ |
| v2flyNG 1.8.x | アプリのバージョン、v2flyコアのバージョン | プロトコルフィールドが現在のコアに対応しているか |
DNS、TLS、システムのネットワーク環境を確認する
サブスクリプションのドメインは、まずアクセス可能なIPアドレスに解決され、その後TLS接続が確立されます。DNSが誤ったアドレスを返す、端末の時刻が大きくずれている、証明書チェーンを検証できない、現在のネットワークがリクエストを遮断するといった状況では、本文を取得する前にクライアントが停止します。この場合、ノード内容がまだダウンロードされていないため、VMessやVLESSのフィールドを変更しても効果はありません。
まず同じ端末でブラウザーとクライアントの結果を比較し、次に同じサブスクリプションを異なるネットワークで比較します。たとえば家庭のネットワークでは常にタイムアウトするのにモバイルネットワークでは約2秒で返るなら、原因は現在のネットワーク経路に近いと考えられます。すべてのネットワークで403が返るならサブスクリプション権限の可能性が高く、ブラウザーは正常でクライアントだけ失敗するなら、クライアントのプロキシ更新方式とシステム証明書環境を確認します。
エラー：No such host is known
原因と対処：サブスクリプションのドメインから有効なDNS応答を取得できません。安定したDNS解決サービスに切り替え、システムのDNSキャッシュを消去してからクライアントを再起動します。
エラー：The SSL connection could not be established
原因と対処：TLSハンドシェイクまたは証明書の検証に失敗しました。まずシステムの日付、時刻、タイムゾーンを正しく設定し、現在のネットワークが証明書を差し替えたり暗号化通信を遮断したりしていないか確認します。
エラー：connection reset by peer
原因と対処：接続確立後に、リモート側または中間ネットワークによって接続がリセットされました。ネットワークを切り替えて再テストし、連続更新の頻度を下げて一時的な制限を切り分けます。
- システムの日付、タイムゾーン、自動時刻設定を確認します。数分のずれでも、証明書の有効期間の判定に失敗することがあります。
- 重複して動作しているプロキシプログラムを終了し、ローカルの待受ポートが競合していないことを確認します。v2rayNではSOCKSポート10808、HTTPポート10809が一般的ですが、実際の値は「設定」→「パラメーター設定」のローカルポートに従ってください。
- 通常更新に失敗した場合は、現在のプロキシ経由で更新する必要があるか確認します。プロキシ更新に失敗した場合も、プロキシを使わない通常リクエストをテストしてください。
- 2つのネットワーク環境でそれぞれ1回ずつテストし、リクエスト時間、HTTPステータス、レスポンスサイズを記録します。「開ける」「開けない」だけでは不十分です。
- 変更するたびに更新は1回だけ実行し、完全な結果を待ちます。更新を連続クリックすると429制限が発生し、元の問題に頻度制限が重なる可能性があります。
結論：ブラウザーが正常でもクライアントの通信経路が正常とは限らない
ブラウザーは独自のDNS、既存のログイン状態、または異なるプロキシ経路を使用している可能性があります。クライアントのログにサブスクリプション本文の取得成功と0件ではないノード数が記録されて初めて、ダウンロードと解析の両方が完了したと判断できます。
結果に応じて対処法を選ぶ
前述の確認が終わったら、問題をリンク権限、ネットワーク通信、内容のエンコード、クライアント互換性、ノード接続の5分類のいずれかに整理します。1回につき1つの変数だけを変更し、更新前後のノード数、レスポンスステータス、エラー文を記録します。DNS、クライアント、サブスクリプションURLを同時に変更すると、本当の原因を判断できなくなります。
古いノードは接続できるのにサブスクリプション更新で401、403、期限切れの表示が出る場合は、有効なURLを再取得します。URLから完全な内容が返るのにクライアントで0件になる場合は、クライアントを更新して形式を確認します。ノードは解析できるのに遅延テストが失敗する場合は、ノードのサーバー、ポート、通信方式、TLSパラメーター、ルーティング設定を確認します。
レスポンスステータスを確認する
200、401、403、404、429、またはタイムアウトの結果を記録します。200以外のレスポンスでは、まず権限、パス、リクエスト頻度を確認します。
本文の種類を確認する
Base64テキスト、行単位のノードURL、JSON、HTMLページ、空のレスポンスを区別し、ダウンロード成功を解析成功と取り違えないようにします。
ノード数を確認する
更新前後の件数を比較します。追加が0件ならエンコードとフィルター条件を確認し、件数が正常なら遅延テストに進みます。
重要なログを保存する
時刻、クライアントのバージョン、エラー原文、レスポンスサイズを保存します。詳細なサブスクリプションURL、ノードアドレス、アクセストークンを削除してから、追加の調査に使用してください。
項目ごとに対処する
1回の確認では、URLの再コピー、ネットワークの切り替え、クライアントの更新、フィルターの解除など、1つの変数だけを変更します。その後に再テストし、結果を記録してください。
症状：更新成功なのにノード数が0
原因と対処：リクエストは成功したものの、本文が空、形式に互換性がない、またはノードがフィルターで非表示になっています。レスポンスの種類を確認し、クライアントを更新して一覧のフィルターを解除します。
症状：古いノードは使えるが、新しいサブスクリプションを更新できない
原因と対処：動作中のノード接続とサブスクリプションURLの読み取りは別の通信経路です。古い設定を残したまま、サブスクリプションのトークン、ドメイン解決、更新経路を確認します。
症状：ノードはインポートできたが、遅延テストがすべて失敗する
原因と対処：サブスクリプションの解析は完了しており、問題はノード接続の段階に移っています。サーバーアドレス、リモートポート、UUID、通信方式、TLS、システムルーティングを確認します。