Clashのサブスクリプション更新に失敗する原因と自動更新間隔の設定

まずはサブスクリプションの取得とノード接続を切り分ける

サブスクリプションの更新に失敗したら、クライアントをすぐ再インストールするのではなく、まず更新リクエストのエラーを確認しましょう。サブスクリプションの更新では、HTTPまたはHTTPSのURLから設定を取得します。一方、ノード接続では、現在の設定を使ってコアがプロキシ接続を確立します。サーバーや認証方式、通信経路はそれぞれ異なる場合があります。以前から使えているノードがあっても、サブスクリプションURLが有効とは限りません。サブスクリプションを取得できても、すべてのノードに接続できるとは限りません。

混同しやすいものに「設定全体」と「ノードプロバイダー」があります。クライアントのサブスクリプション管理画面では、通常、設定全体を取得してコアに読み込みます。一方、proxy-providersは、対応するコアがノード一覧を取得する仕組みです。この2つは更新方法が異なります。YAMLのintervalだけを変更しても、設定全体を更新するクライアント側の間隔は変わらないことがあります。

クライアント名、バージョン、コアの種類を記録します。たとえば、mihomoを使っているかどうかも確認しましょう。「Clash最新版」だけでは情報が足りません。
手動で一度更新し、発生時刻とエラーの詳細を記録します。
失敗した段階が、ダウンロード・解析・設定の適用のどれかを確認します。
一度に変更する条件は1つだけにし、成功してから自動更新を設定します。DNSやポート、サブスクリプションURLを同時に変更するのは避けましょう。

エラー内容から通信やリンクの問題を特定する

まず、クライアントのサブスクリプション通知、更新詳細、ログを確認しましょう。同じ「更新失敗」でも、接続タイムアウトの場合もあれば、サーバーからアクセス拒否の応答が返っている場合もあります。ポップアップの曖昧なメッセージより、ステータスコードやエラーの詳細が手がかりになります。

エラーの手がかり	まず確認すること	次の対応
`no such host`	サブスクリプションのドメインを名前解決できない	ドメイン名の入力とシステムのDNSを確認し、別のネットワークでも試す
`i/o timeout`、`context deadline exceeded`	接続・ハンドシェイク・応答の読み込みがタイムアウトする	直接接続と、利用可能なプロキシ経由の接続をそれぞれ試す
`401`、`403`	トークン、アカウントの状態、アクセス制限	サービス提供元の管理画面にログインし、専用のサブスクリプションURLをコピーし直す
`404`、`410`	URLが変更された、またはリソースが削除されている	管理画面で新しいURLを確認し、古いURLへの再試行をやめる
`429`	更新頻度がレート制限にかかっている	連続で更新せず、サーバー側の指定時間が経つまで待つ
`500`、`502`、`503`	サブスクリプションサービスまたは上流側で一時的な障害が発生している	現在の設定を残し、しばらく時間をおいてから再試行する

別のネットワークでも試す

同じ端末で、まず現在のWi-Fiから更新し、次にスマートフォンのテザリングで試します。テザリングでは成功する場合、現在のネットワークのDNS、外向き通信の制限、認証ポータルに原因がある可能性が高くなります。公共Wi-Fiでログイン認証が済んでいないと、YAMLではなくログイン画面が返されることがあります。ブラウザーでサービス提供元のトップページを開けても、サブドメインやAPIに接続できるとは限りません。

ログにconnection refusedと出た場合は、接続を拒否した対象を確認します。接続先が127.0.0.1:7890なら、サブスクリプションサーバーを疑う前に、ローカルのプロキシポートが待ち受け状態か確認しましょう。7890はよくある例です。実際に使うポートは、現在のクライアントに表示されているHTTPポートまたは混合ポートを確認してください。

証明書エラーとサブスクリプションの期限切れは別々に対処する

証明書エラー：まず時刻を合わせ、通信環境を確認

x509: certificate has expired or is not yet validは、サーバー証明書の期限切れだけでなく、端末の時刻ずれが原因の場合もあります。まずシステムの日付と時刻を自動設定にし、年・日付・タイムゾーンを確認してから再度更新してください。certificate signed by unknown authorityと表示される場合は、システムの証明書ストア、企業ネットワークのHTTPS検査、クライアントが使う実行環境の古さを確認します。

「証明書の検証をスキップ」を恒久的な対処として使わないでください。サブスクリプションの取得にはアカウントのトークンが含まれるため、検証を無効にするとサーバーの正当性を確認しにくくなります。また、ノード設定のskip-cert-verifyは通常、対象ノードのTLS接続に影響する設定であり、クライアント自身がサブスクリプションを取得する際の証明書エラーを解決するものではありません。サーバー証明書に問題があると確認できた場合は、サービス提供元に修正を依頼しましょう。

