Mihomo 启动没有红字，只能说明配置大体能被解析。节点列表为空，通常发生在 provider 下载、provider 名称引用和筛选规则这三层。
Mihomo 文档里 proxy-providers 和 proxy-groups 是两段配置：前者负责拿到节点，后者用 use 把 provider 放进策略组。两段只要断一处，Dashboard 或客户端节点页就可能是空白。
先判断：到底是哪一种空？
| 表现 | 更可能原因 | 先查什么 |
|---|---|---|
| 所有策略组为空 | provider 没下载，或缓存文件不是节点文件 | provider 缓存文件 |
| 只有某个组为空 | use 名称写错 | proxy-groups[].use |
| 有节点但延迟全失败 | 节点存在，健康检查失败 | health-check 日志 |
| 更新后突然为空 | 远程订阅返回空内容、登录页或 HTML | provider URL 响应前 20 行 |
| 只在一个客户端空 | 客户端缓存路径或 HomeDir 不一致 | provider path 和运行目录 |
不要一上来换订阅。先看本地缓存里到底有没有节点；缓存里没有节点，策略组怎么改都不会凭空变出来。
最小 provider 配置长什么样？
proxy-providers:
provider1:
type: http
url: "https://example.com/provider.yaml"
path: ./providers/provider1.yaml
interval: 3600
health-check:
enable: true
url: https://cp.cloudflare.com
interval: 600
proxy-groups:
- name: PROXY
type: select
use:
- provider1
rules:
- MATCH,PROXY关键是 provider1 出现了两次：一次在 proxy-providers 下定义，一次在 proxy-groups.use 里引用。
Provider1、provider-1、provider1 都不是同一个名字。排查时先复制粘贴名称，不要手敲。
provider 缓存文件里必须有什么？
文档里的 inline provider 用 payload 放代理对象列表；远程 provider 文件也要能解析出代理条目。缓存文件里至少要能看到类似结构：
proxies:
- name: node-a
type: ss
server: example.com
port: 443如果打开缓存文件看到的是下面这种内容，它就不是 provider 文件：
<!doctype html>也可能是一段错误 JSON、登录提示或空白文件。这时不要继续改 proxy-groups，先回到 provider URL、请求头、订阅状态和客户端更新日志查。
use 名称怎么核对？
把 proxy-providers 下的一级 key 复制出来，再和每个策略组里的 use 对比。
proxy-providers:
work-provider:
type: http
url: "https://example.com/provider.yaml"
path: ./providers/work.yaml
proxy-groups:
- name: PROXY
type: select
use:
- work-provider常见错法有 4 种：
| 错法 | 例子 | 结果 |
|---|---|---|
| 大小写不同 | Work-Provider vs work-provider | 引用不到 provider |
| 多了空格 | work-provider | 看起来一样，实际不同 |
| 改了定义没改引用 | provider 改名后 use 还用旧名 | 组为空 |
| 多客户端混用配置 | A 客户端缓存旧 provider，B 客户端加载新文件 | 只有一个客户端空 |
如果你在 Clash Verge Rev、OpenClash、裸 Mihomo 之间同步同一份 YAML，这一步尤其容易出错。
filter 会不会把节点全筛掉？
会。proxy-groups.filter 会按关键词或正则筛 provider 导入的节点，include-all、include-all-providers 也会影响导入范围。
先把 filter 拿掉，只保留最小引用：
proxy-groups:
- name: PROXY
type: select
use:
- provider1确认节点出现后，再加筛选：
filter: "HK|Hong Kong"中文、英文、emoji 混合命名的节点很容易被正则漏掉。第一轮只验证 provider 能否进组，不要同时验证筛选规则。
health-check 失败要不要一起查？
节点为空时，health-check 没有对象可测；节点显示出来但延迟全失败，才轮到它。
Mihomo 文档示例里常见的测试 URL 包括 https://cp.cloudflare.com 和 https://www.gstatic.com/generate_204。配置大致如下：
health-check:
enable: true
url: https://cp.cloudflare.com
interval: 600
timeout: 5000不要把延迟失败当成 provider 为空。前者是连通性或测试 URL 问题，后者是节点根本没进列表。
怎么确认已经恢复？
导入后看 4 个信号：
- provider 缓存文件存在，里面能看到
proxies。 - Dashboard 或客户端节点页数量大于 0。
proxy-groups里的目标组能看到 provider 节点。- 手动更新 provider 后，缓存文件不会变回 HTML、JSON 错误或空文件。
多端共用同一套配置时，最麻烦的不是语法，而是不同客户端拿到的订阅格式不一致：Windows 能显示，OpenWrt 上空；家里路由器能更新，笔记本却拿到 HTML。需要减少这类格式混用时，可以把核心设备统一到配套订阅线路；但本机节点页是否为空，仍然按 provider 文件和 use 名称验证。
相关阅读
FAQ
Mihomo 没有报错为什么没有节点？
Mihomo 配置能解析，只说明 YAML 语法过了。provider 下载到空文件、名称引用错，或者 filter 把节点全筛掉，节点页都会是空的。
proxy-providers 的名字能随便写吗？
provider 名称可以自定义，但不能重复；proxy-groups.use 里也要逐字写同一个名称。大小写、横线和尾部空格都按不同名字处理。
health-check 全失败和节点为空是一回事吗？
不是。health-check 全失败说明节点已经进列表，只是延迟测试失败；节点为空是 provider 或 group 没拿到节点，应该先查缓存和引用。
要不要先换 Mihomo 内核？
先别换。只有日志提示字段不支持、版本过旧或客户端无法加载当前配置时才考虑换内核；空列表更常见于 provider 文件、路径、名称和筛选条件。