Clash 分流规则中的 NO-RESOLVE 选项：加速直连

凌晨三点十七分，我的Telegram频道突然炸了。

一条消息被疯狂转发：“老铁们，币安提币卡了四十分钟了！有没有人跟我一样？”紧接着是第二张截图，显示的是某链上浏览器的pending状态，红色感叹号刺眼得吓人。我正躺在出租屋的床上刷手机，看到这条消息时，后背瞬间出了一层冷汗——因为就在十分钟前，我刚把一笔不小的U转进了一个新钱包，准备去抢一个即将开盘的IDO。

我猛地坐起来，手忙脚乱地打开电脑。屏幕亮起，我下意识地看了一眼Clash的日志面板，那一列密密麻麻的REJECT和DIRECT记录里，有一条特别扎眼：

[Rule] DOMAIN-SUFFIX,binance.com,REJECT

不对，我明明用的是Proxy策略组。再往下翻，我看到了那条罪魁祸首：

[Rule] DOMAIN-SUFFIX,binance.com,DIRECT,no-resolve

就是那个no-resolve。它让所有指向币安的请求绕过了代理，直接走本地网络。而我的本地网络，此刻正被运营商的高延迟和丢包折磨得死去活来。提币交易广播不出去，链上确认卡死，IDO的窗口正在一秒一秒地关闭。

我盯着那行配置，脑子里嗡嗡作响。这个no-resolve选项，是我三天前为了“优化直连速度”加上去的。当时我在某个技术群里看到有人说：“加个no-resolve，直连域名不走DNS解析，快得飞起。”我没多想，直接抄了过来。现在好了，快得飞起的是我的血压。

那个让我失眠的 no-resolve 到底是什么鬼？

如果你用过Clash，你肯定见过这种配置：

yaml rules: - DOMAIN-SUFFIX,binance.com,DIRECT,no-resolve - DOMAIN-SUFFIX,coinbase.com,PROXY - GEOIP,CN,DIRECT

简单来说，no-resolve 是一个性能优化开关。它告诉Clash：当某个请求匹配到这条规则时，不要先做DNS解析，直接把原始域名或IP交给策略组处理。

听起来很美好对吧？省去了DNS查询的时间，理论上能加快直连速度。但问题在于，这个“加速”是有前提的。它只适用于两种情况：

1. 目标域名本身不需要解析（比如你直接写了一个IP地址段）。
2. 你明确知道该域名会走直连，且直连网络质量极佳。

而我的情况是第3种——我根本不知道binance.com的DNS解析结果会被运营商污染成什么样。当Clash跳过DNS解析，直接把域名交给本地网络时，系统会调用默认的DNS服务器去解析。而我的默认DNS服务器是运营商提供的，它返回了一个被墙的IP，或者一个高延迟的CDN节点。

结果就是：直连加速变成了直连自杀。

币圈人的噩梦：当 no-resolve 撞上网络拥塞

事情还没完。我手忙脚乱地删掉了那条规则，强制Clash重新加载配置。但已经晚了，那笔提币交易在链上挂了整整两个小时才被打包。IDO自然没抢到，我眼睁睁看着那个代币开盘翻了五倍，然后回落，然后我什么都没做。

更讽刺的是，我后来复盘时发现，问题根本不在no-resolve本身。它只是暴露了一个更深层的矛盾：在币圈，你的“直连”和“代理”从来不是简单的二选一。

你以为DIRECT就是“快”？错。在加密货币的世界里，DIRECT意味着你的流量要经过：

• 运营商DNS（可能被污染）
• 本地ISP的NAT（可能有CGNAT限制）
• 国际出口带宽（高峰期可能只有几百KB/s）
• 目标交易所的CDN（可能对你所在地区做了限速）

而no-resolve这个选项，就像是一个“跳过体检直接上手术台”的医生。它帮你省了做CT的时间，但完全没检查你身体里有没有肿瘤。

一个真实的对比：同样的规则，不同的命运

为了让你更直观地理解，我给你讲两个朋友的故事。

朋友A：老韭菜，用Clash三年，配置里全是no-resolve。

他的逻辑是：“我所有交易所域名都走直连，因为交易所本身就在海外，直连反而比绕代理快。加个no-resolve，省得每次都要查DNS。”

