OpenWRT主路由透明代理，singbox vs openclash实测对比

之前分享过sing-box和mihomo的客户端使用体验上的不同:电子斗蛐蛐之 mihomo vs sing-box 客户端使用体验

这一帖来一个更显著的实测对比：

1. immortalwrt主路由，分别使用sing-box裸核和openclash作透明代理，同样使用fakeip模式，无痕窗口访问google对比加载速度
2. 节点均采用洛杉矶gia线路（瓦工DC1），本地电信
3. 切换透明代理前重启软路由端的dnsmasq，刷新windows本地dns缓存，重启chrome进行测试

[!tip]补充：受3L大佬 @randname指正，sing-box在fakeip模式下，调整action:resolve位置，sing-box的初次加载速度能得到一定提升，但与openclash仍有显著差距

以下是实际对比：

并且日常使用中，油管加载速度都很优秀：

9K81IswCg773PJPw5XtRyDpYY0Xvg3YB673×320 47.3 KB

需要说明的是，sing-box使用tun+auto_redirect，而openclash则采用默认推荐的fakeip-增强，因此并不能说明两种核心效率上的高低。

以下是分别使用的sing-box核心配置及mihomo核心配置：
mihomo
sing-box v1.13 with fakeip

clash 有点烦的是要搓配置文件。
搓不好还报错。

都软路由了，不如直接用 iperf3 来测试性能。

至于你的体验上的差别，主要是 dns 解析上的差异。sing-box 按照你当前的配置文件，请求 google 的流程是 sing-box 接受客户端访问 google 的请求，sing-box 通过代理进行 dns 请求，使用返回的 dns 结果使用 ip 访问目标域名。

这么说有点抽象，我让ai画了个时序图

{727337D6-A920-4513-AAD2-1B4E67A44D5F}2125×918 71.3 KB

而 clash 就要简单不少，是直接域名到代理服务器，代理服务器请求dns再访问。

{DB1064B9-A660-4B0E-860E-8D55F23BB4EF}2118×960 129 KB

那么sing-box 访问 google 的首屏延迟可能是 150(dns请求)+150(http请求)，clash 就是只有 2ms + 150ms 了。简单说就是 dns 解析变慢了

那么问题大吗，其实也不大，这样的优点是完全的控制 dns 的解析，不会出现 dns 泄露的问题，而且 dns 是会被缓存的，第二次访问就没有多的 rtt 了，主要是你用的是美国的节点，放大了这个问题

singbox最开始就是这样设计的吗，没有配置能像mihomo一样直接域名到代理服务器？

你直接发域名到代理服务器，那就没法匹配路由规则中的ip规则了

说错了，是singbox不能像mihomo那样代理服务器直接请求dns再访问，这样就可以像mihomo那样少150ms吗，而不是返回ip到核心再自己发送

去掉配置文件中的

   {
                "action": "resolve"
   },

但是

{
                "rule_set": [
                    "privateip",
                    "cnip"
                ],
                "outbound": "Direct-Out"
}

就不会被匹配，这样你就得有个非常完善的规则列表，否则用起来很难受

干货，感谢大佬纠正。我之前对sing-box开启resolve后的fakeip运行模式有点误解，确实和mihomo的逻辑并不一样。

不过倒是有个想法

{
                "action": "resolve"
}

不是一定要在规则的顶部，可以移动下位置，这样匹配了域名规则的就会走远程服务器解析域名。我去验证下

还真可以，之前没往这方向想

nb！！！

参考大佬说的改了配置测试，把action:resolve放在domain规则下、ip规则上，确实体感有提升

YAML文件相比JSON来说还是比较友好的。

佬可以测测 daeuniverse/dae: eBPF-based Linux high-performance transparent proxy solution.吗？

没有开启fakeip，route中不写action:resolve，好像也能匹配到geoip上。从zashboard截的图

image912×508 58.3 KB

咨询个问题，配置文件不用block quic协议吗，看了好多模版都不写这条了

为啥block quic协议，防止目标网站有ech不能分流吗？首先fakeip模式下不会有这种情况，其次一般需要做策略组的站点走ech的真没见过

我就是先匹配域名规则，在resolve之后才是IP规则
reF1nd分支好像可以做到类似mihomo的分流方式

Screenshot_20251017-1603561080×2299 336 KB

quic访问网站因为使用udp可能会被运营商感染，我用的realip，之前使用homeproxy代理singbox内核就需要手动禁用quic，否则看优先走quic协议的网站视频十分卡顿

想知道小白如何入坑，我看大家聊这个配置；是如何学习起来的；

clash是搓不好
singbox是不知道怎么搓
singbox的文档太差了