FlClash 配置字段参考大全

YAML 结构总览：先看层级，再看字段

根对象、映射与序列

mihomo 配置文件的根层是一个 YAML 映射。映射由“键、冒号、值”组成，例如 mode: rule；序列由短横线开始，常见于 proxies、proxy-groups 和 rules。层级完全依靠缩进表达，同一级字段必须保持相同缩进深度。通常使用两个空格，不使用制表符。YAML 不要求统一采用两个还是四个空格，但同一层级忽深忽浅会改变数据结构，解析器可能直接报错，也可能把字段归入错误的父对象。后者更难发现：文件能够加载，某个选项却始终不生效。

标量值包括字符串、数字、布尔值和空值。端口写成 7890 时是数字；true 与 false 是布尔值；节点名称、域名和模式通常是字符串。包含冒号、井号、方括号、花括号或首尾空格的字符串，建议使用引号。井号在未引用字符串中表示注释起点，因此密码或名称含井号时必须加引号。YAML 对大小写敏感，Rule、RULE 与 rule 不是同一个值。字段名也必须使用文档规定的拼写，界面显示的中文名称不能直接替代配置键。

# config.yaml 的典型根结构
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.example/dns-query

proxies:
  - name: "示例节点"
    type: socks5
    server: proxy.example.com
    port: 1080
    username: "your-user"
    password: "your-password"

proxy-groups:
  - name: "节点选择"
    type: select
    proxies:
      - "示例节点"
      - DIRECT

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

字段读取顺序不等于流量处理顺序

YAML 映射在语义上不依赖书写顺序，所以把 dns 放在 proxies 前后通常不会改变结果。不过，人类阅读需要稳定结构。建议依次放置通用设置、DNS、入站监听、代理节点、代理提供者、策略组、规则提供者和规则。真正存在顺序意义的是序列：rules 从上到下匹配，首条命中后停止；策略组中的节点顺序会影响默认选项或自动选择时的候选次序；名称相同的对象在覆写阶段还可能发生替换。

引用关系必须闭合。规则末尾的策略名称，需要在 proxy-groups 中存在，或使用 DIRECT、REJECT 等内置策略。策略组引用的节点名称，必须对应 proxies 中的节点、其他已定义策略组，或由 use 引入的代理提供者。修改名称时不能只改定义处，还要同步检查策略组与规则。中文、空格和标点都属于名称的一部分，“节点选择”和“节点选择 ”会被视作两个不同字符串。

锚点、别名与高级 YAML 写法

YAML 支持锚点和别名，可复用一组参数。例如为多个节点共享 udp、skip-cert-verify 等字段。不过，订阅转换器、覆写引擎和图形编辑器对复杂 YAML 特性的保留能力并不完全一致。经过界面保存后，锚点可能被展开为普通字段；某些合并键也可能被重新序列化。需要跨设备长期维护时，优先选择清晰的显式字段。锚点适合手工维护的独立文件，不适合依赖频繁远程更新的订阅正文。

注释同样可能在图形化保存或订阅更新后丢失。重要维护说明不要只写在订阅缓存里，可以把规则意图和来源记录在独立文档，或把自定义内容放入稳定的覆写文件。FlClash 负责加载与管理配置，mihomo 内核负责解释实际字段；出现“界面能看到但内核未采用”的情况，应先查看运行日志中的解析提示，再确认最终生效配置，而不是只检查原始订阅文本。

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

监听端口怎样分工

port 是 HTTP 代理监听端口，socks-port 是 SOCKS5 代理监听端口，mixed-port 则在同一端口接受 HTTP 与 SOCKS5。桌面环境通常只需启用 mixed-port，便于系统代理和不同应用共用一个入口。多个监听字段可以并存，但端口号不能互相冲突，也不能被其他程序占用。若 FlClash 界面负责分配端口，手工配置中的值还可能被客户端覆写；排查时应查看最终监听地址与运行日志，而不是只依据编辑器里的原始数字。

redir-port、tproxy-port 等字段服务于透明代理链路，通常由 Linux 防火墙规则、路由器环境或特定接管方式使用。普通桌面用户不应为了“更全面”而同时开启所有端口。端口只是接收流量的入口，不会自动修改系统路由。系统代理模式需要操作系统把支持代理的应用导向 HTTP 或 SOCKS 端口；TUN 模式则创建虚拟网络接口接管更广泛的流量，两者的权限、覆盖范围和排错方法不同。

