Clashのサブスクリプション更新に失敗する原因と対処法｜リンク切れ・タイムアウト・自動更新間隔

まず失敗箇所を特定する：サブスクリプションの取得か設定の読み込みか

「サブスクリプションの更新に失敗しました」という問題は、主に3つの段階で発生します。クライアントが内容をダウンロードできない、サーバーから内容は返るものの有効な設定ではない、ファイルの保存後にコアがフィールドや参照のエラーを検出する、といったケースです。それぞれ対処方法が異なります。ノードに接続できても、ローカルに保存された古い設定が使えているだけかもしれません。サブスクリプションURLが有効だとは限りません。

現在使えている設定は残し、サブスクリプション項目をすぐに削除しないでください。クライアント名、コアの種類、更新時刻、エラー全文を記録します。ログを共有する前に、サブスクリプションURLのパスに含まれるキー、クエリパラメーター、ノードのパスワード、サーバーアドレスを隠してください。サブスクリプションURLはアクセス認証情報として機能することがあります。

リンク切れ：URL、アカウント、HTTPステータスコードを確認する

アカウントページではなく、サブスクリプションURLをコピーし直す

1. サービス提供元の管理画面にログインし、サブスクリプションの状態、有効期限、残りの利用量を確認してください。アカウントにログインできても、サブスクリプションをダウンロードできるとは限りません。
2. ClashまたはMihomo用と明記されたサブスクリプションの項目を選んでください。ブラウザーのアドレスバーに表示される管理画面のURLは、サブスクリプションURLの代わりにはなりません。
3. リンク全体をコピーし、?以降のクエリパラメーターも残してください。コピー時に混入した空白、改行、日本語の句読点は削除します。
4. 元のサブスクリプション項目の編集画面でURLを差し替え、保存してから手動で1回更新してください。サブスクリプションキーをリセットした場合は、ほかの端末に保存されている古いURLも差し替える必要があります。

401は通常、認証の問題を示します。403はアクセス制御、地域制限、保護ページなどが原因の可能性もあり、ステータスコードだけではアカウントの期限切れと判断できません。404はパスの誤りのほか、無効な認証情報をサービス側が隠している場合にも発生します。管理画面の状態とレスポンス内容をあわせて確認してください。

ステータスが200でもエラーページが返ることがある

サーバーが200を返すのは、HTTPリクエストが正常に処理されたことを示すだけです。本文が<!DOCTYPE html>や<html>で始まる場合、ダウンロードしたのはログインページ、CAPTCHAページ、メンテナンスページかもしれません。この場合、YAMLのインデントを変更しても解決しません。まず正しいサブスクリプションのレスポンスを取得してください。

キーを含むサブスクリプションURLを、公開のチェックサイトに貼り付けないでください。サービス提供元に調査を依頼する際は、ステータスコード、発生時刻、機密情報を伏せたエラーを伝えます。URL全体を送る場合は、信頼できる非公開のサポート窓口だけを利用してください。

タイムアウト：DNS・TLS・プロキシ経路を切り分ける

サブスクリプションのリクエストは、クライアント自身が送信する場合と、コアのproxy-providersが送信する場合があります。両者が同じネットワーク経路を使うとは限りません。システムプロキシやTUNモードを有効にしてブラウザーからサイトにアクセスできても、クライアントの更新リクエストが同じ経路を通るとは限りません。

エラーが発生した段階ごとに確認する

• ドメインの名前解決に失敗：no such hostが表示された場合は、サブスクリプションのドメインの綴り、システムDNS、現在のネットワークをまず確認してください。サブスクリプションのドメインをIPアドレスに置き換えるのは避けましょう。HTTPSの証明書検証や仮想ホストのルーティングに影響する可能性があります。
• 接続タイムアウト：dial tcpに続いてタイムアウトが発生する場合、接続段階が正常に完了していません。スマートフォンのテザリングに切り替えて試すと、現在のネットワークの制限かサーバー側の問題かを切り分けやすくなります。
• レスポンス待ちのタイムアウト：context deadline exceededは、複数の段階で発生する可能性があります。レスポンスヘッダーの待機に関するメッセージも表示される場合は、DNSだけでなく、サーバーの負荷や接続経路も確認してください。
• TLSエラー：x509、証明書の期限切れ、ホスト名の不一致が発生した場合は、まず端末の日付、時刻、タイムゾーンを確認し、その後サービス提供元に証明書の対応を依頼してください。証明書検証を無効にして問題を隠さないでください。

更新を2回比較して経路を特定する

クライアントにサブスクリプション更新の「直接接続」または「プロキシ」設定がある場合は、まず直接接続で手動更新し、次に現在使えるプロキシノードを選んで更新してください。毎回変更する条件は1つだけにします。直接接続では成功し、プロキシでは失敗する場合は、選択したノードとプロキシの出口を確認します。プロキシでは成功し、直接接続では失敗する場合は、ローカルネットワークからサブスクリプションのドメインに接続できるか確認してください。

現在の設定にあるノードがすべて使えず、更新にもそのノードの1つを経由する設定が必要だと、依存関係のループに陥ることがあります。その場合は、更新可能な経路に切り替えるか、信頼できる別のネットワークを一時的に使って設定を取得してください。手元に1つしかないローカル設定を先に削除しないでください。

形式の不一致：設定全体とプロバイダーを確認する

