v2rayN、v2rayNG、v2flyNGでサブスクリプションを更新できない、または更新完了後もノードが表示されない場合に役立つ内容です。まず、失敗がリクエスト、レスポンス、解析、フィルタリングのどの段階で起きているかを確認し、サブスクリプションURL、更新時のネットワーク、レスポンス形式、グループのフィルターを順に調べます。設定は一度に一つだけ変更し、利用できる元の設定は残しておきましょう。
1. リクエスト失敗と解析結果が空の状態を見分ける
「サブスクリプション更新失敗」は、原因が一つとは限りません。クライアントはまずサブスクリプションURLへHTTPリクエストを送り、受信した内容の形式を判別してから、解析したノードをグループに登録し、画面に表示します。タイムアウトは、内容をまだ取得できていない可能性があります。解析エラーが出ても、受信内容が有効なサブスクリプションとは限りません。一覧が空の場合は、グループの選択や検索条件が原因のこともあります。
調査を始める前に、クライアントのログまたは更新結果のメッセージを開き、最初のエラーと発生時刻を記録します。ノード接続時のコアログを、サブスクリプション取得時のログと混同しないでください。サブスクリプションはクライアント内蔵のネットワーク機能で取得し、ノード接続は選択中のコアが処理することがあります。両者のエラーは別々に確認する必要があります。
- 待ち続けた後にタイムアウトする:サブスクリプションのドメイン名解決、ネットワーク接続、プロキシ経由で更新しているかを確認します。
- すぐに解析エラーが出る:レスポンスがログイン画面やエラーページではないか、設定形式がクライアントに対応しているかを確認します。
- 更新完了と表示されるのに一覧が空:対象のグループに切り替えて検索条件を消し、フィルター設定を確認します。
- ノードは表示されるが接続できない:サブスクリプションのインポートはおおむね完了しています。サーバーアドレス、ポート、プロトコルのパラメーター、TLS設定を別途確認してください。
2. サブスクリプションURLとアカウント状態を確認する
サブスクリプションURLは、サービス提供元のトップページやログイン後の管理画面とは異なります。提供元の「サブスクリプションリンクをコピー」などの機能、またはクライアントに対応したメニューからURLをコピーし、サブスクリプショングループのURL欄に貼り付けてください。URLにはアクセス情報が含まれることが多いため、公開フォーラムに全文を投稿したり、オンラインのデコードサービスやサブスクリプション変換サイトに入力したりしないでください。
-
元の設定を残す
まずクライアントの設定をバックアップするか、元のサブスクリプショングループを残します。新しいURLが有効だと確認する前に、唯一使えるノードを削除したり、一覧の消去と再インポートを繰り返したりしないでください。
-
リンクを再取得する
サービス提供元のアカウントページで、サブスクリプションの有効期限と利用権限を確認し、クライアント互換のURLをコピーし直します。サブスクリプションをリセットした場合、以前のURLは無効になっている可能性があります。
-
文字列を確認する
URLの先頭、末尾、クエリパラメーターを手元で確認し、コピー時に混入した空白、改行、引用符を削除します。疑問符以降のパラメーターを勝手に削除したり、半角記号を全角に変えたりしないでください。
-
対象のグループだけ更新する
v2rayNでは「サブスクリプショングループ」から「サブスクリプショングループ設定」を開き、URLを確認できます。v2rayNGではサイドメニューから「サブスクリプショングループ設定」を開きます。保存したら、調査対象のグループだけを更新し、別のサブスクリプションのエラーが混ざらないようにしてください。
バージョンによってメニュー名が多少異なる場合があります。現在の画面にあるサブスクリプショングループの編集項目を確認してください。v2flyNGもメニューと設定を個別に確認し、画面が似ているからといって更新方法まで同じだと決めつけないようにします。チャットで受け取ったリンクは、末尾に日本語の句点が混ざっていないか確認してください。ウェブページのソースからコピーした場合は、パラメーターの区切り文字が誤ってコピーされていないかにも注意します(&)。
3. 更新時に無効なプロキシを経由していないか確認する
「プロキシ経由で更新する」こと自体は問題ではありません。問題になるのは、使用中のプロキシが利用できるかどうかです。無効になったノード経由で新しいサブスクリプションを取得しようとすると、古いノードに接続できず、サブスクリプションのリクエストもタイムアウトするという依存のループに陥ります。一方、ネットワークによってはサブスクリプションのドメインに直接接続できないため、直結を強制しても解決しません。
エラー:The operation has timed out
原因と対処:制限時間内にリクエストが完了しなかった状態ですが、これだけでアカウントの期限切れとは判断できません。プロキシを使わない方法と、利用可能と確認済みのプロキシを使う方法をそれぞれ試し、サブスクリプションのドメインに接続できるか確認してください。
エラー:No such host is known
原因と対処:リクエスト先のホスト名を解決できません。ログに表示されたホスト名がサブスクリプションサーバーかプロキシサーバーかを確認し、スペルと現在のネットワークのDNS設定を調べてください。ノードのプロトコルをすぐに変更する必要はありません。
エラー:Connection refused
原因と対処:接続先のポートで接続が拒否されました。エラーの接続先がサブスクリプションサーバーか、ローカルのプロキシ待ち受けポートかを確認します。ローカルポートの場合は、クライアントのコアが起動していることと、ポート番号がプロキシ設定と一致していることを確認してください。
該当メニューがあるバージョンのv2rayNでは、「サブスクリプショングループ」から「プロキシを使用しない」と記載された更新項目を選び、「プロキシ経由」の更新と比較できます。v2rayNGの「設定」に「プロキシ経由でサブスクリプションを更新する」項目がある場合は、元の状態を記録してから一度切り替え、現在のグループを更新してください。その項目がないバージョンでは、他のクライアントの手順をそのまま適用しないでください。
- プロキシを使わないと更新でき、プロキシ経由では失敗する場合は、選択中のノードとローカルのプロキシ待ち受け状態を優先して確認します。
- 利用可能なプロキシ経由では更新でき、直結では失敗する場合は、更新できる経路を維持したうえで、ローカルネットワークの名前解決やアクセス制限を調べます。
- どちらの方法でも失敗する場合は、HTTPステータスとレスポンス内容を確認します。ルーティングモードを何度も切り替えて試すのは避けてください。
- TUNも有効にしている場合、「プロキシを使用しない」は通常、アプリケーション層のリクエスト方法を示すものであり、パケットが仮想ネットワークインターフェースを必ず迂回するとは限りません。必要に応じて現在の状態を記録し、TUNを一時的に無効にして結果を比較します。
4. ステータスコードとレスポンス内容から原因を絞り込む
サブスクリプションのドメインのトップページを開けても、サブスクリプションAPIが有効とは限りません。HTTPの200もリクエストが成功したことを示すだけで、内容の解析まで保証するものではありません。ログにステータスコードが表示されている場合は、次の表を使って原因を絞り込みます。クライアントにレスポンス本文が表示されない場合は、サービス提供元にAPIエラーの説明を問い合わせてください。ローカルでレスポンスを確認する必要があるときは、信頼できる端末だけで扱い、認証情報を含む内容を同期または転送しないようにします。
| 確認できた結果 | 考えられる状態 | 次に行うこと |
|---|---|---|
| HTTP 401 | APIが有効な認証を要求しているが、現在の認証情報が受け付けられていない | ログイン済みのアカウントからサブスクリプションURLをコピーし直し、利用権限を確認する |
| HTTP 403 | サーバーがリクエストを拒否している。アクセス制御に該当した可能性もある | サーバー側のエラー説明を確認し、アカウントの期限切れと決めつけない |
| HTTP 404 または 410 | APIが存在しない、またはリソースが削除されている | 以前のサブスクリプション入口が移行されていないか確認し、最新のURLを取得する |
| HTTP 429 | 更新頻度が高すぎる、またはレート制限に達している | 更新を繰り返さず、レスポンスのRetry-Afterまたはサービス提供元の案内に従って待つ |
| HTTP 5xx | サーバーまたは中継ゲートウェイで処理エラーが発生している | ローカルのノードを残し、しばらく待ってから再試行し、サーバーの状態を確認する |
| HTTP 200、本文はHTML | ログイン画面、認証画面、エラーページが返されている可能性がある | サブスクリプション専用URLを使い、APIがブラウザー上の操作を必要としないか確認する |
| HTTP 204 または本文が空 | 解析できるレスポンス内容がない | サブスクリプションの利用権、サーバー側のノード割り当て、APIのレスポンスを確認する |
要点:まずサブスクリプションの内容を取得できているか確認する
ログイン画面、アクセス拒否、空のレスポンスが返された場合は、まずAPIと利用権の問題に対処します。レスポンスにクライアント対応のノード情報が含まれていると確認できてから、文字コードやフィルター設定を調べてください。
ブラウザーでは開けるのにクライアントでは失敗する場合、ブラウザーにログインCookieが保存されている、ウェブ上の認証が自動で完了している、または両者で異なるネットワーク経路を使っている可能性があります。そのため、ブラウザーのアドレスバーに表示されたページのURLをコピーしても解決しないことがあります。ログに証明書エラーが出る場合は、システム時刻、リクエスト先のドメイン、サーバー証明書を確認してください。証明書検証を無効にして、サブスクリプションAPIの問題を隠すのは避けてください。
5. Base64、共有リンク、設定形式を確認する
サブスクリプションはコンテンツを配布する方法であり、統一されたファイル形式ではありません。レスポンスには、ノードの共有リンクを1行ずつ並べたものや、リンク一覧全体をBase64でエンコードしたテキストなどがあります。対応形式はクライアントのバージョンによって異なり、サービス提供元の「汎用サブスクリプション」がすべてのクライアントで使えるとは限りません。
- サブスクリプション全体のエンコード:複数行の共有リンク全体をBase64でエンコードするサブスクリプションもあります。デコードすると
vmess://やvless://などの接頭辞が現れます。元のテキストに接頭辞が見当たらないからといって、内容が壊れているとは限りません。 - 個別の共有リンク:従来のVMess共有形式では、接頭辞の後にBase64エンコードされたJSONが含まれるのが一般的です。VLESSの共有リンクでは、通常URIパラメーターが使われます。すべてのプロトコルに対して一律に「2回デコード」しないでください。
- エンコード形式の違い:標準Base64とURLセーフ形式では使われる文字が異なり、末尾のパディングにも違いがあります。これらの形式を受け付けるかどうかはパーサーによって異なるため、文字を適当に置換して修正しようとしないでください。
- 完全な設定ファイル:コアのJSON設定ファイルは、サブスクリプションのリンク一覧とは別物です。あるメニューから完全な設定をインポートできても、「サブスクリプション更新」で同じ内容を読み込めるとは限りません。
- その他の形式:レスポンスの先頭にYAMLの項目、HTMLタグ、エラーメッセージなどがあり、現在のメニューが共有リンクを想定している場合は、サービス提供元が用意する互換性のあるサブスクリプションURLに切り替えてください。
エンコードを確認する必要がある場合はローカルのツールを使い、構造だけを調べてください。デコードした内容を第三者のサービスにアップロードしてはいけません。デコード後もHTMLのログイン画面が表示されるなら、問題はレスポンス内容にあります。リンクにサーバーアドレス、ポート、必須パラメーターが含まれていない場合は、サブスクリプションの提供元に修正を依頼してください。フィールドを手動で補っても正しい設定の代わりにはなりません。
6. 更新できても一覧が空の場合:フィルターと表示を確認する
通常、フィルタリングは内容を取得した後に行われます。サブスクリプションにノードが含まれ、クライアントが認識できていても、グループの包含・除外ルールや画面の検索条件によってすべて非表示になることがあります。まずメイン画面の検索欄を空にし、更新したグループを選択してください。別の空のグループを見て更新結果を判断しないようにします。
-
グループを確認する
サブスクリプショングループ名と保存されたURLを確認し、更新完了の表示が、現在見ているグループに対応しているか確かめます。同名の別グループや古いグループと取り違えないようにしてください。
-
フィルターを一時的に解除する
クライアントのグループ編集項目に現在のフィルター内容を記録してから、一時的に消去します。フィルター項目の内容はバージョンによって異なります。該当項目がなければ、検索条件を確認してください。
-
対象のグループだけ更新する
現在のグループだけを更新してログを確認します。ノードが再表示された場合は、サブスクリプションURLをリセットし続けるのではなく、フィルターの条件を見直してください。
-
条件を一つずつ戻す
条件を一つ戻すたびに、一覧を確認します。まず、その項目が「一致するものを残す」のか「一致するものを除外する」のかを確認し、次に通常のテキスト検索か正規表現かを確かめてください。
正規表現に対応すると明記された項目では、^$は通常、空文字列に一致し、.*は通常、長さを問わず任意の文字列に一致します。前者を包含条件に指定すると、空でない名前をすべて除外する可能性があります。後者を除外条件に指定すると、すべての項目を除外する可能性があります。通常のキーワードだけに対応する項目に正規表現を貼り付けないでください。また、複数キーワードの区切り文字がすべてのバージョンで同じだと決めつけないようにします。
要点:条件を消してからルールを戻す
フィルターと検索条件を消してノードが表示された場合は、サブスクリプションURLと更新経路は変えず、絞り込み条件だけを修正します。それでも一覧が空なら、レスポンス内容と形式の確認に戻ってください。
7. 再現時の記録を整理し、設定変更の繰り返しを防ぐ
ここまでの手順でも原因が特定できない場合、設定全体のスクリーンショットより、必要事項を絞った記録のほうが役立ちます。クライアントの更新で解析互換性が変わることがあるため、「最新版」とだけ書かず、正確なバージョン番号を記録してください。アップグレードする場合は、まず元の設定を残し、インストーラーのページから対応するOS向けのクライアントを選びます。最初からアンインストールして再インストールするのは避けてください。
- 利用環境:クライアント名、完全なバージョン番号、OS、TUNの有効・無効。
- 操作手順:1つのグループだけ更新したか、すべてのサブスクリプションを更新したか、直結かプロキシ経由か、毎回再現するか。
- リクエスト結果:エラーメッセージの原文、HTTPステータスコード、レスポンスが空か、ウェブページか、サブスクリプションのテキストか。
- 表示結果:検索とフィルターを消しても一覧が空か、既存の別グループは正常に表示されるか。
- 実施した操作:URLの再取得、利用権のリセット、ネットワークの切り替え、更新経路の変更を行ったか。記録を共有する前に、URL内の認証情報とノード接続用パラメーターを削除してください。
最終的には「URLが有効か、リクエストが届くか、レスポンスが正しいか、形式に互換性があるか、フィルターが適切か」の順に原因を絞ります。各段階を確認できたら、その設定は変更せずに進めてください。DNS、ルーティング、コア、サブスクリプションの入口を一度に切り替えると、復旧してもどの操作が有効だったのか分からなくなります。