mixed-port: 7890
allow-lan: false
bind-address: "*"
mode: rule
log-level: info
ipv6: false
unified-delay: true
tcp-concurrent: true
find-process-mode: strict

allow-lan 与监听边界

allow-lan 控制局域网设备能否连接本机代理端口。设为 false 时，常用于仅供本机应用使用的桌面配置。设为 true 后，还需要正确设置监听地址，并确认操作系统防火墙允许相应端口。此字段不会自动为其他设备填写网关或代理地址，也不会替代访问控制。若确需向局域网提供代理，应使用固定的内网地址、限制可信网段，并设置身份验证；不要把监听端口直接暴露到公网。

bind-address 决定监听绑定范围。通配地址表示在可用接口上监听，具体地址则把入口限制在指定网卡。移动设备切换 Wi‑Fi 与蜂窝网络时，接口变化可能导致原绑定地址失效。局域网共享场景出现“本机可用、其他设备拒绝连接”，应依次检查 allow-lan、绑定地址、防火墙、设备是否位于同一网段，以及代理类型是否填写正确。连接成功但无法访问目标站点，则继续检查策略组、DNS 与出站节点。

三种运行模式

mode: rule 按规则列表决定流量去向，是日常配置的主要模式。global 把流量交给全局策略，适合临时验证节点是否可用；direct 让流量直连，适合快速判断问题是否由代理链路引起。模式切换不会删除规则，只是改变决策入口。排错时可短暂切换：全局模式正常而规则模式异常，通常说明规则命中或策略引用有误；直连模式也异常，则应检查本地网络、DNS 或系统接管状态。

log-level 常见值包括 silent、error、warning、info 和 debug。日常使用保持 info 通常足够；定位规则命中、DNS 查询或握手问题时可临时提高到 debug。详细日志会显著增加输出量，也可能包含目标域名、节点地址等运行信息，问题处理完成后应恢复常规级别。日志中的第一条错误往往比后续连锁错误更有价值，应从配置载入、监听启动、DNS 初始化和代理握手的先后顺序阅读。

延迟测量、并发连接与进程识别

unified-delay 用于统一延迟测试口径，使不同代理类型的测试结果更便于比较。测速结果表示测试 URL 与当前网络条件下的一次连接表现，不等同于所有网站的固定延迟。tcp-concurrent 允许对目标地址的多个候选连接进行并发尝试，在双栈或多地址场景可能缩短建立连接的等待，但会产生额外连接尝试。网络受限、路由器资源紧张或需要严格控制连接数时，可以关闭并对照测试。

find-process-mode 影响内核获取连接所属进程的方式。进程规则依赖操作系统能力和运行权限，在不同平台上的可用程度并不一致。Android、macOS、Windows 与 Linux 对进程路径、包名和权限的表达不同，因此同一条进程规则不应被假定为跨平台完全等价。若规则以域名或 IP 就能完成分流，通常优先采用网络层条件；确实需要按应用区分时，再结合目标平台验证进程名。

DNS 字段：解析路径、Fake-IP 与分流一致性

DNS 配置解决的不是单一“解析速度”

代理环境中的 DNS 同时承担域名解析、规则判断、节点服务器地址解析和防止请求绕开预期链路等任务。dns.enable 开启内核 DNS 模块后，查询可以按照配置进入指定上游；但系统是否把全部查询交给内核，还取决于 TUN、系统 DNS 设置或应用自身行为。浏览器可能启用独立的加密 DNS，某些应用可能缓存地址或直接请求固定 IP。出现解析结果与规则不一致时，应先画清楚查询路径：应用向谁提问、内核使用哪个上游、节点服务器域名由谁解析、最终连接又命中了哪条规则。

nameserver 是主要解析服务器列表，通常用于普通域名查询。default-nameserver 常用于解析加密 DNS 服务器自身的域名，避免“要连接 DNS 服务器，先得解析 DNS 服务器域名”的循环依赖，因此这里通常放置可直接访问的 IP 形式服务器。proxy-server-nameserver 可专门解析代理节点服务器域名，使节点地址解析与普通业务域名分离。direct-nameserver 则可为明确直连的域名提供单独解析路径。是否需要全部配置，应按实际网络拓扑决定，不是字段越多越稳定。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
    - "+.stun.*.*"
  default-nameserver:
    - 1.1.1.1
    - 8.8.8.8
  nameserver:
    - https://dns.google/dns-query
    - tls://1.1.1.1
  proxy-server-nameserver:
    - https://dns.google/dns-query
  respect-rules: true

