V2Rayのサブスクリプションが無効・解析できないときの確認リスト：リンク形式から更新プロキシまで順番にチェック

サブスクリプションの更新は、単一の操作ではありません。クライアントはまずリンクを読み込み、ドメインを解決して HTTPS 接続を確立し、レスポンス本文を取得します。続いてエンコードとノードのプロトコルを判別し、最後に VMess や VLESS などの項目を現在のサブスクリプショングループへ書き込みます。どの段階で失敗しても、画面上では「更新に失敗」や「ノード数 0」と表示されることがあります。そのため、何度も更新ボタンを押すのではなく、まず失敗した段階を特定することが重要です。

まず障害がどの段階で起きているかを確認

操作を始める前に、更新日時、クライアントのバージョン、使用中のサブスクリプショングループ、エラー原文を記録します。先に元のグループを削除しないでください。古いノード、グループ設定、更新ログが判断材料になります。クライアントでログをコピーできる場合は、更新を押す5秒前からエラー表示後10秒までの範囲を保存します。

ブラウザーとクライアントの両方で同じサブスクリプションアドレスを開けない場合は、まずリンクの状態、ドメイン解決、アクセス権を確認します。ブラウザーではテキストを取得できるのに、クライアントで Base64、JSON、プロトコル形式のエラーが出る場合は、問題は本文の解析層に近いと考えられます。更新が成功しノードも追加されたのに、すべてのノードで遅延テストに失敗する場合は、サブスクリプション自体は読み込めています。次はノードのアドレス、ポート、トランスポート層、ルーティング設定を確認します。

• 接続層：タイムアウト、接続拒否、TLS ハンドシェイク失敗、ドメイン解決失敗などが典型です。
• レスポンス層：HTTP 401、403、404、429、またはサブスクリプション本文ではなくログインページが返るケースが典型です。
• 解析層：Base64 の長さエラー、JSON 構造エラー、プロトコルの接頭辞を認識できないなどが典型です。
• 書き込み層：更新は完了したのにノード数が 0、またはフィルターですべてのノードが除外されるケースが典型です。
• 接続テスト層：ノードは表示されるものの、TCP 遅延がタイムアウトし、実際の接続も確立できない状態です。

サブスクリプションリンク、レスポンス状態、有効期限を確認

サブスクリプションリンクには、アクセストークン、ユーザー識別子、デバイス用パラメーター、有効期限などが含まれる場合があります。コピー時に1文字欠けたり、末尾に空白が入ったり、チャットツールでクエリパラメーターが切り取られたりすると、サーバーはエラーページを返します。元の管理画面から完全なアドレスをコピーし、手入力で組み立てないでください。複数のアドレスを1つの入力欄に入れるのも避けます。

1. 先頭と末尾を確認

   アドレスが https:// で始まり、先頭の前後や末尾の後ろに空白、改行、全角の句読点がないことを確認します。クエリパラメーターを含めて完全にコピーし、特に疑問符の後ろにあるトークンを省略しないでください。

2. 単独でアクセス

   現在の端末のブラウザーでリンクを開き、テキストが直接返るか、ファイルのダウンロードが始まるか、ログインページへ移動するか、401、403、404、429 などのステータスが表示されるかを記録します。

3. 有効期限を確認

   サブスクリプションの提供元の管理画面を開き、アカウント状態、有効期限、通信量の残量、サブスクリプションが再生成されていないかを確認します。アドレスがリセットされると、古いトークンは通常使えなくなります。

4. キャッシュの影響を除外

   60秒空けてからもう一度リクエストします。最初に 429 が返った場合、連続クリックするとレート制限の時間が延びるだけです。サーバーが次のリクエストを受け付けるまで待ちます。

