Clashのサブスクリプション更新に失敗したときの対処法｜よくある原因と自動更新間隔の設定

まずは「サブスクリプションのダウンロード失敗」か「設定の有効化失敗」かを切り分ける

クライアントの「サブスクリプション」または「設定」画面を開き、エラーが出た項目の最終更新時刻を確認してから、手動で更新します。続いて「ログ」を開き、この操作で発生したエラーを記録してください。まず失敗した段階を特定してから、ネットワークや更新間隔を見直しましょう。ノードの不具合をサブスクリプションの問題と誤認せずに済みます。

• ダウンロード段階の失敗：timeout、connection refused、no such host、HTTPエラーコードが表示される場合は、まずサブスクリプションURLと接続経路を確認します。
• 解析段階の失敗：データを受信できているのにyaml、unmarshal、unsupported proxy typeが表示される場合は、返却形式とコアの対応状況を確認します。
• 有効化段階の失敗：更新は成功しているのに設定の切り替えでエラーになる場合は、ルールの参照先、プロキシグループ名、設定のマージ結果を確認します。
• ノード接続の失敗：設定の読み込みは完了し、ノードの速度測定だけがタイムアウトする場合は、ノードの接続性に問題があります。サブスクリプションを繰り返し更新しても解決しないことがあります。

エラー別の確認方法：タイムアウト、証明書、HTTPステータスコード

同じ「更新に失敗しました」という表示でも、原因はさまざまです。以下のステータスコードはサブスクリプションのダウンロード要求に対するもので、ノードの速度測定結果ではありません。カードに表示される赤いメッセージだけで判断せず、クライアントのログでエラーの詳細を確認してください。

タイムアウト：ルールを変える前に接続経路を切り替える

現在のWi-Fiの代わりにスマートフォンのテザリングを使い、手動で一度更新します。テザリングでは成功し、元のネットワークでは失敗する場合は、元のネットワークのDNS、アクセス制限、ゲートウェイを重点的に確認してください。プロキシ経由でのみ成功するなら、サブスクリプションの接続に既存のプロキシ経路が必要です。反対に、プロキシ経由では失敗して直接接続なら成功する場合は、使用中のプロキシノードとクライアントのダウンロード方式を確認します。

クライアントによっては、ダウンロードのタイムアウト時間を設定できます。比較テストとして10秒から30秒に延ばす方法もありますが、すべてのクライアントに設定項目があるわけではありません。ドメインを名前解決できない場合や認証情報が無効な場合、待ち時間を延ばしても解決しません。

証明書エラー：時刻を合わせ、ネットワーク環境を確認する

Windows 11では、「設定」→「時刻と言語」→「日付と時刻」を開き、自動時刻設定を有効にして「今すぐ同期」を実行します。システム時刻がずれていると、証明書の有効期間を正しく判定できません。会社や学校のネットワークだけでエラーになる場合は、スマートフォンのテザリングで再確認してください。組織の証明書が必要な端末では、管理者の案内に従ってシステムの信頼設定を行います。

証明書検証の無効化を、通常の対処法として使わないでください。サブスクリプションにはノードのアドレスや認証情報が含まれるため、検証を省略するとダウンロード時の相手先確認が弱まります。特に、ノード設定のskip-cert-verifyは該当ノードへの接続時の証明書検証を制御するもので、クライアントによるサブスクリプションのダウンロードで発生するTLSエラーを汎用的に解決するものではありません。

受信したデータを確認：YAML、Base64、ログインページ

テキストをダウンロードできても、それがClashの設定とは限りません。よくあるのは、アカウント管理画面のURLや、別のクライアント専用のサブスクリプションURLを使ってしまうケース、URL末尾のパラメーターがコピー時に抜けてしまうケースです。サービス提供元のアカウントページに戻り、Clashまたはmihomo対応と明記されたURLを選んで、トークンを編集せず全体をコピーしてください。

内容から形式を見分ける

• Clashの完全な設定：通常はproxiesまたはproxy-providersのほか、プロキシグループやルールなどを含みます。具体的な項目はサービス提供元の生成方式によって異なるため、ファイルの拡張子だけで判断しないでください。
• プロキシプロバイダー用のデータ：proxies:で構成されたノード一覧が一般的です。メイン設定のproxy-providersから参照して使うもので、完全な設定としてそのまま有効化できるとは限りません。
• Base64形式のノード一覧：デコードすると、プロトコルリンクが1行ずつ並んでいる場合があります。ClashのYAML設定とは異なる形式です。クライアントでのインポートや変換に対応しているかは、個々の実装によります。
• HTMLページ：内容が<!DOCTYPE html>で始まる場合や、ログイン、認証、アクセス拒否の文言が含まれている場合は、サブスクリプション設定ではなくWebページが返されています。