リンク切れ：アカウント管理画面から再取得する

アカウントの期限切れ、トークンの再発行、古いサブスクリプションドメインの停止などで、以前のURLが使えなくなることがあります。サービス提供元の管理画面でプランの状態を確認し、現在のクライアントやコアに合った形式を選んで、URLをすべてコピーしてください。ブラウザーのログインページのURLをコピーしたり、疑問符以降のパラメーターを省いたりしないよう注意します。チャットアプリによる自動改行や末尾の空白も確認しましょう。

URLを変更する前に、現在のサブスクリプション情報を残しておきましょう。まず設定を新しく追加して更新が成功することを確認し、その後で古い項目を削除できます。
403が返っても、アカウントの期限切れと決めつけないでください。リクエスト元やUser-Agentの制限によって拒否されることもあります。
ブラウザーのログインCookieがないとダウンロードできないページは、クライアントの自動更新用APIとして使えるとは限りません。

ダウンロードできても解析に失敗するときの確認方法

HTTPステータスコードが200でも、サーバーがコンテンツを返したことを示すだけで、それがClashの設定とは限りません。エラーにHTMLタグ、DOCTYPE、ログインを促す文言が含まれている場合は、Webページを取得している可能性があります。Base64形式のノード一覧や、ss://、vmess://などの単一ノード用リンクが返された場合も、完全なYAML設定として読み込めるとは限りません。

設定全体とproviderファイルを見分ける

設定全体：通常はproxies、proxy-groups、rulesなどのフィールドを含み、provider経由で外部のノードを参照する場合もあります。
ノードprovider：一般的なYAML形式ではproxies:にノードを記述します。完全なプロキシグループやルールを提供するものではありません。
ルールprovider：一般的にはpayload:にルールを記述します。ノードのサブスクリプションとしては使えません。

旧バージョンのClashコアとmihomoでは、対応するプロトコルやフィールドが完全には一致しません。ログに未対応のプロキシタイプが示されている場合は、コアの対応状況を確認するか、互換性のある形式を選びましょう。インデントを直すだけでは解決しません。YAMLを手動編集する際はタブではなく半角スペースを使い、同じ階層のフィールドを揃えてください。設定全体のルールが存在しないプロキシグループを参照していると、「ダウンロード完了後に適用失敗」となることもあります。

まず、サービス提供元が案内する正しい形式から再ダウンロードしてください。変換が必要な場合は、信頼できるローカルツールか自分で運用する変換サービスを使い、変換後も必要なプロキシグループやルールが残っているか確認します。原因調査のためでも、トークンを含むサブスクリプションURLを公開しないでください。

クライアントの自動更新間隔を設定する

自動更新は、手動更新が成功してから有効にしましょう。まずは6時間ごとに設定できます。単位が分なら360、秒なら21600を入力します。これは設定の目安であり、すべてのサービスに共通する条件ではありません。サービス提供元が最短の更新間隔を定めている場合は、その指示に従ってください。

主なクライアントでの設定場所

メニューの名称は配布版によって異なります。全体のネットワーク設定だけを探すのではなく、まずサブスクリプション項目の編集画面を確認してください。以下は設定場所を探すときの目安です。最終的には、現在のバージョンに表示される項目名と単位を確認してください。

クライアント	一般的な操作手順	保存後の確認
Clash Verge Rev	「サブスクリプション」→対象項目のメニュー→「編集」→更新間隔	単位と自動更新の設定を確認し、手動更新を一度実行する
旧版 Clash for Windows	「Profiles」→サブスクリプション項目を右クリック→「Settings」→「Update Interval」	一般的なバージョンでは分単位で入力します。旧版では画面が異なる場合があります。
旧版 Clash for Android	「設定」→対象設定の編集画面→自動更新	自動更新が有効か確認し、バックグラウンド実行の制限も確認する

0を「今すぐ更新」の意味だと思わないでください。自動更新の無効化を示すクライアントもあれば、別のスイッチで制御するバージョンもあります。保存後、「前回の更新」時刻が変わったか確認しましょう。画面上の数値が変わっただけでは、スケジュールされた更新が実行されたとは限りません。

PCの電源が切れているときやクライアントを終了しているとき、スマートフォンでアプリがシステムに停止されているときは、通常、予定どおりに更新できません。端末がスリープから復帰した後に未実行のタスクを補うかどうかは、クライアントの実装によります。Androidで更新が繰り返し実行されない場合は、システムの「設定」→「アプリ」→対象クライアント→「バッテリー」または「バックグラウンド管理」で制限を確認してください。メーカーによってメニュー名は異なります。サブスクリプション更新のために、システムの省電力機能をすべて無効にする必要はありません。

