电子斗蛐蛐之 mihomo vs sing-box 使用体验

[LongLights]

前言

两者都是开源免费的内核，都拥有非常顶级的运行效率，都能支持复杂的规则分流、链式代理等花式需求，都是非常 nice 造福广大网友的项目。

本文仅看个乐子，同时对有意折腾但是选择困难的 v2er 提供一点或许有用的参考。

我们追求的效率本质是什么

这里不讨论节点本身的线路、带宽，也不讨论后端协议。保证以上变量相同的情况下，不同内核、不同配置影响运行效率的其实几乎只有两点：

1. 流量重定向方式（ redirect/tproxy/tun ）
2. 规则匹配精准度

关于第 1 点：对于 x86 软路由及其他正常性能的 pc 、手机、比较新的硬路由等终端来说：

除了 tun 模式下，sing-box 开启 auto_redirect 显著强于 mihomo 的 tun 模式（也显著强于其他插件、内核的 tun 模式）。其余各种组合很难再让你刷网页提速 0.1 秒，也不会影响外网测速。至于通过回环测速之类的方式测试吞吐量，相信我，对实际运行场景来说几乎没有任何参考意义。

这就需要详细说一下第 2 点：无论是 geo 数据库还是 ruleset 使用“增强规则集”，其最初目的都是一样的：通过更全面的域名规则、和变化很小的 ip 规则补充不足。

这个特性与市面上所谓的“防 DNS 泄露方案”是相左的。因为无论是 mihomo 的 nameserver-policy （或 no-resolve ）、还是套 mosdns 这类插件实现所谓的“防泄露”，抑或是 sing-box 不开启 action:resolve ，运行逻辑都是一样的：

对于未命中的域名规则，一律匹配代理。 这种运行方式会使得在域名访问时，你添加的 ip 规则统统无效，自然也就无从谈起“匹配精准”了，因此更建议的方式是这样的：

远程 dns 由代理节点发起确保可信无污染，同时单独使用 gfw 域名规则集，确保 gfw 内的网址不经过本地 dns 解析

以上操作在 mihomo 和 sing-box 中都能轻易实现，因此运行效率方面我认为二者相当（唯一需要注意的是，sing-box 很多流行的“配置模板”中未在 route.rules 中添加 action:resolve ，不添加这个字段可以等价为在 mihomo 的所有 ip 规则后添加 no-resolve ，此时对于域名匹配来说，你的 ip 规则都是无效的）

ipv6 和 fakeip

早年折腾软路由的朋友们应该都听说过“关闭 ipv6 提升网速”的说法，因为那年的姿势都还很青涩，ipv6 常会导致很多预期外的问题。同时 ipv6 的好处是显而易见的：一个无成本的公网地址用于远程连接等场景、部分特殊小鸡获得更优线路、更稳定的公益 iptv 源等等等等。

mihomo 和 sing-box 都能完美实现 ipv6 流量透明代理，但如果你使用的是 realip 模式，会发现这样一个问题：本地有 v6 、目标网站有 v6 、节点本身只有 v4 ，啪一下，连接中断了。所以很多 gui 插件开启 v6 透明代理时会提示你“请确保本地和节点服务器均支持 ipv6”。那有没有什么方法能让我的不同节点（有的有 v6 有的没有）都正常连接呢？其实非常简单，启用 fakeip 即可，fakeip 模式下实际的网络连接会由远端自行发起 dns 解析（并不同于上面说的节点代理发起），自然就能在不支持 v6 的情况下正常回落 v4 了。

这里又不得不提一下 mihomo 和 sing-box 的 fakeip 模式存在些许差异，具体表现为：mihomo 开启 fakeip ，上一步说的 ip 规则分流依然能正常工作； sing-box 则不行（经过 fakeip 的都默认代理了）

sing-box 的解决方案也并不复杂：在 dns.rules 中再定义 dns 本身的分流规则即可，例如创建一个 dns.servers 为 cn_dns ，他由本地直接发起，获得真实 ip ；再创建一个 fake_dns ，类型为 fakeip 。去 dns.rules 中定义哪些经过 cn_dns ，哪些经过 fake_dns （这一步是可以添加 ip 规则的，可能有点反直觉，其本质是通过第一次解析结果判断是否要经过 fake_dns ，一般搭配 invert 字段使用）