Fake-IP 与 Redir-Host 的差异

enhanced-mode: fake-ip 会先向应用返回保留地址池中的映射地址，内核随后依据映射恢复原域名并进行规则判断。这样即使应用只把目标 IP 交给网络层，内核仍能保留域名信息，域名规则与嗅探配合通常更直接。fake-ip-range 指定映射地址池，不应与本地实际网段、容器网段、企业 VPN 网段重叠。发生内网地址冲突时，表现可能是特定网段无法访问，而不是所有连接都失败。

redir-host 更接近传统的真实地址解析：应用获得目标域名的实际 IP，内核再基于可用信息处理流量。它对某些不接受 Fake-IP 的设备发现、局域网服务或特殊协议更直观，但域名信息可能在后续连接阶段丢失，规则判断更依赖 DNS 缓存与嗅探。选择模式时应围绕应用兼容性和规则准确性，不必把某一种写成普遍结论。多数问题可以先使用 Fake-IP，再把明确不兼容的域名加入过滤列表，而不是直接放弃域名映射能力。

fake-ip-filter 应保持可解释

过滤列表中的域名会绕过 Fake-IP 映射，获得真实解析结果。局域网发现、时间同步、STUN、部分游戏平台与设备配网场景可能需要过滤。添加前应有明确症状与验证方法：例如应用只在 Fake-IP 下无法发现同网段设备，加入对应域名后恢复。不要把大范围顶级域名或通配规则随意塞入过滤列表，否则大量请求会退回真实地址解析，域名规则的可观察性下降，也可能造成不同设备上的表现分裂。

通配写法需要区分精确域名、单层通配与后缀匹配。不同字段对通配语义的支持范围可能不同，不能把规则列表中的 DOMAIN-SUFFIX 语法直接复制到过滤列表。修改后应清理应用 DNS 缓存，重新建立连接，并在日志中确认查询是否进入预期上游。只刷新网页可能继续使用浏览器连接池和旧缓存，造成“配置没有变化”的误判。

规则分流与 DNS 上游选择

respect-rules 让 DNS 请求在适用情况下遵循规则体系，但这也要求用于 DNS 的代理策略能够在解析完成前建立，避免递归依赖。例如代理节点服务器写的是域名，而连接加密 DNS 又必须经过该代理，此时节点域名需要由 proxy-server-nameserver 或可直接访问的引导解析器先解析。设计时应把“节点地址解析”和“业务域名解析”分开，确保最底层总有一条不依赖尚未建立代理的解析路径。

nameserver-policy 可以按域名选择特定上游，适合企业内网域名、局域网服务或需要固定解析来源的区域。策略应尽量窄：先匹配明确后缀，再保留通用 nameserver 作为兜底。若同一域名可能同时命中多条策略，应检查匹配优先级和最终日志。对于通过规则提供者维护的域名集合，还需确认规则集行为与 DNS 策略字段是否支持对应引用方式。

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.google/dns-query
  nameserver-policy:
    "+.internal.example":
      - 192.0.2.53
    "geosite:private":
      - system
  direct-nameserver:
    - system
  direct-nameserver-follow-policy: true

常见故障可按层拆分。域名完全无法解析，检查 DNS 监听、上游可达性和证书时间；能解析但无法连接，检查规则策略与节点；只有节点域名失败，检查引导解析和 proxy-server-nameserver；局域网设备异常，检查 Fake-IP 地址池冲突和过滤项；偶发新旧结果混用，则清理系统、浏览器与内核缓存。更完整的故障路径可继续查阅常见问题中的 DNS 与连接分类。

代理节点字段：公共属性、协议参数与传输层

所有节点都从名称、类型与服务器开始

proxies 是手工节点序列。每个节点至少需要唯一的 name、协议 type、服务器 server 和端口 port，再补充协议所需认证字段。节点名称是策略组和规则引用的主键，应保持稳定。订阅更新时若上游改变名称，手工策略组可能出现悬空引用，因此自动订阅更适合通过代理提供者和筛选规则组织，而不是把大量动态节点名称写死在策略组中。

server 可以是 IP 或域名。使用域名便于服务端迁移，但要求节点地址解析链路稳定；使用 IP 可减少一次解析，却无法自动跟随地址变化。udp 控制节点是否承载 UDP，实际可用性还取决于协议、服务端和网络路径。interface-name 或路由标记类字段可把连接绑定到特定出口，适用于多网卡环境，但在移动设备切网后可能失效。除非确有多出口需求，不应把平台相关字段固化到跨设备配置。

