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

まず、失敗しているのがサブスクリプションのダウンロードか、設定の読み込みかを確認

Clashのサブスクリプション更新は通常、クライアントがURLにアクセスし、応答を設定ファイルとして保存した後、コアが設定を検証して読み込むという3段階で行われます。「更新失敗」はどの段階でも起こり得ます。ノードに接続できても、以前の設定が引き続き使われている可能性があるため、新しいサブスクリプションのダウンロードに成功したとは限りません。画面上の最終更新時刻が変わっていても、新しい設定が正常に読み込まれたとは限りません。

まずクライアントの「設定」または「Profiles」画面を開き、対象のサブスクリプションを見つけて手動で「更新」します。その後、「ログ」または「Logs」で同じ時刻のエラーを確認してください。メニュー名はクライアントやバージョンによって異なります。ノード一覧の遅延テストではなく、サブスクリプション項目自体の更新操作を探しましょう。

1. エラーの内容を記録：context deadline exceeded、403、x509、yaml: line 12など、具体的なメッセージを記録します。「失敗」だけでは原因を絞り込めません。
2. 影響範囲を確認：失敗するのが1つのサブスクリプションだけなら、まずURLとサーバー側を確認します。異なる提供元のサブスクリプションが複数同時に失敗する場合は、端末のネットワーク、時刻、クライアント設定を調べましょう。
3. 現在使える設定をバックアップ：ダウンロード方法を変更する前に、現在の設定をエクスポートするかバックアップします。バックアップファイルにノードのパスワードが含まれる場合があるため、安全な場所に保管してください。

エラー別に原因を絞り込む：タイムアウト、ステータスコード、解析エラー

これらの手がかりは原因を絞り込むためのもので、必ずしも原因を断定できるものではありません。たとえば403はアカウントの期限切れではなく、保護用ゲートウェイによる拒否の可能性もあります。タイムアウトも、DNSの名前解決、接続確立、TLSハンドシェイク、応答本文の受信など、さまざまな段階で発生します。判断する際はエラー前後のログを残しつつ、リクエストに含まれる認証情報は公開しないでください。

サブスクリプションの取得がタイムアウトする場合：通信経路を確認

ブラウザーで開けても、クライアントがダウンロードできるとは限りません

ブラウザーはシステムプロキシ、独自のセキュアDNS、ログイン済みのセッションを使用する場合があります。一方、クライアントのサブスクリプション取得機能は、直接接続する場合もあれば、独自のプロキシ設定を使う場合もあります。そのため、「ブラウザーではダウンロードできるのに、Clashでは更新できない」という状況も起こり得ます。まずクライアントの設定画面で「プロキシ経由で更新」などの項目を確認し、ログを見て、サブスクリプションサーバーとローカルのプロキシポートのどちらに接続しているかを調べましょう。

• 直接接続でタイムアウトする：同じ端末をスマートフォンのテザリングに切り替えて、もう一度更新します。テザリングでは成功する場合、元のネットワークのDNS、外部への通信経路、アクセス制限が原因である可能性が高くなります。
• プロキシ経由の更新に失敗する：選択中のノードで通常のWebサイトにアクセスできるか確認します。以前のノードがすべて使えない状態で、それらのノード経由で新しいサブスクリプションを取得しようとすると、更新できない状態が循環します。
• エラーにローカルポートが表示される：127.0.0.1:7890などが示されている場合は、コアが起動しているか、混合プロキシポートが実際に7890かを確認します。これはよくある例であり、クライアントに表示される実際のポートとは異なる場合があります。

サブスクリプションを更新するためだけに「LAN内接続を許可」を有効にしないでください。ローカルのプログラムがループバックアドレスでプロキシに接続する場合、通常、LANにポートを公開する必要はありません。また、サブスクリプション更新にTUNが必須というわけでもありません。TUNはネットワークトラフィックを取り込む機能であり、サブスクリプションのダウンロードがその経路を通るかどうかは、ルーティング、プロセスの除外設定、クライアントの実装によって異なります。

何度もクリックせず、条件を変えて1回ずつ比較する

同じサブスクリプションURLを使い、「現在のネットワークから直接接続」「現在のネットワークから利用可能なプロキシ経由」「別のネットワーク」の順に試します。一度に変更する条件は1つだけにしてください。クライアントにダウンロードのタイムアウト設定がある場合は、短すぎる値を適度に延ばせます。ただし、ドメインの名前解決エラー、認証情報の失効、サーバーによるアクセス拒否は、タイムアウトを延ばしても解決しません。