ブラウザーで「開ける」ことは、レスポンスを解析できることを意味しません。正常なサブスクリプション本文は、長いエンコード済みテキスト、プロトコルリンクの一覧、またはクライアントが対応する構造化データであることが一般的です。ナビゲーション、認証画面、ログインフォーム、エラー説明が含まれているなら、それはWebページのレスポンスです。クライアントが HTTP 200 を受け取っても、本文の種類が合わず解析エラーになることがあります。

サブスクリプション更新時のネットワーク経路を確認

「現在のノードでネットワークに接続できる」ことと、「サブスクリプションの更新リクエストが現在のノードを経由する」ことは別です。ブラウザーの通信はシステムプロキシ経由でも、サブスクリプション更新は直接接続になっている場合があります。逆に、コアが起動していない状態でプロキシ経由の更新を有効にすると、待ち受けていないローカルポートへリクエストが送られることもあります。

v2rayNで2つの経路をテスト

1. コアを確認

   まず、まだ利用できる古いノードを選択してコアを起動し、メイン画面下部の状態を確認します。一般的なローカル SOCKS ポートは 10808、HTTP ポートは 10809 ですが、実際の値は「設定」→「パラメーター設定」にあるローカル待ち受け設定を優先します。

2. 直接接続をテスト

   「サブスクリプショングループ」を開き、「すべてのサブスクリプションを更新（プロキシを使用しない）」を実行します。所要時間、HTTP ステータス、ノード数の変化を記録します。

3. プロキシ接続をテスト

   もう一度「サブスクリプショングループ」を開き、「すべてのサブスクリプションを更新」を実行します。現在のプロキシ設定でリクエストを送信し、直接接続の結果と比較します。

4. ポートを確認

   「設定」→「パラメーター設定」を開き、サブスクリプション更新に使うローカルアドレスと実際の待ち受けポートが一致していることを確認します。変更後にコアを再起動し、もう一度更新します。

v2rayNGとv2flyNGのネットワーク確認

Android 端末では、まずメイン画面の接続スイッチが有効になっていることを確認してからサブスクリプションを更新します。v2rayNG は Xray コア、v2flyNG は v2fly コアを使用しますが、サブスクリプションのリクエスト結果はアプリのネットワーク、プロキシ状態、システムによるバックグラウンド通信の制限にも左右されます。一般的なローカル SOCKS 待ち受けポートは 10808 ですが、確認時はアプリの設定画面に表示されるポートを優先してください。

• サイドメニューから「サブスクリプショングループ設定」を開き、対象グループが有効で、アドレスが古い内容で上書きされていないことを確認します。
• メイン画面に戻り、右上のメニューから「サブスクリプションを更新」を実行します。タイムアウト、解析失敗、更新完了のどれが表示されるかを確認します。
• 現在のネットワークと、別の利用可能なネットワークでそれぞれ1回ずつテストします。サブスクリプションアドレスやコア設定を同時に変更せず、ネットワーク条件だけを変えてください。
• 接続スイッチを有効にするとすぐ切断される場合は、まずコアの起動エラーを解決してから「プロキシ経由の更新」をテストします。

サブスクリプション本文のエンコードとプロトコル形式を確認

接続に成功した後、クライアントはレスポンス本文の形式を判別する必要があります。よくあるのは、Base64 でエンコードされた複数行のノードリンク、またはプロトコル名から始まるリンクを直接含む形式です。デコード後も各レコードは対応するプロトコルの必須項目を満たす必要があります。VMess にはエンコードされた JSON が含まれることが多く、VLESS では通常、ユーザー識別子、サーバー、ポート、トランスポートパラメーターを URI に記述します。

認識可能な項目の構造例：
vmess://エンコード済みノード設定
vless://ユーザー識別子@サーバーアドレス:ポート?type=ws&security=tls
trojan://認証情報@サーバーアドレス:ポート?security=tls

確認ポイント：
1. 各レコードが1行で完結しているか
2. プロトコルの接頭辞が半角文字か
3. ポートが 1～65535 の整数か
4. クエリパラメーターの区切りに & を使っているか
5. レスポンスにWebページ、エラー説明、空白の内容が混入していないか

