入門ガイド 読了目安：12分

Clashのサブスクリプション更新に失敗したときの対処法：よくあるエラー原因と自動更新間隔の設定

Clashのサブスクリプション取得に失敗する原因を、期限切れリンク、UAのブロック、DNS汚染、プロキシのループバックまで順に確認。FlClashの自動更新間隔と更新プロキシの推奨設定も解説します。

まず失敗した層を切り分ける

ClashまたはFlClashに「サブスクリプションの更新に失敗しました」と表示されても、原因がサブスクリプションサービス自体にあるとは限りません。更新処理では少なくとも、クライアントによるサブスクリプションURLの読み取り、システムまたはmihomoによるドメイン解決、直接接続またはプロキシ経由でのHTTPS接続、設定内容のダウンロードと解析という4つの段階を通ります。どこか1つが止まるだけでも、画面には短いエラーしか表示されないことがあります。

切り分ける前に、失敗した正確な時刻、画面やログに表示された完全なエラー、現在のネットワーク環境の3点を記録してください。自宅の固定回線では使えるのにモバイルホットスポットでは失敗するなら、ネットワークまたはDNSが原因である可能性が高いでしょう。ブラウザーではリンクを開けるのにクライアントだけが403を返す場合は、リクエストヘッダーやアクセス制御を確認します。ダウンロードは成功するのに設定が無効と表示される場合は、レスポンス内容とYAML構造を確認してください。

ステータスコードで素早く特定する

  • 401 Unauthorized：有効な認証情報が必要です。トークンの期限が切れている可能性があります。
  • 403 Forbidden：サーバーがリクエストを拒否しています。User-Agent、送信元IP、アクセス頻度が制限条件に合わない場合によく発生します。
  • 404 Not Found：URLのパスが存在しません。古いサブスクリプションURLが差し替えられた可能性があります。
  • 429 Too Many Requests：短時間に更新しすぎています。手動更新をいったん止め、自動更新の間隔を延ばしてください。
  • 5xx：サブスクリプションサーバーまたは上流ゲートウェイに問題があります。別のネットワークでも再確認し、復旧を待ちましょう。
  • timeout、connection reset：接続の確立中またはデータ転送中に切断されています。DNS、経路、更新プロキシを引き続き確認してください。
  • invalid character、yaml: unmarshal errors：レスポンスは受信できていますが、クライアントが読み取れるClash YAMLではありません。

サブスクリプションURL、有効期限、レスポンス内容を確認する

サブスクリプションURLには通常、長いアクセストークンが含まれます。コピー時に末尾の文字が抜けたり、チャットアプリがURLを自動的に途中で切ったり、URL内に改行が混入したりすると、サーバーはエラーを返します。サービス提供元の管理画面から完全なURLをコピーし直し、FlClashの設定一覧で対象サブスクリプションを編集してください。古いURLを何度も書き換える方法は避けましょう。

ブラウザーで開けても、内容が正しいとは限らない

ブラウザーでサブスクリプションURLを開くと、YAML、Base64テキスト、またはクライアント種別に応じてサーバーが生成した設定が表示されるはずです。ログイン画面、CAPTCHA、HTMLのエラーページ、JSON形式のエラーが表示される場合、クライアントがダウンロードを完了してもClash設定として読み込めません。レスポンスの先頭に<!doctype html>や<htmlがあれば、Webページを取得していると判断できます。

デスクトップでは、コマンドを使ってステータスコードとレスポンスヘッダーを確認できます。トークンを含む完全な出力は公開しないでください。

curl -L --connect-timeout 10 --max-time 30 \
  -A "clash.meta" \
  -o subscription.yaml \
  -w "HTTP=%{http_code} SIZE=%{size_download} TIME=%{time_total}\n" \
  "https://example.invalid/subscription/token"

通常はHTTP=200となり、ファイルサイズは0ではありません。数十個のノードとルールを含む設定なら、通常は少なくとも数KBあります。200～500バイトしか取得できない場合は、ファイルを開いてエラー説明ではないか確認してください。コマンド内のドメインは形式を示す例です。実際のテストでは自分のサブスクリプションURLを使用してください。

