本文目录
文件能在磁盘上找到，不代表运行中的内核正在读同一个位置。客户端生成配置时可能改写集合路径，因此节点列表为空时，需要比较原文件和实际读取地址。恢复也应在单独副本里完成，外部文件与主配置都要留下，避免为了让列表出现而丢失唯一原件。
本地 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 的报告者版本描述、从源码中找到的临时处理办法或“节点重新出现”写成已确认的客户端修复；升级后仍应用同一份配置和验证方法重新测试。