Clashのサブスクリプション更新に失敗する原因と対処法｜タイムアウト・証明書・形式エラーと自動更新間隔

まず失敗した段階を特定：ダウンロード・解析・読み込み

Clashのサブスクリプション更新は、ひとつの処理ではありません。クライアントがサブスクリプションURLにリクエストを送り、応答を取得して設定を解析した後、ファイルを保存してコアに読み込ませます。ダウンロードに成功しても形式が正しいとは限らず、設定を保存できても、使用中のコアですべての項目が動作するとは限りません。何度も「更新」を押すより、どの段階でエラーが起きたかを確認しましょう。

サブスクリプション管理は主にGUIクライアントが担います。Clash、Clash Meta、mihomoのコア機能と、クライアントのダウンロード処理は同じではありません。更新時のプロキシ、スケジューラー、エラー表示はクライアントによって異なります。以下では設定項目の意味と確認手順を説明します。メニュー名は使用中のバージョンで確認してください。

1. クライアントの「サブスクリプション」または「設定」画面で、失敗した項目の名前、最終更新日時、エラーの詳細を記録します。
2. 現在使えている設定は残し、サブスクリプションを削除したり、ノードをすべて消去したりしないでください。再インポートする前に、元のURLから内容を取得できることを確認します。
3. クライアントのログを開き、手動更新を1回だけ実行します。同じ時刻のダウンロードエラーとコアの読み込みエラーを確認してください。
4. 「更新に失敗」と「更新後にノードが使えない」は区別してください。後者ではノードの状態、グループ、ルールも確認が必要です。サブスクリプションのダウンロードが原因とは限りません。

タイムアウトの調査：直結と更新用プロキシを比較

名前解決の失敗と接続タイムアウトを切り分ける

no such host は通常、ドメイン名の解決に問題があることを示します。connection refused は接続拒否、i/o timeout は接続、ハンドシェイク、読み込みのどの段階で起きたかをログで確認する必要があります。ネットワークエラーが出たからといってすぐDNSを変更したり、ブラウザーでサービスのトップページを開けることをサブスクリプションAPIの正常性の証拠とみなしたりしないでください。

WindowsではPowerShellで次の2つのコマンドを実行し、HTTPS接続とローカルの待ち受け状態を確認できます。1つ目はこのサイトの443番ポートだけを確認するもので、実際のサブスクリプションドメインの確認には代用できません。2つ目の7890は一般的な混合ポートの例です。クライアントに表示されている値と照合してください。

Test-NetConnection clash-winpc.com -Port 443
Test-NetConnection 127.0.0.1 -Port 7890

サブスクリプションのログに特定ドメインへの接続失敗が記録されている場合は、1つ目のコマンドのホスト名をそのドメインに置き換えてテストできます。ホスト名だけを使い、アクセストークンを含む完全なURLを公開スクリーンショットや問い合わせの件名に貼り付けないでください。ポートに接続できても、TLS、認証、本文のダウンロードがすべて正常とは限りません。

ブラウザーでは開けるのにクライアントがタイムアウトする

ブラウザーはシステムプロキシを使う一方で、クライアントのサブスクリプションダウンローダーは直接接続する場合があります。逆に、ダウンローダーがすでに使えないプロキシ経由に設定されていることもあります。TUNモードが実際のルーティングに影響する場合もあるため、画面上で「更新時は直結」を選んでも、通信が最終的に中継されないとは限りません。

1. 失敗したサブスクリプションの編集メニューを開き、「更新用プロキシ」「プロキシ経由で更新」などの項目を探し、現在の設定を記録します。
2. まず直結で1回、次に正常に使えることを確認した出口経由で1回テストします。一度に変更する項目は1つにし、それぞれの時刻のログを残してください。
3. プロキシアドレスを手動入力する場合は、ダウンローダーがHTTPプロキシとSOCKSプロキシのどちらに対応しているか確認します。混合ポートの例は http://127.0.0.1:7890 です。実際のプロトコルとポートはクライアントの設定に従ってください。
4. プロキシの待ち受けが正常なのにリクエストがタイムアウトする場合は、選択した出口からサブスクリプションのドメインにアクセスできるか、無効なポリシー、認証、ネットワーク制限がないか確認します。

