Clash 配置文件参考大全

01 / Structure

YAML 结构总览

配置文件由哪些部分组成

Clash 配置文件本质上是一份 YAML 文档。mihomo 内核读取它以后，先建立监听端口和 DNS 服务，再载入代理节点、策略组、规则集与运行参数。常见文件可以分成六层：通用运行字段、DNS、节点或节点提供器、策略组、规则提供器、规则。它们在文本中的先后顺序通常不影响解析，但引用关系有明确方向：规则引用策略组，策略组引用节点或其他策略组，Provider 则向策略组和规则提供可更新的数据。

下面是一份便于理解层级的最小骨架。它使用本机 HTTP 与 SOCKS 端口，定义一个手动策略组，并让未提前命中的流量直连。示例中的节点地址与密码是教学假值，不能直接用于连接。

port: 7890
socks-port: 7891
allow-lan: false
mode: rule
log-level: info

proxies:
  - name: Example-Trojan
    type: trojan
    server: example.com
    port: 443
    password: "your-password"
    sni: example.com

proxy-groups:
  - name: 节点选择
    type: select
    proxies:
      - Example-Trojan
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.org,节点选择
  - MATCH,DIRECT

顶层键必须从行首开始。属于某个键的子项需要统一缩进，通常使用两个空格。YAML 不要求固定为两个空格，但同一层级必须一致；Tab 制表符不适合作为缩进。列表项以连字符开头，键和值之间使用半角冒号和至少一个空格。节点名称、策略组名称可以包含中文，但名称必须在所有引用位置完全一致，包括空格、大小写和标点。

映射、列表与标量

理解三种数据形态可以快速看懂绝大多数配置。映射是一组键值，例如 dns: 下的 enable: true；列表是一串顺序项，例如 rules: 下每行一条规则；标量则是字符串、数字、布尔值或空值。true、false 应写成布尔值，不要加引号。端口应写成数字。含有冒号、井号、前后空格或容易被 YAML 解释成其他类型的字符串，建议使用引号包裹。

井号表示注释起点。若密码或名称自身含有井号，必须使用引号，否则井号后的内容会被当成注释丢弃。配置里重复出现同一个顶层键时，不同解析器可能保留前一项或后一项，也可能直接报错，因此不要依赖重复键覆盖。编辑订阅文件时尤其要注意：把新的 dns: 段直接粘到原有 dns: 段后面，不等于完成合并。

名称引用与加载顺序

策略组名称是规则的最终目标。例如规则写成 DOMAIN-SUFFIX,example.org,自动选择，配置中就必须存在名为“自动选择”的策略组，或存在同名的内置动作。DIRECT、REJECT 等动作由内核识别；其他名称都需要在 proxy-groups 中声明。策略组还可以引用另一个策略组，但应避免形成 A 引用 B、B 又引用 A 的循环关系。

客户端导入配置时，可能先保存原始订阅，再应用本地覆写，最后交给内核解析。因此你在界面里看到的最终配置未必与订阅服务器返回的文本完全相同。排错时应确认正在运行的是哪一份配置、最后一次更新是否成功、客户端是否启用了脚本或合并规则。若只是想完成订阅导入和首次连接，不需要手工编写整份 YAML，可先按快速上手文档操作。

02 / General

通用字段：端口、模式与日志

监听端口的选择

port 提供 HTTP 代理端口，socks-port 提供 SOCKS5 代理端口，mixed-port 则允许同一个端口同时接收 HTTP 与 SOCKS 流量。桌面系统里，系统代理常使用 HTTP 或 mixed 端口；需要单独指定 SOCKS5 的命令行工具可以使用 socks 端口。多数情况下选择 mixed-port 能减少端口数量，但已有脚本若固定引用 7890 和 7891，就应保持原来的端口规划。

mixed-port: 7890
allow-lan: false
bind-address: "*"
mode: rule
log-level: info
ipv6: false

同一台设备上的两个程序不能同时监听相同地址和端口。客户端报“address already in use”时，先关闭另一套代理软件或更换端口，不要把问题归因于节点。端口范围是 1 到 65535，低位端口在部分桌面系统上可能需要额外权限。修改端口后，还要同步修改浏览器、终端环境变量或局域网设备里的代理地址。

局域网访问与绑定地址