設定形式とクライアントの互換性を確認する

  • FlClashでmihomoカーネルを使用する場合は、Clash、Clash Meta、またはmihomo形式を優先してください。
  • vmess://、ss://などの共有リンクだけを含むプレーンテキストは、完全な設定としてそのまま読み込めるとは限りません。
  • 設定でrule-providersを参照している場合は、ルールセットのURLにもアクセスできることを確認してください。メインのサブスクリプション更新に成功しても、リモートルールセットの同期まで成功するとは限りません。
  • サービス側に「汎用サブスクリプション」と「Clashサブスクリプション」の2つの入口がある場合は、Clashまたはmihomoと明記された入口を選択してください。

User-Agentのブロックとリクエスト頻度制限に対処する

一部のサブスクリプションサービスは、User-Agentに応じて異なる形式を返したり、認識済みのクライアント識別子だけを許可したりします。ブラウザーはChromeやSafariなどの識別子を使いますが、FlClashやmihomoは別の識別子を送ることがあります。そのため「ブラウザーでは正常にダウンロードできるのに、クライアントでは403になる」という差が生じます。

リクエストヘッダーを比較する

一般的なブラウザーの識別子とmihomoの識別子を使って同じURLにリクエストを送り、HTTPステータスコード、ファイルサイズ、レスポンス形式を比較できます。特定の識別子でだけ200になるなら、サーバー側にリクエストヘッダーのルールがあります。

curl -L -A "clash.meta" -D headers-meta.txt \
  -o profile-meta.yaml "https://example.invalid/subscription/token"

curl -L -A "Mozilla/5.0" -D headers-browser.txt \
  -o profile-browser.yaml "https://example.invalid/subscription/token"

まずはサブスクリプションサービスのクライアント種別設定を確認し、Clash向けのURLを生成し直してください。FlClashの現行バージョンにサブスクリプションのリクエストヘッダー設定がある場合は、サービス側が明示しているUser-Agentを設定できます。指定がない限り、多数の識別子を次々に試すことはおすすめしません。

429と自動更新の頻度過多

更新ボタンを連続して手動クリックしたり、複数の端末で同じサブスクリプションを共有したり、間隔を5分に設定したりすると、頻度制限にかかることがあります。サブスクリプションの内容は通常、毎分変わりません。個人用端末では24時間を標準間隔にすると安定します。ノードの変更が多い場合は6時間、サービス提供元から明確な案内がある場合だけ1時間に短縮してください。

利用シーン 推奨間隔 秒換算
日常的な個人端末 24時間 86400
ノード変更が多い場合 6時間 21600
短期的な障害の監視 1時間 3600

429が発生したら、少なくとも15～30分は更新を停止してください。クリックを続けると制限時間が延びるだけです。複数の端末で同じURLを使う場合は、PCを毎時00分、スマートフォンを毎時30分に設定するなど、更新時刻をずらすと同時リクエストを減らせます。

DNS汚染、証明書エラー、ネットワークタイムアウトを調べる

サブスクリプションのドメインが誤ったIPに解決されると、接続タイムアウト、接続リセット、ドメイン名と証明書名の不一致などが起こります。まずシステムの名前解決結果を信頼できるDNSの結果と比較し、そのうえでFlClashのDNS設定を変更するか判断してください。

2種類の名前解決テストを行う

nslookup subscription.example.com
nslookup subscription.example.com 1.1.1.1

2回の結果が大きく異なっても、どちらか一方が必ず間違いとは限りません。ただし、サービス提供元が公開している経路情報と照合する価値はあります。自宅の固定回線とスマートフォンのホットスポットを切り替える方法も有効です。同じ端末がホットスポットでは2秒以内に更新でき、固定回線では30秒間タイムアウトするなら、原因はYAMLではなく固定回線側のDNSまたは経路にある可能性が高いでしょう。