解析エラー：Clash用の設定を取得できているか確認

サブスクリプションURLによって、返される内容は異なります。完全なClash設定には通常、proxies、proxy-groups、rulesなどのフィールドが含まれます。ノード一覧ファイルにはproxiesだけが含まれる場合があり、プロキシの一覧として使われます。また、エンコードされたノードURIのリストを返す一般的なサブスクリプションもあります。これは完全なYAML設定としてそのまま読み込めるものではありません。

まず応答の種類を確認し、その後でYAMLを編集する

1. サービス提供元の管理画面で、Clash、Clash Meta、mihomo用と明記されたサブスクリプションURLを選び、現在のクライアントのコアがその形式に対応しているか確認します。
2. 応答の冒頭が<!DOCTYPE html>、ログインページのタイトル、または認証ページの場合は、設定ではなくWebページを取得しています。ログインへのリダイレクト、アクセス制限、URLの選択ミスを確認してください。
3. 応答がvmess://やss://などのノードリンク一覧の場合は、クライアントが明示的に対応しているインポート方法を使うか、サービス提供元に対応形式の提供を依頼してください。
4. ログにYAMLの行番号が表示される場合は、ローカルに保存したファイルで該当行とその前の数行を確認し、インデント、コロン、引用符をチェックします。YAMLのインデントにはスペースを使い、タブを混在させないでください。

ファイルの拡張子を.yamlに変えただけでは、内容は変換されません。また、正体のわからないオンライン変換サイトにサブスクリプションURL全体を入力するのは避けてください。変換サービスにノード情報や認証情報を読み取られるおそれがあります。サービス提供元が用意した出力形式か、信頼できるローカルツールを使いましょう。

構文に問題がなくても、コアに対応していない場合があります

ログにunsupported proxy typeが表示されたり、未対応のフィールドが示されたりする場合、原因はダウンロードではなく、現在のコアが実装していないプロトコルやオプションを設定で使用していることかもしれません。Clash本家、Clash Meta、後継のmihomoでは、対応機能が完全に同じではありません。クライアントの「バージョン情報」またはコア情報画面で実際に動作しているコアを確認し、対応するサブスクリプション形式を選んでください。アプリ名だけでは互換性を判断できません。

新しくダウンロードした設定に構文エラーや互換性の問題がある場合は、見慣れないフィールドを1つずつ削除するのではなく、まずバックアップから元に戻してください。ポリシーグループ、プロキシ一覧、ルール参照を削除すると、今度は「ポリシーが見つからない」という読み込みエラーが発生する可能性があります。

証明書エラーとURLの無効化は分けて対処する

x509エラーが出たら、まず端末の時刻を確認

証明書の検証には、正しい日付と時刻が必要です。Windows 11では「設定」→「時刻と言語」→「日付と時刻」を開き、自動設定が有効になっているか確認して同期します。macOSでは「システム設定」→「一般」→「日付と時刻」で自動設定を確認してください。時刻を修正したら再度更新します。先にサブスクリプション形式を変更する必要はありません。

• certificate has expired or is not yet valid：端末の時刻を確認します。時刻が正しい場合は、サーバー側で証明書の有効期間を確認する必要があります。
• certificate signed by unknown authority：証明書チェーンの不備、端末の信頼ストアの問題、ネットワーク上のHTTPS検査などが考えられます。
• 証明書のドメイン名が一致しない場合：URLがIPアドレスに変更されていないか、異なるドメインに転送されていないか確認し、サービス提供元のHTTPS URLをコピーし直してください。

ノード設定のskip-cert-verifyは、該当ノードへの接続時に証明書を検証するかどうかを指定するもので、サブスクリプション取得全般の修復オプションではありません。切り分けのために証明書検証を無効にするとリスクが高まるうえ、認証エラーやYAMLの構文エラーも解決できません。

401・403エラーとアカウントの状態

サービス提供元の管理画面にログインし、プランが有効か、サブスクリプションURLが再発行されていないか、アクセス頻度や端末数の制限がないかを確認します。URLは管理画面のコピー機能を使って取得し、表示テキストの省略記号、改行、全角記号が混入しないようにしてください。疑問符以降のパラメーターをむやみに削除しないでください。認証情報が含まれている場合があります。

