Clashのサブスクリプション更新に失敗

使える設定を残し、まず手動で一度更新する

Clashのサブスクリプション更新に失敗しても、現在使っているノードがすぐに無効になるとは限りません。多くのクライアントは、直前に正常取得した設定を引き続き使用します。以前のノードが使えるなら、接続を維持したまま更新経路を調べましょう。最初からサブスクリプションを削除したり、設定フォルダーを空にしたり、何度も再インストールしたりすると、通信可能な以前の設定まで失うおそれがあります。

1. 「設定」または「Profiles」を開き、現在有効なサブスクリプション名と最終更新時刻を確認します。
2. クライアントのエクスポートまたはバックアップ機能で、現在の設定を保存します。ファイルにはノードのパスワードやサブスクリプショントークンが含まれる場合があるため、信頼できる端末だけに保存してください。
3. 対象のサブスクリプションを一度「更新」し、「ログ」を開いてエラー全文、発生時刻、HTTPステータスコードを記録します。
4. 失敗しているのがサブスクリプション全体なのか、設定内の proxy-providers なのかを確認します。ダウンローダーや更新間隔が異なる場合があります。

エラーメッセージから失敗箇所を特定する

まずダウンロードへの応答があるかを確認し、次に応答内容を解析できるかを調べます。クライアントによっては、以下のエラーが独自の日本語メッセージに置き換えられます。判断にはログに記録された元のエラーを使いましょう。ステータスコードだけで契約切れと決めつけず、サブスクリプションサービスの管理画面と応答内容も確認してください。

HTTP 200はサーバーから何らかの内容が返ったことを示すだけで、Clashで使える設定が取得できたとは限りません。認証ページがログイン画面を返す場合や、APIがエラーをJSONで返す場合があり、その後クライアントがYAMLやフィールドの型に関するエラーを表示することがあります。

URL切れやトークン無効への対処

URL全体をコピーし直し、パラメーターを手入力で組み立てない

サブスクリプションサービスの管理画面で、「Clash」または「Clash Meta / mihomo」向けのURLをコピーし、既存設定のリモートURLと置き換えます。アカウントの期限切れ、トークンのリセット、サブスクリプション用ドメインの移行などにより、以前のURLが無効になることがあります。QRコードはURLを伝える手段にすぎず、読み込んでもトークン認証は省略できません。

• URLの前後に空白、改行、日本語の句読点が混入していないか確認します。チャットアプリからコピーした & によって、元のパラメーターが壊れる場合もあります。
• Web管理画面のURLをサブスクリプションURLとして使わないでください。ブラウザーでログインできるページでも、クライアントが設定ファイルとしてダウンロードできるとは限りません。
• 新旧のURLでトークンが異なる場合は、まず1台で動作を確認してからほかの端末に反映します。何度もリセットすると、すべての旧端末で使えなくなります。
• サブスクリプションURL全体を公開画像、オンライン変換ツール、質問掲示板などに掲載しないでください。調査時に必要なのはドメインとエラーの種類までにとどめ、パスに含まれる認証情報やクエリパラメーターは隠してください。

403は、サーバー側の保護機能やクライアント識別の制限によって返されることもあります。管理画面でアカウントが有効だと確認できたら、DNSを何度も変更するのではなく、サービス提供元のクライアント互換情報を確認してください。DNSの変更では、サーバーに拒否されたアクセス権限は解決できません。

直接接続に失敗した場合、プロキシ経由で更新する方法

まず、クライアントのサブスクリプションダウンローダーがどのネットワーク経路を使うか確認します。ブラウザーからシステムプロキシ経由でアクセスできても、クライアントのバックグラウンドダウンロードが同じプロキシを通るとは限りません。クライアントによっては独立した「プロキシ経由で更新」設定があり、別のネットワーク処理を使うものもあります。TUNモードはより多くの通信を処理できますが、すべてのバックグラウンド更新リクエストが指定したノードを通る保証はありません。

何度も再試行せず、条件をそろえて2回テストする

