本文目錄
磁碟上找得到檔案，不代表執行中的核心正在讀取同一位置。用戶端產生設定時可能改寫集合路徑，因此節點清單為空時，要比較原檔案和實際讀取位址。復原也應在獨立副本中進行，外部檔案與主要設定都要保留，避免為了讓清單出現而失去唯一原件。
本機 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 都必然發生同樣故障；其他平台只有出現相同設定和路徑證據時，才參考下面的判斷方法。
為什麼原 path 正確，核心仍可能找不到檔案？
先儲存目前主設定、所有外部 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（內容直接寫在主設定中），其他集合的 path 會按 Profile、集合類別及名稱重新產生，不直接沿用原 path。
這段程式碼只有存在非空 url 時才進入舊快取遷移分支；本機 file Provider 沒有 url 時，也會被賦予新的路徑，但該分支沒有把原 path 檔案複製過去。原始碼分析可佐證「原檔案與執行路徑可能不一致」的判斷，與報告者的解釋相符；本站沒有在實際 Windows 安裝上獨立重現，不把這一推斷當成維護者已確認結論。
原檔案存在，日誌卻指向另一處不存在的檔案
儲存原設定和路徑對照；小型可信清單可在副本中改成 inline。
日誌指向原檔案，但出現 YAML 或欄位錯誤
先修正內容和格式，不直接歸因於 #2448。
Provider 有節點，策略群組卻為空
檢查 use、集合名稱、filter 與 exclude-filter，區分引用或過濾問題。
使用 type: http，更新收到錯誤回應
檢查遠端來源與下載日誌，不套用本機檔案恢復步驟。
小型本機節點清單怎樣改為 inline？
只處理來源可信、自己能讀懂的少量 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 是範例值，不能用於連線。實際操作應使用自己的可信節點物件，並保留原設定的集合和策略群組名稱。把片段合併到設定副本，不用它替換整份設定。
proxy-providers:
my-local-nodes:
type: inline
payload:
- name: example-node
type: ss
server: example.com
port: 443
cipher: chacha20-ietf-poly1305
password: REPLACE_WITH_YOUR_PASSWORD
proxy-groups:
- name: Local
type: select
use:
- my-local-nodes儲存設定副本後，先做用戶端設定驗證，再選中該副本並啟動。若驗證失敗，立即停止，不開啟 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 規則。
rule-providers:
local-rules:
type: inline
behavior: classical
payload:
- DOMAIN-SUFFIX,example.com
rules:
- RULE-SET,local-rules,Localdomain 集合的項是該類型支援的網域表達式，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 回報時附上用戶端完整版本、系統版本、原 Provider 類型與相對路徑、日誌中的實際路徑，以及是否在設定副本上嘗試 inline。公開副本須遮蓋訂閱 token、密碼、伺服器及個人目錄名；保留原始私密證據在本機。
後續只依據官方 issue、提交和 Release 判斷修復是否已發布。不能把 Open issue 中回報者的版本描述、從原始碼找到的臨時處理方式或「節點重新出現」寫成已確認的用戶端修復；升級後仍應用同一份設定和驗證方法重新測試。