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

前言

两者都是开源免费的内核，都拥有非常顶级的运行效率，都能支持复杂的规则分流、链式代理等花式需求，都是非常 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 端不推荐了，繁多而且有争议。