proxies:
  - name: "办公 SOCKS"
    type: socks5
    server: proxy.example.com
    port: 1080
    username: "your-user"
    password: "your-password"
    udp: true

  - name: "示例 HTTP"
    type: http
    server: gateway.example.net
    port: 8443
    username: "your-user"
    password: "your-password"
    tls: true
    skip-cert-verify: false

TLS 字段与服务器身份

支持 TLS 的协议通常包含 tls、servername、skip-cert-verify、ALPN 或指纹相关选项。servername 用于 TLS 握手中的服务器名称，应与服务端证书和部署配置一致，不等同于随意填写的伪装域名。skip-cert-verify: true 会跳过证书有效性验证，只适合明确受控的测试环境；正常配置应保留验证，并修正系统时间、证书链、服务器名称或中间网络干扰。连接日志出现证书名称不匹配时，应先核对订阅参数，不要用关闭验证掩盖配置错误。

WebSocket、gRPC、HTTP/2 等传输参数通常嵌套在各协议对应的选项中。路径、Host、服务名与请求头必须和服务端一致。字段看似相近，层级却可能不同，例如 WebSocket 的路径不会因为写在节点根层就自动生效。迁移其他客户端配置时，不能只按中文标签逐项复制，应对照 mihomo 支持的节点结构。订阅由服务提供方生成时，优先保留原始传输参数，只在确认服务端要求后修改。

常见协议字段不能互相套用

Shadowsocks 节点核心字段是 cipher 与 password；Trojan 以密码、TLS 服务器名称和传输参数为主；VMess 通常需要 uuid、加密选项与传输配置；VLESS 需要 UUID，并可能包含 flow、Reality 或其他扩展字段；Hysteria2 与 TUIC 还涉及基于 UDP 的传输、拥塞控制或带宽参数。每种协议都应按自身结构填写。把某协议的认证字段放入另一协议不会产生兼容层，通常只会被忽略或导致载入失败。

协议能力由 mihomo 内核提供，FlClash 提供配置管理和跨平台界面。某字段在内核中存在，不代表每个平台的系统网络条件都相同。例如基于 UDP 的协议可能受到公共 Wi‑Fi、企业网络或运营商路径限制；TUN 权限和后台运行也会影响移动端体验。验证节点时应先使用简单的连通性测试，再观察握手日志。节点测速失败并不必然说明订阅失效，也可能是测试地址不可达、DNS 未就绪、UDP 被限制或策略形成循环。

节点名称、敏感字段与分享边界

节点配置包含服务器地址和认证信息，不应直接贴入公开问题页面。排错时可以保留字段结构，把地址替换为 proxy.example.com，把密码或 UUID 替换成明显的测试值，同时保留协议类型、层级和布尔字段。不要只截取一行报错而隐藏上下文，因为很多问题来自缩进或父字段。也不要在公开文本中留下订阅 URL；订阅链接通常具备访问凭据属性，泄露后应到服务端重置，而不是只从帖子中删除。

同名节点会让策略引用和界面选择变得不确定。手工配置应保证唯一名称；从多个代理提供者聚合节点时，可在覆写阶段添加来源前缀或后缀。名称过滤使用正则表达式时，需要考虑括号、加号和其他元字符。先用少量节点验证筛选表达式，再应用到完整订阅。若需要重新选择图形客户端，下载中心按平台列出 Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu 等选项，其中 Clash Plus 为全平台首推入口。

策略组字段：选择、自动测试、故障转移与链式引用

策略组是规则与节点之间的决策层

proxy-groups 把节点、内置动作和其他策略组组织为可引用的出站集合。规则通常不直接写具体节点，而是指向“节点选择”“自动选择”“国外流量”之类的稳定策略名称。这样订阅节点变化时，只需更新组内候选，不必重写全部规则。每个组至少包含 name 和 type，候选来源通过 proxies 明确列出，或通过 use 引用代理提供者。

select 允许用户手动选择候选项，适合作为顶层总入口。候选中可以同时放置具体节点、自动测试组和 DIRECT。组内第一个项目通常具有默认意义，但客户端也可能保存上次选择，因此调整顺序后不一定立即改变当前选项。排查“规则命中了正确组但仍走错节点”时，应同时检查策略组的当前选择和持久化状态。

