まず既存のノードを残し、サブスクリプションへのリクエスト失敗と内容の解析失敗を切り分けます。次にURL、直接接続とプロキシ経由の更新方法を確認し、最後に自動更新間隔を設定します。サブスクリプションを登録済みで、更新時にエラーが出る、または一覧が変わらないv2rayNユーザー向けに、メニュー操作やHTTPステータスコード、復旧後の確認方法を解説します。
1. サブスクリプションの更新失敗とノードの接続失敗の違い
障害の切り分け：サブスクリプションの更新では、クライアントがサブスクリプションURLにアクセスして設定内容を取得します。一方、ノードへの接続では、コアが個々の設定を使って接続します。使用するドメインやポート、通信経路は異なる場合があります。以前からあるノードでWebページを開けても、サブスクリプションURLが有効とは限りません。サブスクリプションを取得できても、すべてのノードに接続できるとは限りません。
設定の保護：確認を始める前に、現在使えるノードとサブスクリプショングループ名を控え、クライアントの設定バックアップ機能で必要な設定を保存し、安全に保管してください。グループ全体を削除したり、一覧を何度も消去したりしないでください。プロキシ経由の更新に使える唯一の接続手段まで失うおそれがあります。
- リクエスト段階の失敗：ログに名前解決失敗、接続タイムアウト、証明書エラー、HTTPエラーが記録されている場合は、まずURLとアクセス経路を確認します。
- 解析段階の失敗：リクエストは成功しているのに設定を認識できない場合は、返された本文とサブスクリプション形式を確認します。
- 一覧に変化がない：ログに更新完了と表示され、ノード数も変わらない場合、サーバーから以前と同じ内容が返された可能性があります。
- 更新後に接続できない：新しい設定が一覧に追加されている場合は、ノードのパラメーター、コアの対応状況、サーバーの状態を確認します。更新間隔を調整する問題ではありません。
2. サブスクリプションURLの確認：リンク切れ、権限、アクセス制限
URLの確認：メイン画面で「サブスクリプショングループ」→「サブスクリプショングループの設定」を開き、問題のあるグループを編集してURLを確認します。バージョンによってはメニュー名が「サブスクリプション設定」と省略されている場合もあります。グループ名、URL、更新オプションを含む編集画面を確認してください。サービス提供元のサブスクリプション画面からURLをコピーし直し、チャット履歴から一部だけをコピーしないようにします。
機密情報の取り扱い：サブスクリプションURLにはアクセストークンが含まれることが多いため、パスワードと同様に保管してください。確認時は、URLの前後にある空白や改行、クエリパラメーターの欠落、Webページ上でエスケープされた & を実際の区切り文字と誤認していないかに注意します。疑問符以降のパラメーターをむやみに削除したり、URL全体を公開ログやオンライン解析ツールに貼り付けたりしないでください。
ステータスコードの見方：401はトークンの期限切れが原因の可能性があります。403はアクセス制限や保護ページによる場合もあり、コードだけでアカウントの期限切れとは判断できません。404の場合はパスや移転の有無を確認し、429の場合はサーバーが指定する待機時間に従ってください。待機時間が明示されていない場合は、自動・手動を問わず再試行を止めてから、サービス提供元の案内を確認します。
結論：まずサブスクリプションURLを確認し、その後に通信経路を変更
対処の判断：サブスクリプショントークンが再発行されている場合は、まずグループに登録した古いURLを新しいものに置き換えます。DNSの変更、コアの切り替え、更新間隔の短縮では、取り消されたアクセス権限は復旧できません。
3. プロキシ経由で更新する：先に接続を確立
通信経路の違い：v2rayNのサブスクリプションメニューには通常、「現在のサブスクリプションを更新（プロキシを使用しない）」「現在のサブスクリプションを更新（プロキシを使用）」などのコマンドがあります。「すべてのサブスクリプション」が対象になる場合もあります。メニューの表記や句読点はバージョンによって異なりますが、「現在またはすべて」と「直接接続またはプロキシ経由」はそれぞれ別に確認してください。切り分けの際は、他のサブスクリプションのエラーが混ざらないよう、まず1つのグループだけを更新します。
-
対象のグループを選択
グループの選択：メイン画面で更新に失敗したサブスクリプショングループを選び、すべてではなく対象のグループが更新されることを確認します。
-
直接接続で更新を試す
直接接続のテスト：「サブスクリプショングループ」を開き、プロキシを使用せずに現在のサブスクリプションを更新するコマンドを選んで、結果を記録します。現在のネットワークからURLに直接アクセスできる場合、ノードを別途経由する必要はありません。
-
利用可能なノードを有効にする
プロキシの準備：以前に接続できることを確認したノードを選択してアクティブサーバーに設定し、コアが起動していることを確認します。ノードが選択状態になっているだけで、ローカルプロキシが利用可能だと判断しないでください。
-
プロキシ経由で更新
経路の比較：「サブスクリプショングループ」を再度開き、プロキシ経由で現在のサブスクリプションを更新するコマンドを選択します。直接接続の結果と比べて、サブスクリプションのドメインへのアクセス経路が原因かどうかを判断します。
-
更新方法を保存
自動更新の設定：「サブスクリプショングループ」→「サブスクリプショングループの設定」に戻ります。現在のバージョンに「プロキシ経由で更新」オプションがある場合は、手動テストの結果に合わせて設定を保存します。手動でプロキシ経由の更新を選択しても、自動更新の設定に反映されるとは限りません。
システムプロキシの注意点：Windowsのシステムプロキシを有効にしても、すべてのサブスクリプションリクエストが自動的にプロキシ経由になるわけではありません。クライアントでは直接接続か、内蔵のプロキシ経由かを明示的に選べます。TUNやルーティングルールも実際の送信経路に影響します。システムプロキシのスイッチだけで判断せず、更新コマンド、グループの設定、ログを確認してください。
4. ログで原因を特定：タイムアウト、証明書、ローカルポート
ログの確認：v2rayNのログまたは情報欄を開き、手動更新を実行した時刻のエラーを探します。次のような英語のエラーがネットワークリクエストに含まれる場合があります。実際の表記はOSの言語や実行環境、バージョンによって異なります。最上位の「更新に失敗しました」だけでなく、内側の例外も確認してください。
エラー：No such host is known.
原因と対処：ドメイン名の解決に失敗しています。まずサブスクリプションのドメインに誤記がないか確認し、次に現在のネットワークでDNSが名前解決できるか確認します。プロキシ経由で更新する場合は、どちら側で接続先のドメインを解決しているかも考慮してください。
エラー：Connection refused
原因と対処：接続先から接続を拒否されています。接続先がローカルのループバックアドレスの場合は、コアが起動しているか、プロキシポートが一致しているか確認します。リモートのサブスクリプションサーバーが接続先の場合は、ログのアドレスとポートを確認し、ローカルプロキシが原因だと決めつけないでください。
エラー：The SSL connection could not be established
原因と対処：TLS接続の確立に失敗しています。詳細な例外を確認し、システムの日付、時刻、タイムゾーンを確認してから、サブスクリプションドメインの証明書や通信の遮断がないか調べます。証明書の検証を無効にする方法を恒久的な解決策にしないでください。
エラー：Response status code does not indicate success: 403 (Forbidden).
原因と対処：サーバーがリクエストを拒否しています。サブスクリプションURLを取得し直し、アクセス権限とサービス提供元の要件を確認してください。保護用の認証ページが返される場合は、クライアントからのリクエストに対応したサブスクリプションURLを使用します。
ポートの確認：「設定」→「パラメーター設定」で、ローカルの待ち受けポートに関する項目を確認します。画面に表示されたHTTPまたは混合プロキシポートが 10808 の場合は、Windows PowerShellで以下のコマンドを実行し、待ち受け状態を確認できます。10808は確認用の例であり、すべてのバージョンや設定に共通する固定値ではありません。実際のポートが異なる場合は、画面に表示された番号に置き換えてください。
Get-NetTCPConnection -LocalPort 10808 -State Listen |
Select-Object LocalAddress, LocalPort, OwningProcess結果の見方：待ち受け記録があれば、そのポートでプロセスが接続を受け付けていることを示します。ただし、そのプロセスがv2rayNのものとは限らず、リモートノードが利用可能とも限りません。タスクマネージャーでプロセスIDを照合できます。記録がない場合は、プロキシ経由で更新する前に、コアの起動エラー、ポートの競合、設定の読み込み失敗を確認してください。
5. ダウンロードできても解析に失敗する場合：内容と形式を確認
返却内容の確認：HTTPリクエストが成功したということは、サーバーから応答があったことを示すだけで、本文にノードが含まれているとは限りません。ログインページ、アカウント情報、ブラウザー認証ページ、サブスクリプション管理ページが返されることがあります。ブラウザーでページを開けても、そのURLがインポート可能なサブスクリプションURLとは限りません。
| 返却内容 | 考えられる内容 | 対処方法 |
|---|---|---|
| HTMLページ | ログインページ、認証ページ、エラーページ | サービス提供元からクライアント用のサブスクリプションURLを取得する |
| 複数行の共有リンク | VMess、VLESSなどの設定が含まれる可能性がある | クライアントが該当するリンク形式と項目に対応しているか確認する |
| エンコードされたテキスト | 共有リンクをBase64でまとめたものの可能性がある | 内容がすべて揃っているか確認し、コピー時に途中で切れていないか確認する |
| JSON設定 | ノードのサブスクリプションではなく、コア全体の設定である可能性がある | 設定の用途に合ったインポート方法を選ぶ |
| 空の本文 | サーバーの異常、または権限の変更が考えられる | サービス提供元に問い合わせ、すぐに古いグループを削除しない |
形式の違い：VMessやVLESSはノードのプロトコルに関する識別子で、サブスクリプションは設定を配布するための仕組みです。両者は同じ階層のものではありません。v2rayNが特定の共有リンクを解析できても、あらゆるコア設定ファイルをノードのサブスクリプションとしてインポートできるわけではありません。インポートに成功しても、選択中のコアが含まれるすべての転送方式、セキュリティ、ルーティング項目に対応しているとは限りません。
確認手順：サービス提供元が用意するクライアント種別から、v2rayNに対応したサブスクリプション形式を選び、グループを1つだけ更新します。クライアントのバージョンが古い場合は、設定をバックアップしてから、本サイトのインストーラー配布ページで対応バージョンを入手し、形式の互換性を確認します。トークンを含むサブスクリプションを見知らぬ変換サービスに渡さず、解析エラーを消すためにプロトコル項目をむやみに変更しないでください。
6. 自動更新間隔：単位、プロキシ設定、スリープ時の注意
設定画面：「サブスクリプショングループ」→「サブスクリプショングループの設定」を開き、対象グループを編集します。「自動更新間隔」または同等の項目を探し、画面に表示された単位を確認してください。一般的な画面では分単位で入力します。現在のバージョンで別の単位が表示される場合は、その画面や説明に従い、数値をそのまま流用しないでください。
- 間隔の例：分単位の画面で
720と入力すると12時間、1440と入力すると24時間です。これは管理しやすい設定例であり、公式の初期値でもサービス提供元のリクエスト上限でもありません。 - プロキシの設定：グループの編集画面に「プロキシ経由で更新」がある場合は、手動テストの結果に応じて選択します。有効にした場合、自動更新時にも利用可能なローカルプロキシと外向きのノードが必要です。
- 無効にする場合：バージョンによっては
0を自動更新しない設定として使用しますが、まず項目の説明を確認してください。明確な説明がない場合、0を即時更新や連続更新の意味だと解釈しないでください。 - 実行条件：クライアントが完全に終了している場合やPCがスリープ中の場合、予定時刻どおりにリクエストが実行されるとは限りません。復帰後に更新が実行されるタイミングはバージョンの実装によって異なります。重要な変更を行った後は、手動で一度確認することをおすすめします。
- 保存の確認：設定を保存した後、対象グループを開き直し、数値とスイッチが保持されていることを確認してから、定期実行と同じ経路で手動更新を1回行います。
更新頻度の選び方：サブスクリプションの更新でリモートノード自体の障害が直るわけではありません。サービス提供元から特別な指定がなければ、まずは長めの間隔に設定し、ノードの移転や設定変更があったときに手動で更新します。「接続維持」のために1分ごとにリクエストしないでください。複数のグループを同時に更新するとリクエストが集中するため、アクセス制限が発生した場合はクライアントを何度も再起動せず、まず頻度を下げます。
結論：まず手動更新を成功させ、その後に定期更新を有効化
実行の順序：同じグループの手動更新が成功したら、確認済みの直接接続またはプロキシ経由の方法を保存し、更新間隔を設定します。手動リクエストでエラーが続く場合、自動更新でも同じ障害が繰り返されます。
7. よくある質問と復旧後の確認
Webページを開けるのに、サブスクリプションを更新できないのはなぜ？
経路の確認：ブラウザーはシステムプロキシを通じてアクセスしていても、サブスクリプションの更新コマンドは直接接続している可能性があります。まず対象グループを直接接続とプロキシ経由の両方で更新し、HTTPステータスと返却内容を確認してください。ブラウザーでログイン済みでも、その状態がクライアントのリクエストに引き継がれるとは限りません。
更新完了と表示されるのに、ノードが1つも増えないのはなぜ？
内容の確認：正しいグループが表示されていることを確認し、フィルター条件、更新時刻、ログを確認してください。サーバーから同じ設定が返された場合、ノード数が増えないのは正常です。数だけを見て更新失敗と判断しないでください。
更新後に古いノードが消えました。再インポートが必要ですか？
設定の提供元を確認：更新時にサブスクリプションの内容がグループに同期され、サービス提供元が削除したノードが一覧から消えることがあります。まずグループのURLを誤って変更していないか確認し、サービス提供元に変更内容を問い合わせてください。手動管理する設定は独立したグループに保存し、サブスクリプションの同期内容と混在させないようにします。
手動なら更新できるのに、自動更新がよく失敗する場合は？
自動更新の確認：グループ設定に戻り、更新間隔の単位とプロキシの設定を確認します。また、予定時刻にクライアントが起動していることを確認してください。プロキシ経由で更新する場合は、その時点でアクティブなノードが利用可能かも確認します。手動更新で使った方法が自動更新にも保存されているとは限りません。
復旧後の確認：更新に成功したら、対象グループが残っていること、ログにダウンロードや解析の異常がないことを確認し、設定を1つ選んで実際に接続できるかテストします。新しいノードに接続できない場合は、更新失敗とは別の問題として対処してください。リクエストログをサポート担当者に共有する場合は、エラー時刻、ステータスコード、機密情報を削除したエラー説明だけを残し、サブスクリプショントークン、ノードの認証情報、URL全体を削除します。
- 提供元の確認：グループに登録されているURLが、サービス提供元の現在のサブスクリプションURLと一致している。
- 経路の確認：直接接続かプロキシ経由かが明確で、更新が1回成功することを確認できている。
- 設定の確認：一覧が対象グループのものであり、追加または保持された設定を想定どおり有効化できる。
- 更新予定の確認：間隔の単位、更新方法、クライアントの実行条件を確認し、連続して手動更新しない。