ブラウザーでサブスクリプションを開けても、クライアントがダウンロードできるとは限りません。ブラウザーにはログイン用Cookieが保存されていることがありますが、クライアントは通常そのログイン状態を引き継ぎません。また、ブラウザーとクライアントでは接続経路が異なる場合もあります。Webサイトへのログインや操作による認証が必要な場合は、クライアント専用のサブスクリプションURLをサービス提供元に問い合わせてください。

解析エラー：コアの対応状況を確認し、インデントを勘で直さない

unsupported proxy typeが表示されたら、まずクライアントの「バージョン情報」またはコア情報の画面で、クライアントのバージョンとコア名を確認します。Clash系のコアはそれぞれ対応する機能が異なり、mihomo向けの設定が古いClashコアでは使えないことがあります。サービス提供元が形式を選べる場合は互換形式を選ぶか、必要なプロトコルに対応したクライアントを使ってください。

行番号付きのYAMLエラーが出た場合は、該当箇所のインデント、コロン、引用符を確認します。更新のたびに遠隔設定でローカルファイルが上書きされるなら、キャッシュだけを編集するのではなく、上流で生成される設定またはクライアントの上書きルールを修正してください。そうしないと、次回更新時に同じエラーが再発します。

プロキシ経由で更新する：使用可能なノードを使ってダウンロード

「システムプロキシを有効にする」設定と「プロキシ経由でサブスクリプションをダウンロードする」設定は別のものです。サブスクリプションのリクエストはクライアント自身が送る場合と、コアが処理する場合があります。システムプロキシに従うかどうかはクライアントの実装次第です。ルールモード、グローバルモード、TUNモードを切り替えても、サブスクリプションの接続経路が変わるとは限りません。

1. 現在も使える旧設定を有効にし、接続可能なノードを選んで、通常のHTTPSリクエストが完了することを確認します。
2. 「サブスクリプション」または「設定」を開き、対象のサブスクリプションの編集・更新メニューから「プロキシ経由で更新」「プロキシを使用」などの項目を探します。項目名や場所はクライアントのバージョンによって異なります。
3. 該当する項目があれば有効にして手動更新を一度行い、ログで結果を確認します。項目が見つからない場合はクライアントのドキュメントを確認し、隠しパラメーターを推測で設定しないでください。
4. 更新に成功したら、更新時刻、ノード一覧、設定の有効化状態を確認してから、このダウンロード経路を継続して使うか判断します。

Windows端末の混合ポートが実際に7890に設定されている場合を例に、PowerShellで次の2項目を確認できます。クライアントに別のポートが表示されている場合は、画面に表示された実際のポートを使ってください。

Test-NetConnection 127.0.0.1 -Port 7890
curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 30 -I https://clash13.com/

1つ目のコマンドはローカルポートが接続を受け付けるかだけを確認します。2つ目はローカルのHTTPプロキシ経由でHTTPSリクエストを送るテストです。Webサイトから応答があっても、その結果が示すのは今回のリクエストだけです。サブスクリプションの接続可否や、クライアントの更新リクエストが同じ経路を使うことまでは証明できません。プロキシ接続に認証が必要な場合は、端末の設定に合わせて認証情報も指定してください。

自動更新間隔：クライアントのサブスクリプションとプロバイダーを区別する

自動更新には2つの階層があります。クライアントが遠隔設定全体を定期的にダウンロードする方法と、mihomoが設定内のプロキシプロバイダーを定期的に更新する方法です。両方を設定できますが、同じ機能ではありません。クライアントのサブスクリプションカードに表示される更新時刻も、プロバイダーが直近に更新されたことを示すとは限りません。

サブスクリプション全体：クライアントの編集画面で設定

「サブスクリプション」または「設定」→対象のサブスクリプションメニュー→「編集」の順に開き、自動更新のオン・オフと更新間隔を確認します。入力欄の単位を先に確認してください。360と入力しても、単位が分なら6時間、秒なら6分です。自動更新の項目がないクライアントでは、YAMLの最上位にintervalを追加しても機能を補えません。

