有些用户会发现，同一条订阅、同一个节点，在 Clash 里用着很流畅，换到另一个客户端却明显变慢。这不是错觉，客户端本身的实现方式确实会影响最终的速度表现，这篇文章解释背后的几个原因。
Clash、sing-box、Shadowrocket 底层用的转发内核并不完全一样，各自在协议解析、连接复用、缓冲区管理等细节上的实现效率有差异。这些差异在网络环境良好、节点带宽充足时可能感觉不明显，但在弱网或者节点负载较高的情况下，不同内核的表现差距就会被放大，这也是为什么同一个节点在不同客户端下的实测速度可能不完全一致。
如果你的客户端配置了大量自定义分流规则（比如按域名、IP 段做精细分流），客户端需要为每个连接请求做规则匹配判断，规则数量越多、越复杂，这个匹配过程消耗的时间和资源也越多。相比之下，规则简单甚至直接全局代理的配置，虽然灵活性差一些，但处理链路更短，某些场景下反而速度表现更稳定。这也是为什么同一个机场，在配置了复杂规则的 Clash 上和简单配置的 Shadowrocket 上，实际体验可能有差异。
系统代理模式只接管明确配置走代理的应用流量，处理路径相对简单；TUN 模式在网卡层面接管全部流量，覆盖范围更广但处理链路更长，理论上会有更多的性能开销。不同客户端对 TUN 模式的实现和优化程度也不一样，这也是导致跨客户端速度对比出现差异的原因之一。日常使用如果对全局覆盖没有硬性需求，系统代理模式通常是更轻量的选择。
DNS 解析发生在建立实际连接之前，如果客户端的 DNS 设置不合理（比如仍然走本地运营商 DNS 而不是代理内置 DNS），解析过程本身就会增加延迟，甚至导致部分域名解析结果不准确、间接影响连接质量。不同客户端默认的 DNS 处理策略不同，这也是速度差异的一个容易被忽视的因素。检查方法可以参考问题排查页里网络速度慢的部分。
同一机场、同一节点在不同客户端下速度不同，通常和内核实现、分流规则复杂度、代理模式（系统代理/TUN）以及 DNS 设置有关，而不是机场本身的问题。想要更公平地对比速度，建议在相同的规则和代理模式设置下测试。