坚定选择 fakeip 的原因

fakeip 确实存在一些问题，例如快捷登录不可用、stun 打洞失败、物联网设备连不上网等，但大多可以通过 mihomo 的 fake-ip-filter 或者 sing-box 的 dns.rules 分流解决。那有朋友可能会问了：我本地只开 v4 是不是使用 realip 模式更好呢？

答案是未必，因为 realip 模式下，理论上你有多少个策略组，就需要添加多少个 dns 分流规则，例如 netflix 规则集走节点 A ，那么对应的 dns 请求就也应该由节点 A 代理发起。由于只有 sing-box 支持复杂的 dns 分流，所以 mihomo 一律建议使用 fakeip 模式，sing-box 也会导致你的 config 异常复杂，很不优雅。

同时由于 sing-box 基本上都是裸核运行，mihomo 则有非常多成熟的 gui ，这些 gui 通过默认覆写的方式已经规避了绝大部分 fakeip 可能导致的问题，因此在本地开启 ipv6 的情况下，我认为 mihomo 小胜。

其他杂项

1. 临时使用（如国内服务器临时代理 docker 源、部分主机一次性使用）选择 sing-box 或许更便捷：拖入核心、拖入 config.json ，一行命令直接 run ，用完停止进程并删除即可（仅限 inbounds 为 tun 模式），优雅且无感。

2. 由 pc 直接 pppoe 拨号上网的特殊情况下：sing-box 的 tun 模式和 mixed 模式会无法接管流量，即使在 windows 的系统代理配置对应端口，原因未知。mihomo 则 work 正常。

3. mihomo 原生支持 proviers 字段，并可以通过 includes 字段进行节点名重写、地区过滤等等复杂操作； sing-box 虽有第三方核心支持，但版本老旧和新版配置存在字段冲突。

4. sing-box 往往需要准备多套配置文件，用于不同系统的 inbounds 字段（如 auto_redirect 只有 linux 支持）； mihomo 由于完善的 gui 生态，依赖 gui 提供的默认覆写即可，配置中不需要特地指定监听端口号等不同字段。

5. sing-box 可以本身调用 tailscale ，甚至服务端可以创建 derp 服务器，同时需要魔法上网+tailscale 会很方便，但是移动端的 app 本身未编译 tailscale 支持，需要自行编译

建议姿势&gui 选择

1. 上述建议的合理使用 ip 规则集、善用 fakeip 模式
2. 其实不需要过分考虑 gui 支持，因为 zashboard 这类面板的存在，裸核跑也有非常好的使用体验
3. 大力推荐 sub-store 这个神器，特别是 sing-box 不使用第三方核心无法使用 providers 的时候，把节点信息、鸡场订阅存在 sub-store 里，通过 js 脚本动态插入 config.json ，就能直接让裸核调用运行了
4. 如果在两种内核往返切换，尤其是软路由环境，切记关闭开机启动，因为即使是裸核 sing-box 的 tun 模式，也会自动往你的 nftables 、iptables 加入规则，常常会导致各种冲突。

建议选择的 gui：

1. sing-box：裸核、官方 app
2. mihomo：

ShellCrash （硬路由、软路由都能用）、OpenClash （良心，更新频繁，默认覆写全面）；

stash （ iOS 收费 app ，但是能把你写好的 mihomo 配置直接拉进去跑，仅有少部分字段不支持）；

windows 端不推荐了，繁多而且有争议。

[xxtt]

目前用 sing-box 官方 app 。。，但是访问国内网站有时还是会卡。。访问国外网站非常流畅，要如何优化啊？

[codehz]

openwrt 不如用 openwrt-nikki ()

[hiyoi]

我还是接受不了 fakeip ，总是各种小问题。因此选择自建 dns 规避污染，docker 开个 paopao dns ，mihomo 的 nameserver 直接指向它就行了。

另外 op23 以上还可以用 nikki ，功能很全的一款 mihomo 透明代理插件。

[willis]

用 singbox 的 dns 可以完美代替 mosdns,用路由器的策略路由分流，关闭 singbox 的 autotoute ，国内国外都是满速

[wuruxu]

