FlClash のローカル Provider が空になるときは？

FlClash に設定をインポートしたあと、ポリシーグループは残っているのにローカル Provider のノードが空になる、または起動・更新時にルールファイルが見つからないというログが出る場合は、その Provider が type: file かを確認します。リモートの type: http のダウンロード失敗、提供元から空のサブスクリプションが返る場合、YAML の解析エラーを、すべて同じ原因として扱わないでください。

公式リポジトリの issue #2448 は、2026 年 9 月 23 日に寄せられた Windows 10 / 11 ユーザーからの単独の報告です。報告者は v0.8.98 を使用し、v0.8.97 から再現すると述べています。再現用の設定はローカル proxy-provider とポリシーグループの use を組み合わせたものです。タイトルには rule-providers も含まれますが、ルールセット単独での再現手順は示されていません。

今回の確認時点で issue は Open のままで、メンテナーが確認した一般的な影響範囲や修正版はありません。そのため、v0.8.97 以降のすべての環境や、macOS・Android でも必ず同じ問題が起きるとは断定しません。他のプラットフォームでは、同じ設定とパスの問題を示す証拠がある場合に限り、以下の切り分け方法を参考にしてください。

この記事で扱うのは、元のファイルが存在し、その内容も信頼できるのに、FlClash が生成した実行時の設定では別のファイルを参照している可能性がある場合です。inline は小規模で内容を読めるリスト向けの一時的な復旧方法であり、クライアントの修正を証明するものではありません。フィルター条件、ノードのプロトコル、ネットワークの問題まで解決する保証もありません。

FlClash v0.8.98 の lib/common/task.dart は、実行時の設定を生成するときに confineProviders を呼び出し、proxy-providers と rule-providers をそれぞれ処理します。

この関数は type: inline を処理対象から除外し、それ以外のマッピングの path を設定し直します。パスは Profile、Provider の種類や名前などから生成され、元の path がそのまま渡されるわけではありません。

このコードで既存キャッシュを移行する分岐に入るのは、空ではない url がある場合だけです。url のないローカル file Provider にも新しいパスが割り当てられますが、この分岐では元の path にあるファイルをコピーしていません。この分析は「元のファイルと実行時のパスが一致しない可能性がある」という判断を支え、報告者の説明とも一致します。ただし、当サイトでは実際の Windows 環境で独立した再現テストを行っておらず、この推測をメンテナーが確認済みの結論としては扱いません。

まず、現在のメイン設定、外部 Provider ファイルすべて、クライアントのバージョン、最初のエラーログを保存します。アプリ内の Profile をバックアップしただけで、外部ファイルも保存されたと思い込まないでください。それぞれに別のコピーがあることを確認してから、テスト用の設定コピーを作成します。

コピーで、元の path が指すファイルの存在、現在のユーザーによる読み取り権限、リストが空でないこと、形式が正しいことを確認します。実際の実行時設定を表示できる場合は、同名 Provider の path を比較してください。表示できない場合はログにある実際のファイルパスを手がかりにし、実行時設定を取得できないという制約も記録します。固定のキャッシュディレクトリを推測したり、MD5 のファイル名に合わせて手作業でファイルを配置したりしないでください。

Mihomo の公式ドキュメントには HomeDir と安全なパスに関する制限もあります。パスへのアクセスが拒否されたことと、FlClash がパスを書き換えたことは別の証拠です。SAFE_PATHS を広げる、ディレクトリ全体の権限を変更する、安全上の制限を無効にするといった手当たり次第の対処は避けてください。元のファイルがない場合は信頼できるファイルを復元し、内容の解析に失敗する場合は先に形式を修正します。

対象は、取得元が信頼でき、自分で内容を確認できる少数の YAML ノードに限定します。ローカルのプロキシ Provider ファイルを開き、最上位の proxies リストにある各ノードオブジェクトを、メイン設定の同名 Provider の payload に移します。type: inline に変更し、その Provider の path、url、ファイル更新用 interval を削除します。

既存の health-check、フィルター、上書き設定が必要な場合は、まとめて削除せず、一つずつ確認して残してください。

Provider の名前とポリシーグループの use は元の値を維持し、ノード名、プロトコル、サーバー、ポート、パスワード、TLS フィールドもすべて保持します。最上位に proxies を含むファイル全体を payload の下に入れたり、URI や Base64 のテキストをノードオブジェクトとして貼り付けたりしないでください。内容の読み取りや変換に確信が持てない場合は変更を中止し、動作確認済みの完全な Profile を使用します。

以下は構造だけを示す例です。my-local-nodes と Local はサンプル名で、server と password は接続には使えない仮の値です。実際には自分の信頼できるノードオブジェクトを使い、元の Provider 名とポリシーグループ名を維持してください。この断片は設定コピーに組み込み、設定全体の置き換えには使いません。

