这是一个创建于 52 天前的主题，其中的信息可能已经有所发展或是发生改变。
前言
两者都是开源免费的内核，都拥有非常顶级的运行效率，都能支持复杂的规则分流、链式代理等花式需求，都是非常 nice 造福广大网友的项目。
本文仅看个乐子，同时对有意折腾但是选择困难的 v2er 提供一点或许有用的参考。
我们追求的效率本质是什么
这里不讨论节点本身的线路、带宽，也不讨论后端协议。保证以上变量相同的情况下，不同内核、不同配置影响运行效率的其实几乎只有两点：
- 流量重定向方式（ redirect/tproxy/tun ）
- 规则匹配精准度
关于第 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 小胜。
其他杂项
-
临时使用（如国内服务器临时代理 docker 源、部分主机一次性使用）选择 sing-box 或许更便捷：拖入核心、拖入 config.json ，一行命令直接 run ，用完停止进程并删除即可（仅限 inbounds 为 tun 模式），优雅且无感。
-
由 pc 直接 pppoe 拨号上网的特殊情况下：sing-box 的 tun 模式和 mixed 模式会无法接管流量，即使在 windows 的系统代理配置对应端口，原因未知。mihomo 则 work 正常。
-
mihomo 原生支持 proviers 字段，并可以通过 includes 字段进行节点名重写、地区过滤等等复杂操作； sing-box 虽有第三方核心支持，但版本老旧和新版配置存在字段冲突。
-
sing-box 往往需要准备多套配置文件，用于不同系统的 inbounds 字段（如 auto_redirect 只有 linux 支持）； mihomo 由于完善的 gui 生态，依赖 gui 提供的默认覆写即可，配置中不需要特地指定监听端口号等不同字段。
-
sing-box 可以本身调用 tailscale ，甚至服务端可以创建 derp 服务器，同时需要魔法上网+tailscale 会很方便，但是移动端的 app 本身未编译 tailscale 支持，需要自行编译
建议姿势&gui 选择
- 上述建议的合理使用 ip 规则集、善用 fakeip 模式
- 其实不需要过分考虑 gui 支持，因为 zashboard 这类面板的存在，裸核跑也有非常好的使用体验
- 大力推荐 sub-store 这个神器，特别是 sing-box 不使用第三方核心无法使用 providers 的时候，把节点信息、鸡场订阅存在 sub-store 里，通过 js 脚本动态插入 config.json ，就能直接让裸核调用运行了
- 如果在两种内核往返切换，尤其是软路由环境，切记关闭开机启动，因为即使是裸核 sing-box 的 tun 模式，也会自动往你的 nftables 、iptables 加入规则，常常会导致各种冲突。
建议选择的 gui：
- sing-box：裸核、官方 app
- mihomo：
ShellCrash （硬路由、软路由都能用）、OpenClash （良心，更新频繁，默认覆写全面）；
stash （ iOS 收费 app ，但是能把你写好的 mihomo 配置直接拉进去跑，仅有少部分字段不支持）；
windows 端不推荐了，繁多而且有争议。
 |
1
xxtt 52 天前
目前用 sing-box 官方 app 。。，但是访问国内网站有时还是会卡。。访问国外网站非常流畅，要如何优化啊？
|
 |
2
codehz 52 天前 via Android
openwrt 不如用 openwrt-nikki ()
|
 |
3
hiyoi 52 天前 via Android
我还是接受不了 fakeip ，总是各种小问题。因此选择自建 dns 规避污染，docker 开个 paopao dns ，mihomo 的 nameserver 直接指向它就行了。
另外 op23 以上还可以用 nikki ，功能很全的一款 mihomo 透明代理插件。 |
 |
4
willis 52 天前 via Android
用 singbox 的 dns 可以完美代替 mosdns,用路由器的策略路由分流，关闭 singbox 的 autotoute ，国内国外都是满速
|
 |
5
wuruxu 52 天前
在 openwrt 上 我一般都是用 dnsmasq 来分流的
再通过 policy route 把流量导入 wireguard interface ，这样效率最优 用 golang 的程序，尤其在路由器这样的嵌入式设备上长时间运行，GC 会是一个很大的隐患 |
 |
6
lnbiuc 51 天前
> 答案是未必，因为 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 内的，所以我个人认为是不存在泄露的 |
 |
7
jko123 51 天前
我的软件内置了 mihomo 和 sing-box ，但是最终用了 sing-box ，因为同样是配置文件有问题，sing-box 可以闪退，mihomo 不会闪退，让我没办法处理
|
 |
9
SenLief 51 天前 via iPhone  1
sing-box 最大的问题是配置文件经常变动，不同版本不兼容，这点 mihomo 表现很良好，所以我选择 mihomo 客户端，xray 服务端，协议 vless reality vision
|
 |
10
KingFong PRO 服务端自建的话我一般选择 xray ，下次试试 singbox ，作者在推上好像说得天下无敌的样子。
|
 |