• 通常の利用：まずは6時間または12時間に設定します。分単位ならそれぞれ360分、720分です。そのうえでサービス提供元の指定に従って調整してください。
• ノードの変更が少ない場合：不要なリクエストを減らすため、24時間（1440分）に設定できます。
• トラブルの調査中：手動で一度更新してログを確認します。一時的に毎分更新する設定にはしないでください。

これらは設定の目安であり、クライアントの初期値ではありません。PCのスリープ、クライアントの終了、スマートフォンのバックグラウンド制限、ネットワークの切断などにより、定期更新が実行されないことがあります。復帰後に更新を補うかどうかはクライアント次第です。設定した時刻になっても更新されない場合は、サーバーの障害と判断する前に、アプリが継続して動作していたかを確認してください。

プロキシプロバイダー：intervalの単位は秒

mihomoのHTTPプロキシプロバイダーでは、proxy-providers内にある各プロバイダーのintervalは秒単位です。6時間は21600秒、12時間は43200秒、24時間は86400秒です。値を変更するときは、プロバイダーのURL、パス、その他の項目を維持し、更新間隔だけを変更してください。

プロバイダー内のhealth-checkにあるintervalは、ノードのヘルスチェック間隔であり、サブスクリプションのダウンロード間隔ではありません。ヘルスチェックを300秒に設定しても、ノード一覧が5分ごとに更新されるわけではありません。また、プロバイダーの秒単位の値を、クライアントの「分」単位の入力欄にそのまま設定しないでください。

手動で強制更新：結果を確認してからキャッシュを処理

すべてのクライアントに「強制更新」ボタンがあるわけではありません。「更新」だけのものもあれば、「すべて更新」や「プロキシプロバイダーを更新」が別に用意されているものもあります。遠隔設定全体を更新するのか、設定内のプロバイダーを更新するのかを確認してください。外側の設定を更新しても、すべてのプロバイダーがすぐに再ダウンロードされるとは限りません。

1. バックアップと記録：現在使える設定を保存し、対象のサブスクリプション名、最終更新時刻、更新前のノード数を記録します。
2. 一度だけ実行：対象のサブスクリプションで「更新」を実行し、リクエストが完了するまで待ちます。429が表示されたら、繰り返しクリックしないでください。
3. 読み込みを確認：ログでダウンロード、解析、読み込みが成功したことを確認します。新しい設定を手動で有効化する必要がある場合は、ここで切り替えてください。
4. 内容を確認：既知の変更があるノードやルールを確認します。ノード数が変わらなくても更新されている場合があります。サーバーが変更なしの内容を返すこともあります。
5. 最後にキャッシュを処理：URLが正しく、応答も有効なのにクライアントが古い内容を読み込み続ける場合に限り、クライアントのドキュメントに従って対象のキャッシュを処理します。設定フォルダー全体を削除しないでください。

サブスクリプションURLの末尾にランダムなパラメーターを追加して、安易に「キャッシュを回避」しないでください。署名やクエリパラメーターの厳密な検証を行うサービスでは、変更によってURLが無効になることがあります。304 Not Modifiedは通常、サーバーが現在のキャッシュを有効と判断したことを示すため、このステータスだけを理由に更新失敗と判断する必要はありません。

解決しない場合：再現に必要な情報をまとめる

まずは最小限の比較テストを行います。同じサブスクリプションで、元のネットワークとスマートフォンのテザリングをそれぞれ試し、さらに直接接続とプロキシ経由のダウンロードを比べてください。それぞれ一度だけ実行し、時刻とエラーを記録します。4通りの結果を比べれば、ネットワーク経路、サブスクリプションサービス、クライアントのどこに原因があるかを切り分けやすくなります。10回続けてクリックするより効果的です。

• OS、クライアントの正確なバージョン、コア名とバージョンを記録します。「最新版」だけでは情報が足りません。
• サブスクリプションのダウンロード時に表示されたエラーコード、解析の成否、エラーが発生した現地時刻とタイムゾーンを記録します。
• システムプロキシ、TUN、プロキシ経由のサブスクリプション更新をそれぞれ有効にしているか記録します。
• 機密情報を伏せたエラー部分を共有します。サブスクリプションURL全体、ノードのパスワード、設定ファイルの原文は公開しないでください。

復旧したら、自動更新を適切な間隔に設定し、動作確認済みの設定を1つ保存しておきます。サブスクリプション更新は設定の取得を担いますが、ノードへの接続、ルールによる振り分け、アプリがプロキシを使うかどうかは、それぞれ別に確認する必要があります。手順を分けておけば、同じ問題が起きても該当する段階からすぐに調査できます。