設定コピーを保存したら、まずクライアントで設定を検証し、合格したコピーを選択して起動します。検証に失敗した場合はすぐに止め、TUN を有効にしてエラーを回避しようとしないでください。payload がリストであること、インデントが正しいこと、ノードのフィールドを現在のコアがサポートしていること、use が実在する Provider を指していることを確認します。

inline は現在の内容をメイン設定に保存する静的なスナップショットです。あとで元の外部ファイルだけを編集しても、この payload は自動では変わりません。更新するときは、内容を再確認して設定コピーにも反映する必要があります。少数の手動リストには適していますが、大きなサブスクリプションをメイン設定へ継続的にコピーする用途には向きません。

ルールセットの payload はルール文字列であり、ノードオブジェクトではありません。元の behavior が domain、ipcidr、classical のどれか、ファイル形式が yaml、text、mrs のどれかを先に確認します。元の behavior を維持し、検証を通すためにこれらの型を適当に入れ替えないでください。

小規模な YAML ファイルなら、payload 内のルール項目を同名の inline Provider に移せます。読める text ファイルは、実際のルールを行ごとに確認してから YAML の文字列リストに変換します。MRS は別の形式なので、ファイルのバイト列や Base64 をそのまま inline に入れることはできません。信頼できる可読形式の元データがない場合は、原本を残して動作確認済みの方法を使い、大きなバイナリのルールセットをここで変換しないでください。

以下は classical の構造を示す断片です。セット内の DOMAIN-SUFFIX,example.com にはポリシーの転送先を付けず、メインの rules にある RULE-SET,local-rules,Local で指定します。Local は完全な設定の中ですでに定義されている必要があります。自分のセット名、転送先、メインルールの順序を維持し、最後の MATCH ルールを追加したり置き換えたりしないでください。

domain セットにはその型で使えるドメイン表現、ipcidr セットには CIDR を指定します。この二種類のセットに、例の DOMAIN-SUFFIX 行を入れないでください。classical セットの中に RULE-SET や SUB-RULE を書くこともできません。変換後はまず設定を検証し、小規模なセットを一つだけテストして、正しく動くことを確認してから次のセットに進みます。

これらの手順は、Mihomo の Provider 形式と、FlClash が inline を処理対象から除外するソースコードに基づいています。#2448 でルールの復旧が検証されたという意味ではありません。ルールの型、変換元、参照関係を確認できない場合は、現状の保存と元に戻す作業までにとどめてください。「inline にすれば必ず動く」とは保証できません。

まず、選択中の設定が検証を終えたコピーであり、古いファイルを参照する Profile ではないことを確認します。Provider とポリシーグループを開き、ノード数と名前を照合して、filter、exclude-filter、ポリシーグループの参照によって全ノードが除外されていないかを確認します。

動作確認済みのノードを一つ選び、普段使っているシステムプロキシまたは TUN で実際の HTTPS リクエストを行い、接続記録の出力先を確認します。ルールセットは、自分で管理しているか日常的に使っているリクエストのうち、確実にそのセットの対象になるものを使い、一致したルールとポリシーを確認してください。リストが表示された、遅延テストに数値が出たというだけでは検証完了とはいえません。

最後にクライアントを完全に終了して再起動し、同じ Profile、ノード、ルールが引き続き動作し、該当するファイル不在のエラーがログに出なくなったことを確認します。ノードは表示されてもリクエストが失敗する場合は、プロトコル、認証情報、ネットワークを調べます。アクセスは復旧してもルールの一致先が違う場合は、メインの rules の順序と behavior を確認し、すべてをファイルパスの問題として扱わないでください。

コピーの検証に失敗した、ノードのプロトコルが未対応だった、ルールの一致結果が悪くなった場合は、そのコピーの使用をやめ、事前に保存したメイン設定と外部ファイルを戻します。元の設定にもパスの問題がある場合、元に戻すのは状況を保存するためであり、接続できることを意味しません。一時的に、別の動作確認済みの完全な Profile を使用してください。

設定がまだ使えない場合は、そのクライアントのシステムプロキシまたは TUN を無効にし、端末が元のネットワーク状態に戻ったことを確認してから、ログを保存して開発元へ報告します。アプリのデータディレクトリ全体、すべての Provider キャッシュ、唯一のローカルファイルを削除しないでください。非公開のノードをオンライン変換サイトにアップロードすることも避けます。

#2448 へ報告するときは、クライアントの完全なバージョン、OS のバージョン、元の Provider の型と相対パス、ログにある実際のパス、設定コピーで inline を試したかどうかを添えます。公開用のコピーではサブスクリプションの token、パスワード、サーバー、個人ディレクトリ名を伏せ、元の非公開資料は端末内に保存してください。

今後、修正版が公開されたかどうかは、公式の issue、コミット、Release だけを根拠に判断します。Open の issue にある報告者のバージョン情報、ソースコードに基づく回避方法、「ノードが再び表示された」という結果を、確認済みのクライアント修正として扱ってはいけません。アップグレード後も同じ設定と確認リストで再テストしてください。