Clash YAML、Base64エンコードされたノードリンク、単一ノードURIは、それぞれ異なる形式です。ss://、vmess://、vless://のリンク一覧を完全なYAML形式のサブスクリプションとして直接インポートすると、解析エラーが発生することがあります。拡張子が.yamlでも、本文が正しい形式とは限りません。

ダウンロード後に読み込みに失敗する場合は、コアの対応状況を確認する

ClashとClash Meta（現名称：mihomo）では、対応するフィールドやプロトコルの範囲が完全には一致しません。ログに不明なプロキシタイプが表示された場合は、リンク切れと決めつけず、サブスクリプションの出力形式と使用中のコアを確認してください。まずはサービス提供元に、現在のコアに対応した形式を提供してもらいましょう。クライアントを変更する場合は、使用するコアの種類を事前に確認してください。

ログにYAMLの行番号が示されている場合は、その行と前後の行でインデント、引用符、リスト記号を確認してください。プロキシグループやルールが参照する名前が存在しないというエラーなら、proxy-groups、rules、ノード名が一致しているか確認します。リモートサブスクリプションの更新で手動編集が上書きされることがあります。継続的な変更は、クライアントが対応するオーバーライドやマージ設定に記述してください。

形式を変換する必要がある場合は、まずサービス提供元が用意している対象形式を使ってください。サードパーティのオンライン変換サービスでは、元のサブスクリプションURLの送信が必要になることがあります。サブスクリプションの内容や認証情報を取得される可能性があるため、安易に送信しないでください。

自動更新間隔：クライアントの設定とintervalフィールド

自動更新には2つの仕組みがあります。クライアントがサブスクリプション全体を定期的にダウンロードする仕組みと、コアが設定内のノードプロバイダーを定期的に更新する仕組みです。前者は通常、クライアント独自のサブスクリプション情報に保存され、後者はproxy-providers内のintervalで指定します。互いに置き換えることはできません。

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

Clash Verge Revの一般的な画面を例にすると、「サブスクリプション」→対象のサブスクリプションカードの右クリックメニュー→「編集」と進み、「更新間隔」欄を探します。バージョンによってメニューの表記が異なる場合があるため、実際の編集画面を確認してください。この画面では分単位で設定することが多いので、入力前に単位の表示を確認し、コアの秒数をそのまま入力しないでください。

1. まず手動更新が成功することを確認してから、自動更新を設定してください。まずは360分（6時間）を目安にし、サービス提供元のリクエスト頻度の制限を守りましょう。
2. 編集内容を保存し、クライアントで自動更新の設定を別途有効にする必要があるか確認してください。遅延テストの間隔をサブスクリプションの更新間隔と混同しないでください。
3. クライアントを起動したままにし、次回の更新記録を確認してください。アプリの終了、端末のスリープ、OSによるバックグラウンド動作の制限などで、定期更新が遅れることがあります。

mihomoのノードプロバイダーではintervalを秒で指定する

以下はノードプロバイダーの例であり、完全な設定ではありません。例にあるドメインは構造の説明用で、実際のノードはダウンロードできません。実際に使う際は有効なURLに置き換え、プロキシグループからuseでプロバイダーを参照してください。

proxy-providers:
  remote-nodes:
    type: http
    url: "https://subscription.example.com/nodes.yaml"
    path: ./providers/remote-nodes.yaml
    interval: 21600

ここでの21600は21600秒、つまり6時間を表します。pathはローカルのキャッシュファイルを指すため、コアの実行ユーザーにそのディレクトリへの書き込み権限があることを確認してください。URLが互換性のあるノードプロバイダーの内容ではなく、完全な設定を返す場合は、更新間隔を変更しても形式エラーは解決しません。

url-testプロキシグループのintervalや、プロバイダーのヘルスチェック間隔をサブスクリプションの更新間隔と混同しないでください。これらのフィールドはノードの稼働状況や遅延を確認するためのもので、サブスクリプション全体のダウンロードには使われません。ログに429が表示された場合は、60秒ごとにリクエストを繰り返すのではなく、サービス提供元の指示に従って更新間隔を延ばしてください。

更新後の確認：ファイル、ノード、ルールが反映されたか確認する

1. 更新結果を確認：対象サブスクリプションの更新時刻が変わり、ログにダウンロードや解析の失敗が続いていないことを確認してください。「リクエストを送信しました」と表示されただけでは、更新完了とは限りません。
2. 現在の設定を確認：更新したサブスクリプションが実際に使用されているか確認してください。有効化されていない設定を更新しても、現在の接続で使うノード一覧は変わらないことがあります。
3. ノードとプロキシグループを確認：ノードの数と名前、プロキシグループからの参照を確認してください。ノードのテストに成功してもアクセスできない場合は、ルールの一致状況と出力先も確認します。
4. 次回の更新を確認：次の自動更新が実行されたか記録してください。手動更新は成功し、自動更新だけ失敗する場合は、URLを作り直す前に、アプリの起動状態、スケジュール設定、更新時のネットワークを確認してください。

それでも解決しない場合は、機密情報を伏せた記録をサービス提供元またはクライアントのメンテナーに共有してください。クライアント名、コアの種類、エラー発生時刻、HTTPステータスコードまたはエラー全文、直接接続とプロキシ経由それぞれの結果を記載します。ネットワークリクエストの失敗、設定形式のエラー、定期タスクが実行されない問題は、分けて説明してください。

フィールドを確認するには設定リファレンスを、初めてサブスクリプションを読み込むにはクイックスタートを参照してください。クライアントを変更する前に設定をバックアップし、サブスクリプションの問題と移行時の問題が重ならないようにしましょう。