たとえば毎回約30秒後に失敗するなど、一定時間でリクエストがタイムアウトする場合は、クライアントにダウンロードのタイムアウト設定があるか確認してください。すべてのクライアントの初期値が30秒とは限りません。読み込み時間を適度に延ばすと応答が遅い場合には有効ですが、無効なドメイン、接続拒否、権限エラーは解決できません。

証明書エラー：時刻・ドメイン・信頼チェーンを確認

HTTPSの証明書検証は、接続先サーバーの身元を確認するためのものです。証明書エラーが出た場合は、時刻や信頼チェーンを修正してください。証明書検証の無効化を通常の対処法にしてはいけません。サブスクリプションURLにはアクセス情報が含まれることが多く、検証を安易に緩めると、認証情報や設定内容が漏えいするリスクが高まります。

• 有効化前または期限切れ：Windows 11では「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」を有効にして「今すぐ同期」をクリックします。システムの日付が正しいことを確認してから再試行してください。
• ドメイン名の不一致：サブスクリプションURLにサービス提供元が指定したドメインが使われているか確認します。HTTPSのドメインを勝手にIPアドレスに置き換えたり、廃止された古い接続先を使い続けたりしないでください。
• 発行元が不明：サーバーの証明書チェーンが不完全、端末の信頼ストアに問題がある、または企業ネットワークでHTTPS通信が検査されている可能性があります。まずシステムを更新し、サービス提供元またはネットワーク管理者に確認してください。
• ブラウザーでは正常なのにクライアントでエラー：ブラウザーとダウンローダーでは、信頼ストアやネットワーク経路が異なる場合があります。クライアントの正確なバージョンとエラー内容を記録してください。ブラウザーで正常に開けるだけでは、証明書の問題を否定できません。

ノード設定内の skip-cert-verify は、該当するプロキシ接続の証明書検証を制御する項目です。GUIクライアントのサブスクリプションダウンローダー全般に適用される設定ではありません。ノードのこの項目を変更しても、サブスクリプションのダウンロード時に発生する x509 エラーは通常解決しません。トラブルシューティングのために一括で有効にするのも避けてください。

HTTPステータスコードと形式エラー：設定ファイルが返されているか確認

まず権限とレート制限を確認し、その後YAMLを調べる

サーバーからレスポンスが返ってきても、それがサブスクリプションファイルとは限りません。ログインページ、アカウントの有効期限通知、アクセス確認ページがダウンロードされ、YAMLの解析エラーとして表示されることがあります。HTTPステータスが 200 でも、本文がHTMLの場合があります。

レスポンスの内容を確認するときは、ローカルのテキストエディターを使い、構造だけを確認してファイル全体は公開しないでください。サブスクリプションにはノードのパスワード、トークン、内部ドメインなどの機密情報が含まれることがあります。第三者のオンライン検査・変換サービスにも、これらの内容が渡る可能性があります。

完全な設定ファイル、ノード一覧、providerファイルは別のもの

完全なClash YAMLには通常、proxies、proxy-groups、rules などの設定セクションが含まれますが、有効な設定ファイルにこれら3つすべてが必須というわけではありません。Base64形式のノード一覧や、ss:// などのプロトコルで始まるURI一覧は、拡張子を .yaml に変えただけではClash設定になりません。

proxy-providers で使うノードファイルは通常、proxies: の下にノードを記述します。ルールプロバイダーには、それぞれ対応するルールデータの形式を使います。これらを完全なデスクトップ設定として直接インポートしないでください。サービス提供元がClashまたはmihomo対応と明記している出力を選び、使用中のクライアントがそのインポート方法をサポートしているか確認してください。

• インデントの誤り：YAMLの階層にはスペースを使い、Tabは避けてください。エラー行とあわせて直前の行も確認します。コロンの書き忘れが次の行のエラーとして表示されることもあります。
• 型の誤り：リストであるべき項目が文字列になっている、または値の型がコアの想定と異なる可能性があります。エラーが出た項目を削除するだけで、設定の意味を無視しないでください。
• コアとの互換性：mihomo向けの新しいプロトコルや拡張項目は、オリジナル版Clashのコアで処理できない場合があります。実際に動作しているコアとバージョンを確認し、互換性のある出力を選んでください。
• 参照先が無効：ポリシーグループやルールが存在しない名前を参照していると、ファイルの解析には成功しても読み込みに失敗することがあります。名前の表記と大文字・小文字、サブスクリプション更新後のノード構成を確認してください。