allow-lan 控制其他设备能否访问当前设备提供的代理端口。仅在本机使用时设为 false，可以减少不必要的暴露。需要让同一 Wi‑Fi 下的电脑、电视或测试机连接时，将它设为 true，并使用代理主机的局域网地址。此时还要确认系统防火墙允许对应端口、两台设备处于可互访的网络，并避免在公共网络中开启。

bind-address 决定监听哪些本地地址。星号通常表示所有可用接口，回环地址则只允许本机访问。不同客户端可能通过图形界面管理这些参数，界面中的“允许局域网”开关可能在运行时生成对应字段。iOS 的网络扩展工作方式与桌面端口代理不同，应用导入同一配置时，不一定向其他设备开放这些监听端口，所以跨设备共享应以客户端实际功能为准。

rule、global 与 direct

mode: rule 按规则列表从上到下决定每个连接的去向，是日常使用最常见的模式。global 让流量统一交给全局策略组处理，适合短时间确认某个节点是否可用，但它不会体现细分规则的结果。direct 让连接直接访问目标，可用来对比代理前后的网络表现。模式切换只是改变分流入口，并不会自动修复无效节点或错误 DNS。

当客户端界面提供“规则模式”“全局模式”“直连模式”时，界面选择通常会覆盖配置文件里的默认 mode。排查规则不生效时，应同时检查 YAML 和当前界面状态。若一直停留在全局模式，修改 rules 自然看不到变化；若处于直连模式，策略组里的节点选择也不会承担主要流量。

日志、控制接口与配置存储

log-level 常用 info，能看到连接、规则命中和部分错误。日志过少时难以定位问题，长期保持过于详细的调试输出又会增加阅读成本。遇到连接失败时，先记录目标域名、命中的规则、选中的策略组和错误类型，再对照配置修改；不要只凭“打不开”这一现象反复更换所有设置。

external-controller 用于给兼容的控制界面提供 API，例如监听在本机回环地址。若设置了 secret，控制端连接时需要使用一致的凭据。移动客户端通常已经管理好控制接口，不建议为了套用桌面教程而随意开放到局域网。配置中的凭据应使用自己的值，并避免把带有订阅地址、节点密码或控制密钥的完整文件公开粘贴到论坛。

profile 下的存储选项可用于保留策略组选择或 Fake IP 映射。客户端是否支持、何时写入由其内核集成方式决定。升级客户端或更换配置后，如果某个策略组仍保持旧选择，先确认是否启用了选择记忆，再判断是不是配置没有刷新。系统要求和可用客户端可在下载页按平台查看。

03 / DNS

DNS 配置：解析链路与劫持

DNS 段解决什么问题

DNS 段决定域名如何转换为地址，以及解析请求是否由内核统一接管。代理节点可用并不代表 DNS 一定正确：域名解析可能仍由系统网络直接完成，也可能被路由器、运营网络或另一套 VPN 接管。表现上常见为部分域名打不开、规则命中与预期不一致、切换网络后短时间异常，或代理已连接但应用仍提示无法访问。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  use-hosts: true
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  proxy-server-nameserver:
    - 223.5.5.5
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

enable 控制内置 DNS 是否启用。listen 是 DNS 服务监听地址，在桌面或路由环境中可供系统转发；移动端通常由网络扩展接管，不应只根据监听端口判断是否生效。ipv6 控制是否返回和处理 AAAA 结果。如果本地网络的 IPv6 路径不稳定，暂时关闭有助于判断问题是否来自双栈网络，但不应把关闭 IPv6 当作所有 DNS 故障的固定答案。

nameserver 与 bootstrap 关系

nameserver 是主要解析器列表，可以使用传统 UDP 地址，也可以使用加密 DNS URL。配置 DoH 时，DoH 服务器自身的域名也需要先解析，这形成启动阶段的依赖。mihomo 的不同配置写法可通过 default-nameserver 或专门的服务器解析项处理初始解析。这里应放能够直接访问的 IP 形式解析器，避免初始解析再次依赖尚未建立的代理链路。

proxy-server-nameserver 主要用于解析代理服务器域名。它与普通目标域名解析分开，可以降低“要连接代理服务器，却必须先通过该代理解析服务器域名”的循环依赖。若节点的 server 已经是 IP 地址，这一环节影响较小；若订阅里大量节点使用域名，设置一组当前网络可直达的解析器更稳妥。

