Clash分流规则：规则与DNS拦截结合

深夜十一点，我盯着屏幕上那个红得刺眼的数字——BTC 又跌了 12%。交易所的深度图像瀑布一样倾泻，而我的 Telegram 群里，一群“钻石手”正在疯狂刷着“抄底”和“归零”的梗图。我深吸一口气，手指悬在“买入”键上，但就在这一瞬间，我眼角瞥见了 Clash 面板上那个不起眼的“日志”标签。里面正滚动着成百上千条连接记录，其中一条刺痛了我的神经：api.coingecko.com 被解析到了一个位于卢森堡的 IP，而这条连接的策略组，赫然写着“PROXY”。

这不对。非常不对。

在加密货币交易的世界里，延迟就是金钱，而错误的路由策略就是灾难。我刚刚差点在一个被错误代理的行情接口上，做出了一个基于 5 分钟前旧价格的投资决策。那一刻我意识到，Clash 的分流规则，绝不只是“国内直连、国外代理”这么简单。它是一场关于数据主权和网络路径的微观战争，而 DNS 拦截，则是这场战争中最致命、也最容易被忽视的狙击枪。

---

场景一：那场被“污染”的抢跑

让我把时间拨回三天前的晚上。那是一个典型的“非农数据”发布夜，币圈惯例的剧烈波动期。我设定了一个网格交易策略，依赖的是 Binance 的 WebSocket 推送。我的 Clash 规则里，*.binance.com 被明确指向了“香港-02”节点。

但奇怪的事情发生了。策略日志显示，有连续 3 秒，订单簿的更新频率从 200ms 一次骤降到 800ms。我以为是节点拥堵，切到了备用节点，毫无改善。直到我打开 Clash 的“连接”面板，看到一条来自 data.binance.vision 的 UDP 流量，它被规则匹配到了“DIRECT”（直连）。

问题找到了。我的规则只写了 *.binance.com，但 Binance 的行情快照服务使用了 data.binance.vision 这个独立域名。 由于我的 DNS 设置是“Redir-Host”模式，这个域名在本地被系统解析，返回了一个被运营商 DNS 缓存污染的 IP——一个位于美国洛杉矶的 Cloudflare 节点，但路径却走了国内直连的骨干网。结果就是，数据包在物理上绕了半个地球，却用的是“最短路径”的预期，导致延迟飙升到 400ms。

这就是典型的规则粒度不够引发的“幽灵拥堵”。在那一刻，我手里的 Clash 根本不是一个代理工具，而是一个网络命运的选择器。而我，把选择权交给了默认的“兜底规则”。

---

核心战场：为什么“规则”必须与“DNS 拦截”共生

要理解这个问题的本质，我们必须拆解 Clash 的两大核心引擎：路由引擎（Rule） 和 解析引擎（DNS）。很多用户把它们当成两个独立模块，但在我眼里，它们是一把剪刀的两片刃。

第一，规则是“地图”，但 DNS 是“路况”。

一个经典的规则长这样： - DOMAIN-SUFFIX,binance.com,PROXY - GEOIP,CN,DIRECT - MATCH,PROXY 这条规则的意思是：只要是 binance.com 结尾的域名，走代理；只要是中国的 IP，直连；剩下的，走代理。看起来逻辑完美，对吧？

但问题在于，Clash 在执行 DOMAIN-SUFFIX 规则之前，必须先拿到这个域名对应的 IP。如果你用的是系统默认 DNS（比如 114.114.114.114），那么当你在浏览器输入 www.binance.com 时，这个 DNS 服务器会返回一个基于你物理位置的 IP——大概率是一个被 CDN 调度到香港或新加坡的节点。

然后 Clash 一看，这个 IP 不是中国的，匹配到 GEOIP,CN 失败，最终走 MATCH,PROXY。这没问题。但致命的漏洞在于：如果你的代理节点本身在国外，而 DNS 解析却是在本地完成的，那么你的“代理”实际上是在为一个“本地解析出的国外 IP”去建立连接。这会导致两个问题： 1. DNS 泄漏：你的真实 DNS 请求（比如 api.binance.com）在本地明文发送给运营商，运营商能看到你在访问币安，这在国内是敏感行为。 2. IP 优先级的错乱：更糟糕的是，如果某个域名同时有国内和国外的 CDN 节点，本地 DNS 可能返回一个国内 IP（比如为了合规），但你的规则却强制它走代理。结果就是，代理服务器去连接一个国内 IP，延迟高得离谱，甚至被墙。