標準 Base64 では、英字、数字、プラス、スラッシュ、末尾のイコール記号が使われます。URL セーフな形式では、ハイフンやアンダースコアが使われることがあります。クライアントは一般的な形式に対応していることが多いものの、コピー時の切り捨て、本文冒頭への案内文の挿入、誤った改行変換によって長さが壊れることがあります。「修復」のために文字を適当に追加しないでください。デコードできても、ノード項目が完全とは限りません。

ノード名に含まれる中国語、空白、特殊記号は、正しくエンコードする必要があります。1件だけ失敗する場合は、サブスクリプション本文を行単位で確認し、いつも同じ項目の近くで失敗していないかを見ます。異常な1件を削除すると残りをインポートできるなら、ネットワークと全体のエンコードはおおむね正常で、問題はそのノードの項目またはエスケープ方法に絞れます。

• VMess：デコード後の JSON が閉じているか、アドレス、ポート、ユーザー識別子、トランスポート形式が存在するかを確認します。
• VLESS：ユーザー識別子とサーバーの間に @ があり、ポート後のパラメーターに半角の疑問符と区切り記号が使われているか確認します。
• TLS パラメーター：サーバー名、フィンガープリント、安全タイプがサーバー側の設定と一致している必要があります。項目を解析できても、ハンドシェイクの成功までは保証されません。
• WebSocket パラメーター：パス内のスラッシュや特殊文字はエンコードされた状態を保ち、サブスクリプション生成時に二重変換されないようにします。
• 空のレスポンス：HTTP ステータスが正常でも本文の長さが 0 なら、クライアントに書き込める項目はありません。サブスクリプション生成側を確認します。

クライアントのバージョン、コア、グループ設定

同じサブスクリプションが旧バージョンでは失敗し、新バージョンでは成功する場合、プロトコル項目、共有リンク形式、コアの対応状況が変わった可能性があります。v2rayN 7.x と初期の 6.x では、画面や一部の設定入口が異なります。v2rayNG 1.10.x には、一部の 1.8.x より新しい Xray コアとインポート処理が含まれています。確認記録には「最新版」ではなく、完全なバージョン番号を記載してください。

1. バージョンを記録

   クライアントの完全なバージョンとコアのバージョンを記録します。たとえば「7.x」だけでは解析動作を比較できないため、バージョン情報画面に表示されるすべての番号を残してください。

2. クライアントを更新

   当サイトのダウンロードページから現在の安定版を入手し、古いプロセスを終了してから、対象プラットフォームに合わせて更新します。上書き後に障害の状況を失わないよう、元の設定のコピーを保存してください。

3. グループを新規作成

   すぐに古いグループを変更しないでください。「サブスクリプショングループ」→「サブスクリプショングループ設定」でテスト用グループを新規作成し、同じアドレスを貼り付けて1回更新します。

4. フィルターを無効化

   一時的に、包含、除外、正規表現フィルター、重複除去の条件をすべて空にします。ノード数が 0 から具体的な数に戻るなら、原因はグループのフィルターであり、サブスクリプション解析ではありません。

5. 件数を比較

   サーバーに表示されるノード数、クライアントのインポート数、フィルターで除外された数を記録します。たとえば提供元が24件、クライアントへの書き込みが0件なら、まず形式またはフィルターを確認します。23件が書き込まれるなら、単一の異常レコードを確認します。

グループフィルターは「更新成功なのに一覧が空になる」代表的な原因です。包含ルールは名前が一致するノードだけを残し、除外ルールは一致するノードを取り除きます。正規表現でドットやワイルドカードの範囲を広くしすぎると、すべての項目が除外されることがあります。テスト時はフィルターをすべて空にしてから、ルールを1つずつ戻し、毎回ノード数の変化を記録します。

更新は成功したのにノードが使えない