加密 DNS 并不自动等于所有查询都经过代理。解析器 URL 可以直连，也可以根据内核支持的地址参数指定通过某个策略处理。设计解析链路时先确定目标：是避免本地解析干扰、让规则获得一致结果，还是要求特定域名通过特定解析器。目标不同，配置也不同。不要同时堆入大量公共 DNS 并期待内核自动判断哪一个最合适；解析器响应内容不同反而可能增加不确定性。

fake-ip 与 redir-host

fake-ip 模式先向应用返回保留地址池中的映射地址，内核再根据映射恢复原始域名并执行规则。它的优势是规则匹配能保留域名信息，对透明接管场景也更直接。redir-host 则返回真实解析结果，某些局域网服务或对地址行为敏感的程序更容易兼容，但域名信息的保留方式与匹配路径会有所不同。

fake-ip-range 应使用专门规划的地址段，不要与家庭网络、公司网络、容器网络或 VPN 已使用的网段重叠。若访问某个局域网域名后得到 Fake IP，说明它没有被排除。可把明确需要真实解析的域名加入 fake-ip-filter，例如局域网后缀、设备发现域名或特定登录域名。过滤项应尽量具体；把过宽的通配符加入列表，会让大量请求绕开 Fake IP，削弱统一接管效果。

nameserver-policy 与分域解析

nameserver-policy 可以让特定域名或规则集使用指定解析器。例如内部域名交给公司 DNS，其他域名使用公共加密解析器。匹配项越具体越容易维护。若一个域名同时符合多条策略，要结合内核的匹配优先级检查最终结果，并通过日志确认，而不是仅凭配置排列猜测。

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://1.1.1.1/dns-query
  nameserver-policy:
    "geosite:cn":
      - https://223.5.5.5/dns-query
    "+.internal.example":
      - 192.168.1.1
  fake-ip-filter:
    - "+.internal.example"
    - "*.lan"

内部解析器通常只能在指定 Wi‑Fi、企业网络或 VPN 内访问。离开该网络后，如果策略仍将内部域名发送给不可达地址，查询会等待超时。移动设备频繁在蜂窝网络与 Wi‑Fi 间切换，建议把这类配置放在对应的按需连接条件或独立配置中，不要让一份强绑定办公网络的 DNS 配置覆盖所有场景。

DNS 排错顺序

先用域名与 IP 分别测试：IP 可访问而域名失败，重点看解析；两者都失败，继续检查策略组、节点和系统网络。其次查看日志中的 DNS 超时、连接拒绝或解析器握手错误。再确认系统是否同时启用了其他 VPN、私有 DNS、过滤应用或路由器 DNS 重写。最后才调整 enhanced mode、解析器或 IPv6。每次只改一个变量，并清理应用或系统的短期缓存后复测。

如果问题表现为“已连接但无法上网”，可以配合阅读从上到下的排查清单。需要逐字段理解 fallback、过滤与 DNS 劫持时，可继续查看DNS 配置详解。不同客户端可能对部分字段进行图形化封装，最终以运行日志和导出的生效配置为准。

04 / Proxies

代理节点字段

公共字段与引用名称

proxies 是静态节点列表。每个节点至少有 name、type、server 和 port，其余字段由协议决定。name 是配置内部的引用标识，不负责网络连接；server 才是服务器域名或地址。策略组引用节点时使用名称，因此重命名节点后必须同步更新所有直接引用它的策略组。

节点名称最好简短且稳定。订阅更新时，如果服务端更改名称，客户端记住的策略组选择可能找不到旧项并回退到默认节点。需要长期固定选择时，可以让策略组通过 Provider 使用过滤规则选取一类节点，或在本地覆写中保持统一命名。不要仅靠名称中的地区词推断线路质量，实际可用性还受本地网络、入口、传输参数和服务端状态影响。

Trojan 示例

proxies:
  - name: Example-Trojan
    type: trojan
    server: edge.example.com
    port: 443
    password: "your-password"
    sni: edge.example.com
    udp: true
    skip-cert-verify: false

