Clashのサブスクリプションを更新できないときの対処法｜よくある原因と自動更新間隔

まず失敗箇所を特定：ダウンロード・解析・有効化

サブスクリプションの更新は通常、クライアントがURLにアクセスし、応答内容を確認してから設定を保存または読み込む、という3段階で進みます。「更新に失敗しました」と表示されても、ノードが使えなくなったとは限りません。ノードに接続できても、サブスクリプションURLが有効とは限りません。調査を始める前に現在使える設定を残し、削除して再インポートしたり、更新ボタンを何度も押したりしないでください。

1. 対象を記録：「設定 / Profiles」にあるリモート設定全体か、「プロキシプロバイダー / Proxy Providers」にある特定のノード一覧かを確認します。
2. ログを記録：クライアントの「ログ / Logs」を開き、手動で一度更新して、同じ時刻付近のエラー、HTTPステータスコード、設定名を保存します。メニュー名はクライアントによって異なる場合があります。
3. 現在の状態を確認：以前の設定がまだ使えるか、最終更新成功時刻が変わったか、更新後に対象の設定が選択されているかを確認します。

ダウンロードのタイムアウト：ドメイン、ネットワーク、通信経路を個別に確認

設定を変える前に、まずネットワークを切り替える

context deadline exceededは処理が制限時間を超えたことを示しますが、このメッセージだけではDNS、TCP接続、TLSハンドシェイク、応答の読み込みのどこで遅延したかは分かりません。まずログで具体的な段階を確認し、同じ端末でWi-Fiからスマートフォンのテザリングに切り替えて、同じサブスクリプションURLを手動で一度更新します。原因を切り分けるため、変更する条件は一度に一つにしてください。

• ドメイン解決に失敗：URLに余分な空白や改行が入っていないか、文字が欠けていないか確認します。他のWebサイトを開けても、サブスクリプションのドメインを解決できるとは限りません。
• 接続を拒否された：connection refusedは通常、接続先のポートで接続が拒否されたことを示します。サーバーアドレスやローカルプロキシの待ち受け状態を確認してください。
• 読み込みタイムアウト：サーバーは接続を受け付けたものの、応答が完了していない可能性があります。発生時刻とネットワーク環境を記録し、サービス提供元に問い合わせてください。

システムプロキシ、TUN、サブスクリプションのダウンロードは別の設定

設定全体はクライアントの画面プロセスがダウンロードする場合もあれば、別のコンポーネントが処理する場合もあります。一方、proxy-providersのリモートリソースは通常コアが取得します。そのため、ブラウザーがプロキシ経由で通信できても、サブスクリプションのリクエストが同じ経路を使っているとは限りません。TUNでどの接続を処理できるかは、ルーティング、プロセスの除外設定、クライアントの実装にも左右されます。

クライアントに「プロキシ経由で更新」などの設定があれば、まず利用可能なノードがあることを確認してから、その設定を切り替えて結果を比較します。古いノードがすべて使えない状態で、新しいサブスクリプションの取得に古いノードを必須とすると、依存関係が循環するおそれがあります。直接接続を試すか、サブスクリプションURLにアクセスできる別のネットワークを使ってください。

証明書エラー：時刻と信頼チェーンを確認

HTTPSのサブスクリプションでは、サーバーの正当性を検証する必要があります。証明書エラーが出ても、検証を無効にせず、まずエラーメッセージ全体を確認してください。ノード設定のskip-cert-verifyは該当ノードのTLS検証に関する項目であり、クライアントのサブスクリプションダウンロード全般を修復する設定ではありません。

1. システム時刻を同期：OSの日付と時刻を自動設定にし、年、タイムゾーン、同期状態を確認します。システム時刻がずれていると、有効な証明書がまだ有効でない、または期限切れと判定されることがあります。
2. ドメインを確認：certificate is valid forなどのエラーは、ホスト名が一致していない可能性があります。サブスクリプションのドメインを勝手にIPアドレスへ置き換えないでください。証明書の検証と仮想ホストの選択に影響するおそれがあります。
3. ネットワーク認証を確認：公衆Wi-Fiでは、先に認証ページを開く必要がある場合があります。ログイン後に更新してください。組織のネットワークでHTTPS検査が行われていると証明書チェーンが変わることもあるため、ネットワーク管理者に確認します。
4. 信頼環境を確認：certificate signed by unknown authorityは、サーバーの証明書チェーンが不完全な場合だけでなく、端末の信頼ストアやネットワークによる検査が原因の場合もあります。個人のテザリングに切り替えて再確認すると、原因を絞り込めます。

端末の時刻が正しく、ネットワークを変えても同じサブスクリプションドメインで証明書の有効期限切れが報告される場合は、サービス提供元に修正を依頼してください。HTTPSのURLをHTTPに変えたり、見知らぬルート証明書をインストールして警告を回避したりしないでください。

YAML以外の応答：ステータスコードとサブスクリプション形式を確認

HTTPリクエストが成功しても、利用可能な設定を取得できたとは限りません。ステータスコードが200でも、本文がログインページ、アクセス確認ページ、契約期限切れの通知の場合があります。逆に、Content-Typeがtext/plainでも、それだけで失敗とは判断できません。有効なYAMLをこの形式で返すサービスもあります。最終的には本文の構造を確認してください。

よくある応答と対処方法