第二，DNS 拦截是“规则”的侦察兵。

真正的解决方案，是 Clash 的 DNS 拦截（Fake-IP 模式）。当这个开关打开时，Clash 会拦截所有应用发出的 DNS 查询请求。它不会去问真实 DNS 服务器，而是直接返回一个假的 IP（通常是一个保留网段，如 198.18.0.0/16）。

这个假 IP 就是一张“预支的彩票”。当你的浏览器或交易软件试图连接 198.18.1.5 时，Clash 会在内部查表，发现这个 IP 对应的是 api.binance.com。然后，它再通过代理节点去发起真正的 DNS 解析（比如通过 DoH 查询 Cloudflare 的 1.1.1.1），拿到真实 IP 后，由代理节点去连接。

这带来的革命性变化是： - 决策前置：Clash 在收到域名请求的那一刻，就已经知道了“这是币安”，所以可以直接套用 DOMAIN-SUFFIX,binance.com,PROXY 规则，而不用等拿到真实 IP 再判断。 - 零泄漏：你的本地网络里，永远不会有 api.binance.com 这个明文字符串出现。所有 DNS 查询都发生在代理节点内部，运营商看到的只是你连接了一个境外 IP 的加密流量。 - 规则精准化：现在，你可以写出这样的规则： - DOMAIN-SUFFIX,binance.com,PROXY - DOMAIN-SUFFIX,binance.vision,PROXY - DOMAIN-SUFFIX,coingecko.com,PROXY - DOMAIN-SUFFIX,defillama.com,PROXY 所有涉及币价、链上数据的域名，全部强制走代理。 而像 google.com 这种可以被本地解析的，你也可以通过 GEOIP,CN,DIRECT 来兜底。

---

实战演练：一场针对“抢跑机器人”的规则手术

让我们回到那个非农数据的夜晚。在意识到 data.binance.vision 的问题后，我立刻打开了 Clash 的 YAML 配置文件。我决定做一次彻底的规则重构。

第一步：启用 Fake-IP 模式。 yaml dns: enable: true listen: 0.0.0.0:53 enhanced-mode: fake-ip fake-ip-range: 198.18.0.1/16 nameservers: - https://dns.google/dns-query - tls://dns.cloudflare.com fallback: - https://dns.alidns.com/dns-query 这里的关键是 enhanced-mode: fake-ip。我把主 DNS 指向了 Google 和 Cloudflare 的 DoH，确保通过代理解析时，得到的是没有被污染的国际版 IP。而 fallback 用了阿里 DoH，用于解析国内域名。

第二步：精细化规则分区。 我不再使用简单的 MATCH,PROXY。我创建了三个策略组：🚀 币安专线、🌍 国际网络、🐢 国内直连。

yaml rules: # 交易所与行情数据 - 绝对走专线，无视 IP 归属 - DOMAIN-SUFFIX,binance.com,🚀 币安专线 - DOMAIN-SUFFIX,binance.vision,🚀 币安专线 - DOMAIN-SUFFIX,okx.com,🚀 币安专线 - DOMAIN-SUFFIX,bybit.com,🚀 币安专线 - DOMAIN-SUFFIX,coinbase.com,🚀 币安专线 - DOMAIN-SUFFIX,coingecko.com,🚀 币安专线 - DOMAIN-SUFFIX,coinmarketcap.com,🚀 币安专线

# 链上数据与 Gas 费查询 - 这些通常需要访问 Ethereum 节点 - DOMAIN-SUFFIX,etherscan.io,🚀 币安专线 - DOMAIN-SUFFIX,infura.io,🚀 币安专线 - DOMAIN-SUFFIX,alchemy.com,🚀 币安专线

# 社交与资讯 - 走国际代理 - DOMAIN-SUFFIX,twitter.com,🌍 国际网络 - DOMAIN-SUFFIX,telegram.org,🌍 国际网络 - DOMAIN-SUFFIX,discord.com,🌍 国际网络

# 国内可直连的资源 - 比如某些项目方的国内镜像 - DOMAIN-SUFFIX,cn.bing.com,🐢 国内直连

# 最终兜底 - GEOIP,CN,🐢 国内直连 - MATCH,🌍 国际网络