Trojan 常使用 TLS。sni 是 TLS 握手中的服务器名称，应与服务端证书和部署配置一致。password 必须完整保留特殊字符，使用引号更稳妥。udp 控制节点是否承载 UDP 流量，但客户端、内核和服务端都支持时才会真正可用。skip-cert-verify 关闭证书验证会削弱身份校验，正常部署应保持为 false，证书错误应从服务器名称、证书有效性、系统时间和网络劫持方向修复。

Shadowsocks 示例

proxies:
  - name: Example-SS
    type: ss
    server: 203.0.113.10
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

Shadowsocks 的核心字段是加密方法与密码，两端必须一致。cipher 不能按个人偏好随意替换，服务端配置什么，客户端就填写什么。连接失败时应核对地址、端口、方法和密码四项，再确认服务器防火墙与本地网络是否允许对应流量。将另一个协议的字段复制进来不会增强兼容性，未识别字段可能被忽略，也可能导致配置校验失败。

VMess、VLESS 与传输层参数

VMess 常使用 uuid、alterId、cipher 等字段；VLESS 使用 UUID，并根据部署选择 TLS、Reality 或其他传输设置。WebSocket、gRPC 等传输层通常还有路径、Host、服务名和请求头。字段层级必须与 mihomo 支持的格式一致，不能把其他客户端导出的 JSON 字段逐字搬进 YAML。

  - name: Example-VMess-WS
    type: vmess
    server: ws.example.com
    port: 443
    uuid: 00000000-0000-4000-8000-000000000000
    alterId: 0
    cipher: auto
    tls: true
    servername: ws.example.com
    network: ws
    ws-opts:
      path: /network
      headers:
        Host: ws.example.com

这里的 server 决定连接目标，servername 或相应 SNI 字段影响 TLS，WebSocket 的 Host 影响上层请求。三个域名在简单部署中可能相同，在经反向代理或分离入口的部署中也可能不同。任何一项拼写错误，都可能表现为 TCP 能建立但握手失败。排错时应按“域名解析、TCP 端口、TLS、传输层、协议认证”的顺序逐层定位。

节点级网络选项

interface-name 可指定出口网卡，routing-mark 常用于 Linux 策略路由，移动客户端通常不需要手工设置。ip-version、prefer-ipv6 等选项影响节点服务器域名如何选择地址，具体支持取决于内核。只有在确认双栈解析选错地址时才应调整，避免把普通线路故障误处理成 IP 版本问题。

节点字段正确但仍不能使用时，先将该节点放进简单的 select 组并临时切到全局模式测试，以排除复杂规则影响。测试结束后回到规则模式。如果所有节点同时失效，优先检查订阅状态、系统时间、DNS 与本地网络；只有单个节点失效时，再集中核对它的协议参数。客户端选择和平台差异可在下载页查看，Clash Plus 作为全平台首推选项，适合先完成基础连接再逐步调整配置。

05 / Policy

策略组字段与选择逻辑

select：把决定权留给使用者

策略组位于节点与规则之间。规则通常不直接写某个具体节点，而是指向策略组；你在客户端界面更换组内选择后，所有指向该组的规则都会使用新的结果。select 是手动选择组，适合作为“节点选择”“流媒体”“下载”等可明确控制的入口。组内既能放节点，也能放其他策略组或 DIRECT。

proxy-groups:
  - name: 节点选择
    type: select
    proxies:
      - 自动选择
      - 故障转移
      - Example-Trojan
      - DIRECT

列表顺序会影响界面默认展示和回退体验。把最常使用的选择放在前面，但不要让上层组和下层组形成循环。比如“节点选择”包含“自动选择”是合理的；若“自动选择”又把“节点选择”当候选，就会形成不可解析或不可执行的循环。复杂配置最好先画出引用方向，再决定分层。

url-test：按探测结果自动选择

url-test 会按指定 URL 对候选节点进行连通性测试，并选择结果较合适的节点。它衡量的是到测试目标的请求表现，不等同于所有网站的真实速度。测试 URL 应稳定、响应体小，并与主要使用网络具有代表性。测试频率过高会增加后台活动与服务器请求，移动设备上还可能带来额外耗电。

  - name: 自动选择
    type: url-test
    proxies:
      - Example-Trojan
      - Example-SS
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80
    lazy: true