在 openwrt 上 我一般都是用 dnsmasq 来分流的
再通过 policy route 把流量导入 wireguard interface ，这样效率最优
用 golang 的程序，尤其在路由器这样的嵌入式设备上长时间运行，GC 会是一个很大的隐患

[lnbiuc]

> 答案是未必，因为 realip 模式下，理论上你有多少个策略组，就需要添加多少个 dns 分流规则

这一部分有不同的看法，我任务本地进行 DNS 解析的分流是毫无意义的，指的是 nameserver-policy ，本地解析（ realip ）或不解析（ fakeip ），返回的 IP 都只是用作保存 IP 和域名的映射关系，之后当客户端发起 TCP/UDP 连接的时候，再通过映射关系找到域名，使用域名进行规则匹配，如果匹配到代理规则，会将域名发送到代理服务器，由代理服务器的 DNS 重新进行解析；如果匹配到直连，则会进行直连。
也就是说，在代理的情况下，不论 realip 还是 fakeip ，本地 DNS 解析的 IP 都不一定是真实连接的 IP 。所以对于需要代理的域名来说，fakeip 还是 realip 都一样，所以没有必要进行分流

基于此，我认为最优的配置是：首先使用 fake-ip-filter 对所有 DIRECT 域名进行分流，让其返回 realip ，只配置一个 nameserver: 223.5.5.5 ，这样所有 DIRECT 和不是 PROXY 的（ MATCH ）域名都会被 223.5.5.5 解析，所有 PROXY 都会在代理服务器解析。这样可以获得最好的 ECS 体验

是否存在 DNS 泄露呢，主要看对泄露的定义，代理过程中无非三种情况，PROXY 、DIRECT 、MATCH ，按照上述配置 DIRECT 和 MATCH 都会使用 223.5.5.5 解析，按照网上常用的配置，MATCH 会被代理解析。而 DNS 泄露的测试网站域名都是在 MATCH 内的，所以我个人认为是不存在泄露的

[jko123]

我的软件内置了 mihomo 和 sing-box ，但是最终用了 sing-box ，因为同样是配置文件有问题，sing-box 可以闪退，mihomo 不会闪退，让我没办法处理

[wqsdfdddd]

@xxtt 我这也是,国外的很流畅, 国内的做了分流有点卡(比如 b 站)

[SenLief]

sing-box 最大的问题是配置文件经常变动，不同版本不兼容，这点 mihomo 表现很良好，所以我选择 mihomo 客户端，xray 服务端，协议 vless reality vision

[KingFong]

服务端自建的话我一般选择 xray ，下次试试 singbox ，作者在推上好像说得天下无敌的样子。

[zhu327]

跟我理解的一致, 不过我用的是 xray 手搓配置, dnsmasq gfwlist 分流到 xray 的 fake dns 返回 fake ip, iptables fake ip 指向 ipt2socks, ipt2socks 导流到 xray

路由器的性能很差, 所有 xray 是跑在 nas 上的, 然后路由器上只需要配置 ipt2socks, 没有 udp 的需求, 透明代理还是很爽的, 也不会有 dns 泄漏的问题

[LongLights]

@zhu327 是的，目前版本日常冲浪 udp 其实并没有走代理的必要

[LongLights]

@yanjieee 如果没有 tailscale derp/naive/一个小鸡搭 n 个入站的需求，xray 跑服务端稳得很。不过试用也简单，这俩服务器配置写法几乎一样

[defaw]

singbox 现在用啥写配置，早期那 json 复杂度真的是被 clash 的 yaml 暴打

[cwxiaos]

@defaw 一样复杂，而且还在变，一边是内核不停 warning 哪个字段要 deprecated, 一边是照着文档写了配置结果字段不支持

总体来说我倒是希望用 singbox, 不过用起来体验不太好，手搓配置几个月就废了，要重新搓

[popzuk]

已经固定使用 sing-box 某个版本，省得老是改配置。

[issakchill]

mihomo 裸核运行也挺省心的

[xiangchen2011]

看的出来不是 AI 生成的，感谢楼主用心编辑帖子

[xiaonian233]

不知道为什么我在 vmware 以桥接网络不复制主机网络状态运行 immortalwrt 作为旁路由，无论是启动 nikki 还是 openclash ，只要一启动主机的网络就会被劫持

[Dk2014]

mihomo 跑客户端，sing-box 用来跑服务端