proxy-groups:
  - name: "节点选择"
    type: select
    proxies:
      - "自动选择"
      - "故障转移"
      - "办公 SOCKS"
      - DIRECT

  - name: "自动选择"
    type: url-test
    proxies:
      - "办公 SOCKS"
      - "示例 HTTP"
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80
    lazy: true

  - name: "故障转移"
    type: fallback
    proxies:
      - "办公 SOCKS"
      - "示例 HTTP"
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: true

url-test、fallback 与 load-balance

url-test 定期请求测试 URL，根据结果选择表现合适的候选。interval 是测试间隔，过短会增加节点和设备负担；tolerance 提供切换容差，避免数值轻微波动导致频繁换线；lazy 允许在组未被使用时减少主动测试。测试 URL 应稳定、响应小、在目标网络可达，并能代表实际连接路径。延迟最低只说明该测试目标下建立请求较快，不表示带宽、丢包和目标网站路径一定最佳。

fallback 按候选顺序选择可用项，适合希望主节点优先、失败后切换的场景。它不是把所有请求平均分配，也不会保证现有长连接无感迁移。load-balance 在多个候选间分配连接，常见策略包括一致性散列或轮询。涉及登录会话、来源地址敏感服务时，应谨慎使用轮询，否则同一业务的不同连接可能从不同出口发出。需要稳定会话时，一致性策略或手动选择通常更可控。

代理提供者与动态候选

当节点来自远程订阅时，proxy-providers 可以把节点数据、更新周期和健康检查独立管理，策略组用 use 引用提供者。这样远程节点增删后，策略组无需逐个改名。提供者的 filter、exclude-filter 或覆写规则可以按名称筛选地区、协议或用途，但筛选依赖上游命名质量。名称不稳定时，更可靠的方法是按多个条件分层，保留一个未筛选的总组作为检查入口。

健康检查与策略组测试存在重叠。提供者级健康检查用于判断节点基本可用性，策略组的 url-test 用于候选决策。两层都设置极短间隔会产生重复流量。设备性能有限或节点较多时，可以延长提供者检查周期，让常用自动组承担更及时的测试。若所有节点同时显示不可用，应先确认测试 URL、DNS 和网络入口，不要立刻判断全部节点失效。

proxy-providers:
  remote-main:
    type: http
    url: "https://subscription.example.com/your-token"
    path: ./providers/remote-main.yaml
    interval: 21600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: "订阅节点"
    type: select
    use:
      - remote-main

  - name: "自动订阅"
    type: url-test
    use:
      - remote-main
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 100

链式引用必须避免循环

策略组可以引用其他策略组，用于构建“业务分类组 → 总选择组 → 自动测试组 → 节点”的层次。例如流媒体组既可以单独选择，也可以回落到总选择组。但任何引用链都不能回到自身。A 引用 B、B 又引用 A 会形成循环，连接无法得到最终出站。复杂配置应把底层节点组、自动组、总选择组和业务组按依赖顺序排列，并用名称体现职责。

内置策略 DIRECT 表示直接连接，REJECT 表示拒绝请求。它们可以作为策略组候选，也可以直接写在规则末尾。将 DIRECT 放入顶层选择组便于临时绕过代理，但也增加误选风险；面向固定设备的配置可以把直连交给明确规则，不必在所有业务组中重复提供。拒绝策略用于确定不需要连接的目标，使用范围过宽会造成页面资源缺失或应用功能异常，应先从窄规则开始。

规则集与 Rule Providers：拆分、更新和行为类型

为什么把大规则表拆出主配置

rule-providers 用于声明可独立加载和更新的规则集。主配置只保留提供者名称、来源、缓存路径、更新周期和行为类型，再通过 RULE-SET 规则引用。这样可以把广告拒绝、局域网直连、特定服务、区域域名等不同职责拆开，减少主文件长度，也便于分别更新。规则集不是策略组，它只提供匹配条件；命中后走哪个策略，仍由主配置中的 RULE-SET,提供者名,策略名 决定。

提供者常见 type 为 http 或 file。远程类型需要 url、本地缓存 path 和更新 interval；本地类型读取设备上的文件。缓存路径应彼此唯一，避免两个提供者覆盖同一文件。远程更新失败时，内核通常会继续使用已有缓存，但首次载入且没有缓存时可能无法使用该规则集。关键直连规则可以保留少量内置兜底，不应让基础联网完全依赖一个尚未成功下载的远程文件。

