代理组 url-test 参数调优：interval 与 tolerance 设置

凌晨三点十七分，我的手机屏幕在黑暗中炸开一片猩红。

“BTC 跌破 62,000 了！你那个网格机器人还在跑吗？”阿杰的语音消息带着明显的颤抖。我揉着眼睛点开交易所 APP，持仓页面上的数字正以每分钟几百美金的速度蒸发。更致命的是，我的代理组——那个本该在极端行情下自动切换最优节点的 url-test 组——竟然卡在了一个延迟 800ms 的香港节点上，而备用列表里明明躺着三个延迟不到 120ms 的新加坡节点。

“为什么没切？”我对着屏幕吼出声。手指疯狂下拉刷新，代理面板上的延迟数字像死人的心电图一样平静。那一刻我意识到，过去半年我精心维护的这套代理架构，在真正的风暴面前，脆弱得像一张浸了水的纸。

那个价值三万美金的延迟数字

事情要从三个月前说起。当时我刚开始用 Clash 的 url-test 代理组来管理十几个机场节点，策略很简单：把所有节点丢进一个组，设置 interval: 300，tolerance: 50，然后祈祷它自动帮我选最快的。平时刷推特、看 YouTube 确实没问题，直到那个周五晚上——美联储主席突然放鸽，BTC 五分钟内拉升 8%。

我的套利脚本需要在三个交易所之间搬砖，对节点延迟极其敏感。但 url-test 组像睡着了一样，死死抱住一个洛杉矶节点不放。那个节点延迟 210ms，而东京节点只有 45ms。等我在手动切换里找到东京节点时，价差已经被机器人吃干净了。事后复盘，那晚因为延迟问题错过的套利窗口，价值大约三万美金。

“你的 interval 设太长了。”阿杰后来在语音里说，“300 秒？行情都走完两轮了。”他顿了顿，“但也不能太短，否则你的订阅流量会爆炸。”

url-test 到底在测什么

要理解 interval 和 tolerance 这对冤家，得先明白 url-test 组的工作原理。每次测试周期到来，Clash 会向组内所有节点同时发起一个 HTTP HEAD 请求（默认目标通常是 http://www.gstatic.com/generate_204），测量从发出请求到收到响应的时间。这个时间就是面板上显示的延迟数字。

但这里有个陷阱：面板上显示的延迟，是 TCP 握手 + TLS 握手 + HTTP 请求的总耗时。对于需要代理的流量，实际数据包还要经过加密、隧道封装、远端服务器转发。所以一个显示 50ms 的节点，在真实下载时可能因为带宽不足而表现得更差。这就是为什么有时候 url-test 选出的“最快”节点，看视频反而卡顿。

“你不能只看数字。”阿杰有次给我看他的配置，“我专门给 url-test 组加了一个 fallback 组兜底，万一 url-test 抽风，fallback 还能用。”他的 url-test 组里只放了五个节点，都是他手动筛选过的低延迟、高带宽节点。“节点不在多，在于精。你放二十个节点进去，每次测试都要等最慢的那个返回结果，反而拖累整体切换速度。”

interval：心跳太快会猝死，太慢会误事

我最初把 interval 设成 300 秒，是因为看到某个教程说“五分钟测一次够了”。但虚拟币市场哪有什么“够了”？一次非农数据公布，三十秒内就能走完一周的行情。300 秒的测试间隔，意味着你的代理组在最多 5 分钟内都是“盲”的——它不知道节点已经变慢，也不知道有更快的节点上线了。

但把 interval 调到 30 秒呢？我的机场订阅是按流量计费的，每个节点每次测试都要消耗一点流量。二十个节点 × 每分钟两次测试 × 24 小时 = 每天 57600 次请求。虽然每次请求只有几百字节，但架不住量大。更关键的是，频繁测试会让一些性能较弱的节点持续处于高负载状态，反而拉高了延迟。

“你试试 90 秒。”阿杰说，“我测过，这是大多数机场能承受的极限。再短，你的订阅流量会像漏水一样消失。”他给我看了他的监控图表：interval 从 300 降到 90 后，节点切换的及时性提升了 4 倍，而流量消耗只增加了 18%。“因为测试请求本身很小，真正的流量大头还是你的实际使用。”

我照做了。那个周末，当 BTC 再次剧烈波动时，我的 url-test 组在 90 秒内就完成了从东京到新加坡的切换。套利脚本的日志里，第一次出现了“节点延迟稳定在 60ms 以下”的记录。

tolerance：那个让节点“不折腾”的缓冲带

但 interval 只是故事的一半。真正让我的代理组在风暴中保持稳定的，是 tolerance 参数。

