规则分流在 Clash 里扮演什么角色？
当你把 Clash 的工作模式设为 rule 时，每一次连接请求都会按顺序扫过 rules 列表：先匹配到的规则先生效，后面的同名目标不再参与判断。这个「自上而下」的逻辑看似简单，却是绝大多数「为什么这个站没走代理」「为什么游戏延迟异常」的根源。理解分流，本质上是理解：流量如何被分类，以及每一类流量被交给哪个策略组或直连。
与「全局代理」或「全局直连」相比，规则分流的优势在于精细与省流：国内业务走直连降低延迟，境外站点走代理突破限制；局域网与设备管理流量可以显式直连，避免误伤。要搭好这套体系，你需要同时掌握三类拼图——域名与 IP 规则写法、GeoIP 与地理库、以及代理策略组的类型与参数。下文按实战顺序展开；更完整的客户端与文档入口可参考本站 使用文档。
匹配顺序：最容易被低估的一条铁律
Clash 不会对规则做「自动优化排序」。你把广告拦截写在最后，它就永远轮不到；你把 MATCH 写在中间，后面的规则全部失效。因此维护配置文件时，请固定遵循一种心智模型：从最具体到最笼统。典型顺序是：局域网与特殊直连域名 → 明确要拒绝或直连的域名或 IP → 国内 IP 或 GeoIP 直连 → 境外或剩余流量走代理，最后用 MATCH 兜底。
若你使用 rule-providers 或 RULE-SET 引用外部规则集，同样要记住：主 rules 数组里的先后顺序决定优先级，而不是「规则文件名字母序」。多人协作时建议在注释（英文注释即可）或独立文档里写清分层意图，避免合并订阅时把大段规则插到错误位置。关于内核与规则集加载，可对照 mihomo 迁移与 rule-providers 说明 一文中的相关段落。
域名类规则：DOMAIN 与 DOMAIN-SUFFIX 怎么用？
DOMAIN 匹配完整主机名，适合单域名精确指向，例如某 API 网关。DOMAIN-SUFFIX 匹配后缀，是最常用的写法：DOMAIN-SUFFIX,google.com,Proxy 会覆盖 www.google.com、mail.google.com 等所有子域。若你只写 DOMAIN,google.com，则通常只命中 google.com 本身，子域需另写或使用后缀规则。
DOMAIN-KEYWORD 按子串匹配，覆盖面大但容易误伤：关键词若过于简短，可能把无关域名一并送进代理或直连。适合明确品牌词且不易冲突的场景；不确定时优先用语义更清晰的 DOMAIN-SUFFIX 或规则集。DOMAIN-REGEX 用正则表达复杂模式，可读性与性能成本都更高，仅在规则集或批量生成场景下使用更合适。
# Examples — order matters in your real config
rules:
- DOMAIN-SUFFIX,github.com,Proxy
- DOMAIN-KEYWORD,youtube,Proxy
- DOMAIN-SUFFIX,cn,DIRECTIP-CIDR 与「先域名后 IP」的现实
IP-CIDR 与 IP-CIDR6 按网段匹配目标 IP。要注意：许多连接在规则匹配时已经历 DNS，若你使用 fake-ip，部分场景下会先按域名规则命中；若域名未命中，解析得到的 IP 再参与 IP 规则。若出现「域名规则写了代理，但实际仍直连」之类现象，往往要结合 DNS 模式、fake-ip 过滤列表与 IP 规则一起查。
SRC-IP-CIDR 按源地址匹配，适合多网卡、局域网分段或指定设备走不同出口的场景。家庭用户较少用到，但在软路由或旁路由上很常见。编写 IP 规则时请使用无歧义的 CIDR 写法，并避免与 GeoIP 规则重复劳动——同一目标既写长串 IP 又写 GeoIP，会增加维护成本。
GeoIP 规则：国家代码与数据库更新
GEOIP 根据目标 IP 归属地判断是否命中，常见写法为 GEOIP,CN,DIRECT，表示中国大陆 IP 直连。它的前提是本地 GeoIP 或 mmdb 数据足够新：库过旧时，CDN 或 Anycast 节点的归属可能判断不准，表现为偶发走错线路。使用 mihomo 等内核时，建议在配置中启用 geodata-mode 或定期更新 geoip.dat / country.mmdb，并与 geox-url 镜像源策略一致。
与 GeoSite（按域名分类的地理/用途集合）配合时，常见模式是：GEOSITE,cn,DIRECT 与 GEOIP,CN,DIRECT 双保险——前者偏域名列表，后者兜 IP。二者顺序若放反，可能让部分域名先被送进代理，直到 IP 阶段才直连，徒增延迟；一般以「先域名分类、再 IP / GeoIP」更直观，但仍需结合你的 DNS 与 fake-ip 策略整体调试。
# Illustrative — adjust groups to your profile
rules:
- GEOSITE,cn,DIRECT
- GEOIP,CN,DIRECT
- GEOIP,private,DIRECT
- MATCH,Proxy代理策略组：不止「手动选节点」
select 类型由用户或 UI 手动选择最终节点或嵌套组，适合「主备线路切换」「按场景选区」等明确决策。它的优点是行为可预测；缺点是需要人工介入或依赖外部脚本切换。
url-test 在候选节点中周期性探测延迟，自动选用当前最优。适合日常「省心」上网：注意合理设置 url、interval 与 tolerance，避免过于频繁的探测触发风控或浪费流量。fallback 按列表顺序找第一个可用节点，更像故障转移而非比延迟，适合对稳定性敏感、能接受非最低延迟的场景。
load-balance 在多条链路上分配连接，需内核与策略支持；并非所有订阅场景都适用，错误配置可能导致会话漂移。若你只是普通浏览与视频，url-test 往往更直观。relay 链式转发，用于指定「入口 → 中转 → 落地」的路径，进阶用户使用，配置错误时排错路径较长。
proxy-groups:
- name: Proxy
type: select
proxies:
- Auto
- HK
- JP
- DIRECT
- name: Auto
type: url-test
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 50
proxies:
- node-a
- node-b最佳实践：分层、可维护、可回滚
第一，把策略组当作「产品界面」来设计：顶层只暴露少量组名（如「自动」「直连」「手动 HK」），具体节点藏在下层，减少改规则时的心智负担。第二，规则与订阅解耦：订阅负责提供节点列表，本地文件负责分流与兜底；这样换订阅商时不至于重写半套分流逻辑。第三，为关键业务保留验证方式：例如定期用日志或面板确认某域名命中了哪条规则，避免「以为直连其实走了代理」长期未察觉。
第四，慎用过于激进的 REJECT：拦截广告与追踪的规则集很便利，但误杀会导致应用异常；遇到问题时先临时放宽规则定位，再收紧。第五，移动端与桌面端分开档案：同一套规则在手机上可能因 DNS 或 IPv6 行为不同而表现不一，必要时为移动设备单独准备一份精简规则。
DIRECT，否则易出现应用无限重试、耗电或日志刷屏。
排查思路：从日志与命中顺序入手
当某个站点行为异常时，建议按顺序检查：当前 mode 是否为 rule；该请求在日志中的域名解析结果；第一条命中的规则类型（DOMAIN、GEOSITE、GEOIP 等）；以及最终策略组解析到的节点是否在线。多数问题出在规则顺序、DNS 与 Geo 数据三者之一。若你使用 TUN 模式，还要确认分流与 DNS 是否形成环路，可与 文档中的网络模式说明 对照排查。
相比在 YAML 里堆上千行内联规则，更推荐把大库交给 rule-providers 维护，本地只保留少量「个人覆盖」规则并放在靠前位置。这样升级内核或换客户端时，你的核心意图仍然清晰可迁移。
把分流策略稳定跑在客户端里
规则写得再漂亮，也需要一款能长期跟进内核、清晰展示策略组与命中日志的客户端来落地。相比仅依赖手工改文件，图形化查看「当前节点」「延迟测试结果」与「规则是否加载成功」，能显著降低排错成本；在 mihomo 等现代内核上，可视化编辑与一键更新规则集也已成为常态能力。
若你希望少折腾 YAML、把精力留在「分流策略是否合理」而不是「缩进是否对齐」，可以选择与当前内核深度整合、且持续维护的 Clash 客户端。相比零散工具链，一体化产品在订阅更新、内核升级与策略调试上往往更省心，也更适合作为长期默认环境。