FlClashでは「設定」→「パラメーター設定」を開き、DNSと動作モードを確認できます。mihomo DNSを有効にする場合は、上流DNSアドレスに到達でき、サブスクリプションのドメインがローカルアドレスへ誤ってマッピングされていないことを確認してください。DoHを使う場合でも、起動時にはDoHサーバーのドメイン解決が必要です。利用可能なデフォルトの名前解決経路を残すか、関連ドメインに正しい先行解決を設定してください。

システム時刻と証明書チェーンも確認する

  • システム時刻が数時間ずれていると、TLS証明書がまだ有効ではない、または期限切れと判定されることがあります。
  • 公衆ネットワークの認証ページが最初のHTTPS接続を妨げることがあります。先にブラウザーでネットワーク認証を完了してください。
  • 企業ネットワークや学校ネットワークではHTTPS検査装置を経由する場合があります。証明書エラーはネットワーク管理者に確認し、証明書検証を無効にしないでください。
  • モバイル端末で省電力機能やバックグラウンド通信の制限を有効にすると、定期更新がシステムによって遅延することがあります。前面に戻して手動更新すると正常に動作する場合があります。

更新プロキシとプロキシのループバックに対処する

現在のネットワークからサブスクリプションサーバーへ直接接続できない場合は、既存のプロキシ経由で更新する必要があります。しかし、新しい端末では最初から利用可能なノードがなく、まだダウンロードしていないサブスクリプションに依存することもできません。これが典型的な起動時の依存関係です。別のケースでは、クライアントがサブスクリプションのリクエストをローカルのプロキシポートへ送り、プロキシプロセスも同じサブスクリプションの読み込み完了を待つため、ループバックやタイムアウトが発生します。

まず直接接続かプロキシかを判断する

  1. システムプロキシを無効にし、サブスクリプションのドメインへ直接接続して200が返るかだけを確認します。
  2. 直接接続に失敗する場合は、すでに利用可能なローカル設定を起動し、ローカルの混合ポート経由でテストします。
  3. 一般的なmixed-portは7890ですが、実際のポートは「設定」→「パラメーター設定」に表示される値を使用してください。
  4. 更新に成功したらログを確認し、リクエストが想定したポリシーを通っていることを確認します。DIRECTとプロキシの間で何度も再試行されていないことも確認してください。
curl -L --proxy http://127.0.0.1:7890 \
  --connect-timeout 10 --max-time 30 \
  -o subscription.yaml \
  "https://example.invalid/subscription/token"

プロキシ経由なら3秒以内に完了し、直接接続では毎回10秒でタイムアウトするなら、更新プロキシが必要です。反対に、プロキシテストでConnection refusedが返る場合は、FlClashが起動しているか、mixed-portが本当に7890か、ポートを別のプログラムが使用していないかを確認してください。

更新トラフィックを利用できないポリシーへ戻さない

サブスクリプションの更新プロキシには、現在利用できることを確認済みのノードまたはプロキシグループを選択してください。更新後に初めて生成される一時的なポリシーは選ばないでください。初回インポートでは、直接接続、スマートフォンのホットスポット、またはローカルで利用可能な設定を使って起動を完了し、その後に通常のルールモードへ戻します。

TUNモードはより多くのシステム通信を引き受けますが、サブスクリプションサーバーへ到達できない問題を自動的に解決するわけではありません。TUNルーティング、DNSハイジャック、システムプロキシを同時に有効にしている場合は、サブスクリプションのリクエストが最終的にどの入口へ入るかを重点的に確認してください。切り分け中はTUNを一時的に無効にし、明確なHTTPまたはmixedプロキシ経路だけを残します。更新が正常になったことを確認してから、TUNとDNS設定を1項目ずつ戻してください。

FlClash自動更新間隔の推奨設定

FlClashで設定管理ページを開き、対象のリモートサブスクリプションを選択して編集画面へ進みます。全体のネットワークパラメーターは「設定」→「パラメーター設定」で確認できます。バージョンによってボタンの文言は多少異なりますが、確認すべき項目はサブスクリプションURL、自動更新の有効化、更新間隔、プロキシ経由で更新するかどうかです。