tolerance 的意思是“容差”。当 url-test 组发现当前节点的延迟是 100ms，而另一个节点是 95ms 时，它不会立即切换——因为 5ms 的差距在容差范围内。只有当新节点比当前节点快出超过 tolerance 设定的毫秒数时，才会触发切换。

我最初把 tolerance 设成 50ms，想着“要换就换明显更快的”。结果在行情剧烈波动时，节点延迟像过山车一样上下跳动：这一秒东京 80ms，下一秒新加坡 75ms，再下一秒东京又变成 70ms。如果 tolerance 太小，代理组就会在这两个节点之间反复横跳，每次切换都会导致现有连接中断。我的 WebSocket 行情推送因此断了好几次，等重连回来，价格已经跑远了。

“把 tolerance 调大。”阿杰说，“至少 100ms。你要的是稳定，不是极限速度。”他解释说，在虚拟币交易场景里，一次连接中断造成的损失，远比多 20ms 延迟要大。“你想想，套利脚本最怕什么？最怕下单到一半连接断了。那时候你连撤单都撤不了。”

我把 tolerance 调到 150ms。效果立竿见影：代理组不再频繁切换，只有当一个节点明显劣化（比如延迟突然从 80ms 跳到 300ms）时，才会果断切走。而在两个性能相近的节点之间，它选择“按兵不动”。

那个让我赚回三万美金的深夜

回到故事开头那个凌晨。BTC 暴跌，市场恐慌，我的手机被预警消息淹没。但这一次，代理组的表现截然不同。

interval 是 90 秒，tolerance 是 150ms。当香港节点延迟飙升到 800ms 时，url-test 在下一个测试周期就发现了。它对比了新加坡节点的 110ms 和东京节点的 95ms——东京更快，但差距只有 15ms，小于 tolerance。按照规则，它没有立即切换。直到 90 秒后下一次测试，东京节点延迟降到 88ms，而香港节点依然在 700ms 以上，差距远超 150ms，代理组才果断切到东京。

这 90 秒的“延迟切换”看似是缺点，实际上救了我。因为在那 90 秒里，香港节点虽然延迟高，但连接是稳定的——没有丢包，没有断流。我的止损单顺利成交，仓位从危险边缘被拉了回来。如果代理组在延迟波动的瞬间就疯狂切换，我的 WebSocket 连接会断，止损单可能根本发不出去。

“你看，”阿杰第二天早上给我发消息，“调参不是为了让数字好看，是为了让你的策略活着。”

那些藏在参数背后的取舍

现在我的 url-test 组配置是这样的：interval: 90，tolerance: 150，组内只放 6 个经过筛选的节点，测试 URL 换成了 http://cp.cloudflare.com/generate_204——因为 Cloudflare 的节点在全球分布更均匀，测出来的延迟更接近真实代理体验。

但这不是终点。上周我发现，在亚洲时段，东京节点表现最好；到了欧洲时段，法兰克福节点开始发力。于是我加了一个 fallback 组作为二级保险，又在 url-test 组里加了一个 lazy: true 参数——让 Clash 只在有流量请求时才触发测试，进一步节省流量。

“你这是在调参还是在养孩子？”阿杰笑我。但我知道，在这个 7×24 小时不间断的市场里，每一毫秒的延迟、每一次不必要的切换，都可能意味着真金白银的得失。代理组不是设好就忘的背景配置，它是你交易系统里最底层的基础设施——就像交易所的撮合引擎，平时感觉不到它的存在，一旦出问题，就是灾难。

当参数有了温度

昨天深夜，BTC 再次插针。我的手机又响了，但这次是盈利提醒。套利脚本在 0.3 秒内完成了三笔跨所搬砖，净利润 4700 美金。代理面板上，东京节点的延迟稳定在 72ms，新加坡节点 78ms，url-test 组安安静静地待在东京节点上，没有切换。

我盯着那个数字看了很久。72ms，人类眨一次眼需要 100ms。在这个比眨眼还短的时间窗口里，我的代理组完成了测试、比较、决策、路由的全过程。而 interval 和 tolerance 这两个看似枯燥的参数，决定了这个过程是精准还是鲁莽，是稳健还是神经质。

阿杰说得对，调参不是技术活，是心理活。你得知道自己在怕什么——怕延迟高？怕连接断？怕流量超？然后根据你的恐惧，去设置那个平衡点。interval 是你对市场的敏感度，tolerance 是你对稳定的容忍度。两者之间的张力，就是你在这个疯狂市场里的生存空间。

凌晨四点的屏幕光映在墙上，像一片小小的、安静的月亮。代理组还在运行，interval 在倒计时，tolerance 在守夜。而我终于可以关掉手机，睡一个不用每隔五分钟就刷新一次面板的觉。

因为我知道，当下一场风暴来临时，那两个数字会替我做出比我的手指更快的决定。