Clash サブスクリプション更新失敗の一般的な原因と自動更新の設定方法

まず症状を確認:更新失敗の3つの典型的なパターン

サブスクリプションの更新失敗は単一の故障ではなく、いくつかの症状の総称です。切り分けを始める前に、自分がどのパターンに当てはまるかを確認しましょう:

• 「更新」をクリックすると数秒間読み込みが続き、タイムアウトや Error の表示が出て、サブスクリプション項目のタイムスタンプがそのまま動かない。
• 更新成功と表示されるのにノードリストが一切変わらず、タイムスタンプも数日前のまま——多くの場合、ローカルキャッシュを読んでいるか、新しい設定の書き込みに失敗しています。
• サブスクリプション項目が赤く表示されノード数がゼロになり、ログに context deadline exceeded、403 Forbidden、401 Unauthorized などの文字が現れる。

クライアントのログパネルを開き、エラーメッセージの原文をすべて控えてから次に進みましょう。「更新失敗」の一言だけでは情報がなく、エラー原文にこそ手がかりがあります。

ネットワークの原因:更新リクエストはデフォルトでプロキシを通らない

これはサブスクリプション更新失敗の原因として最も多く、同時に最も見落とされやすいものです。

サブスクリプション更新の実体は、ごく普通の HTTPS リクエストです。クライアントがサブスクリプションアドレスに接続し、ノードリストを取得します。多くのクライアントはこのリクエストをデフォルトで直接接続にし、プロキシを通しません。そのため一見矛盾した現象が起きます——ノードは使えるのにサブスクリプションだけ更新できない、という状態です。理由は単純で、ノードの通信はプロキシトンネルを通るのに対し、更新リクエストはトンネルの外をそのまま流れるからです。サブスクリプションのドメインがローカルネットワークから到達不能だったり、サーバーからローカルへの回線品質が悪かったりすると、直接接続のリクエストはタイムアウトします。

対処法は3つあります。順番に試してください:

1. TUN モードまたはシステムプロキシを有効にしてから、もう一度手動で更新します。TUN がマシン全体の通信を引き受けると、更新リクエストもトンネル内に入り、直接接続の遮断を回避できます。TUN の有効化と切り分けの詳細はトラブルシューティングページを参照してください。
2. クライアントのサブスクリプション設定にある「プロキシ経由で更新」オプションをオンにします。Clash Verge Rev ではサブスクリプション項目の編集メニューにこのスイッチがあり、FlClash や Clash Meta for Android のサブスクリプション編集にも同様の設定があります。オンにすれば直接接続が通らなくても更新を完了できます。
3. mihomo の設定を手書きしている場合は、proxy-providers でサブスクリプションソースに proxy フィールドを指定すると、ダウンロード通信が指定したプロキシグループを通るようになります:

proxy-providers:
  airport:
    type: http
    url: "https://example.com/api/sub?token=xxxx"
    interval: 43200
    proxy: 节点选择
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300

proxy フィールドを書かない場合のデフォルトは DIRECT(直接接続)で、これこそが多くの人が更新に失敗する根本原因です。

リンクの原因:無効化・リセット・形式の不一致

ネットワークに問題がなければ、リンク自体を調べます。サブスクリプションリンクの無効化には4つの典型的なケースがあります:

• プランの期限切れ・データ量の枯渇:プロバイダはサブスクリプションの応答を直接遮断し、403 または空の内容を返します。プロバイダの公式サイトにログインしてプランの状態を確認しましょう。この一手間で「クライアントの故障」という誤判断の半分を排除できます。
• サブスクリプションのリセット:プロバイダの管理画面で「サブスクリプションをリセット」を実行すると、古い token は即座に無効になり、クライアント内の古いアドレスは永久に更新に失敗します。新しいリンクをコピーして再インポートすれば解決します。
• プロバイダのドメイン変更:旧ドメインが到達不能または廃止されると、古いリンクはリダイレクト異常を起こすか完全に接続できなくなります。公式サイトのお知らせにある最新のサブスクリプションアドレスを基準にしてください。
• UA 形式の不一致:多くのプロバイダはリクエストの User-Agent に応じて異なる形式を返します。ブラウザでサブスクリプションを開いて長い base64 文字列が見えても、Clash で使えるとは限りません——Clash 系クライアントが必要とするのは YAML です。クライアントの UA が誤判定されると汎用形式が返され、解析がそのままエラーになります。