interval 是测试间隔，单位通常为秒；tolerance 用于避免候选结果只因很小差异就频繁切换；lazy 可让测试更接近按需执行。配置这些字段时，重点是稳定而非追求不断刷新。若业务连接需要保持同一出口，频繁切换节点可能导致会话变化，因此应增大容差和间隔，或改用手动组。

fallback 与 load-balance

fallback 按列表优先级使用节点，当当前节点探测失败时切换到后续候选。它适合“首选线路优先、不可用再换”的场景。与 url-test 不同，它不以最低测试结果作为唯一目标，而是保留顺序偏好。排错时如果总是落到第二个节点，应检查首选节点对测试 URL 是否可达，而不是只检查普通网页。

load-balance 会根据策略把不同连接分配到多个节点。它不等于把一个下载任务的带宽简单相加，也可能因为出口地址变化影响登录状态、风控判断或长连接。需要固定来源地址的网站不适合随意使用负载均衡。具体策略可按哈希或轮询思想分配，选择前要理解客户端当前内核支持的字段。

通过 Provider 选取节点

当节点来自 proxy-providers 时，策略组可以使用 use 引用 Provider，而不是把每个节点名称写进 proxies。这样订阅更新增删节点后，组内候选会同步变化。还可以使用 filter 按名称筛选，例如只纳入名称含有某个地区标识的节点。过滤规则通常使用正则表达式，应考虑大小写、全角符号和服务端改名带来的变化。

  - name: 移动网络
    type: select
    use:
      - provider-main
    filter: "(?i)mobile|移动"
    exclude-filter: "(?i)expire|剩余|到期"

名称过滤只依据文本，不验证节点真实所在地、协议或线路属性。订阅命名规则改变后，组可能突然变空。维护配置时应为重要策略组准备可见的回退项，并在更新订阅后检查候选数量。若客户端界面显示策略组为空，先检查 Provider 更新是否成功，再检查过滤表达式，最后检查 Provider 名称是否写错。

策略组设计不宜过深。常见的三层足够覆盖大多数需求：底层是节点池与自动测试组，中层是“节点选择”等总入口，上层是视频、下载或特定服务策略。层级越多，日志里追踪最终出口越困难。规则命中后，应沿着“规则目标组—当前组选择—下层组选择—具体节点”逐级确认。

06 / Rules

规则语法与匹配顺序

从上到下，命中即停止

rules 是有序列表。内核从第一条开始检查连接，命中后使用该条指定的策略，不再继续检查后续规则。因此具体规则应放在宽泛规则之前，最终兜底放在末尾。若把 MATCH 提前，下面的域名和地址规则永远没有机会执行。排查“规则写了但不生效”时，首先查看日志实际命中了哪一条，而不是继续追加重复规则。

rules:
  - DOMAIN,api.example.com,节点选择
  - DOMAIN-SUFFIX,example.com,节点选择
  - DOMAIN-KEYWORD,example,节点选择
  - IP-CIDR,203.0.113.0/24,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

每条经典规则通常由规则类型、匹配内容和策略目标组成，以半角逗号分隔。策略目标必须是现有策略组、节点名称或内置动作。规则行中的额外空格可能成为内容的一部分，最好保持统一格式。域名匹配不包含 URL 路径；如果想按网页路径分流，仅靠 DOMAIN 类规则无法完成。

DOMAIN、DOMAIN-SUFFIX 与 DOMAIN-KEYWORD

DOMAIN 精确匹配完整域名。例如 DOMAIN,api.example.com 只匹配该主机，不自动包含 www.example.com。DOMAIN-SUFFIX,example.com 匹配该根域及其子域，适合覆盖同一服务的一组主机。DOMAIN-KEYWORD 只要域名中出现指定文本就可能命中，覆盖范围较宽，容易误伤名称相似但无关的站点。

规则设计应优先使用精确域名和后缀，只有确实无法整理域名集合时才使用关键词。服务可能依赖多个域名，包括登录、接口、图片和媒体域名，只处理网页主域不一定覆盖完整请求。可以观察连接日志逐步补全，但不要把每个临时 CDN 主机都硬编码进主配置；规模较大的域名集合更适合放进规则集 Provider。

IP-CIDR 与 no-resolve

