まず、サブスクリプションへのリクエストが完了していないのか、取得した内容を解析できないのかを切り分けます。v2rayNでサブスクリプションを管理していて、更新がタイムアウトする、またはノード一覧が空になる場合に役立つ手順です。URL、応答内容、エンコード、形式、更新経路を順に確認し、最後にグループ内の件数とログで結果を確かめます。サブスクリプションの問題をノードの接続障害と混同しないようにしましょう。
更新失敗と解析結果が空の状態を切り分ける
サブスクリプションの更新は、URLへのリクエスト、応答内容の取得、内容からノードへの変換という3段階で行われます。タイムアウトは通常、最初の段階で発生します。形式エラーは後の段階で起きることが多いです。ノードの遅延テストはインポート完了後に行う別の操作です。「ノードがタイムアウトした」というだけで、サブスクリプションURLが無効だとは判断できません。
v2rayNのログまたは更新結果画面を開き、今回の更新時刻、サブスクリプショングループ、エラーの原文を控えます。まずは1つのグループだけを更新し、すべての配信元を同時に更新しないでください。画面のグループフィルターと検索欄もクリアします。ノードはすでに追加されていて、現在の絞り込み条件で隠れているだけかもしれません。
- 待ち続けた後にタイムアウトする：サブスクリプションのドメイン名解決、ネットワーク接続、直結またはプロキシ経由の更新経路を確認します。
- 401または403が返る：サブスクリプションの認証、URLの有効期限、サーバー側のアクセス制限を確認します。
- ダウンロードは完了したがノードが0件：応答がWebページや空の内容ではないか、対応していない設定形式ではないかを確認します。
- ノードは表示されるが接続できない：何度もインポートするのはやめ、ノードの設定値、コアの互換性、接続ログを確認します。
サブスクリプションURLを確認：アカウントページをURLとして使わない
サブスクリプション提供元のアカウントページから、使用中のクライアントに対応したサブスクリプションURLをコピーし直します。アカウントのログインページ、プラン案内ページ、ノードの共有リンクはそれぞれ別のものです。リモートサブスクリプションは通常、https://で始まるURLです。一方、vmess://やvless://などは通常、単一ノードの共有リンクを示すため、ノードのインポート機能を使います。
-
URLをコピーし直す
提供元のページでv2rayN向けのサブスクリプション項目を選び、URL全体をコピーします。チャットのスクリーンショットから文字を読み取ったり、省略表示されたプレビューをコピーしたりしないでください。
-
文字列を確認する
ローカルのテキストエディターでURLの先頭と末尾を確認し、誤って含まれた引用符、空白、改行を取り除きます。パス、疑問符、等号、パーセント記号、クエリパラメーターはそのまま保持し、URLを手作業で並べ替えたりデコードしたりしないでください。
-
グループを編集する
v2rayNのメイン画面で「サブスクリプショングループ」→「サブスクリプショングループ設定」を開き、対象グループのURLを編集して保存します。メニュー名はバージョンによって多少異なることがあります。個別ノードの編集画面ではなく、サブスクリプションURLを管理する画面を開いてください。
-
1つのグループを更新する
対象グループを選択し、「サブスクリプショングループ」メニューから「現在のサブスクリプションを更新（プロキシを使用しない）」を実行します。まずこの方法での結果を記録し、失敗した場合はプロキシ経由での更新結果と比べます。
提供元がサブスクリプショントークンをリセットしていると、アカウントの有効期限内でも古いURLはすぐに無効になることがあります。URLをコピーし直したら、グループの古いURLを置き換えてください。新しいURLを古いURLの後ろに追加してはいけません。PCの時刻も確認します。時刻が大きくずれているとHTTPS証明書の検証に失敗し、内容の解析ではなくダウンロードのエラーとして現れることがあります。
HTTP応答を確認：200でもノードを取得できたとは限らない
以下の3つはHTTPステータスコードであり、クライアントのバージョンやノード数ではありません。更新ログのステータスコードを確認すると、更新ボタンを何度も押すより原因を絞り込めます。ログにステータスコードがなくても、タイムアウトをサーバーによる拒否と決めつけないでください。
ブラウザーでURLを開けても、クライアントが同じ内容を取得できるとは限りません。ブラウザーではログイン状態が維持されていたり、Web認証を通過していたり、別のネットワーク経路を使っていたりすることがあります。クライアント側ではログイン案内、アクセス制限の説明、CAPTCHAページが返る場合があります。こうしたページはHTTP 200でも、ノードのサブスクリプションとして解析できません。
Response status code does not indicate success: 403 (Forbidden).
原因：サブスクリプションサーバーがリクエストを拒否しています。トークン、接続元のIPアドレス、アクセス方針などが関係している可能性があります。対処：有効なサブスクリプションURLをコピーし直してアカウントの状態を確認し、クライアント用のサブスクリプションURLとアクセス制限について提供元に問い合わせます。
The operation has timed out.
原因：制限時間内にリクエストが完了していません。これだけではURLの有効期限切れとは判断できません。対処：直結とプロキシ経由の両方で更新を試し、現在のネットワークで事前のログイン認証が必要か確認します。
The SSL connection could not be established, see inner exception.
原因：HTTPS接続を確立できませんでした。詳しい原因は後続のエラーを確認してください。対処：まずシステム時刻を合わせ、証明書エラーやネットワークのブロックに関する表示を確認します。証明書検証を無効にしないでください。
結論：まず応答内容を確認し、その後にエンコードを調べる
応答がログインページ、CAPTCHAページ、有効期限切れの通知なら、サブスクリプションURLやアクセス条件を見直します。こうしたページを何度Base64デコードしても、インポートできるノードにはなりません。
Base64と共有リンクの形式を確認：正しい階層だけをデコード
従来型のサブスクリプションでは、複数の共有リンクを1行ずつ並べたテキスト全体をBase64エンコードする形式がよく使われます。デコードせず、平文のリンクを返す場合もあります。Base64はテキストのエンコード方式にすぎず、内容が有効であることや、クライアントが含まれるプロトコルに対応していることを保証しません。まず応答内容を見分け、必要な場合だけローカルでデコード結果を確認します。
| ローカルで確認できる内容 | 考えられる内容 | 対処方法 |
|---|---|---|
| 複数行のプロトコル共有リンク | 平文のノード一覧 | 各行が完全なリンクか確認し、対応する形式のインポート機能を使います。 |
| 連続したエンコード文字列 | Base64形式のサブスクリプションの可能性 | ローカルで1回だけデコードし、完全な共有リンクになっているか確認します。 |
| HTMLタグで始まる | Webページまたはエラーページ | サブスクリプションURL、ログイン状態、サーバー側の制限を確認し直します。 |
| JSONまたはYAML形式の設定 | 別の設定出力形式 | 提供元で互換性のあるサブスクリプション出力を選びます。ファイルの拡張子を変えるだけでは解決しません。 |
| 空白または期限切れの通知 | ノードがない、またはアカウントの状態に問題がある | 利用上限、有効期限、提供元によるノードの割り当て状況を確認します。 |
VMess共有リンクは、通常、プレフィックスの後にエンコードされた設定内容が続きます。VLESS共有リンクはURI形式のフィールドとクエリパラメーターを使います。互いのプレフィックスを置き換えて使うことはできません。外側のサブスクリプションをデコードしてvmess://で始まる完全なリンクが得られたら、その行全体を外側のBase64として何度もデコードしないでください。
- 構造上の文字を保持：URI内の
%を手作業で置き換えたり、パラメーター間の&を日本語の句読点に変えたりしないでください。 - コピー元に注意：URLに
&のようなHTMLエンティティが実際に含まれている場合は、元のページに戻ってコピー用ボタンを使い、ページのソースコードからコピーしないようにします。 - むやみに補完しない：Base64には標準形式とURLセーフ形式があり、パディング文字の扱いも異なる場合があります。デコードエラーが出たら、まず文字列が途中で切れていないか確認してください。イコール記号を何度も追加するだけでは解決しません。
- 利用可能なフィールドを確認：プロトコル名を認識できても、すべてのトランスポートパラメーターに現在のクライアントやコアが対応しているとは限りません。未対応のフィールドを記録し、提供元に互換性のある設定を依頼します。
v2rayNはデスクトップ向けの設定管理クライアントです。インポート形式への対応だけでなく、実際に使うコアも確認してください。Android版のv2rayNGはXrayコア、v2flyNGはv2flyコアを使用しており、3つのクライアントが完全に同じ機能に対応しているとは限りません。一部の種類のノードだけが表示されない場合は、サブスクリプション全体が壊れていると判断する前に、形式と機能の対応状況を比べてください。
更新経路を切り替える：直結とプロキシ経由を個別にテスト
サブスクリプションのダウンロード経路と、ブラウザーでシステムプロキシを有効にする設定は同じではありません。v2rayNには複数のサブスクリプション更新コマンドがあるため、実際に選んだコマンドを確認してください。システムプロキシを有効にしても、以前失敗した更新処理が自動的にプロキシ経由になるとは限りません。
-
既存のノードを確認
すでにインポート済みで接続できるノードを1つ選び、コアが実行中であることを確認します。プロキシ経由の更新には利用可能なプロキシが必要です。ノード一覧が空の状態では、この接続を新たに確立できません。
-
プロキシ経由で更新
「サブスクリプショングループ」→「現在のサブスクリプションを更新（プロキシを使用）」を開きます。同じサブスクリプションURLとグループのまま更新経路だけを変え、タイムアウトが続くか、どのステータスコードが返るかを記録します。
-
ローカルの待ち受け設定を確認
ログにローカル接続の拒否が表示された場合は、「設定」→「パラメーター設定」を開き、ローカルの待ち受けポートとコアの実行状態を確認します。設定によっては10808を使いますが、実際のポートは現在の設定に従ってください。他の端末の値をそのまま使わないでください。
-
2つの結果を比較
直結では失敗し、プロキシ経由では成功するなら、アクセス経路に違いがあります。どちらも同じ認証エラーになる場合は、URLとアカウントを再確認してください。サーバーの認証問題を直すためにノードのプロトコルを変更し続けないでください。
更新後の確認：グループ、件数、接続結果をチェック
「更新完了」と表示されたら、対象グループに切り替えて検索欄をクリアし、ノード数を確認します。追加ノード数が0でも、インポートに失敗したとは限りません。ログには追加件数が記録され、既存の設定に変更がなければ0になることがあります。グループ内のノードと更新ログを合わせて判断してください。
- 対象グループを確認：編集と更新を行ったグループが同じであることを確認します。別のグループの一覧を結果と取り違えないようにしてください。
- フィルター設定を確認：サブスクリプショングループの設定で絞り込み条件を確認し、名前の条件を一時的に緩めて再試行します。
- ノードを1つ確認：アドレス、ポート、トランスポート、TLSの設定がそろっているか確認します。認証情報などの機密項目はローカルでのみ確認してください。
- 接続テストは別に行う：インポートできたノードを1つ選んで接続し、コアのログを確認します。遅延の数値だけでWebサイトへのアクセス可否を判断しないでください。
- 確認内容を記録：更新方法、ステータスコード、応答本文の有無、グループ内のノード数を記録します。提供元への問い合わせには、個人情報を隠した内容だけを使ってください。
サブスクリプション管理のよくある質問
ブラウザーではサブスクリプションを開けるのに、v2rayNの更新に失敗するのはなぜですか？
まず、ブラウザーに表示されているのがアカウントページではなくノードの内容か確認します。次に、プロキシを使わない更新とプロキシ経由の更新をそれぞれ試してください。ブラウザーとクライアントでは、ログイン状態、認証手順、ネットワーク経路が異なる場合があります。クライアントだけが拒否される場合は、対応するサブスクリプションURLとリクエスト制限を提供元に確認します。
同じサブスクリプションのノードが一部しかインポートされません。再インストールが必要ですか？
まずサブスクリプショングループの絞り込み条件と検索条件を確認し、次にスキップされたノードのプロトコル、トランスポート設定、ログを確認します。クライアントのダウンロードページで利用するプラットフォームに合ったバージョンを選び、設定をバックアップしてからクライアントを更新してください。設定を先にすべて消去しないでください。再インストールしても、元の形式に互換性がなければ解決しません。
ノード一覧が空でも、プロキシ経由の更新で復旧できますか？
この方法を使えるのは、クライアントに接続可能なノードが別にあり、コアが正常に動作している場合だけです。すべてのグループが空なら、ローカルのバックアップを復元する、提供元から有効な単一ノードを取得する、またはサブスクリプションに直結できるネットワークに切り替えてから更新してください。
サブスクリプションをオンライン変換ツールに貼り付けて試してもよいですか？
提供元が用意する互換形式の出力と、ローカルでの確認方法を優先してください。サブスクリプションURLには通常アクセス権限が含まれているため、外部ツールに送信すると、その運営者にURLを知られるおそれがあります。誤って公開した場合は、提供元のアカウントでサブスクリプショントークンをリセットし、クライアントの古いURLを置き換えてください。
ここまで確認すれば、問題の原因は通常、URLの認証、ネットワークリクエスト、応答形式、クライアントの互換性のいずれかに絞れます。以降は一度に1項目だけ変更し、同じグループで再テストしてください。どの変更が有効だったかを判断しやすくなり、繰り返しインポートして元の接続可能な設定を失うことも防げます。