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 でも必ず同じ問題が起きるとは断定しません。他のプラットフォームでは、同じ設定とパスの問題を示す証拠がある場合に限り、以下の切り分け方法を参考にしてください。

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

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

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

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

この関数は、内容を主設定に直接記述する type: inline を除外します。他の集合では Profile、集合の種類、名前から path を作り直し、元の path をそのまま使いません。

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

対象は、取得元が信頼でき、自分で内容を確認できる少数の 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 の文書と FlClash の inline 処理に基づきます。#2448 には、ルール集合の復旧を個別に確認した結果はありません。behavior、出所、参照関係を確認できなければ、原本を残して元に戻してください。

有効な設定が検証したコピーか確認してください。古いファイルを参照する Profile では復旧を確かめられません。Provider とポリシーグループのノード数・名前が元の一覧と一致し、filter、exclude-filter、グループの参照ですべてのノードを除外していないことを確認します。

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

クライアントを完全終了して起動し直しても、同じ Profile、ノード、ルールが有効で、対応するファイル不足のエラーが出ないことを確認します。ノードが表示されても通信できない場合は、プロトコル、認証情報、ネットワークを調べます。通信はできてもルールが違う場合は、主設定の rules の順序と behavior を確認してください。

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

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

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

修正が公開されたかどうかは、公式のissue、コミット、Releaseだけを根拠に判断してください。Open issueでの報告者のバージョン説明、ソースコードから見つけた一時的な対処方法、「ノードが再表示された」という結果を、確認済みのクライアント修正として記載しないでください。アップグレード後も、同じ設定と確認方法で再テストしてください。