rule-providers:
  private-domain:
    type: http
    behavior: domain
    format: yaml
    path: ./rules/private-domain.yaml
    url: https://rules.example.com/private-domain.yaml
    interval: 86400

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

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

behavior 决定规则载荷怎样解释

domain 行为用于域名集合，载荷通常是完整域名、域名后缀或受支持的域名表达式；ipcidr 用于 IPv4、IPv6 网段；classical 则允许规则集中的每一项携带传统规则类型，例如 DOMAIN-SUFFIX、IP-CIDR、PROCESS-NAME。行为类型必须与文件内容一致。把带规则类型前缀的 classical 文件声明为 domain，不会自动去掉前缀并转换，通常会导致无法载入或全部不匹配。

选择行为时应优先使用最窄模型。纯域名列表使用 domain，纯网段列表使用 ipcidr，需要混合条件时再使用 classical。清晰的行为类型便于内核优化，也方便维护者判断规则是否需要 DNS 解析。不要因为 classical 能容纳更多格式，就把所有规则都塞入一个巨大文件；按职责和数据类型拆分，排查命中时更直接。

规则集文件格式与载荷

YAML 规则集通常以 payload 为根键，下面是规则序列。domain 行为下，后缀表达可以匹配根域及子域；精确域名只匹配指定主机。ipcidr 行为下，应写标准 CIDR 网段。classical 行为则写完整规则条件，但不在规则集条目中附加最终策略，因为策略由主配置引用时指定。把同一个规则集交给不同策略是可行的，例如工作配置将某集合直连，旅行配置将同一集合交给代理。

# private-domain.yaml
payload:
  - "+.lan"
  - "+.local"
  - "router.example"
  - "intranet.example.org"

# private-network.yaml
payload:
  - "10.0.0.0/8"
  - "172.16.0.0/12"
  - "192.168.0.0/16"
  - "127.0.0.0/8"
  - "::1/128"
  - "fc00::/7"

format 应与远程文件实际格式一致。文本扩展名不是充分依据，下载后应检查正文结构和响应内容。远程地址返回登录页、限流提示或 HTML 错误页时，文件可能成功保存，却无法按规则集解析。日志若出现规则集格式错误，应检查最终响应而不是只检查 URL 能否在浏览器打开。需要鉴权的私有规则集还应考虑凭据更新与设备间同步，不应把真实访问参数贴入公开配置示例。

更新周期、缓存和原子性

interval 以秒表示更新间隔。规则内容每天变化一次时，没有必要每几分钟拉取。频繁更新会增加网络请求和上游压力，也更容易在短暂故障时反复报错。合理策略是让远程文件具备稳定缓存，本地继续使用上一份可解析内容，并在日志中记录更新失败。修改规则源后，可手动触发更新或清理对应缓存进行验证，但不要一次删除全部提供者缓存，否则会把单个文件问题扩大为所有规则集同时不可用。

规则集更新与主配置更新并非同一个事务。主配置先引用一个尚未下载成功的提供者时，可能出现暂时缺失；远程规则内容发生不兼容变化，也可能在下一次周期更新后才暴露。重要配置应保留简短的主规则兜底，例如私有网段直连和最终 MATCH，并把外部集合放在合适位置。规则来源应清楚、职责单一、可回退。来源不明的大型集合可能互相覆盖，最终表现为某些域名偶发走错策略。

规则语法：从上到下匹配，首条命中结束

一条规则的基本结构

rules 是有序序列。传统规则通常由规则类型、匹配内容、目标策略和可选参数组成，以逗号分隔。例如 DOMAIN-SUFFIX,example.org,节点选择 表示以 example.org 为后缀的域名交给“节点选择”。内核从第一条向下检查，命中后不再继续。因此规则设计的核心不是单条是否正确，而是范围更窄的规则是否位于范围更宽的规则之前。

MATCH 不需要匹配内容，通常写在最后，接收此前未命中的所有流量。若把它放在中间，后续规则永远没有机会执行。规则目标可以是策略组、具体节点或内置动作，但为了维护稳定，通常指向策略组。节点名称变化时，规则无需改动；只要策略组仍能提供有效候选，整个决策链就保持完整。

rules:
  # 精确域名优先
  - DOMAIN,api.example.org,DIRECT
  # 再处理整个域名后缀
  - DOMAIN-SUFFIX,example.org,节点选择
  # 关键词范围更宽，放在后面
  - DOMAIN-KEYWORD,example,节点选择
  # 私有网络直接连接
  - 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,fc00::/7,DIRECT,no-resolve
  # 最终兜底
  - MATCH,节点选择