他平时确实很快。但有一次，他所在的城市遭遇了海底光缆故障，国际出口拥堵。他的直连延迟从80ms飙升到800ms，而他的Clash因为no-resolve，连切换到代理的机会都没有。他当时正在做合约交易，看到行情剧烈波动，想平仓却平不了——因为所有请求都卡在直连的队列里。

他最后是打电话给客服，用电话委托平掉的。亏了多少钱他没说，但他说“以后再也不敢在关键时候用no-resolve了”。

朋友B：新入场的科学家，用Clash不到一个月，配置干净得像白纸。

他的规则很简单：DOMAIN-SUFFIX,binance.com,PROXY。没有no-resolve，没有GEOIP，甚至没有MATCH。

他每次打开币安App，Clash都会先解析域名，然后走代理。代理是他租的香港VPS，延迟稳定在30ms左右。他从来没遇到过提币卡顿，也没遇到过行情延迟。

有一次我问他：“你为什么不加no-resolve？听说能加速。”

他愣了一下：“加速什么？我的代理已经够快了，而且解析一次DNS也就几十毫秒，比重新连接一个被墙的IP快多了。”

什么时候该用 no-resolve？一个币圈人的自我修养

我不是说no-resolve一无是处。它确实有它的用武之地，但只限于极少数场景：

场景一：你明确知道目标IP段是“干净”的

比如你有一个自建的VPS，IP是1.2.3.4，你想让所有到1.2.3.4的流量直连。这时候你可以写：

yaml rules: - IP-CIDR,1.2.3.4/32,DIRECT,no-resolve

因为IP-CIDR本身不需要DNS解析，加no-resolve只是跳过“先解析域名再匹配IP”的步骤。这种情况下，它确实能省一点时间。

场景二：你用的是“纯IP规则”，且确认网络环境极佳

比如你在公司内网，有一个内部交易所的IP段，延迟极低，丢包率接近0。这时候加no-resolve没问题。

场景三：你是个“赌徒”，且已经做好了亏钱的准备

如果你非要加，我建议你至少加一个fallback策略。比如：

yaml rules: - DOMAIN-SUFFIX,binance.com,DIRECT,no-resolve - DOMAIN-SUFFIX,binance.com,PROXY

这样当直连失败时，Clash会走代理。但注意，这并不能解决DNS污染的问题——因为no-resolve已经跳过了解析，直接以域名形式发给本地网络。本地网络会用自己的DNS去解析，如果这个解析结果本身就是错的，那直连还是失败。

那次事故之后，我做了什么？

我花了整整一个周末，重新梳理了我的Clash配置。我删掉了所有no-resolve，然后针对每个交易所域名单独测试了直连和代理的延迟。

结果很有意思：

• 币安现货API：直连延迟120ms，代理延迟45ms。我选了代理。
• 币安合约WebSocket：直连延迟200ms且丢包5%，代理延迟35ms且丢包0%。我选了代理。
• 某小众DEX的RPC节点：直连延迟80ms，代理延迟150ms。我选了直连（但没加no-resolve，因为我用了MATCH,DIRECT兜底）。

然后我写了一个脚本，每小时自动测试一次这些域名的连通性，如果直连延迟超过阈值，就自动切换规则。虽然听起来很“硬核”，但至少我再也不用在凌晨三点盯着pending交易发愁了。

给你的最后一条建议

如果你现在还在用no-resolve，我建议你立刻做两件事：

1. 打开Clash的日志，看看你的DIRECT规则匹配了多少次DOMAIN-SUFFIX,binance.com。 如果你发现直连的延迟经常超过100ms，那么恭喜你，你正在用“加速”的名义慢性自杀。

2. 把no-resolve改成no-resolve的“反义词”——也就是什么都不加。 让Clash正常解析DNS，然后根据你的策略组决定走代理还是直连。多花的那几十毫秒，换来的是“不会因为DNS污染而突然断线”的安心。

记住，在币圈，速度不是第一位的，稳定才是。你可以接受10ms的延迟差异，但你绝对接受不了“提币卡住”或者“行情延迟导致爆仓”。no-resolve这个选项，就像是一把没有保险的枪——它确实能让你扣扳机更快，但走火的概率也更高。

而我，现在已经把所有交易所的域名都写进了PROXY策略组，并且加了一句注释：

# 别他妈加no-resolve，除非你想亏钱

凌晨三点十七分的教训，一次就够了。