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 的报告者版本描述、源码上的绕行方式或“节点重新出现”写成已确认的客户端修复；升级后仍应用同一份配置和验证清单重新测试。