IP-CIDR 匹配 IPv4 网段，IP-CIDR6 匹配 IPv6 网段。CIDR 后缀表示网络前缀长度，例如 /24 覆盖相邻的一段 IPv4 地址。IP 规则无法稳定表达经常变化的云服务域名，因此不要把一次解析出的地址当作长期规则。只有服务提供稳定网段、局域网地址或明确网络范围时，IP 规则才更适合。

no-resolve 表示为判断该 IP 规则不要额外触发域名解析。当连接已经具有目标 IP 时可以直接匹配；若只有域名，内核不会为了这条规则专门解析。它能减少不必要查询和潜在循环，但也可能让依赖解析结果的 IP 规则不命中。是否使用应根据请求进入内核时掌握的信息决定。

rules:
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR6,::1/128,DIRECT,no-resolve

局域网直连规则常放在靠前位置，避免打印机、路由器和文件服务器被送进远程代理。公司网络可能使用更大的私有地址规划，家庭网络也可能与 VPN 网段重叠。遇到局域网服务无法访问时，先确认目标实际地址，再判断是规则错误、Fake IP 过滤不足，还是系统路由没有指向本地接口。

GEOIP、GEOSITE 与规则集

GEOIP 根据目标 IP 所属数据库分类，适合做区域级 IP 分流，但数据库判断不是业务归属判断。一个本地品牌也可能使用其他地区的云节点，一个海外服务也可能在本地部署边缘地址。GEOSITE 使用域名分类数据，覆盖方式与规则数据库内容有关。两者都依赖数据更新，不应被理解为永远准确的固定事实。

mihomo 常见的规则集匹配还包括 RULE-SET。规则集可以装载 domain、ipcidr 或 classical 行为的数据，引用时必须与 Provider 的 behavior 对应。把 classical 格式的完整规则放进 domain 行为规则集，或给 IP 规则集使用错误行为，都会导致解析失败或匹配结果异常。

进程规则与平台限制

PROCESS-NAME、PROCESS-PATH 等进程规则依赖操作系统提供进程信息。桌面系统在具备权限时可能可用，iOS 网络扩展通常不能按桌面方式读取任意进程路径。编写跨平台配置时，不应让关键分流完全依赖进程规则。更稳妥的主线仍是域名、IP 和规则集，再把进程规则作为特定桌面环境的补充。

同一配置在 Windows、macOS、Android 与 iOS 上出现差异，常见原因并不是 YAML 语法变化，而是系统接管方式、权限和网络栈不同。可将平台相关规则放进本地覆写，保持订阅主体通用。这样订阅更新时不会把桌面专属进程规则强行带到移动端。

REJECT、DIRECT 与最终兜底

DIRECT 让连接直接访问，REJECT 拒绝连接。拦截规则要精确，过宽的关键词或域名后缀可能阻断登录、支付和基础接口。最终一条通常使用 MATCH 指向总策略组或直连，具体取决于配置目标。没有最终兜底时，未命中流量的行为可能由内核默认逻辑决定，配置意图不够清晰。

修改规则后应覆盖主要分支测试：一个应直连的域名、一个应代理的域名、一个局域网地址和一个规则集目标。只测试单个网页无法证明完整规则链正确。速度问题则应区分节点、线路和本机设置，可参考速度慢的三层排查方法，避免把所有性能问题都归结为规则数量。

07 / Providers

Proxy Provider 与 Rule Provider

为什么使用 Provider

Provider 把经常更新的数据从主配置中拆开。proxy-providers 提供节点列表，rule-providers 提供规则集合。主配置负责引用名称、选择更新周期和定义策略，远端文件负责实际内容。这样订阅更新时不必重写整份主配置，也能让多个策略组共享同一节点池。

Provider URL 往往包含访问凭据，应把完整配置视为敏感数据。排错时可以公开删除凭据后的结构，但不要公开真实订阅地址。远端文件不可访问时，客户端可能继续使用本地缓存，也可能因首次下载失败而让对应组为空。看到旧节点仍存在并不一定代表更新成功，应查看更新时间和 Provider 日志。

节点提供器配置

proxy-providers:
  provider-main:
    type: http
    url: "https://subscription.example/path?token=xxxx"
    path: ./providers/provider-main.yaml
    interval: 21600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 900
      lazy: true

