Mihomo proxy-providers 怎么配置？节点集合、筛选与健康检查详解

先分清 provider、代理组与当前节点

proxy-providers 是节点集合的来源层：它负责从远程 URL、本地文件或配置内联数据读取代理条目。proxy-groups 才是消费这些条目的策略层，通过 use 引用一个或多个 provider；用户最终在客户端里选中的，则是组中的具体节点或另一个子策略组。三层名称可能同时出现在界面里，但作用并不相同。

这一区分直接影响排障。provider 卡片能够更新，只能证明文件已经获取并被解析；它不能证明每个服务器都可达。代理组里没有节点，应先检查 use、筛选表达式和协议排除项；有节点却全部超时，才应继续看健康检查地址、服务器连通性与本地网络。

选择 HTTP、file 或 inline 来源

远程订阅通常使用 type: http，同时设置 url、本地缓存 path 与更新 interval。Mihomo 按间隔重新获取远程内容，并把结果保存在指定路径。type: file 只读取本地文件，不会替你访问远程订阅；inline 则把代理条目直接写在主配置中，适合少量、稳定且由自己维护的节点。

YAMLproxy-providers:
  main-subscription:
    type: http
    url: "https://provider.example/sub?token=REDACTED"
    path: ./providers/main.yaml
    interval: 21600
    proxy: DIRECT
    size-limit: 10485760
    header:
      User-Agent:
        - "mihomo"

proxy 决定更新请求经哪个出口发出，DIRECT 并非永远正确：如果订阅站只能经现有代理访问，需要指定可用的代理或策略组。size-limit 的单位是字节，示例值为 10 MiB；它不能替代对来源可信度的判断。路径还应保持唯一，避免两个 provider 写入同一缓存文件。

用 filter、exclude-filter 和协议类型做筛选

filter 是针对节点名称的正则包含条件，exclude-filter 是名称排除条件；二者可放在 provider 层，也可在代理组引用 provider 时进一步收窄。provider 的 exclude-type 可按协议类型排除其中节点；代理组也有同名字段，但官方文档说明它只排除直接引入的出站代理，不会替你排除 use 引入的 provider 节点。若多个组需要不同地区，通常保留一个原始 provider，再在各组分别做名称筛选。

YAMLproxy-groups:
  - name: Japan
    type: select
    use:
      - main-subscription
    filter: '(?i)(日本|东京|大阪|japan|tokyo|osaka|\bjp\b)'
    exclude-filter: '(?i)(到期|剩余|官网|套餐)'

正则匹配的是服务商给出的节点名称，不是服务器真实地理位置。名称规则变化后，表达式可能一个节点也匹配不到。YAML 中的反斜线还会受到字符串引号影响；需要使用  等正则转义时，优先复制到测试配置中验证，而不要一次改动所有生产策略组。

健康检查测到的是什么

health-check 会让 Mihomo 通过各节点访问指定 URL，以延迟、超时和期望状态判断可用性。常用字段包括 enable、url、interval、timeout、lazy 与 expected-status。检测地址应稳定、响应体小，并且在你的网络和所有候选出口上都可访问。

YAMLhealth-check:
  enable: true
  url: https://www.gstatic.com/generate_204
  interval: 600
  timeout: 5000
  lazy: true
  expected-status: 204

检测成功只说明“该节点能够在检测时访问该 URL”，不等于视频、游戏或特定 API 一定可用；检测失败也可能是测试站被节点出口拦截，而非代理协议失效。lazy 适合减少闲置 provider 的探测，但第一次使用时可能需要等待检查。不要把间隔设得过短，否则大量节点会产生持续请求与额外负载。

把 provider 接入 select、url-test 或 fallback

provider 本身不决定流量走向。手动控制可使用 select；希望按探测延迟选择可用节点，可使用 url-test；强调连续可用并按顺序切换，则可考虑 fallback。这些组自己的测试参数与 provider 的健康检查是两个层级，不应只看见一个延迟数字就认为配置重复。

同一个 provider 可以被多个组引用。建议先建立一个不带复杂筛选的“全部节点”组作为观察面，再建立地区组或用途组。这样更新后若某个组突然为空，可以与原始集合对照，而不必猜测是远程文件、解析器还是正则出了问题。

按层验证，避免同时改三个变量

1. 手动更新 provider，确认时间、文件大小和解析日志正常。
2. 在不加筛选的临时组中确认节点数量与名称。
3. 逐一加入 filter、exclude-filter 和 exclude-type，每次观察结果。
4. 触发健康检查，区分“无节点”“检测失败”和“业务网站不可用”。
5. 最后再调整组类型、检测间隔与自动选择策略。

如果更新返回 HTML 登录页、鉴权错误或空文件，应回到订阅服务端检查，而不是继续调正则。如果日志显示缓存路径权限错误，应修正目录；若只有某个检测 URL 失败，换一个稳定端点交叉验证。完整字段含义与约束应以 Mihomo proxy-providers 文档和 proxy-groups 文档为准。

最后保留一份可回退配置，并记录修改前后的节点数量与错误。这样“订阅能更新、组内有节点、健康检查通过、目标业务可访问”四个结论彼此独立，问题也更容易定位。

官方来源与版本边界

• wiki.metacubex.one/config/proxy-providers
• wiki.metacubex.one/config/proxy-groups