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

サブスクリプション更新に失敗したら、ダウンロード・解析・ノード接続を切り分ける

FlClashでサブスクリプションを更新する際は、まずURLにアクセスして設定内容を取得し、解析して保存します。ノードへの接続は別の処理です。そのため、「サブスクリプションの更新失敗」と「ノードの速度測定がタイムアウトする問題」は分けて対処する必要があります。古い設定のノードが使えても、サブスクリプションURLが有効とは限りません。また、更新に成功しても、すべてのノードに接続できるとは限りません。

調査を始める前に、現在使える設定を残しておきましょう。エラーが発生した時刻、エラーメッセージ、使用中のネットワークを記録します。古いサブスクリプションは削除せず、DNS、TUN、ルールモードを一度に変更するのも避けてください。条件を一つずつ変えると、原因となった手順を特定しやすくなります。

エラー・症状	まず確認する項目	次の手順
`401`、`403`	トークン、アカウント権限、サーバー側のアクセス制限	サブスクリプションの提供元にログインし、クライアント用URLをコピーし直す
`404`、`410`	古いAPI、URLのパス、無効化されたアドレス	提供元がサブスクリプションのURLを変更していないか確認する
`429`	リクエスト頻度の制限	連続更新をやめ、サーバーの案内に従って待つ
`timeout`、接続タイムアウト	ネットワーク経路、プロキシの出口、サーバーの応答	ネットワーク経路を変えて、手動で一度更新する
`YAML`、解析エラー	レスポンス本文、サブスクリプション形式、コアの対応状況	Clash / mihomo形式の設定を取得できているか確認する

エラーコードは手がかりであり、原因を一つに絞るものではありません。たとえば403は、サブスクリプション権限の失効だけでなく、Webサイト側のアクセス制限を示す場合もあります。200はHTTPリクエストに応答があったことを示すだけで、本文がログインページという可能性もあります。

手動更新の場所：設定項目から更新結果を確認する

一般的な操作手順は、「設定」→対象のリモート設定を探す→項目の更新アイコンをタップ、または項目のメニューから「更新」を選択です。プラットフォームやバージョンによっては、カードの右側やその他のメニューに操作項目があります。ホーム画面の接続スイッチを再起動するのではなく、対象のサブスクリプション項目を更新してください。

設定の種類を確認します。URLから追加したリモート設定には、再取得に使うサブスクリプションURLがあります。ローカルファイルから読み込んだ設定は、ファイルを読み込み直すか、リモートURLを別途追加してください。
更新する項目は一つに絞ります。複数のサブスクリプションがある場合は、まずエラーが出た項目だけを更新しましょう。一括リクエストによってエラー表示が混在するのを防げます。
リクエストが完了するまで待ちます。成功の通知、エラーの詳細、更新日時を確認してください。連続でクリックしても無効なURLは直らず、リクエスト制限にかかるおそれもあります。
選択中の設定を確認します。設定Aを更新しても設定Bが選択されたままでは、プロキシグループやノード一覧が変わらないことがあります。

URL切れや権限の問題：正しいサブスクリプションURLを取得する

サブスクリプションURL、管理画面、共有リンクを区別する

FlClashで必要なのは、設定内容を直接返すURLです。アカウント管理ページ、ログイン後に開けるダウンロードページ、通常のノード共有リンクは、いずれもClash用のサブスクリプションとは異なります。提供元のサブスクリプション欄で、Clash、Clash Meta、mihomoと記載されたURLを選んでください。クライアント別に選択肢がある場合は、FlClash対応と明記されたものを優先します。

コピーしたURLがチャットアプリで途中までしか貼り付けられていない、末尾に空白・改行・日本語の句読点が混ざっている、といった点を確認してください。クエリパラメーターのトークンはそのまま保ちます。不要に見えるパラメーターを削除したり、特殊文字を何度もデコード・エンコードしたりしないでください。

レスポンスのステータスコードに応じて権限やリクエスト制限を確認する