type: http 表示从远端获取，url 是资源地址，path 是本地缓存路径，interval 控制更新间隔。路径应避免多个 Provider 共用同一个文件，否则更新时可能互相覆盖。客户端处于沙盒环境时，实际存储位置由应用管理，相对路径通常由内核工作目录解析，不应照搬桌面绝对路径。

health-check 用来检查 Provider 内节点的可用性。它不会自动改变所有策略组选择，只有 url-test、fallback 等组会依据探测结果作出相应选择。检查频率需要兼顾及时性与后台开销；在 iPhone 上设置大量 Provider 并进行高频检测，会增加网络扩展的工作量。可结合按需连接和实际使用频率调整。

Provider 返回内容应符合代理提供器格式，而不是完整 Clash 配置。常见内容以 proxies: 开头，内部包含节点列表。如果远端返回 HTML 登录页、错误提示或普通文本，即使 HTTP 状态看似成功也无法解析。更新失败时应检查响应内容类型、重定向、访问权限和系统时间。

规则提供器配置

rule-providers:
  private-network:
    type: http
    behavior: ipcidr
    format: yaml
    path: ./rules/private-network.yaml
    url: "https://rules.example/private-network.yaml"
    interval: 86400

  service-domains:
    type: http
    behavior: domain
    format: yaml
    path: ./rules/service-domains.yaml
    url: "https://rules.example/service-domains.yaml"
    interval: 86400

rules:
  - RULE-SET,private-network,DIRECT,no-resolve
  - RULE-SET,service-domains,节点选择
  - MATCH,节点选择

behavior 决定规则集条目的解释方式。domain 用于域名集合，ipcidr 用于地址网段，classical 则可容纳带类型和参数的经典规则。format 需要与远端文件一致。YAML 规则集通常以 payload: 包裹列表；文本或二进制规则集使用相应格式。扩展名不能单独证明内容格式，最终仍要以实际数据结构为准。

payload:
  - "+.example.com"
  - "api.example.net"
  - "*.service.example"

domain 行为规则集里的通配表达方式应符合 mihomo 规则集语义，不要把浏览器匹配模式或正则表达式直接混用。classical 规则集则可以写成 DOMAIN-SUFFIX,example.com 这类完整项目。引用时若加入 no-resolve，应确认规则集确实是 IP 行为且不需要额外解析。

更新、缓存与回退

Provider 更新应当是可观察的独立步骤。节点突然消失时，先确认远端文件是否改变，再看过滤条件和策略组引用。规则行为突然变化时，记录规则集更新时间，并检查数据源是否调整分类。把所有问题归因于主配置会忽略外部数据变化。

首次运行必须能够取得 Provider 文件，否则引用它的组或规则集不能完整建立。已有缓存只适合作为临时回退，不应长期掩盖失效 URL。若远端不可达，可以在网络允许时更新后再启用对应配置；也可以把关键的局域网与最终兜底规则保留在主配置中，避免基础连通完全依赖外部规则集。

更新间隔并非越短越好。节点订阅可能一天更新数次，稳定规则集可能一天一次或更低频。高频更新会增加请求、写入和解析次数，在移动网络下尤其没有必要。配置更新失败时，可按照“地址可访问—返回内容正确—本地路径可写—格式与 behavior 一致—引用名称正确”的顺序检查。

08 / Override

覆写、合并与配置排错

订阅、本地覆写与最终配置

多数客户端不会直接运行订阅原文。常见流程是下载订阅、解析基础配置、应用本地覆写或脚本、生成最终配置，再交给 mihomo 内核。理解这一层很重要：你在订阅网页看到某条规则，不代表最终运行配置仍保持原样；同样，本地编辑过的字段也可能在下次订阅更新时被替换。

适合放在订阅中的内容包括服务端维护的节点、基础策略组和常规规则。适合放在本地覆写中的内容包括端口、局域网开关、设备专属 DNS、个人规则和平台差异。不要直接在自动更新的订阅文件里长期维护大量个人修改，否则每次更新都要重新比对。

覆盖与深度合并不是一回事

覆盖通常表示新值替换旧值；深度合并则会继续进入映射内部，只替换指定子键。列表的处理差异更大：有的合并器整段替换列表，有的支持前置、后置或按名称修改。不能仅凭“merge”一词判断行为，应查看客户端的覆写说明并导出最终配置确认。

