Clash 分流规则调试技巧：查看实时匹配日志

凌晨两点十七分，我盯着屏幕上那个迟迟不肯刷新的K线图，心里只有一个念头：这笔USDT的跨链转账，到底卡在哪个环节了？

事情要从三天前说起。朋友老陈在电报群里发了一条消息，说某个新上的DeFi项目头矿收益高得离谱，但必须用特定地区的IP才能访问。我当时没多想，随手在Clash里切了个节点，结果钱包一连上就报了“区域限制”的错。更诡异的是，我明明把那条规则写进了配置文件，日志里却死活看不到它被匹配上的痕迹。

这就是我决定彻底搞懂Clash分流规则调试的起点。不是为了成为网络工程师，而是因为在这个圈子里，一条错误的规则可能意味着错过一个空投、一笔套利，或者更糟——把私钥签名请求暴露在错误的代理链路上。

那个让日志开口说话的夜晚

我打开Clash的Dashboard，点进“日志”标签页。满屏滚动的条目像加密市场的行情一样让人眼花缭乱。[TCP] connected to ...、[DNS] resolved ...、[Rule] match ...——这些字我都认识，但连在一起就像在看一份没有注释的智能合约。

问题在于，大多数教程只告诉你“把规则写进config.yaml”，却很少教你如何观察规则在运行时到底是怎么被应用的。而虚拟币世界的特殊性在于，你面对的不仅仅是网页浏览，还有钱包RPC请求、交易所API调用、链上广播节点连接，每一种流量都可能需要不同的出口策略。

我决定从最基础的实时日志过滤开始。

理解Clash日志的层级结构

Clash的日志大致分为几个级别：INFO、WARNING、ERROR、DEBUG。默认情况下，你看到的是INFO级别，它只会告诉你“连接建立了”“规则匹配了”，但不会告诉你“为什么这条规则匹配了而不是另一条”。

要调试分流，第一步是把日志级别调到DEBUG。在配置文件的log-level字段里改成debug，或者在Dashboard的设置里直接切换。然后你会看到类似这样的输出：

[DEBUG] Rule match: DomainSuffix(google.com) --> Proxy(US-LA-01) [DEBUG] Rule match: IPCIDR(1.1.1.1/32) --> DIRECT [DEBUG] Rule match: GeoIP(CN) --> DIRECT

注意那个箭头。左边是匹配条件，右边是最终采用的策略。但真正关键的信息藏在中间——Clash是按顺序逐条匹配规则的，一旦命中就停止。这意味着如果你把一条宽泛的DOMAIN-SUFFIX,google.com,PROXY放在一条精确的DOMAIN,www.google.com,DIRECT前面，后者永远不会生效。

这跟智能合约里的require语句顺序有点像：先检查的條件会先短路。

一个真实的踩坑场景：交易所API被误判

上周我在调试一个Binance的现货网格策略。脚本通过api.binance.com拉取订单簿，但总是超时。我第一反应是节点问题，换了三个地区还是一样。打开Clash的DEBUG日志后，我看到了这样一行：

[DEBUG] Rule match: GeoIP(US) --> Proxy(HK-01)

问题来了：api.binance.com的DNS解析结果是一个美国IP，而我的规则里有一条GEOIP,US,PROXY，它被匹配上了。但香港节点到Binance的美国API服务器，延迟反而比直连更高。更麻烦的是，有些交易所会对代理IP做风控，导致API Key被临时限制。

我需要的是一条更精确的规则：让所有*.binance.com的流量走直连，或者走专门优化的金融专线。于是我加了一条：

yaml rules: - DOMAIN-SUFFIX,binance.com,DIRECT - GEOIP,US,PROXY

但这里有个细节：DOMAIN-SUFFIX必须放在GEOIP前面。因为Clash的规则匹配是从上到下的，如果GEOIP,US先命中了，后面的域名规则就没机会执行了。这跟Solidity里函数修饰器的执行顺序是一个道理——顺序错了，逻辑就全反了。

用实时日志追踪一笔跨链转账

回到开头那个USDT跨链的问题。我用的是一条Polygon到Arbitrum的桥，前端界面显示“等待确认”，但钱包里的交易一直没动静。我打开Clash日志，过滤关键词bridge，看到了这样的序列：

[DEBUG] Rule match: DomainSuffix(polygon-rpc.com) --> Proxy(SG-02) [DEBUG] Rule match: DomainSuffix(arbitrum.io) --> Proxy(SG-02) [DEBUG] Rule match: DomainSuffix(api.telegram.org) --> Proxy(US-01)

看起来没问题，RPC请求都走了新加坡节点。但仔细看，api.telegram.org走了美国节点——而我的电报机器人正是用来接收交易通知的。问题在于，电报的API在某些地区会被限速，导致通知延迟，让我误以为交易卡住了。

更关键的是，我没有看到任何关于bridge.arbitrum.io的日志。这说明前端可能根本没发出请求，或者请求被浏览器缓存了。我清空缓存后重新发起，日志里终于出现了：

[DEBUG] Rule match: DomainSuffix(bridge.arbitrum.io) --> Proxy(US-01)

