Clash 分流规则中的 AND 规则：多条件组合分流

凌晨两点，林澈还盯着屏幕上那根上下插针的K线。比特币刚经历完一波急跌，从六万九千美元一路砸到六万五，又在一小时内拉回六万七。他的手机震个不停，几个交易群都在喊“抄底”“跑路”“狗庄洗盘”。但他顾不上这些，因为他刚发现自己那套跑了大半年的Clash分流规则，在这个夜晚彻底乱了套。

事情起因很简单。他同时开着三个交易所的网页端、两个链上钱包的RPC节点、一个Telegram中文群、一个Discord的NFT白名单频道，还有挂在后台的某量化机器人。平时这些流量各走各的线路：交易所走美国节点，钱包走日本节点，社群走新加坡节点，量化机器人走香港低延迟节点。但今晚比特币剧烈波动时，他发现自己设在Clash里的规则像被什么东西撞碎了——币安网页卡在加载，OKX的K线半天不刷新，链上钱包广播交易时一直转圈，而Telegram群里别人发的行情截图他却能秒收。

他第一反应是节点挂了。切到Clash面板一看，延迟测试全绿。再一看连接列表，他愣住了：本来该走美国节点的币安流量，正挤在日本节点上；本该走日本节点的钱包RPC，却跑去了香港；而那个量化机器人，居然在走新加坡。他揉了揉眼睛，重新读了一遍自己的规则列表，才发现问题出在一个他半年前随手写下的配置上——他把所有带“api”字样的域名都扔进了同一个策略组，而那个策略组只根据“域名关键字”做分流，没有区分这些API到底属于谁。

这让他想起一个被很多人忽略的事实：Clash的分流规则里，最基础的DOMAIN、DOMAIN-SUFFIX、IP-CIDR、GEOIP这些，本质上都是单条件判断。你写DOMAIN-SUFFIX,binance.com,美国节点，它就看域名后缀是不是binance.com，是就走美国，不是就往下走。简单、直接、高效，但也脆弱。一旦你的需求变成“既要域名属于币安，又要目标IP不是美国Cloudflare的CDN，还要连接端口是443”，单条件规则就无能为力了。而今晚，恰恰就是这种多条件交织的场景。

他想起自己曾经在某个技术群里看到有人提过一嘴“AND规则”，当时没在意。现在他打开Clash的文档，翻到AND逻辑规则那一页，才意识到自己错过了什么。AND规则允许你把多个条件组合在一起，只有所有条件同时满足时，才会命中这条规则。比如：

yaml rules: - AND,((DOMAIN-SUFFIX,binance.com),(NETWORK,tcp),(DST-PORT,443)),美国节点

这行规则的意思是：只有当请求的域名后缀是binance.com，且使用的是TCP协议，且目标端口是443时，才走美国节点。三个条件缺一不可。林澈盯着这行配置，脑子里突然闪过一个念头：如果今晚的混乱是因为币安的API域名被CDN调度到了日本，而他的单条件规则又只看域名不看IP，那流量自然会被错误地扔进日本节点。但如果他加上IP条件的AND组合，就能强制让“币安域名+非日本IP”的流量走美国，而“币安域名+日本IP”的流量走日本——这才是真正的精细分流。

他决定动手改规则。但改之前，他先做了一件事：把当前所有连接按进程和域名导出来，一条条看。他发现几个关键问题。第一，币安网页端除了binance.com，还会请求binance.cloud、binance.me、bscscan.com，以及大量cloudflare的IP。这些请求里，有些是行情数据，有些是K线图，有些是用户认证。如果只按域名后缀分流，cloudflare的IP会被GEOIP规则捕获，走默认节点，而默认节点是香港——延迟低，但香港节点对币安的部分API有风控，偶尔会返回403。第二，他的链上钱包用的是infura.io和alchemy.com的RPC，这些域名背后是AWS和GCP的IP，而他的GEOIP规则把美国IP全扔进了美国节点，导致钱包广播交易时走美国，延迟高，偶尔超时。第三，Telegram的MTProto协议走的是TCP和UDP混合，他的规则只写了DOMAIN-SUFFIX,telegram.org,新加坡节点，但Telegram实际连接的是IP，域名解析后走的是IP-CIDR规则，结果新加坡节点没命中，流量跑去了默认的香港。

这些问题，单条件规则全都没法解决。因为它们的本质是“多个维度的条件必须同时成立”。比如钱包RPC，他希望“域名是infura.io，且目标IP不是美国，且端口是443”时走日本节点；而“域名是infura.io，且目标IP是美国，且端口是443”时走美国节点。这需要AND规则。

他打开配置文件，开始写：