域名规则的范围差异

DOMAIN 只匹配完整域名，适合需要单独处理的 API、登录入口或特定主机。DOMAIN-SUFFIX 匹配一个域及其子域，适合按服务整体分流。DOMAIN-KEYWORD 根据域名中是否出现关键词判断，覆盖范围更宽，也更容易误伤，例如短关键词可能出现在无关域名中。能够使用精确域名或后缀时，不应先用关键词扩大范围。

域名规则能否参与匹配，取决于内核是否掌握连接对应的域名。系统代理通常直接提供域名；Fake-IP 可以保留映射关系；仅有目标 IP 的透明连接可能需要 DNS 缓存或嗅探。若日志只显示 IP，域名规则不命中并不一定是规则拼写问题。应检查 DNS 是否由内核处理、嗅探是否适用于该协议，以及应用是否直接连接固定地址。

IP、Geo 与 no-resolve

IP-CIDR 和 IP-CIDR6 根据目标地址匹配网段。规则末尾的 no-resolve 表示不要为了执行这条 IP 规则额外解析域名，可减少不必要查询，也避免在规则阶段引入解析副作用。对于已经具有目标 IP 的连接，仍可直接判断。私有网段和本机地址通常应放在较前位置直连，避免局域网设备流量被送入远程代理。

地理数据库相关规则依赖本地数据文件及其更新状态。域名分类与 IP 地理归属是不同数据源：一个服务域名可能解析到全球分布地址，单纯按 IP 地区并不等同于按服务归类。使用 Geo 类规则时，应理解其覆盖范围，并保留针对关键业务的明确域名规则。数据库无法加载时，相关规则可能失效，而普通 DOMAIN 与 IP-CIDR 规则仍可工作，日志会提供区分线索。

进程、网络与逻辑组合

PROCESS-NAME、PROCESS-PATH 等进程规则适合按桌面应用分流，但依赖系统权限和平台实现。Android 更常见的是包名或系统提供的应用识别方式，iOS 的系统限制也不同。进程路径在 Windows 与类 Unix 系统上的表示完全不同，不能共享一条绝对路径。跨平台配置若必须包含进程规则，应按设备覆写注入，而不是把所有平台路径混入同一基础文件。

mihomo 支持的逻辑规则可组合多个条件，用于表达“同时满足”“任一满足”或“排除某项”。组合能力越强，阅读与排错成本越高。实际维护中，优先通过规则顺序表达例外：先写少量排除项，再写一般规则。只有当顺序无法清晰表达，或多个条件确实必须同时成立时，再使用逻辑组合。复杂表达式应配注释和可重复测试的目标域名，否则数月后很难判断原始意图。

规则顺序的稳定模板

一套可解释的顺序通常是：本机与局域网例外、明确拒绝项、关键业务精确规则、业务域名规则集、区域或网络规则、最终兜底。顺序不是固定答案，但每一层都应说明为何先于下一层。若某个精确域名需要直连，它必须位于包含该域名的代理后缀规则之前；若某个子域需要代理，它也必须位于整个父域直连规则之前。

验证规则时，不要依赖单次网页打开。浏览器可能复用已有连接，DNS 也可能命中缓存。修改后可关闭相关连接、清理必要缓存，再观察日志中的目标、规则类型和策略名称。若日志命中正确而出口不符，应继续沿策略组检查；若日志未显示域名，则回到 DNS 与嗅探层。规则问题、策略选择问题和节点连接问题应分层判断。

覆写与合并：让订阅更新保留本地调整

原始订阅、生成配置与最终配置

远程订阅是上游数据源，FlClash 导入后可能经过解析、覆写和内核适配，最终形成运行配置。直接编辑订阅缓存看似立即有效，但下次更新通常会被新内容替换。稳定维护应把上游负责的节点数据与本地负责的策略分开：订阅提供节点和基础组，本地覆写负责端口、DNS、组结构、规则与设备差异。发生问题时，要区分原始订阅是否正确、覆写是否按预期执行，以及最终配置是否被内核接受。

覆写不等于简单文本拼接。映射字段、序列字段和同名对象需要不同策略。映射可以按键替换或递归合并；序列可以整体替换、头部插入、尾部追加或按名称处理。若不清楚当前工具的合并语义，最安全的方法是从一个可观察字段开始测试，例如修改 mode，随后查看最终配置。不要一次加入完整 DNS、几十条规则和多个策略组，否则出现错误时难以定位是哪种合并操作造成的。

