FlClash 本機 Provider 沒有節點怎麼辦？

FlClash 匯入設定後，策略群組還在但本機 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、集合類別及名稱等資訊產生，而不是原 path 的原樣傳遞。

這段程式碼只有存在非空 url 時才進入舊快取遷移分支；本機 file Provider 沒有 url 時，也會被賦予新的路徑，但該分支沒有把原 path 檔案複製過去。原始碼分析可佐證「原檔案與執行路徑可能不一致」的判斷，與報告者的解釋相符；本站沒有在實際 Windows 安裝上獨立重現，不把這一推斷當成維護者已確認結論。

先儲存目前主設定、所有外部 Provider 檔案、用戶端版本和首條錯誤日誌。不要只備份應用內 Profile 就假定外部檔案也在封存中；確認那些檔案確實另有副本，再建立一份設定用於測試。

在副本中確認原 path 所指檔案存在、目前使用者能讀取、清單非空且格式正確。若用戶端能夠展示實際執行設定，比較其中同名 Provider 的 path；否則依據日誌中的實際檔案位址判斷，記錄無法取得執行設定這一限制。不要猜測固定快取目錄或手動往 MD5 檔案名中塞入檔案。

Mihomo 官方文件另有 HomeDir 與安全路徑限制。路徑被拒絕和 FlClash 改寫路徑是不同證據：不要透過擴大 SAFE_PATHS、修改整個目錄權限或關閉安全限制來碰運氣。原檔案缺失時，先恢復可信檔案；內容解析失敗時，先修正格式。

只處理來源可信、自己能讀懂的少量 YAML 節點。開啟本機代理集合檔案，把頂層 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 是範例值，不能用於連線。實際操作應使用自己的可信節點物件，並保留原設定的集合和策略群組名稱。把片段合併到設定副本，不用它替換整份設定。

儲存設定副本後，先做用戶端設定驗證，再選中該副本並啟動。若驗證失敗，立即停止，不開啟 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 已驗證過的規則恢復結果。若規則類型、轉換來源或引用關係無法確認，應停在儲存現場與還原階段，不承諾「改成 inline 就一定生效」。

先確認目前選中的是剛驗證過的設定副本，而不是仍引用舊檔案的 Profile。查看 Provider 和策略群組，核對節點數量與名稱，排除 filter、exclude-filter 或策略群組引用把所有節點篩掉的情況。

選一個已知可用節點，按平時使用的系統代理或 TUN 方式完成實際 HTTPS 請求，並檢查連線記錄中的出站。規則集合則用一條自己控制或日常使用、確實落在該集合範圍的請求，觀察命中的規則與策略；只看到清單出現或延遲測試有數字不算驗證完成。

最後完整退出並重新啟動用戶端，確認相同 Profile、節點和規則仍有效，日誌不再出現對應的檔案缺失錯誤。若節點出現但請求失敗，轉查協議、認證資訊和網路；若存取恢復但規則命中不對，轉查主 rules 順序和 behavior，不把所有問題繼續歸給檔案路徑。

若副本驗證失敗、節點協議不支援或規則命中變差，停止使用該副本，恢復事前儲存的主設定與外部檔案。原設定本來就受路徑問題影響時，恢復它只用於保留現場，並不代表能聯網；臨時使用另外一份已驗證可用的完整 Profile。

設定仍不可用時，關閉該用戶端的系統代理或 TUN，確認裝置回到原有網路狀態，再保留日誌向上游回報。不要刪除整個應用資料目錄、所有 Provider 快取或唯一的本機檔案，也不要把私密節點上傳線上轉換網站。

在 #2448 回報時附上用戶端完整版本、系統版本、原 Provider 類型與相對路徑、日誌中的實際路徑，以及是否在設定副本上嘗試 inline。公開副本須遮蓋訂閱 token、密碼、伺服器及個人目錄名；保留原始私密證據在本機。

後續只依據官方 issue、提交和 Release 判斷修復是否已發布。不能把 Open issue 的報告者版本描述、原始碼上的繞行方式或「節點重新出現」寫成已確認的用戶端修復；升級後仍應用同一份設定和驗證清單重新測試。