# 基础配置
dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://1.1.1.1/dns-query

# 期望修改
dns:
  ipv6: false
  nameserver:
    - https://8.8.8.8/dns-query

如果采用深度合并，最终 DNS 可能保留 enable 和 enhanced-mode，同时替换 ipv6 与 nameserver。如果采用顶层覆盖，原有 DNS 段可能整体消失，只剩覆写中的两个字段。若列表采取追加策略，则两个 nameserver 可能同时存在。只有查看最终结果，才能知道客户端采用了哪种语义。

规则的前置、后置与删除

个人规则通常应前置到订阅规则之前，因为规则命中后即停止。比如希望某个内部域名直连，就要把它放在可能覆盖该域名的宽泛代理规则前面。追加到 MATCH 后面不会生效。覆写工具若支持 prepend 与 append，应把精确例外放到 prepend，把最终兜底留给主配置。

# 逻辑示意：前置规则
rules-prepend:
  - DOMAIN,router.example,DIRECT
  - DOMAIN-SUFFIX,internal.example,DIRECT

# 逻辑示意：后置内容不能放在 MATCH 之后
rules-append:
  - DOMAIN-SUFFIX,archive.example,节点选择

上面的键名属于合并逻辑示意，并非所有客户端都直接识别。实际操作应使用客户端提供的覆写界面或其文档规定的键。删除规则比新增规则更容易受文本差异影响：空格、策略组名或参数不同，都可能导致精确删除失败。更稳妥的方法是用一条范围更具体的前置规则覆盖旧结果，而不是依赖脆弱的字符串删除。

用最小配置定位故障

复杂配置出现问题时，不要同时修改 DNS、节点、策略组和规则。先制作一份最小配置，只保留一个已知节点、一个 select 组和一条 MATCH。若最小配置能够连接，说明问题位于被移除的层级；随后按 DNS、Provider、策略组、规则的顺序逐段加回。若最小配置仍失败，则集中检查节点参数、系统权限和当前网络。

mixed-port: 7890
mode: rule
log-level: info

proxies:
  - name: Test
    type: trojan
    server: example.com
    port: 443
    password: "your-password"
    sni: example.com

proxy-groups:
  - name: TEST
    type: select
    proxies:
      - Test
      - DIRECT

rules:
  - MATCH,TEST

移动端测试时还要考虑系统 VPN 状态。先关闭其他可能占用网络扩展的应用，重新启用当前配置，再观察客户端是否成功建立系统 VPN。Wi‑Fi 正常而蜂窝网络失败时，检查应用蜂窝数据权限、按需连接条件和 DNS 可达性；只有某个 Wi‑Fi 失败时，检查该网络的认证页面、路由器过滤和私有地址策略。

按错误类型分层处理

保存、回滚与变更记录

修改前保留一份能够工作的配置，并给本地副本使用清晰文件名。每次只改一类字段，记录修改目的和测试结果。发现问题后直接回到上一份可用配置，比凭记忆撤销多处编辑可靠。订阅地址和节点凭据不应进入公开代码仓库；如需记录结构，可把服务器、密码和访问参数替换成明显的教学假值。

完成编辑后按四层检查。第一层是 YAML：缩进、冒号、列表和重复键；第二层是引用：策略组、Provider、规则目标名称一致；第三层是运行：端口没有冲突，DNS 和 Provider 能加载；第四层是行为：直连、代理、局域网和最终兜底分别命中预期。只有四层都通过，才算配置完成。

从参考手册回到实际操作

如果目标只是完成首次连接，回到使用文档依次导入订阅、选择模式、建立连接并验证即可。需要更换或安装客户端，可在下载页选择 Windows、Android、iOS、macOS 或 Linux 对应入口。配置已经载入但网页仍提示证书异常时，可阅读HTTPS 证书错误的原因与处理方式；iPhone 后台耗电异常则可参考网络扩展后台机制与省电设置。

配置维护的重点不是把所有字段都写进同一文件，而是保持引用清楚、更新来源可追踪、平台差异可隔离。主配置负责稳定结构，Provider 负责可更新数据，本地覆写负责设备和个人需求。遇到问题时沿着 YAML、DNS、节点、策略组、规则、系统网络逐层收窄范围，比整体替换配置更容易找到真实原因。