关键点在于：binance.com 的规则被放在了最前面。在 Fake-IP 模式下，Clash 只要看到域名是 binance.com，就直接把连接丢给“币安专线”策略组，根本不会去理会这个域名在 DNS 系统里被解析成了什么 IP。即使本地运营商 DNS 试图把 api.binance.com 解析到一个国内 IP，Fake-IP 模式也根本不会去查询本地 DNS，它直接返回一个假的 198.18.x.x，然后由代理节点去海外解析。

第三步：针对 UDP 的拦截。 币圈的很多交易软件（尤其是做市商工具）会使用 UDP 协议进行行情推送。Clash 默认对 UDP 的处理是“转发”，但如果你不指定规则，它可能会走 MATCH 的兜底。我在 🚀 币安专线 策略组里，明确设置了： yaml proxy-groups: - name: "🚀 币安专线" type: select proxies: - "香港-01" - "新加坡-01" url: "http://www.gstatic.com/generate_204" interval: 300 并且，我在规则里增加了对 UDP 的强制约束： - DST-PORT,443,🚀 币安专线 这意味着，对于币安的域名，无论 TCP 还是 UDP，只要目标端口是 443（HTTPS/QUIC），全部走专线。这彻底杜绝了 UDP 流量因为规则不匹配而掉落到直连的尴尬。

---

场景二：那场“被劫持”的空投

规则和 DNS 拦截的结合，不仅能解决延迟问题，还能救命。就在上周，我参与了一个新项目的空投交互。项目方要求连接 app.uniswap.org 进行流动性操作。我像往常一样，用 Clash 的 Fake-IP 模式访问。

但这次，我注意到一个细节。在 Clash 日志里，app.uniswap.org 的解析结果被显示为 198.18.2.15，而对应的真实节点是“美国-西雅图”。一切正常。但当我点击“Approve”按钮时，MetaMask 弹出的签名请求里，显示的合约地址竟然是 0x8ba1f109551bD432803012645Ac136ddd64DBA72——一个我从未见过的地址，而不是 Uniswap 官方路由合约 0xE592427A0AEce92De3Edee1F18E0157C05861564。

我瞬间冷汗直流。这明显是一个恶意 DApp 或中间人攻击。但我的 Clash 规则明明把所有 uniswap.org 的流量都代理了，怎么会这样？

答案在于 DNS 拦截的“假阳性”。Fake-IP 模式虽然能防止 DNS 泄漏，但它有一个副作用：它拦截了所有 53 端口上的 UDP 查询。如果你在本地跑了一个自定义的 DNS 服务（比如 Pi-hole 或者 AdGuard Home），而 Clash 的 DNS 监听端口与它冲突，或者你的浏览器开启了“安全 DNS”（DoH），那么浏览器可能会绕过 Clash 的 DNS 拦截，直接使用系统内置的 DoH 查询。

在这种情况下，浏览器通过 DoH 查到了 app.uniswap.org 的真实 IP，然后直接通过系统路由（非 TUN 模式）发起连接。而这个连接因为不经过 Clash 的虚拟网卡，所以不匹配任何规则。如果此时你的运营商 DNS 被污染，或者你所在网络有恶意劫持，返回了一个钓鱼 IP，那么你访问的就是一个伪造的 Uniswap 前端。

解决方案是：必须在 Clash 的 DNS 设置里，强制将 app.uniswap.org 加入“fake-ip-filter”白名单之外，并且确保系统 DNS 指向 Clash 的监听端口。 更重要的是，我修改了规则： - DOMAIN,app.uniswap.org,🚀 币安专线 并且，在 Clash 的 dns 配置里，增加了 fake-ip-filter： yaml fake-ip-filter: - "*.uniswap.org" - "*.revoke.cash" 这个 fake-ip-filter 的意思是：对于这些域名，不要返回假 IP，而是返回真实 IP。因为像 Uniswap 这样的 DApp，它的前端会通过 JavaScript 读取 window.location.hostname 来构建交易请求。如果返回假 IP，某些钱包插件可能会因为跨域问题而拒绝签名。但如果我们返回真实 IP，同时又强制规则走代理，那就能保证连接的安全性和兼容性。

---

深度解析：规则与 DNS 的三种“结合姿势”