替换映射与追加序列的差别

假设原配置已有完整 dns 映射，本地覆写只写 dns.enable: true。递归合并会保留原有 nameserver 等子项，整体替换则可能只剩 enable。两种结果都符合某种“覆写”定义，因此必须以 FlClash 当前覆写类型和最终预览为准。对于关键 DNS 段，若需要完全控制结果，明确写出完整目标结构通常比依赖部分合并更稳定。

rules 是有顺序的序列。简单追加适合把 MATCH 前的补充规则放入正确位置，但若原列表已以 MATCH 结尾，把新规则追加在末尾将永远无法命中。头部插入适合局域网例外和精确覆盖；整体替换适合完全自主管理规则体系。策略组序列按名称合并时，还要确认同名组是替换、扩展还是产生重复对象。出现两个同名组会让界面和引用结果难以判断。

# 基础配置：base.yaml
mixed-port: 7890
mode: rule

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

rules:
  - MATCH,节点选择

# 本地覆写目标：override.yaml
log-level: info
ipv6: false

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.google/dns-query

规则插入需要明确位置

为订阅增加自定义规则时，先判断规则属于例外、常规分类还是兜底。例外规则通常插入头部；业务规则应放在更宽泛集合之前；兜底规则只能存在于末尾。支持脚本覆写时，可以查找原列表中的 MATCH 索引，再把新增规则插入其前方。若未找到 MATCH，应记录提示并决定是否补充，而不是默默追加后假定结构正确。

去重不能只比较整行文本。两条规则可能匹配条件相同却指向不同策略，这代表冲突而不是重复；同一域名的精确规则和后缀规则也不是重复。合理做法是先按规则类型和匹配内容识别冲突，再按本地优先级决定保留位置。自动删除前应输出可检查结果。规模较小的自定义规则，保持显式和可读通常优于过度自动化。

设备差异应放在最外层

跨平台共享配置时，节点、策略组和大部分域名规则可以共用；TUN、进程路径、网络接口、局域网监听和系统 DNS 接管则具有明显设备差异。建议维护一个平台无关的基础层，再为 Windows、macOS、Android 和 Linux 分别应用轻量设备覆写。这样不会为了兼容某个平台，把其他平台不认识或不需要的字段塞进同一文件。

例如桌面端可能需要进程规则，Android 更适合按应用能力处理；Linux 路由器可能使用透明代理端口，普通 Windows 桌面则只需要 mixed-port 或 TUN；macOS 网络扩展需要系统授权，配置字段本身无法替代权限批准。涉及平台安装和权限时，应回到快速上手与macOS 网络扩展设置说明，不要试图只靠 YAML 绕过系统要求。

订阅更新后的验证清单

更新完成后先确认订阅拉取成功，再检查节点数量与名称结构是否发生预期变化；随后确认覆写执行没有报错，最终配置中的 DNS、策略组和规则仍存在；最后启动内核，观察监听、DNS 初始化、规则提供者和代理提供者载入状态。配置载入成功后，再检查策略组当前选择，因为上游删除节点时，已保存的旧选择可能失效或回退。

自动更新失败不应通过反复缩短间隔解决。应检查订阅地址是否有效、网络是否需要经过代理、DNS 是否能解析订阅服务器、更新请求是否形成代理环路，以及客户端是否在后台被系统限制。相关分支可查阅Clash 订阅更新失败与自动更新设置。若客户端项目停止维护并需要迁移，可参考配置导出与客户端迁移清单。

可回退的维护方式

每次只修改一个职责明确的配置段，并保留上一份可用文件。命名可以体现用途与平台，例如基础层、DNS 层、规则层和设备层，但不要把动态日期或临时状态写进策略名称，否则规则引用会频繁变化。更新前记录当前策略选择，更新后验证关键域名、局域网访问、DNS 路径和一个代理目标。测试覆盖应包含直连与代理两类流量，避免只验证网页能打开。

当覆写逐渐变得难以解释，说明应该整理，而不是继续追加补丁。删除失效规则源，合并职责重复的策略组，把设备专属字段移出基础层，并为每个外部提供者记录用途。配置手册的目标不是堆满所有可用字段，而是让每次请求都能沿着“入口、DNS、规则、策略组、节点”的链路得到明确解释。完成基础配置后，可回到快速上手执行连接验证，或前往常见问题按症状继续排查。