サブスクリプションを更新できたことから分かるのは、クライアントが設定を取得して解析できたことだけです。すべてのノードがオンラインであるとは限りません。次に、サーバーアドレスの解決、対象ポート、トランスポート方式、TLS パラメーター、システム時刻、ルーティングを確認します。この段階では、リンクはすでに役割を果たしているため、サブスクリプションリンクを変更し続けないでください。

• まず TCP 遅延テストを実行します。20個のノードがほぼ同じタイミングでタイムアウトするなら、ローカルネットワーク、DNS、または共通のサーバードメインを優先して確認します。
• 1つのノードだけ失敗する場合は、利用可能なノードとアドレス、ポート、トランスポート形式、安全パラメーターを比較します。
• システム時刻のずれは TLS 証明書の有効期限判定に影響します。日付、時刻、タイムゾーンの自動同期を有効にしてください。
• ルーティングモードで、ノードのサーバーアドレスが誤ってプロキシの出力先へ戻され、接続ループになっていないか確認します。
• システムプロキシのポートとクライアントの待ち受けポートが一致していることを確認します。v2rayN の一般的な HTTP ポートは 10809 ですが、実際の設定が優先されます。

遅延テストの結果も種類を分けて読み取る必要があります。TCP 遅延で確認できるのは対象ポートへの接続確立だけで、VMess、VLESS、TLS、WebSocket のセッション全体を検証できるわけではありません。実際の接続テストでは認証、トランスポート層のカプセル化、ルーティングも通過するため、「TCP は 80 ミリ秒なのにアクセスできない」場合は、ポート以降のプロトコルパラメーターに問題があることが多いです。

接続を最小構成で検証

1. 項目が完全で名前も分かりやすいノードを1つ選び、複雑なルーティングルールを一時的に無効にします。
2. コアを起動し、ローカル SOCKS または HTTP ポートが待ち受け状態になっていることを確認します。
3. 干渉する通信を避けるため、テスト対象のアプリ1つだけをプロキシ経由にします。
4. 後続の再試行ではなく、ログに最初に現れたエラーを確認します。
5. ルーティングルールを戻して再テストします。この時点で失敗するなら、問題は分岐条件または出力先のタグに絞られます。

10分でできる再利用可能な確認手順

複雑な問題は段階的に調べるのが適していますが、日常のトラブル対処には決まった順序が必要です。以下の手順では、発生しやすく低コストな確認を先に行い、いきなりクライアントを再インストールしたり、設定をすべて作り直したりする事態を避けます。各手順の結果、特にレスポンスステータス、所要時間、ノード数、エラー原文を記録してください。

1. 状況を保存

   クライアントとコアのバージョンを記録し、古いグループ、更新日時、ノード数、最初のエラーログを保存します。

2. リンクを再コピー

   元の管理画面から完全なサブスクリプションアドレスをコピーし、先頭と末尾の空白、改行、トークン、有効期限を確認します。

3. レスポンスを確認

   返っているのがサブスクリプション本文であり、ログインページ、認証画面、空ページ、401、403、404、429 のいずれでもないことを確認します。

4. 経路を切り替え

   直接接続での更新とプロキシ経由の更新をそれぞれテストし、10808、10809 などのローカルポートが実際の設定と一致しているか確認します。

5. グループを新規作成

   空のテストグループに同じアドレスをインポートし、包含、除外、正規表現フィルター、重複除去の条件を無効にします。

6. ノードを検証

   更新に成功したら TCP と実際の接続をテストし、DNS、ポート、TLS、トランスポート層、ルーティングの順に切り分けます。

手順が2番目で止まるなら、通常はリンクまたはアカウント状態の問題です。3番目ならサーバーのレスポンスまたはアクセス制限、4番目ならネットワーク経路またはローカルポート、5番目なら形式、バージョン、フィルターの問題が考えられます。最初の5段階をすべて通過して初めて、ノードのプロトコルやサーバー設定を詳しく調べます。

よくある質問