11
zhu327 51 天前
跟我理解的一致, 不过我用的是 xray 手搓配置, dnsmasq gfwlist 分流到 xray 的 fake dns 返回 fake ip, iptables fake ip 指向 ipt2socks, ipt2socks 导流到 xray
路由器的性能很差, 所有 xray 是跑在 nas 上的, 然后路由器上只需要配置 ipt2socks, 没有 udp 的需求, 透明代理还是很爽的, 也不会有 dns 泄漏的问题 |
 |
12
LongLights OP @zhu327 是的，目前版本日常冲浪 udp 其实并没有走代理的必要
|
|
13
LongLights OP @yanjieee 如果没有 tailscale derp/naive/一个小鸡搭 n 个入站的需求，xray 跑服务端稳得很。不过试用也简单，这俩服务器配置写法几乎一样
|
 |
14
defaw 51 天前
singbox 现在用啥写配置，早期那 json 复杂度真的是被 clash 的 yaml 暴打
|
 |
15
cwxiaos 51 天前 via iPhone
@defaw 一样复杂，而且还在变，一边是内核不停 warning 哪个字段要 deprecated, 一边是照着文档写了配置结果字段不支持
总体来说我倒是希望用 singbox, 不过用起来体验不太好，手搓配置几个月就废了，要重新搓 |
 |
16
popzuk 51 天前
已经固定使用 sing-box 某个版本，省得老是改配置。
|
 |
17
issakchill 51 天前
mihomo 裸核运行也挺省心的
|
 |
18
xiangchen2011 51 天前 2
看的出来不是 AI 生成的，感谢楼主用心编辑帖子
|
 |
19
xiaonian233 51 天前
不知道为什么我在 vmware 以桥接网络不复制主机网络状态运行 immortalwrt 作为旁路由，无论是启动 nikki 还是 openclash ，只要一启动主机的网络就会被劫持
|
 |
20
Dk2014 51 天前 via Android
mihomo 跑客户端，sing-box 用来跑服务端
|
 |
21
wm5d8b 51 天前 via Android
额外请教个问题，我现在使用 mosdns 套 adguard home 的方式解析 DNS ，因为除了代理，我有电信移动两条宽带。
除了代理出去，视频网站移动的 cdn 更快，而一般的网站电信更快。所以现在在 adguard home 上面配置，需要代理的终端指定 mosdns 解析，视频网站收集域名使用移动 DNS 解析，剩下的默认电信 DNS 。 但这么搞整个方案不稳定，而且 adguard home 最近的版本不稳定，在 x86 的小主机上偶尔走缓存解析需要 10 多秒。 有更巧妙或者更精简的方案吗 |
 |
22
WizardLeo 51 天前
能否请 op 细说一下“sing-box 很多流行的“配置模板”中未在 route.rules 中添加 action:resolve ...此时对于域名匹配来说，你的 ip 规则都是无效的”这部分和“fakeip 模式下实际的网络连接会由远端自行发起 dns 解析”。
对于前者，我的逻辑是域名匹配仅决定 dns 规则、解析来的正确 ip 再进行 ip 匹配以决定实际走哪个代理服务器。为什么需要以及如何实现 singbox 下域名匹配和 ip 匹配同时生效？ 对于后者，我的理解是远端是否进行 dns 解析取决于是否关闭了 sniffing 下的 route only(对于 3x-ui 面板，如关闭则进行 dns 解析)，本地想要影响远端是否进行 dns 解析应该和 override_address(也叫做覆盖目标地址)，fakeip 应该只影响 dns 解析速度？ 顺便推荐 openwrt 插件 homeproxy🤣，是比较好用的 singbox 面板。 |
 |
23
xxbing 51 天前
挺好的,目前我也选择的这套方案.
==== 客户端: ios 上用 stash , 软路由上用的 openclash , windows 用 clash-verge-rev 节点拉取、清洗: sub-store + subconverter 规则用的是 ACL4SSR 这样可以保证所有客户端的配置文件统一. ==== 防 dns 泄露,在 mihomo 配置文件中配置挺简单的. nameserver 和 fallback 里面用国外的 dns default-nameserver 用国内的 dns. 再搞个 Nameserver-Policy 限定 cn 用 国内 dns , !cn 的用国外的 dns. 缺点是打开国外的网页明显慢了一点,可以在里面加更多规则吧.比如微软系/苹果系的网址也用国内 dns 解析. 多看文档就行了. ==== |
 |
24
isAK47 51 天前
Windows 环境下 sing-box 有办法开启 auto_redirect 吗
|
 |
25
Kinnice 51 天前 via Android 1
dns 泄露/污染：自建 doh+eo 加速
分流：adgHome chn 列表+nftables 绕过国内 ip 代理：mihomo 裸核+realip+自定义规则 兼容和稳定性，用了很久都不错，代理挂了丝毫不影响，所有解析都是真实无污染，配合嗅探服务端解析也完全正常 |
 |
