01 · RULES
按顺序匹配域名、IP 与兜底规则
规则模式的重点不是规则数量,而是匹配顺序。域名规则通常放在 IP 类规则之前,广告分类、指定域名与局域网地址应优先处理,最后再由 MATCH 接住未命中的连接。客户端的规则页适合确认当前配置包含哪些规则,并查看连接最终进入了哪个策略组。
修改配置时,要同时检查规则名称与策略组名称是否完全一致。规则指向不存在的策略组会导致载入失败,过早出现的宽泛规则则可能让后续规则失去作用。与只提供开关的普通代理工具相比,Clash 的规则链允许把域名、地理数据和进程等条件组合成清晰、可复查的流量路径。
查看协议与规则参考 →
config.yaml · rules
已载入
DOMAIN-SUFFIX github.com节点选择
DOMAIN-KEYWORD google节点选择
GEOSITE category-ads-allREJECT
GEOIP CNDIRECT
MATCH 兜底节点选择
02 · ROUTING
区分系统代理与 TUN 模式
系统代理会把本机代理地址写入操作系统设置,适合浏览器和主动读取系统代理的桌面应用。终端程序、部分游戏和自行管理网络连接的软件可能忽略这项设置。遇到浏览器可用而命令行不通时,先确认应用是否遵循系统代理,再决定配置环境变量或使用覆盖范围更广的 TUN 模式。
TUN 模式通过虚拟网络接口接管流量,适合需要统一处理更多应用的场景,但也更依赖权限、路由和 DNS 设置。两种方式不需要同时反复开关。先从系统代理开始,确认配置和节点工作正常,再根据应用覆盖范围启用 TUN,排查时会更容易定位问题所在。
阅读连接步骤 →
网络设置
本机
系统代理 写入操作系统代理设置
TUN 模式 通过虚拟网络接口接管连接
允许局域网连接 允许同一网络中的设备访问
混合端口 HTTP 与 SOCKS 共用入口 7890
IPv6 按当前网络环境决定
03 · DNS
把域名解析纳入同一条分流链
规则以域名为条件时,DNS 处理方式会直接影响匹配结果。客户端可把查询交给内核处理,并根据规则选择解析路径。若操作系统、浏览器和客户端分别使用不同的解析方式,可能出现域名命中与预期不一致、连接绕过代理或解析结果缓存未更新等现象。
排查 Clash DNS 泄漏时,不应只看一个测试页面。先确认当前模式、配置中的 DNS 开关、浏览器安全 DNS 设置和系统缓存,再检查日志里是否出现相应查询。修改 nameserver、fallback 或 fake-ip 相关配置后,需要重新载入配置,并关闭已有连接重新测试。这样才能区分旧缓存、浏览器独立解析与内核配置问题。
查看 DNS 常见问题 →
DNS 配置
mihomo
enable true
listen 0.0.0.0:1053
enhanced-mode fake-ip
respect-rules true
ipv6 false
解析方式需要与规则模式、网络环境和应用行为一起检查。
04 · LOGS
用日志确认连接走向
日志页适合回答三个问题:请求是否进入内核、命中了哪条规则、最终使用了哪个策略。排查时先把日志级别保持在常规信息范围,再复现一次问题。大量调试行并不会自动带来更清晰的结论,反而可能淹没关键连接。按时间、域名和错误关键词缩小范围通常更有效。
如果日志里完全没有目标连接,问题多半发生在流量进入 Clash 之前,应检查系统代理、TUN 权限或应用自己的代理设置。若日志显示规则命中正确但连接失败,再检查策略组选择、订阅状态和目标网络。把入口、匹配、出口分成三段查看,比反复更换节点更容易找到稳定原因。
阅读浏览器与终端排查流程 →
运行日志
INFO
10:21:08 INFO 配置文件载入完成
10:21:11 INFO 系统代理设置已更新
10:21:17 INFO github.com 命中 DOMAIN-SUFFIX
10:21:17 INFO 策略:节点选择
10:21:24 INFO 规则模式连接已建立