1. 現在使えるノードを維持したまま、手動で一度更新し、タイムアウトするか記録します。
2. クライアントに「プロキシ経由で更新」の項目があれば、その設定を切り替えてもう一度試します。項目がない場合は、システムプロキシが必ず使われると決めつけず、クライアントの説明を確認してください。
3. プロキシ経由でのみ成功する場合は、その更新方法を維持します。直接接続でのみ成功する場合は、選択中の出口がサブスクリプションサービスによって制限されていないか確認します。
4. どちらの経路でも失敗する場合は、ノードを次々切り替える前に、ドメイン解決、サーバーの状態、ローカルファイアウォールを確認します。

デスクトップでは curl を使った比較もできます。以下のコマンドはURLを端末上で対話入力するため、トークンがコマンド履歴に直接残りません。出力ファイルにも機密情報が含まれるため、確認後に削除してください。Bashとcurlが使える環境向けの例です。

read -r -s -p 'サブスクリプションURLを入力：' SUB_URL
printf '\n'
curl --noproxy '*' --connect-timeout 10 --max-time 30 \
  -D subscription.headers -o subscription.body "$SUB_URL"
unset SUB_URL

ここでの 10 秒は接続タイムアウト、30 秒はリクエスト全体の制限時間であり、実測した遅延時間ではありません。--noproxy '*'はcurlのプロキシ設定を無視しますが、システムのルーティングや有効なTUNを迂回するものではありません。TUNを使わない経路と比較するには、現在の設定を記録してから一時的にTUNを無効にしてテストしてください。

curlでローカルプロキシを指定する場合は、クライアントに表示されたHTTPポートまたは混合ポートを確認します。実際の待ち受け先が 127.0.0.1:7890 の場合に限り、--proxy http://127.0.0.1:7890を使います。コントロール用ポートをプロキシポートとして指定しないでください。待ち受けポートは設定によって異なります。

証明書エラーと形式の互換性

TLSエラーが出たら、まずシステム時刻を確認

certificate has expired、certificate is not yet valid、unknown authorityが表示された場合は、まずシステムの日付と時刻を開き、自動時刻合わせを有効にします。次に、公衆Wi-FiのWeb認証が必要でないか確認し、セキュリティソフトがHTTPS通信を中間で復号していないか調べてください。

特定のサブスクリプションドメインだけで証明書エラーが続き、ほかのHTTPSサービスは正常な場合は、サービス提供元に証明書の有効期限と中間証明書チェーンの確認を依頼します。ノード設定の skip-cert-verify は、サブスクリプションのダウンロードに共通して使える修正方法ではありません。サブスクリプションサーバーの証明書問題は解決できず、トラブル対処のために証明書検証を長期的に無効にすることも推奨しません。

内容を取得してから形式を確認する

• Clash YAML全体：通常は proxies、proxy-groups、rulesを含みます。providers経由で外部リソースを参照する場合もあります。互換性のあるクライアントに読み込ませてください。
• Base64形式のノード一覧：デコードすると複数行のプロトコルURLになることがありますが、Clashの設定全体とは異なります。サービスの管理画面で対応する形式を選んでください。
• Provider用YAML：proxiesだけを含むノード一覧が一般的です。proxy-providersに設定する形式であり、完全なルーティング設定としてそのまま使えるとは限りません。
• HTMLまたはJSONのエラー応答：まずログイン、権限、ゲートウェイの問題を解決してください。YAMLのインデントを直しても解決しません。

Clashはクライアントとコアのエコシステムを指す総称で、Clash Metaの後継はmihomoとして開発されています。旧コアでは新しいプロトコルやフィールドに対応していないことがあります。ログに非対応のプロキシタイプが明記されている場合は、デスクトップアプリの名称だけで判断せず、実際に動作しているコアとサービス提供元の互換条件を確認してください。手動編集の前にバックアップを取り、YAMLのインデントにはスペースを使い、Tabは使わないでください。

クライアント別・自動更新間隔の設定場所