providerのintervalとサブスクリプション更新は別

mihomoのHTTPノードプロバイダーを使う場合、proxy-providers内の各providerに個別のintervalを設定できます。単位は秒です。以下は既存のHTTP provider項目の中に追加するフィールド例であり、設定全体ではありません。既存のtype、url、pathなどの設定は残してください。

interval: 3600
proxy: DIRECT

この設定では、providerの更新を3600秒ごと、つまり1時間ごとに試み、直接接続でダウンロードします。proxyフィールドが現在のコアでサポートされていることを確認してください。このフィールドに対応するmihomoでは、既存の利用可能なアウトバウンド名またはプロキシグループ名を指定することもできます。これらのフィールドを、未対応の旧コアにそのまま追加しないでください。

クライアントによる設定全体の更新：クライアントがスケジュールし、リモートの設定全体を置き換える場合があります。
providerによるノード更新：コアがスケジュールし、対象providerのノード情報だけを更新します。
health-check.interval：ヘルスチェックの間隔を指定します。ノード一覧をダウンロードする頻度ではありません。

リモート設定ファイルを直接編集すると、次回のクライアント更新で変更が上書きされる場合があります。変更を継続して反映したい場合は、クライアントのオーバーライド、マージ、ローカル設定機能を使い、更新後に実際に適用された設定を確認してください。マージの動作はクライアントによって異なるため、エディターで開いたソースファイルだけでは判断できません。

プロキシ経由でサブスクリプションを更新する手順

サブスクリプションのドメインに直接接続できない場合は、利用可能なプロキシ経路がすでにあることを前提に、プロキシ経由でのダウンロードを試せます。設定全体のサブスクリプションは通常クライアント自身の通信機能で取得しますが、providerはコアが取得する場合があります。システムプロキシ、TUNモード、サブスクリプション項目のプロキシ設定はそれぞれ別の設定です。いずれかを有効にしても、他の層のリクエストまでプロキシ経由になるとは限りません。

以前の設定でコアを起動し、接続できることを確認済みのノードを選択します。
サブスクリプション項目の編集画面または更新メニューを開き、「プロキシを使用」などの設定を探します。現在のバージョンにその項目がある場合のみ有効にしてください。
クライアントからプロキシアドレスの入力を求められた場合は、http://127.0.0.1:7890など、実際に待ち受けているHTTPポートまたは混合ポートを指定します。コントローラー用のポートは入力しないでください。
もう一度更新し、接続タイムアウトが明確なHTTP応答に変わったかを確認します。あわせて、更新時刻と新しい設定の内容も確認してください。

クライアントにサブスクリプション専用のプロキシ設定がない場合は、そのバージョンがシステムプロキシやTUNに対応しているか確認してください。リクエストが必ずプロキシ経由になると思い込まないようにしましょう。TUNが対象リクエストを処理できるかどうかは、ルーティング、プロセスの除外、DNS設定にも左右されます。HTTPプロキシのポートは外部コントローラーのポートではありません。一般的なコントローラーポートの9090はコアの管理に使うもので、サブスクリプションのダウンロード用プロキシには使えません。

復旧後に確認する5項目

最後に、「更新成功」という表示だけで判断しないでください。設定のダウンロード、コアへの適用、ノードの利用可否はそれぞれ別の結果です。すべて確認して、初めて原因の切り分けが完了します。

時刻：サブスクリプションの前回更新時刻が今回の操作時刻に変わっていること。古い記録のままではないことを確認します。
内容：必要なプロキシグループとノードが存在し、現在選択されている設定も正しいこと。
ログ：その後にYAMLの解析失敗、プロキシグループの参照エラー、未対応プロトコルの警告が出ていないこと。
接続：実際にプロキシが必要な接続先にアクセスし、現在の出口から正常に接続できることを確認します。
自動更新：クライアントを起動したまま次回の予定時刻を迎え、自動更新されるか確認します。失敗した場合は、そのときの通信環境とスリープ状態を記録してください。

解決しない場合は、クライアントのバージョン、コアのバージョン、OSのバージョン、エラー発生時刻、機密情報を伏せたエラー行に加え、「直接接続は失敗、プロキシ経由なら成功」といった比較結果をメンテナーに伝えましょう。サブスクリプションのトークンやノードのパスワードを公開する必要はありません。失敗した段階を明確に伝えるほうが、設定を何度も削除したり再インストールしたりするより、原因を早く特定できます。