把版本限制说清楚：我在 2026-05-24 查看官方 release，sing-box 最新稳定版是 1.13.12，1.14.0-alpha.* 仍是预发布；Mihomo 最新 release 是 v1.19.25。这篇只讨论稳定版能放心写进日常配置的行为，alpha 分支的新字段只当后续观察项。
旧文把重点放在协议覆盖，2026 年再这样选会偏。真正影响日常维护的是 DNS 怎么分流、规则集怎么更新、TUN 怎么接管系统流量。协议只在少数前沿需求里决定胜负。
2026 年到底怎么选？
| 你的主要场景 | 先选 | 原因 | 不适合的情况 |
|---|---|---|---|
| Windows / macOS 桌面端日常使用 | Mihomo | Mihomo Party、Clash Verge Rev 生态成熟，YAML 配置可读性高 | 必须用 sing-box JSON 模板统一多端 |
| OpenWrt / 旁路由 / 家庭网关 | Mihomo | OpenClash 和 Mihomo 配置资料更多，规则迁移成本低 | 你已经用 sing-box 做服务端和网关 |
| Android 单客户端 | sing-box 系或 Mihomo 系都可 | Karing、Hiddify 偏 sing-box，FlClash 偏 Mihomo，关键看订阅格式 | 只拿旧 Clash 配置直接导入 sing-box |
| 自建服务端和客户端同构 | sing-box | 服务端、客户端、规则和 DNS 可放进同一套 JSON 思路 | 团队只熟 Clash YAML |
| 追 Naive、AnyTLS 等前沿协议细节 | sing-box | sing-box 文档和实现通常更早暴露新字段 | 只需要常见协议和桌面 GUI |
大量历史 rule-providers | Mihomo | .mrs、RULE-SET 和 Clash YAML 可继续沿用 | 准备统一改成 .srs 和 JSON |
我的建议很简单：没有强约束就先用 Mihomo；有服务端同构、前沿协议或配置自动化要求，再把 sing-box 作为主内核。
DNS 差异为什么比协议更影响日常？
Mihomo 的 DNS 更像 Clash 传统配置的延伸。你会看到 enhanced-mode、fake-ip、redir-host、nameserver-policy、fallback、fallback-filter、proxy-server-nameserver 这些字段。它适合从旧配置微调，因为字段名和大量中文教程里的写法接近。
sing-box 的 DNS 更像一套独立规则引擎。核心是 dns.servers、dns.rules、final 和 rule action；到 1.14.0-alpha 文档里，DNS rule 还继续扩展了 ip_version、query_type、match_response 等行为。稳定版用户不该直接追 alpha 字段，但可以看出 sing-box 的方向是把 DNS 解析纳入更严格的规则系统。
| 差异点 | Mihomo | sing-box | 选择建议 |
|---|---|---|---|
| 配置入口 | dns: 顶层 YAML | dns 对象 JSON | 旧 Clash 用户选 Mihomo 更省时间 |
| Fake-IP 控制 | enhanced-mode: fake-ip、fake-ip-filter | 通过 DNS rule、route rule 和 TUN 行为组合 | 需要细粒度规则时 sing-box 更清晰 |
| 分域名 DNS | nameserver-policy 支持域名和规则集 | dns.rules 用对象匹配并指定 action/server | 大量历史模板继续用 Mihomo |
| 代理节点域名解析 | proxy-server-nameserver 独立处理 | 通过 DNS server、route action 和 detour 组合 | 团队配置审计选 sing-box 更规整 |
| 迁移风险 | 字段多但容错高 | JSON 严格，层级错就不生效 | 新手不要手写完整 sing-box DNS |
DNS 迁移时先测两个域名：一个走常规解析，一个走你自定义规则。只要这两个域名的出口不一致，先停下来查 DNS，不要继续改协议字段。
rule-set 和 rule-providers 最大坑在哪里？
Mihomo 叫 rule-providers，sing-box 叫 rule-set。这不是换个名字那么简单，两边文件格式、引用方式、转换命令都不同。
| 项目 | Mihomo rule-providers | sing-box rule-set |
|---|---|---|
| 配置语言 | YAML | JSON |
| 来源类型 | http / file / inline | remote / local / inline |
| 常见格式 | yaml / text / .mrs | source JSON / .srs binary |
| 行为分类 | domain / ipcidr / classical | headless rule，放进 route 或 DNS rule 引用 |
| 转换方式 | mihomo convert-ruleset domain/ipcidr yaml/text xxx.yaml xxx.mrs | sing-box rule-set compile --output xxx.srs xxx.json |
| 旧 geodata 处理 | Clash 系配置还能见到 GEOSITE / GEOIP | 新配置应转向 rule-set，避免继续依赖旧 geosite / geoip 直引 |
2026 年不要把 .mrs 和 .srs 混在同一个规则仓库里当成同类文件。文件名看起来都像二进制规则集，实际只能被各自内核读取。
如果你从 Mihomo 迁到 sing-box，先迁 domain 和 ipcidr 两类规则。classical 规则里经常混着 DOMAIN-SUFFIX、IP-CIDR、PROCESS-NAME，直接转换后最容易出现命中顺序变化。
TUN 差异怎么影响 Windows、Linux 和 Android？
Mihomo 的顶层 tun: 对普通用户更友好，字段名是 Clash 系习惯：auto-route、auto-redirect、auto-detect-interface、dns-hijack、strict-route。Mihomo 文档还明确提示，listeners 里的 tun 更适合高级用户，普通用户优先用顶层 tun。
sing-box 把 TUN 放在 inbound 体系里，字段是 JSON 风格：type: tun、auto_route、auto_redirect、strict_route、route_address_set、route_exclude_address_set。Linux 上 auto_redirect 依赖 nftables，官方文档也把它作为更高性能、减少 Docker bridge 冲突的推荐项。
| 平台 / 问题 | Mihomo | sing-box | 排查重点 |
|---|---|---|---|
| Windows 多网卡 DNS | strict-route 可减少多宿主 DNS 解析问题 | strict_route 同样用于限制系统 DNS 行为 | 开启后检查 VirtualBox、WSL、公司 VPN 是否异常 |
| Linux 网关 | auto-redirect 配合 auto-route | auto_redirect、route_address_set 更细 | 确认 nftables、路由表编号和 Docker bridge |
| Android | 可用 include-package、exclude-package | 可用 package_name、package_name_regex 等规则 | 先关私人 DNS，再测应用级规则 |
| Apple 平台 | 依赖 GUI 客户端封装 | 图形客户端支持网络类型匹配更多 | 不要照搬 Linux TUN 字段 |
| 大规则集进 TUN | route-address-set 依赖规则集 | route_address_set / route_exclude_address_set | Android VpnService 对超大路由表更敏感 |
TUN 排错不要从协议开始，看虚拟网卡是否生成，再看 DNS 是否被接管，最后看 route rule 是否命中。顺序反了，会把一个路由表问题误判成协议问题。
协议覆盖还值得作为主因吗？
值得，但只在少数场景里值得。常见的 Shadowsocks、VMess、VLESS、Trojan、Hysteria 2、TUIC、WireGuard，两边都能覆盖到日常客户端需求。
sing-box 的优势是 Naive、AnyTLS 等前沿协议细节，以及服务端和客户端放在同一项目里维护的工程一致性。Mihomo 的优势是 Clash 系客户端生态，尤其是 Mihomo Party、Clash Verge Rev、OpenClash、FlClash 这类工具已经把大部分复杂度藏起来。
Mihomo v1.19.25 release 里继续新增 Tailscale outbound、OpenVPN outbound、GOST relay outbound proxy type 等能力，说明它不是只做旧 Clash 兼容。sing-box 1.13.12 则继续更新 naiveproxy 并修复问题，说明它仍在新协议和底层能力上快速推进。
| 协议或能力 | Mihomo | sing-box | 结论 |
|---|---|---|---|
| 常见订阅协议 | 覆盖日常足够 | 覆盖日常足够 | 不作为默认选择依据 |
| Naive | 不是 Mihomo 主线能力 | 官方文档列为 inbound / outbound | 依赖 Naive 时优先 sing-box |
| AnyTLS | 已有配置项和客户端跟进 | 官方文档列为 inbound / outbound | 追字段细节时优先 sing-box |
| OpenVPN / Tailscale outbound | v1.19.25 有新增 | 也在持续扩展相关能力 | 看客户端封装，不只看内核 |
| GUI 生态 | Mihomo Party、Clash Verge Rev 更成熟 | Karing、Hiddify 更友好但配置迁移仍有条件 | 新手桌面端先选 Mihomo |
从 Mihomo 迁到 sing-box 要重写哪些字段？
下面这张表比协议表更重要。只要你有一份超过 300 行的 Clash YAML，迁移成本基本都在这里。
| Mihomo / Clash YAML | sing-box JSON | 迁移备注 |
|---|---|---|
proxies | outbounds | 每种协议字段名不同，不能机械改名 |
proxy-groups | selector / urltest outbounds | 分组逻辑要重建 tag |
rules | route.rules | RULE-SET、MATCH、GEOIP 写法要改成对象规则 |
rule-providers | route.rule_set | .mrs 不能直接给 sing-box 读取 |
dns.nameserver-policy | dns.rules | 先迁域名规则，再迁 IP 结果规则 |
tun.auto-route | inbounds[].auto_route | 字段命名和默认行为都要重新比对 |
tun.dns-hijack | TUN + DNS inbound 行为组合 | 不同 GUI 封装会隐藏部分字段 |
迁移建议是保留旧 Mihomo 配置作为基线，另建一份 sing-box 最小配置，跑 mixed inbound、一个 outbound、一条 domain rule、一条 DNS rule，确认后再加 rule-set。不要一次性把完整订阅、规则、DNS、TUN 全部迁过去。
哪些情况不建议折腾迁移？
第一，桌面端只想导入订阅、点选策略组、偶尔看日志，继续用 Mihomo 系客户端。Mihomo Party 和 Clash Verge Rev 的学习成本低很多。
第二，OpenWrt 路由器已经跑得稳定，规则更新也正常，不建议为了协议覆盖迁移到 sing-box。路由器场景的代价不在内核，而在 DNS、DHCP、旁路由网关和家庭设备回滚。
第三，团队里只有一两个人能看懂 JSON 配置，其他人只会改 Clash YAML，不建议把主配置切到 sing-box。配置可维护性比内核先进性更重要。
sing-box vs mihomo 不覆盖什么
我没有在 2026-05-24 重新跑吞吐量基准测试，所以不写「谁快 10%」这类结论。不同系统协议栈、网卡驱动、规则数量和 GUI 封装都会改变结果。
我也不把 1.14.0-alpha.* 的字段写成稳定建议。sing-box alpha 分支已经出现 DNS rule、route rule、TUN 相关新项，但生产配置更适合跟随稳定版文档。
iOS 端没有把 Shadowrocket、Quantumult X、Surge 纳入同表比较，因为它们不是简单的 Mihomo vs sing-box 二选一。iOS 用户更该看客户端自身的规则语法和订阅兼容性。
结论怎么落地？
把选择压成四条规则：
- 桌面新手、Clash YAML 老用户、OpenWrt 用户，默认选 Mihomo。
- 服务端和客户端想用同一套配置模型，或者需要 Naive、AnyTLS 细节，选 sing-box。
- 已经有大量
.mrs、rule-providers、RULE-SET的配置，不要为了新协议贸然迁移。 - 真要迁移，顺序是 outbound、route rule、DNS、rule-set、TUN，最后再处理 GUI 导入。
Sing-box 和 Mihomo 都不是短期会消失的项目。2026 年的选择题不是谁更先进，而是谁能让你的 DNS、规则集和 TUN 在下一次更新后仍然可维护。