等等，为什么是US-01？我明明把arbitrum.io指向了SG-02。原来，bridge.arbitrum.io是一个子域名，而我的规则写的是DOMAIN-SUFFIX,arbitrum.io,SG-02，它应该匹配才对。但日志显示它走了US-01，说明有一条更靠前的规则拦截了它。

我往上翻，发现了一条DOMAIN-KEYWORD,bridge,US-01。这是我几个月前为了访问某个桥接工具加的，当时没注意它会把所有带bridge的域名都劫持到美国节点。这就是规则调试中最常见的陷阱：关键词匹配的优先级和范围。

如何用日志验证规则优先级

Clash的规则匹配遵循“首次命中即停止”的原则。要验证优先级，你可以临时在配置文件顶部插入一条MATCH,REJECT，然后观察哪些流量被拒绝了。但这太暴力，更优雅的方式是利用RULE-SET和PROXY-GROUP的嵌套。

比如，你可以为虚拟币相关流量单独建一个规则集：

yaml rule-providers: crypto: type: http behavior: domain url: "https://example.com/crypto-rules.yaml" path: ./ruleset/crypto.yaml interval: 86400

rules: - RULE-SET,crypto,CRYPTO-PROXY - GEOIP,CN,DIRECT - MATCH,PROXY

然后在CRYPTO-PROXY这个策略组里，你可以根据延迟自动选择节点。但关键在于，RULE-SET的匹配结果也会出现在DEBUG日志里，格式类似：

[DEBUG] Rule match: RuleSet(crypto) --> Proxy(JP-03)

这样你就能清楚地知道，到底是哪条规则、哪个规则集在起作用。

当DNS也来搅局

虚拟币世界里，DNS污染和劫持是家常便饭。有些交易所的域名会被解析到错误的IP，导致你连上钓鱼网站。Clash的DNS模块可以帮你排查这类问题。

在DEBUG日志里，你会看到[DNS]开头的行，比如：

[DNS] resolve api.coinbase.com --> 104.16.0.1 (via 1.1.1.1) [DNS] resolve api.coinbase.com --> 198.51.100.1 (via 8.8.8.8)

如果同一个域名解析出多个不同的IP，说明你的DNS查询走了不同的上游。Clash支持fallback和nameserver-policy，你可以为特定域名指定DNS服务器。比如：

yaml dns: nameserver: - 1.1.1.1 - 8.8.8.8 fallback: - tls://dns.google:853 nameserver-policy: "geosite:binance": - 1.1.1.1 - 8.8.8.8

这样，Binance相关的域名只会用Cloudflare和Google的DNS解析，避免被本地ISP污染。而日志里会显示[DNS]的解析路径，让你确认策略是否生效。

一个套利者的日志调试清单

如果你也在做跨交易所套利或者链上交互，下面是我总结的日志调试清单，按优先级排列：

1. 确认日志级别为DEBUG：没有DEBUG，你只能看到结果，看不到原因。
2. 过滤关键词：在Dashboard的日志搜索框里输入Rule match，只看规则匹配行。
3. 检查规则顺序：把最精确的规则放在最前面，宽泛的规则放在最后。
4. 验证DNS解析：搜索[DNS]，确认关键域名解析到了预期IP。
5. 观察策略组切换：如果用了url-test或fallback，日志里会显示节点切换的原因。
6. 留意REJECT规则：有些广告拦截规则可能会误杀交易所的API域名。
7. 用MATCH兜底：最后一条规则永远是MATCH,PROXY或MATCH,DIRECT，确保没有流量漏掉。

那个让我损失了0.3个ETH的教训

去年以太坊合并前夕，我急着把一笔ETH从交易所提到冷钱包。当时Clash的规则里有一条DOMAIN-SUFFIX,eth,REJECT——这是我之前为了屏蔽某个垃圾空投网站加的。结果交易所的提现页面域名里恰好包含了eth这个字符串，比如withdraw-eth.exchange.com。规则匹配后直接拒绝，页面一直加载失败。我以为是自己网络问题，反复刷新，最后错过了那个区块的低Gas窗口，多付了0.3个ETH的手续费。

如果当时我会看DEBUG日志，就会看到：

[DEBUG] Rule match: DomainSuffix(eth) --> REJECT

然后立刻意识到问题所在。所以现在，我养成了一个习惯：每次修改规则后，先打开日志，用curl或浏览器访问几个关键域名，确认匹配路径符合预期。

让日志成为你的链上雷达

虚拟币市场7×24小时运转，你的分流规则也必须时刻保持警觉。与其在出问题后手忙脚乱地翻配置文件，不如把实时日志当成一个雷达屏幕。你不需要时刻盯着它，但当你发现某个RPC请求变慢、某个API返回403、某个空投页面打不开时，第一时间去看日志里的Rule match行。

它会告诉你：流量走了哪条规则、匹配了什么条件、最终用了哪个节点。这三个信息，足够你定位90%以上的分流问题。

剩下的10%，通常是因为DNS缓存、浏览器连接复用，或者规则集更新不及时。而这些问题，在DEBUG日志里同样有迹可循。

现在，我的Clash Dashboard常年开着日志窗口，过滤词就两个：Rule match和[DNS]。它们像两条链上事件日志，安静地记录着每一笔流量的去向。而我要做的，只是在市场波动之前，确保每一条规则都指向正确的方向。