yaml rules: # 币安：域名+端口+网络协议组合 - AND,((DOMAIN-SUFFIX,binance.com),(DST-PORT,443),(NETWORK,tcp)),美国节点 - AND,((DOMAIN-SUFFIX,binance.com),(DST-PORT,80),(NETWORK,tcp)),美国节点 # 币安CDN：域名+IP段组合，避免CDN调度到日本 - AND,((DOMAIN-SUFFIX,binance.com),(IP-CIDR,104.16.0.0/12)),美国节点 # 钱包RPC：域名+非美国IP，走日本 - AND,((DOMAIN-SUFFIX,infura.io),(NOT,((IP-CIDR,0.0.0.0/0,no-resolve)))),日本节点

写到最后一条时他停住了。NOT和IP-CIDR的组合在Clash里需要谨慎，因为IP-CIDR默认会触发DNS解析，而no-resolve又会让规则失效。他想了想，换成更稳妥的写法：

yaml - AND,((DOMAIN-SUFFIX,infura.io),(NETWORK,tcp),(DST-PORT,443)),日本节点 - AND,((DOMAIN-SUFFIX,alchemy.com),(NETWORK,tcp),(DST-PORT,443)),日本节点

这样至少保证了钱包RPC走日本，而日本节点对以太坊RPC的连通性一直不错。

改完规则，他重启Clash，重新打开币安网页。这一次，K线加载速度明显快了，订单簿的深度数据也不再卡顿。他切到钱包，广播了一笔小额转账，三秒内就返回了txhash。Telegram群里有人发了一张比特币清算热力图，他点开，秒开。量化机器人的日志里，延迟从之前的180ms降到了45ms。

他靠在椅背上，看着屏幕上跳动的K线，突然觉得这件事很有意思。虚拟币交易本身就是一个多条件交织的场景：你要低延迟，所以要选近的节点；你要防风控，所以要选干净的IP；你要稳，所以要避开拥堵的线路；你还要快，所以不能让流量绕地球一圈。而Clash的AND规则，恰好给了你把这些条件组合起来的权力。它不是简单的“如果A就走B”，而是“如果A且B且C，才走D”。这种逻辑在传统代理工具里很少见，但在币圈这种对网络敏感的环境里，简直是救命稻草。

他想起白天在某个NFT群里看到有人抱怨：“为什么我 mint 的时候总是失败？明明节点延迟很低。”底下有人回复：“你试试把AND规则加上，让mint的流量走独立IP，别和网页浏览混在一起。”当时他没在意，现在才明白，那个人的意思是：mint交易需要的是“域名是合约地址+端口是443+网络是TCP+目标IP不是被标记的CDN”这样的组合条件，而不是简单的“域名后缀是opensea.io”。

他继续往下想。其实AND规则还能玩出更多花样。比如，你可以把“时间”作为条件吗？Clash本身不支持时间条件，但你可以通过外部脚本动态生成规则。再比如，你可以把“进程名”和“域名”组合起来：AND,((PROCESS-NAME,chrome.exe),(DOMAIN-SUFFIX,binance.com)),美国节点——这样只有Chrome访问币安才走美国，其他浏览器访问币安走默认。这在多账户操作时特别有用，因为不同浏览器可能对应不同的交易所账户，而不同账户的风控策略不同。

他又想到一个场景：套利。很多量化团队会同时跑多个交易所的API，用AND规则可以精确控制每个交易所的流量走向。比如币安走美国，OKX走日本，Bybit走新加坡，Coinbase走德国。每个交易所的API域名不同，端口不同，甚至协议不同（有的用WebSocket，有的用REST）。你可以为每个交易所写一组AND规则，把域名、端口、协议、IP段全部组合进去，确保流量不会串线。一旦串线，轻则延迟增加，重则触发风控，甚至被封号。

凌晨四点，比特币开始反弹，从六万五拉回六万八。林澈的量化机器人在这波反弹里抓到了两笔套利，利润不多，但足够覆盖他今晚的折腾。他打开Clash的日志，看着一条条AND规则命中记录，突然觉得这玩意儿比K线还有意思。K线是市场的情绪，而AND规则是他自己的情绪——他想要什么，他就组合什么。他想要币安快，他就把币安和TCP、443、美国IP绑在一起；他想要钱包稳，他就把钱包和日本、443、TCP绑在一起。这种掌控感，在币圈这种充满不确定性的地方，显得格外珍贵。

他关掉电脑，躺在床上，脑子里还在想：明天要把Discord的NFT频道也加上AND规则，让语音流量走UDP，文字流量走TCP，图片流量走CDN。这样就不会因为语音卡顿而错过白名单了。想着想着，他睡着了。窗外天快亮了，比特币的K线还在跳，而他的Clash规则，已经悄悄进化了一层。