mihomo ユーザーは proxy-providers の header フィールドで UA を明示的に指定し、Clash 形式で返すよう強制できます:

proxy-providers:
  airport:
    type: http
    url: "https://example.com/api/sub?token=xxxx"
    interval: 43200
    header:
      User-Agent:
        - "clash.meta"

また、第三者のサブスクリプション変換サイトを経由したリンクは、変換サイトのダウンやドメインの到達不能でも更新に失敗します。切り分けの段階では変換サイトを迂回し、まずプロバイダの元のサブスクリプションリンクで検証することをおすすめします。

環境の原因:システム時刻・書き込み権限・セキュリティソフト

リンクとネットワークの両方が正常なら、問題はマシンの環境にあります。発生頻度の高い順に並べます:

• システム時刻のずれが大きい:TLS 証明書の検証はシステム時刻に依存し、数分のずれでもハンドシェイクに失敗します。ログには通常 certificate の文字が含まれます。時刻を校正し、自動同期を有効にしてから再試行してください。
• 通信の中間傍受:社内ネットワークやキャンパスネットワークが TLS インスペクションを行っている場合、クライアントは中間証明書を信頼せず、更新は必ず失敗します。スマートフォンのテザリングに切り替えて一度検証すれば特定できます。
• 設定ディレクトリに書き込み権限がない:サブスクリプション内容のダウンロードには成功したのにローカルファイルに書き込めず、「更新したのに変化がない」という状態になります。Windows でクライアントを Program Files にインストールし通常権限で実行している場合に最も起きやすい問題です。設定ディレクトリの権限とディスク空き容量を確認してください。
• セキュリティソフトによる遮断:一部のウイルス対策ソフトはクライアントの送信リクエストをブロックします。クライアントの本体プログラムをホワイトリストに追加してから再試行してください。
• クライアントのバージョンが古い:Clash のオリジナルコアはメンテナンスが終了しており、新しい形式のサブスクリプションとの互換性が悪化しています。mihomo コアの現行クライアントに切り替えれば、解析系の問題はたいてい解消します。

自動更新:間隔はどう設定するのが適切か

自動更新の仕組みはシンプルです。クライアントが設定した間隔であの HTTPS リクエストを繰り返します。間隔の設定はトレードオフです——短すぎるとサブスクリプション API への頻繁なリクエストでプロバイダの API クォータを消費し、高頻度アクセスに対するレート制限を誘発してサブスクリプションが一時的に停止される恐れがあります。長すぎるとノードの増減や入口アドレスの変更といった重要な情報を取得できず、使っているうちに接続が切れてしまいます。

経験上の適切な範囲は 6〜24 時間に1回です。各クライアントの設定場所と単位は次のとおりです:

混同しやすい点が2つあります。1つ目、mihomo 設定の interval の単位は秒であり分ではありません。12 時間に設定したい場合は 43200 と入力します。2つ目、proxy-providers 内の health-check の interval はノード遅延チェックの頻度であり、サブスクリプションのダウンロード頻度とは無関係です。変更する際は行を間違えないようにしてください。

最後に、手動更新の習慣も残しておきましょう。プロバイダが入口の変更やノード調整を告知したときは、次の自動更新をじっと待たず、クライアントで手動更新を一度実行すれば即座に反映されます。

更新後:4ステップの確認チェックリスト

1. サブスクリプション項目のタイムスタンプを確認し、現在時刻に更新されていることを確かめる。
2. ノード数とグループ構成を確認し、プロバイダの公式サイトの告知と一致しているか確かめる。
3. 使用中のノードに遅延テストを一度実行する——サブスクリプション更新後に旧ノードが廃止されている可能性があり、無効なノードに接続したままだと「プロキシはあるのにネットに繋がらない」状態になります。
4. ブラウザで海外サイトにアクセスして経路の疎通を確認する。繋がらなければノードリストに戻って再度速度テストで選び直します。

サブスクリプション問題の切り分け順序は固定できます。まずエラー原文を確認し、次にネットワークの直接接続を調べ、リンクの状態を確認し、最後にマシン環境を調べます。9割以上の更新失敗はこの4ステップで特定できます。あとは自動更新に任せ、間隔を12時間前後に設定しておけば、普段は何もする必要がありません。