深入解析 Clash for Windows 的规则与策略组设置（进阶但好懂）
Clash for Windows（CFW）的“规则（rules）+策略组（proxy-groups）”决定了应用如何分流与选路。理解两者关系与匹配顺序，能显著提升稳定性与速度。
一、规则的核心逻辑
匹配顺序：从上到下，先匹配先生效；未匹配的会落到最后的 FINAL 规则。
常见匹配类型：
– DOMAIN-SUFFIX/DOMAIN-KEYWORD/DOMAIN：按域名后缀、关键字或完整域名匹配。
– GEOIP：按目的 IP 的国家/地区库匹配（如 GEOIP,CN → 直连）。
– IP-CIDR/IPC6-CIDR：按网段匹配（常用于内网/企业网段）。
– PROCESS-NAME/DST-PORT：按进程名或目标端口匹配（高级用法）。
– 书写建议：把“准确且范围小”的规则放前面，“范围大”的在后；广告/拦截规则优先，直连白名单第二，代理类规则第三，最后是 FINAL。
二、策略组的类型与用途
– select：手动选择具体节点或其他组，适合“手工切换、稳定优先”。
– url-test：定期探测指定 URL，自动选择延迟最低的节点，适合“稳定追求速度”。
– fallback：按顺序尝试节点，前者失效才切换，适合“高可用”。
– load-balance：对并发请求做负载均衡，适合下载/并发场景（注意部分站点登录态可能不友好）。
– 常见分组体系（示例）：GLOBAL（总入口）→ [Media、AI、Game、Social、Default] → [url-test 或 select 节点]；DIRECT 用于本地/内网/银行等敏感站点。
三、规则与策略组如何协同
– 规则只决定“走哪个策略组”，最终由策略组选出“哪个节点”。
– 实战顺序：先设计分组（如 Default 走 url-test，Media 走专用节点、CN 直连），再编写规则把“域名/IP/国家”引流到对应组。
– FINAL 的去向：通常指向 Default 组，避免漏网流量误走代理或直连。
四、DNS 与 TUN 的影响
– 若启用 TUN，更多非浏览器流量会进入 Clash；规则覆盖需要更完整（如游戏/客户端）。
– DNS 建议使用 DoH/可信 DNS，结合 fake-ip 或 redir-host 模式；避免因 DNS 污染导致规则命中异常。
– 观察 Connections 与 Logs，可以验证请求是否按预期命中规则与分组。
五、落地的最佳实践
– 分组命名清晰：DIRECT、Default、Media、AI、Game、AdBlock、Apple/Microsoft 等。
– 规则分层：先拦截（广告/恶意）→ 再直连（内网/银行/常见国区）→ 再代理（媒体/社交/AI）→ 最后 FINAL。
– Provider 管理：使用规则提供器（rule-provider）定期更新流行规则集，同时保留少量自定义覆盖。
– 控制复杂度：从“少即是多”开始，先保证 80% 场景可用，再逐步加精细化规则。
– 排错流程：遇到命中异常→ 查看 Logs 匹配结果→ 临时提高规则优先级或加显式域名条目→ 验证后再沉淀到长期配置。
把握“规则决定去哪个组，组决定用哪个节点”的核心逻辑，结合合理的组类型与规则顺序，你就能在稳定、速度与易用性之间找到最佳平衡。建议从简单分组与少量关键规则起步，借助日志验证，再逐步完善为更高级的规则体系。