日常的に使う端末の安定設定

  • 自動更新：有効。
  • 更新間隔：24時間。ノードを頻繁に変更する場合は6時間。
  • 更新プロキシ：サブスクリプションのドメインへ直接接続できる場合はDIRECTのままにし、直接接続が安定して失敗する場合は利用可能なプロキシポリシーを選択します。
  • 起動時に更新：短い間隔の更新と併用する必要はありません。再起動のたびに重複リクエストが発生するのを防ぎます。
  • 失敗時の再試行：間隔は少なくとも5～15分にし、秒単位で連続再試行しないでください。

mihomoのproxy-providersでリモートノードを管理する場合は、更新間隔を秒単位でintervalに設定します。次の例では6時間に設定し、ノードのヘルスチェックを10分ごとに実行します。ヘルスチェックは既存ノードをテストするだけで、サブスクリプションを再ダウンロードするものではありません。

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

proxy-providersのリモートファイルは、プロキシノードの集合を返す必要があります。一方、完全なClash設定サブスクリプションは通常、クライアントの設定管理機能からインポートします。両者は構造が異なるため、完全な設定URLをproviderに入力すれば必ず互換性があるとは限りません。解析エラーが出た場合は、サービス側がprovider専用形式を提供しているか確認してください。

自動更新が実際に実行されたことを確認する方法

  1. 設定ページに表示される最終更新時刻を記録します。
  2. 一度手動更新し、時刻、通信量、ノード一覧に妥当な変化があることを確認します。
  3. 1周期分待ってから再度確認します。クライアントの起動時刻を更新時刻の代わりにしないでください。
  4. ログにHTTPステータスコード、providerの更新成功、解析失敗の記録があるか確認します。
  5. 更新後に2つのノードを切り替えて遅延をテストし、新しい設定が実行中のカーネルへ読み込まれていることを確認します。

ファイルのダウンロードに成功したのに実行中の設定が変わらない場合、新しい設定の検証に失敗した、クライアントが別のローカル設定を使用している、providerファイルの更新後に再読み込みされていない、といった可能性があります。まず現在有効な設定名を確認し、次にログの読み込みパスを確認してください。

症状別に最終確認する

症状 優先して確認する項目 対処方法
401または404 サブスクリプションのトークンとURL サービスの管理画面でURLを再生成する
403 User-Agent、送信元IP Clash形式を選び、リクエストポリシーを確認する
429 更新頻度と端末数 更新を停止し、間隔を6～24時間に変更する
接続タイムアウト DNS、経路、更新プロキシ 直接接続、ホットスポット、mixed-portを比較する
証明書エラー システム時刻、認証が必要なネットワーク 時刻を調整し、ネットワーク認証を完了する
YAMLの解析に失敗 レスポンス内容とサブスクリプション形式 HTMLやログインページが返っていないことを確認する
更新は成功したがノードが変わらない 有効な設定と読み込みパス 現在の設定を確認して再読み込みする

完全な切り分け手順は6段階にまとめられます。サブスクリプションURLをコピーし直す、HTTPステータスコードとダウンロード内容を確認する、User-Agentを比較する、ネットワークを切り替えてDNSを確認する、直接接続とローカルプロキシを個別にテストする、最後に適切な自動更新間隔を設定する、という順序です。これでClash、mihomo、FlClashのサブスクリプション更新トラブルの大半を確認でき、形式の問題をカーネルの問題と誤認することも防げます。

修復後は、起動可能なローカル設定を1つ保存し、現在のmixed-port、DNSモード、更新時刻を記録しておくことをおすすめします。次に障害が起きたときは、まずローカル設定で安定したネットワークを確立してからリモートサブスクリプションを更新すると、クライアントを何度も削除・再インストールするより早く復旧できます。

FlClash ダウンロード 各プラットフォーム向けクライアントを見る