ブラウザーでログインした後に見られるページでも、クライアントから直接リクエストできるサブスクリプションAPIとは限りません。クライアントは通常、ブラウザーのログインCookieを引き継ぎません。正しいURLは、サービス提供元の仕様に従って設定を直接返し、ログインボタンのクリックを要求しないものです。

自動更新間隔：サブスクリプションとプロキシ一覧を区別する

「どのくらいの間隔で更新するか」には2種類の設定があります。クライアントに保存されたリモート設定はクライアント側で管理し、設定内のproxy-providersは、その機能に対応したコアが管理します。両方を併用できる場合もありますが、同じフィールドで代用することはできません。

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

「設定」または「Profiles」を開く → リモートサブスクリプションの項目を探す → 右クリックメニューまたはその他のメニューを開く → 「編集」「サブスクリプション設定」「自動更新」などの項目を確認します。現在のバージョンに更新間隔の設定がある場合は、入力欄の単位を確認してから保存してください。該当項目がない場合はクライアントのヘルプを確認しましょう。トップレベルにintervalを追加しても、画面からの自動更新は有効になりません。

これらは設定の目安であり、ノードの品質を示す指標ではありません。更新間隔を1分にしてもノードが速くなることはなく、かえってリクエスト制限の対象になる可能性があります。複数の端末で同じサブスクリプションを使う場合は、リクエスト数の合計も考慮してください。PCがスリープ中、スマートフォンのバックグラウンド動作が制限されているとき、またはクライアントが終了しているときは、更新タスクが予定どおりに実行されない場合があります。再起動後は最終成功時刻とログを確認してください。

プロキシ一覧：intervalの単位は秒

以下はプロキシ一覧に対応するコアの設定例です。例に使われているドメインは構造を示すためのもので、実際に使うにはサービス提供元が発行したプロキシ一覧のURLに置き換えてください。この断片だけでは設定として動作しません。

proxy-providers:
  remote-nodes:
    type: http
    url: "https://example.com/nodes.yaml"
    path: ./providers/remote-nodes.yaml
    interval: 21600
    health-check:
      enable: false

ここでのinterval: 21600は、21600秒、つまり6時間ごとにプロキシ一覧を取得する設定です。応答はそのコアに対応したプロキシ一覧形式である必要があり、通常はproxiesのリストを含みます。完全な設定のサブスクリプションを種類を確認せずに指定しないでください。ポリシーグループから利用するには、該当グループのuseリストでremote-nodesを参照する必要があります。

health-checkはノードの接続可否を確認する設定で、ノード一覧を再ダウンロードする設定ではありません。この例では更新動作だけを確認できるよう、無効にしています。サブスクリプションの更新を速める目的でヘルスチェックの間隔を短くしないでください。解決する問題が異なります。

設定後、更新処理が最後まで成功するか確認する

1. 手動で1回更新：ログに以前のダウンロードエラーや解析エラーが出なくなったことを確認し、最終成功時刻を記録します。
2. 設定の反映を確認：現在有効な設定が対象のサブスクリプションか確認し、ノードとポリシーグループが正しく表示されているか確認します。
3. ポリシーの選択状態を確認：更新後もポリシーグループで利用可能なノードが選択されているか確認します。サブスクリプションのダウンロードに成功しても、すべてのノードに接続できるとは限りません。
4. 実際にアクセスして確認：普段使うWebサイトを開いて接続状況とログを確認します。ノードへの接続失敗とサブスクリプションの取得失敗は分けて対処してください。
5. 更新間隔を1回待つ：クライアントが動作できる状態を保ち、新しい成功記録が出るか確認します。手動更新だけ成功する場合は、スケジュールタスク、バックグラウンド実行の権限、クライアントの動作状態を調べましょう。

クライアントの開発者やサービス提供元に問い合わせる場合は、OSとクライアントのバージョン、コアの名称とバージョン、失敗した時刻、エラー全文、直接接続とプロキシ経由でダウンロードした場合の比較結果を伝えてください。「サブスクリプションが壊れた」と伝えるより、原因を特定しやすくなります。サブスクリプションURL全体、ノードのパスワード、アカウント情報は、公開の場ではなく非公開のサポート窓口でのみ共有してください。