经过这么多年的折腾，我总结出 Clash 分流规则与 DNS 拦截结合的三种境界：

境界一：规则优先，DNS 跟随（Redir-Host 模式） 这是最基础的玩法。Clash 拿到域名后，用本地 DNS 解析出 IP，再用 IP 去匹配规则。优点是配置简单，缺点是 DNS 泄漏和 IP 错乱。适合只用来上上 Google 搜索，不玩币不看行情的普通用户。

境界二：DNS 前置，规则后置（Fake-IP 模式 + 宽松规则） 这是大多数进阶玩家的选择。用 Fake-IP 拦截所有 DNS，然后根据域名匹配规则。这是目前对币圈用户最友好的模式，因为它能确保 binance.com 永远走代理，同时不会因为 IP 归属问题而误判。但需要你花心思维护一份精准的域名列表。

境界三：规则与 DNS 协同作战（Fake-IP + 条件注入 + 策略组联动） 这是终极形态。比如，你可以利用 Clash 的 script 功能，根据节点的延迟或丢包率，动态调整策略组的选择。或者，你可以使用 rule-provider 从 GitHub 拉取社区维护的币圈域名列表，自动更新。

例如，我写了一个简单的脚本规则： yaml rules: - SCRIPT,should_use_proxy,🚀 币安专线 然后在 Clash 的 JavaScript 引擎里，我判断：如果是 binance.com 或 okx.com 的域名，且当前时间在美东时间 8:30-9:30（非农数据发布），则强制走延迟最低的节点；否则走默认节点。这种结合，让 Clash 不再是一个死板的工具，而是一个有生命周期的交易基础设施。

---

场景三：那场“被静默”的清算

最后一次事件，发生在今天凌晨。我的一个做合约的朋友，他的全仓保证金被强平了。他用的也是 Clash，规则也设置了 binance.com 走代理。但他忽略了一个细节：他的策略软件（一个开源机器人）在连接 Binance API 时，使用的是 fapi.binance.com（期货 API），而他的规则只写了 api.binance.com。

由于他的 Clash 开启了 Fake-IP 模式，fapi.binance.com 被解析为假 IP，但因为没有匹配到 DOMAIN-SUFFIX,binance.com 规则（因为他的规则写的是 DOMAIN,api.binance.com），所以这个连接落到了 MATCH,🌍 国际网络 策略组。而这个策略组选的节点是“美国-洛杉矶”，延迟高达 180ms。

在行情剧烈波动时，他下单指令的延迟导致开仓价格滑点巨大，最终触发强平。他不是死于行情，而是死于一条缺失的 DOMAIN-SUFFIX 规则。

我帮他检查配置时，发现他的规则列表里，binance.com 和 binance.vision 是分开写的，但漏掉了 fapi.binance.com 和 sapi.binance.com。我告诉他一个诀窍：对于大型交易所，永远使用 DOMAIN-SUFFIX 而不是 DOMAIN。 因为交易所的子域名多如牛毛，而且经常新增。用 SUFFIX 匹配，可以一网打尽。

同时，我建议他开启 Clash 的 geodata 加载模式，下载完整的 geosite.dat 文件，里面包含 category-bank、category-exchange 等分类。然后写一条规则： - RULE-SET,geosite,category-exchanges,🚀 币安专线 这样，只要域名属于交易所分类，无论它是 fapi 还是 sapi，都会自动被捕获。

---

最后的叮咛：规则是死的，网络是活的

现在，我坐在电脑前，看着 Clash 面板上那条 fapi.binance.com 的连接，它正稳定地通过“香港-01”节点，延迟 28ms，UDP 流量 0 丢包。我按下那个“买入”键，订单瞬间成交，价格和盘面完全同步。

我关闭了日志窗口，屏幕上只剩 K 线图的跳动。我知道，这场与网络延迟和 DNS 污染的战争永远不会结束。交易所会换域名，CDN 会改策略，GFW 会升级。但只要你理解了规则是“意图”，DNS 是“感知”，并且学会用 Fake-IP 模式将两者缝合，那么 Clash 就不再是一个简单的翻墙工具，而是你在这个数字黄金时代里，最忠实、最迅捷的私人交易员。

记住，每一次点击买入，都是一次网络路径的选择。而你的 Clash 规则，就是那条路径上的红绿灯。别让你的红绿灯，在关键时刻，变成了红灯。