401または403：アカウントの状態、サブスクリプション権限、トークンが再発行されていないかを確認します。ブラウザーにCAPTCHAやアクセス確認が表示される場合、クライアントからWebページのように操作して認証を完了することは通常できません。クライアントで使えるURLを提供元に問い合わせてください。
404または410：古いサブスクリプションAPIの移行状況を確認します。管理画面からURLをコピーし直してください。古いURLのドメインだけを書き換えて試すのは避けましょう。
429：手動更新や、ほかの端末からの頻繁なリクエストを停止します。レスポンスにRetry-Afterが含まれている場合は、指定された時間が経過してから再試行してください。
500、502、503：サブスクリプションサービスまたは上流サーバーの一時的な障害が考えられます。古い設定を残して時間をおいて再試行してください。繰り返し発生する場合は提供元に問い合わせましょう。

タイムアウトや証明書エラー：実際のアクセス経路を確認する

サブスクリプションのリクエストがブラウザーと同じ経路を通るとは限りません。ブラウザーはシステムプロキシを使う一方、クライアントの設定ダウンロードは独自のリクエスト方式を使う場合があります。TUNを有効にすると通信経路が変わることもあります。そのため、ブラウザーでURLを開けても、FlClashの更新リクエストが通るとは限りません。

2つの条件を比較して原因を絞り込む

ネットワークを変えて比較：Wi-Fiで発生したエラーを記録し、スマートフォンのテザリングや別の信頼できるネットワークに切り替えて、同じサブスクリプションを手動更新します。一方のネットワークだけで失敗する場合は、そのネットワークのDNS、ポータル認証、アクセス制限を優先して確認してください。
通信経路を変えて比較：古い設定は残したままにします。使用中のバージョンにサブスクリプション更新用のプロキシ設定があれば、直接接続と、すでに使えるプロキシ経由の両方を試します。その設定がない場合、「グローバルモード」に切り替えればサブスクリプションのダウンロード経路も必ず変わる、とは限りません。

no such hostなどのエラーが出る場合は、ドメインの入力ミスとDNSの名前解決を確認します。connection refusedの場合は、待ち受けが停止したローカルプロキシのポートに接続していないか確認してください。エラーに127.0.0.1:7890と表示される場合、7890はそのリクエストで使われたポートです。利用中のクライアントの設定と照合し、すべての環境の既定値だと決めつけないでください。

証明書エラーが出たら、まずシステムの日付、タイムゾーン、自動時刻設定を確認します。certificate has expiredはサーバー証明書の期限切れだけでなく、端末の時刻ずれが原因の場合もあります。証明書のドメインが一致しない場合は、サブスクリプションのドメインとリダイレクト先を照合してください。証明書検証を無効にして問題を隠すのは避けましょう。サブスクリプションのトークンはHTTPSで保護する必要があります。

初回に追加するURLがプロキシ経由でしかアクセスできず、クライアントに使える設定がまだない場合は、直接接続できるサブスクリプションURLやローカル設定の読み込み方法を提供元に問い合わせてください。アクセスできないURLを何度更新しても、最初の接続経路は確立できません。

形式の解析エラー：Clash / mihomo形式の設定か確認する

Clash系クライアントでは、通常YAML形式の設定を使います。ほかのクライアント用のJSON設定や、エンコードされたノードURIの一覧は、拡張子を変えるだけではClashで使える設定になりません。また、FlClashが使用するmihomoコアは、オリジナルのClashとは対応機能に違いがあります。実際のクライアントが対応する形式を選んでください。

拡張子だけでなくファイルの内容を確認する

本文が<!DOCTYPE html>またはログインフォームで始まる：取得したのはWebページです。ログイン、リダイレクト、アクセス認証の問題を優先して確認してください。
本文の大半がvmess://やss://などのリンク：ノード一覧のサブスクリプションを選んでいる可能性があります。提供元のClash / mihomo形式の出力URLを使ってください。
エラーに行番号や列番号が表示される：該当箇所とその前の行のインデント、引用符、コロンを確認します。YAMLのインデントにはスペースを使い、Tabを混在させないでください。
プロキシの種類やフィールドが未対応と表示される：設定の要件と現在のクライアント・コアのバージョンを照合し、クライアントを更新するか、互換性のある形式を選んでください。

以下はYAMLの階層とルールの構成例です。ノードを含まず、プロキシに使える完全なサブスクリプションではありません。実際のリモート設定にはproxiesが含まれる場合もあれば、proxy-providersでノードの取得元を参照する場合もあります。特定のフィールドがないことだけで、ファイルが無効だとは判断できません。

proxy-groups:
  - name: 出口の選択
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,出口の選択