26
Censhuang 50 天前 via iPhone
https://www.v2ex.com/t/1144959
楼主看看我的这个提问？ 经测试，macOS ，tun 模式下的 chrome 的 google 打断解决了问题，但是 openai 的附件上传仍然存在打断问题。在 edge 上，即使使用了代理插件，仍然会在 chatgpt 普通发送中直接提示 close |
|
27
LongLights OP @Censhuang 描述太少了，也没贴出运行配置（ verge 的运行配置不等于你导入的配置，有 gui 默认覆写）
但是目测大概率和 dns 有关，可以参考帖里的方式启用远程代理查询+fakeip 试试，按照帖里你全部 udp 模式即可，不需要 dot/doh ，如果非要加密 dns 解决，建议 dot （如 tls://8.8.8.8 ）而非 doh |
 |
28
yyysuo 50 天前
@lnbiuc 搞蒙蔽了，realip 为什么也成了映射关系了，你是指用了 sing-box 在路由规则中 sniff 么？可是嗅出来的域名也只是用于路由规则匹配，最终发送出去的还是 ip 啊。
|
|
29
yyysuo 50 天前
最优的当然是 dns 阶段就彻底分开 fakeip 和 realip ，只路由 fakeip 到 sing-box/mihomo 。
|
|
34
lnbiuc 38 天前
|
|
36
lnbiuc 37 天前
@yyysuo #35
> sing-box 如果不用 fakeip 的话，是发 ip 的 我都说了 你的发域名的前提时 《没开启嗅探 && 没有使用 singbox 内置 DNS 解析》 并不是你说的“不用 fakeip”就会发送 IP 你觉得你说的没问题就发配置文件，我自然会验证 |
|
37
lnbiuc 37 天前 1
JSON 这种传输用于的格式就不适合作为配置文件使用
最大的问题是不能注释太麻烦了 还有这个该死的行尾逗号 |
 |
38
bigwin 35 天前 via Android
关于为什么，sing-box 很多流行的“配置模板”中未在 route.rules 中添加 action:resolve ，不添加这个字段可以等价为在 mihomo 的所有 ip 规则后添加 no-resolve ，此时对于域名匹配来说，你的 ip 规则都是无效的）。
我刚才看了一下日志，不添加 action:resolve ，是因为 tun 入站可以直接匹配基于 ip 的规则，所以不需要 action:resolve 。只有 mixed 入站，才需要 action:resolve 。目前市面上流行的大多数 sing-box 配置模板，都是基于 tun 入站的，自然也就不需要 action:resolve 。 附上日志截图： 补充一点，如果想分流精准，可以在 dns 部分开启"reverse_mapping": true ，用于在路由时，通过 ip 反查域名，这个目前确实没有在主流的配置模板中见到。根据官方文档来看，macos 不支持这个字段，其它系统都可以尝试开启 |
|
39
bigwin 35 天前 via Android
@bigwin 补充日志截图 https://i.mji.rip/2025/08/18/ebb29cf583de05723fa5548c2cb897ab.jpeg
|
|
40
bigwin 35 天前 via Android
@bigwin 怪了，图片发不出来，再试一下
https://i.111666.best/image/kUBKVphJEm70yad4Gg5Tp0.jpg |
|
41
bigwin 35 天前 via Android
|
 |
47
superht 32 天前
几点不同看法：
1 、mihomo 用的 sing-tun ，其模块和配置大体一致，两者都开启 auto-direct 的话，性能应该相当。 2 、sing-box 会配置 hijack-dns ，不开启 action:resolve 也会匹配 ip 规则，action:resolve 的主要作用：你想在什么阶段进行 resolve 。 3 、tun 模式是 ip 入站，如果未命中的域名规则，ip 规则仍然有效，对于 mihomo 来说，匹配到 ip 规则后，发送域名到远程解析并连接；对于 sing-box 来说，匹配到 ip 规则则向 ip 根据规则进行连接。 4 、“sing-box 经过 fakeip 的都默认代理了”，这取决于规则，如果匹配到的规则是 direct ，则仍然会解析为 realip 并发起直连。 5 、本地开启 ipv6 的情况下，因为 sing-box 有 fakeip v6 ，我认为 sing-box 小胜。 |
 |
48
Csheng 29 天前
配置复杂度、文档确实是个问题，不过折腾完一轮之后还是挺舒服的。。。
json 目前我是用 json5 模板写注释和行尾","支持(对于这两点用 jsonc 也可以)，然后用 python 写脚本填充 outbounds （按照自己的需求过滤、重新组织不同的 rule-set 来对应不同的 outbounds ），最后 json.dumps 出 json 格式的，这样不会有什么问题 面向移动设备(iOS)、透明旁路网关、服务器 docker compose 使用分别有几份稍微有点差异的模板，不过都是代码生成问题不大，每次调试修改通用规则稍微麻烦点，改完网关的，再用 beyond compare 对比差异保留差异中对特定模板有用的部分。 |
Select Language