自動更新間隔：クライアントのサブスクリプションとコアのproviderを区別

クライアントのサブスクリプション更新タイマー

デスクトップクライアントでは通常、「サブスクリプション／設定」→「対象のサブスクリプションメニュー」→「編集」から自動更新を設定できます。バージョンによっては全般設定に項目があります。「自動更新」「更新間隔」「更新用プロキシ」を見つけたら、まず項目の単位を確認して保存してください。プロジェクトごとに初期値は異なるため、特定クライアントの画面設定をClashコアの標準仕様とみなさないでください。

一般的な利用では、まず6時間ごとを目安に設定できます。画面の単位が分の場合は 360、秒の場合は 21600 を入力します。これは推奨値の一例であり、共通の初期値ではありません。サービス提供元が最短間隔を指定している場合は、その制限に従ってください。ノードの変更が少ない場合は、12時間または24時間ごとの更新でもかまいません。障害を隠すために毎分更新する設定は避けてください。

1. 自動更新を有効にする前に、手動でサブスクリプションを更新できることを確認します。
2. 間隔を保存したら、サブスクリプション一覧に設定が反映されているか確認し、最終更新成功時刻を記録します。
3. 次回の予定時刻を過ぎたらログを確認します。PCがスリープ中、またはクライアントが終了している間も、デスクトップのタイマーが動き続けるとは限りません。
4. 「起動時に更新」を有効にしている場合は、起動時の動作も個別に確認してください。固定間隔での更新とは別の条件です。

mihomoのHTTP provider更新パラメーター

設定で proxy-providers を使用している場合、リモートノードproviderはコアが個別に更新できます。HTTP providerの interval は秒単位です。対応する proxy 項目では、そのリソースのダウンロードに使う送信先の名前を指定します。以下は既存のHTTP provider内に記述するフィールドの一部であり、単独では完全な設定としてインポートできません。

# 既存のHTTP proxy-provider定義内に記述
interval: 21600
proxy: DIRECT

DIRECT は直接接続の送信先を選ぶ指定であり、現在のネットワークからリソースにアクセスできることを保証するものではありません。プロキシやポリシーグループの名前に変更する場合、その名前が設定内に存在し、有効である必要があります。また、まだダウンロードできていない同じproviderを経由して接続先を取得する構成は避けてください。対応範囲は、実際の設定検証結果とコアのバージョンで確認してください。

復旧後の確認手順と問い合わせ時の情報

エラー表示が消えた後も、新しい内容が現在の設定に反映されたか確認が必要です。ファイルの更新日時が変わっただけでは不十分です。ダウンロードには成功しても、上書き、マージ、コアの検証で失敗する場合があります。トラブルシューティング中にプロキシ、DNS、TUN、設定形式を同時に変更しないよう、次の順番で確認してください。

1. ダウンロードの成功を確認：サブスクリプション一覧に新しい更新成功時刻が表示され、該当時刻のHTTPまたはTLSエラーがログにないことを確認します。
2. 読み込みの成功を確認：現在の設定に解析エラーがなく、ポリシーグループが正常に表示されることを確認します。更新前後でサブスクリプションに変更がなければ、ノード数が変わらなくても正常です。
3. 接続できることを確認：使用可能とわかっている出口を選んで対象サイトにアクセスし、接続ログで適用されたルールと実際の送信先を確認します。
4. 自動更新を確認：クライアントを起動したまま設定した更新間隔を待ち、次回の更新成功時刻を確認します。

サービス提供元またはクライアントプロジェクトに問い合わせる際は、OSのバージョン、クライアントのバージョン、実際に使用しているコアのバージョン、発生時刻、エラー内容、直結とプロキシ経由での更新結果の比較を伝えてください。サブスクリプションURLのパス、クエリパラメーター、ノードの認証情報は伏せてください。設定全体を公開の問い合わせ欄にアップロードしないでください。インポートや接続の手順は使い方ガイド、各項目の意味はプロトコルリファレンスをご覧ください。