• 本文が<!DOCTYPE html>で始まる：Webページを取得しています。コピーしたURLがアカウント管理ページではなく、クライアント用のサブスクリプションURLか確認してください。ページ内容を設定ファイルとして保存し、無理に読み込ませないでください。
• 本文がvmess://などのURLや長いエンコード文字列：現在のクライアント向け設定ではなく、汎用のノードサブスクリプションを選んでいる可能性があります。サービス提供元のサブスクリプション出力画面に戻り、該当する形式を選んでください。
• 本文がJSON形式のエラー：まずサーバーから返されたエラー内容を確認してください。YAMLのインデントを直しても、アカウントの無効化やトークンのエラーは解決しません。
• 本文がYAML：続けてフィールドの階層、データ型、コアの対応状況を確認します。YAMLとして解析できても、Clashやmihomoの設定形式に適合するとは限りません。

設定全体とノード一覧を混同しない

設定全体にはproxies、proxy-groups、rulesを含めたり、proxy-providersでノード一覧を参照したりできます。一方、一般的なprovider用YAMLではproxies:にノードを列挙します。これはポリシーグループやルールを含む完全な設定とは異なります。ノード一覧専用の欄に設定全体のURLを入力したり、ノード一覧を設定全体として読み込んだりすると、解析や動作に問題が生じることがあります。

ログに特定のノード種類やフィールドが未対応と明記されている場合は、クライアントの「バージョン情報」でコアの名称とバージョンを確認してください。従来のClashとClash Meta（現mihomo）では対応範囲が異なるため、アプリ名にClashが含まれているかだけでは判断できません。フィールドの階層は設定ファイルの構造、形式変換の範囲はサブスクリプションの変換ガイドを参照してください。

自動更新間隔：3種類のintervalを区別

「サブスクリプションを1時間ごとに更新」するために、YAMLの任意の場所へinterval: 3600と書くわけではありません。リモート設定全体の定期更新は通常、クライアントの設定管理機能で行います。providerのダウンロードとノードのヘルスチェックには、それぞれ別のフィールドがあります。これらを混同すると、遅延テストは動き続けるのにノード一覧が更新されない、といった状態になりがちです。

設定全体：リモート設定の項目で指定

一般的な操作例は、「設定 / Profiles」→対象のリモート設定のメニュー→「編集 / Edit」→自動更新または更新間隔です。実際のメニュー名はクライアントによって異なります。入力欄の単位が分なら60、秒なら3600で1時間です。別のクライアントの数値をそのまま流用しないでください。

まずは6時間ごと、または1日1回を目安にし、サービス提供元の指定に合わせて調整してください。URLが安定していてノードの変更も少ない場合、頻繁に更新しても効果はあまりありません。また、0が必ず更新無効を意味するとは限りません。明示的な無効化設定を使い、利用中のクライアントの説明を確認してください。

HTTP provider：対象のノード一覧で設定

以下はmihomoでよく使われるHTTP providerの設定例であり、単体で動作する完全な設定ではありません。example.comはドキュメント用の例示ドメインで、実際のノードは取得できません。利用時はアカウントで発行したノード一覧のURLを入力し、ポリシーグループからuseで一覧名を参照してください。

proxy-providers:
  daily-nodes:
    type: http
    url: "https://example.com/subscription.yaml"
    path: ./providers/daily-nodes.yaml
    interval: 21600
    health-check:
      enable: true
      url: "https://www.gstatic.com/generate_204"
      interval: 300

この例では21600秒が6時間で、ノード一覧のダウンロード間隔を指定します。300秒はヘルスチェックの間隔であり、ノード一覧は更新されません。ヘルスチェック用URLには、現在のノードからアクセスできるものを指定してください。複数のproviderを使う場合は、キャッシュファイルのパスを分け、同じファイルに書き込まないようにします。

手動更新：動作の確認と結果の検証

手動更新は修正が有効か確認するためのもので、何度も試せば成功するというものではありません。特に429が返された場合は、連続して更新ボタンを押さないでください。応答にRetry-Afterが含まれていれば、サーバーが指定した時間だけ待ちます。500、502、503などのサーバーエラーが出た場合は、現在の設定を残し、時間をおいて再試行するかサービスの稼働状況を確認してください。

1. バックアップを保存：クライアントのエクスポート機能を使って、現在利用できる設定を保存します。ローカルの上書き設定、ポリシー選択、サブスクリプションの入手元も別途記録してください。
2. 対象を確認：リモート設定の項目から更新を実行し、ポリシーグループの遅延テストボタンを誤って押さないようにします。providerを更新するときは、ノード一覧の名前も確認してください。
3. 変更は一つずつ：たとえばネットワークの切り替えかシステム時刻の修正のどちらか一方を行い、手動更新を一度実行してエラーが変わったか記録します。
4. 保存と読み込みを確認：更新時刻が変わったこと、ログに後続の解析エラーがないこと、現在有効な設定が正しいことを確認します。現在選択されていない設定を更新しても、自動では切り替わらないクライアントがあります。
5. 実際の接続を確認：ポリシーグループで有効なノードが選択されていることを確認してから、普段使うサービスにアクセスします。「ダウンロード成功」と「サービスへ正常にアクセスできること」は別々に確認してください。

更新後にノードが復旧してもカスタムルールが消えた場合は、遠隔設定ファイルに直接変更を書き込んでいなかったか確認してください。次回のダウンロードでそのファイルが置き換わることがあります。ルールを長期的に使う場合は、クライアントが正式に対応する上書き、マージ、拡張機能に設定し、最終的に生成された設定を確認してください。インポートと切り替えの手順はサブスクリプションのインポート手順を参照してください。

サービス提供元やクライアントの開発者に問い合わせる際は、発生時刻、OSとクライアントのバージョン、コアのバージョン、個人情報を伏せたステータスコード、「同じURLでネットワークを変えたら成功するか」の比較結果を伝えてください。「更新に失敗した」と繰り返すより、原因の特定に役立ちます。サブスクリプションのトークン、ノードの認証情報全体、アカウント画面の画像に含まれる機密情報は、事前に削除してください。