設定自体のダウンロードに成功しても、特定のproxy-providersやrule-providersの更新に失敗する場合は、該当するリソースのURLとエラー内容を確認してください。これは設定内部のリソース取得に関する問題で、メインのサブスクリプションURLをダウンロードできない問題とは別です。

サービスによっては、リクエストのUser-Agentに応じて異なる形式を返します。ブラウザーでダウンロードした内容とクライアントが取得する内容が異なる場合は、FlClash向けの対応URLを提供元に確認してください。リクエスト識別情報をむやみに変更したり、個人用サブスクリプションを出所不明のオンライン変換サービスに渡したりしないでください。

自動更新の間隔：リモート設定の編集画面で設定する

まず手動更新を一度成功させてから、自動更新を設定します。一般的な手順は、「設定」→対象のリモート設定のその他メニュー→「編集」→自動更新のスイッチと更新間隔を探す、です。項目名、選べる単位、メニューの場所はインストールされているバージョンによって異なります。ローカルファイルの設定には、通常、同じサブスクリプション更新の項目はありません。

単位を確認してから数値を入力する

自動更新間隔は、予定された更新と次の更新の間隔です。リクエストのタイムアウト時間やノードの速度測定周期ではありません。たとえば1時間は60分または3600秒、24時間は1440分または86400秒です。画面の単位が分なら、毎時の更新には60を入力します。秒数を分の欄にそのまま入力しないでください。

利用状況	間隔の目安	設定の基準
設定とノードが安定している	24時間	リクエストの重複を抑え、必要なときだけ手動更新する
提供元がノードを頻繁に変更する	6時間	変更の反映とリクエスト頻度のバランスを取る
提供元が短い更新間隔を指定している	提供元の案内に従う	APIのリクエスト制限も守る

表の間隔は設定の目安であり、FlClashの既定値ではありません。0を入力すれば自動更新が無効になるとは限らず、バージョンによって扱いが異なる場合があります。自動更新を止める場合は、明示的なスイッチを優先してください。保存後に編集画面を開き直し、設定が保持されているか確認します。

自動更新が予定どおり実行されない場合の確認点

自動更新には、通常、クライアントの起動とシステムのスケジューリングが必要です。デスクトップ版を終了した場合やPCがスリープ中の場合、スマートフォンでバックグラウンド動作が制限されている場合は、実行が遅れることがあります。特にAndroidでは、バッテリー最適化とバックグラウンド通信の権限を確認してください。変更前にバッテリー消費への影響を把握し、すべてのバックグラウンド制限を一度に解除する必要はありません。

設定を保存したら、更新が成功した時刻を記録し、クライアントを起動したまま設定した間隔を過ぎるまで待ってから確認します。その間にスリープやネットワーク切断があった場合は、復帰後に手動更新してURLが使えるか確かめてください。自動更新では、期限切れのトークン、形式の誤り、サーバーのリクエスト制限は解決できません。また、秒単位で正確に実行されるシステムの定期タスクではありません。

復旧後の確認手順と問い合わせに必要な情報

サブスクリプションのリクエストが成功したか確認します。ホーム画面の接続状態だけでなく、対象の設定に成功通知と更新日時が表示されているかを確認してください。
更新した設定が選択されているか確認します。プロキシグループ、ルール、ノードの参照元が、更新した設定のものか照合してください。
ノードへの接続を個別に確認します。更新に成功してもアクセスできない場合は、ノード、ルールの適用状況、システムプロキシ、TUNを確認してください。サブスクリプションURLを何度も入れ替える必要はありません。
最後に適切な更新間隔を設定します。複数のクライアントから同じサブスクリプションへ短い間隔で同時にリクエストするのは避けてください。

失敗が続く場合は、OS、FlClashのバージョン、コアのバージョン、発生時刻、ネットワークの種類、個人情報を伏せたエラーメッセージをまとめてください。「ネットワークを変えると成功するか」「古い設定は使えるか」「失敗しているのはメインのサブスクリプションか内部リソースか」も添えると、「更新に失敗しました」とだけ表示されたスクリーンショットより原因を特定しやすくなります。

リモート設定を初めて追加する場合は、サブスクリプションのインポート手順で操作を確認できます。サブスクリプションのURLとクライアントの関係がわからない場合は、サブスクリプションの提供元についてをご覧ください。