リモート設定全体の定期更新は通常、GUIクライアントが管理します。すべてのクライアントのサブスクリプションを制御できる共通のトップレベル interval はありません。対象のサブスクリプションの編集画面を開き、項目に表示された単位を確認してください。以下は一般的な設定場所です。日本語訳、ボタンの位置、項目名はバージョンによって異なるため、インストール済みの画面を優先してください。

更新間隔の選び方

一般的なノードのサブスクリプションなら、まず6時間ごとに設定します。項目の単位に合わせて360分または21600秒と入力してください。これは初期設定の目安で、すべてのサービスに当てはまるわけではありません。サービス提供元が最低間隔を指定している場合は、その指示に従います。ノード数が少なく長期間安定しているサブスクリプションなら、12時間または24時間ごとに変更できます。

更新失敗を解決するために、間隔を1分に設定しないでください。権限、証明書、形式のエラーは高頻度でリクエストしても解消せず、429を招くおそれがあります。間隔を0にしたときの動作もクライアントによって異なります。自動更新を無効にするものもあれば、既定値に戻すものもあるため、項目の説明を確認してください。

mihomoのProvider更新は別の仕組み

設定全体のダウンロードには成功したのにノード一覧が変わらない場合は、proxy-providersを確認します。mihomoのHTTP providerでは秒単位のintervalを指定でき、コアが外部のノードファイルを取得します。これはGUIクライアントによるサブスクリプション全体の更新とは別の仕組みです。

以下は、既存設定に追加するローカルproviderの例です。ファイルがあらかじめ存在し、有効なノード一覧を含んでいる必要があります。この設定ではリモート更新を行いません。intervalを追加しただけでHTTPサブスクリプションになるわけではありません。

proxy-providers:
  local-nodes:
    type: file
    path: ./providers/local-nodes.yaml

既存のHTTP providerでは、実際のurlや必要なフィールドを残したうえで、そのprovider内にinterval: 21600を設定します。これは6時間ごとにノードファイルを更新する指定です。この行をrulesに入れたり、設定の最上位に書いてサブスクリプション全体が自動更新されると期待したりしないでください。

• proxy-providers.名称.interval：HTTPノード一覧のダウンロード間隔を秒単位で指定します。
• health-check.interval：provider内のノードをヘルスチェックする間隔です。新しいノードはダウンロードしません。
• rule-providers.名称.interval：該当するHTTPルール一覧の更新に使います。ノード一覧の更新は行いません。

サブスクリプションを次回更新すると、手動で編集したprovider設定が上書きされる場合があります。設定を維持するには、クライアントが対応するオーバーライド、マージ、拡張設定機能を使い、最終的に適用された設定を確認してください。エディターで保存できただけでは、実行中のコアに新しい値が反映されたとは限りません。

更新再開後の確認手順

1. ダウンロード結果を確認：最終更新時刻が変わり、ログに新しいHTTP、TLS、解析エラーがないことを確認します。
2. 設定の有効状態を確認：同じ名前のローカルコピーではなく、更新した設定が選択されていることを確認します。
3. プロキシグループを確認：ノードが変わったか確認し、選択中のノードが削除されていた場合は、利用可能な出口を選び直します。
4. 実際の接続を確認：プロキシが必要なサービスを開き、接続ログでルールと出口を確認します。サブスクリプションの更新に成功しても、通信が想定どおりに振り分けられているとは限りません。
5. 次の更新周期を確認：現在時刻と更新間隔を記録し、次の周期を過ぎてからタイムスタンプを確認して、定期更新が実行されたか確かめます。

最後に、いつでも復旧できる手段を確保しましょう。現在の設定をバックアップし、サブスクリプションURLと手動更新の場所を記録します。それでも解決しない場合は、認証情報を伏せたログ、クライアントとコアのバージョン、エラー発生時刻、直接接続とプロキシ経由のテスト結果をサービス提供元またはクライアントのメンテナーに送ってください。サブスクリプションURL全体や認証情報を含む設定ファイルは送らないでください。