Mihomo 和 sing-box 对比：先看订阅与设备，再决定用哪个
简答：一句话结论：只想快速导入常见订阅、沿用 Clash 规则和代理组，优先考虑 Mihomo；需要更模块化的 JSON 配置、规则集和跨平台内核能力，再考虑 sing-box。两者的速度、延迟和耗电不能脱离设备、节点、协议、DNS 与配置单独下结论。
定义：Mihomo 和 sing-box 都是代理客户端可调用的网络内核，但内核、图形客户端和订阅链接不是同一个东西，配置格式也不能默认互换。
先看结论：按使用场景选择
如果你现在最关心的是“订阅能不能直接导入”，先确认订阅输出格式，而不是先看内核名称。Mihomo 主要使用 YAML 配置；sing-box 官方配置采用 JSON 结构，包含 DNS、路由、规则集、入站和出站等模块。两者都能处理代理节点、路由和 TUN，但字段名称、规则模型和订阅转换方式不同。可先用下面的表格缩小范围。
| 使用场景 | 优先考虑 | 判断理由 | 需要注意 |
|---|---|---|---|
| 已有 Clash/Mihomo YAML、代理组和规则提供者 | Mihomo | 迁移成本通常更低，原有配置结构更容易延续 | 仍要核对客户端内置内核版本与字段兼容性 |
| 希望使用 JSON、模块化路由和规则集 | sing-box | 官方文档将 DNS、Route、Rule Set、Inbound、Outbound 分开组织 | 不能把 Mihomo YAML 直接当作 sing-box JSON 使用 |
| 只想导入一条订阅并日常切换节点 | 看客户端支持 | 真正决定能否导入的是客户端与订阅格式匹配 | 先确认输出是 Clash/Mihomo、sing-box、通用 URI 还是需要转换 |
| 复杂分流、DNS、TUN 和多出口组合 | 按配置能力选择 | 两者都有 TUN、DNS 和路由能力，但字段与规则写法不同 | 不要将一个内核的示例字段复制到另一个内核 |
| 低配设备或手机续航优先 | 不要先凭名称决定 | 实际负载受协议、规则数量、日志级别、TUN 和 DNS 设置影响 | 应在同一设备、同一节点、同一配置下测试 |
官方资料显示，Mihomo 的配置文档覆盖通用配置、DNS、TUN、代理、代理组、规则和 API；sing-box 的配置则按 DNS、Route、Rule Set、Inbound、Outbound 等模块组织。由此可以确认两者都不只是“节点播放器”，但它们的配置体系并不相同。参考 Mihomo 配置文档 与 sing-box 配置总览。
Mihomo 与 sing-box 的核心差异
1. 配置格式：YAML 与 JSON 不是简单换后缀
Mihomo 常见配置以 YAML 表示，层级结构依靠缩进；sing-box 官方示例使用 JSON，字段通常位于 inbounds、outbounds、route、dns 等对象中。迁移时不能只把文件格式化或改扩展名，因为代理节点、代理组、规则、DNS 和 TUN 的字段模型都可能不同。
2. 规则体系：代理组与规则集的组织方式不同
Mihomo 文档提供代理组、规则和规则提供者等配置入口；sing-box 文档提供 Route Rule 与 Rule Set。sing-box 官方说明，Rule Set 用于组织规则数据，并且 Geosite 已被弃用并在 1.12.0 移除。若旧配置仍依赖 Geosite，迁移前应先查找替代的规则集方案，不要直接照抄旧字段。参考 sing-box Route Rule、sing-box Rule Set 与 sing-box 废弃配置说明。
3. 协议：重叠很多，但不能按“支持数量”下结论
官方文档列出的重叠协议包括 Shadowsocks、VMess、Trojan、VLESS、WireGuard、Hysteria、Hysteria2、TUIC 和 AnyTLS 等；Mihomo 文档还列出 ShadowsocksR 等配置入口。sing-box 的当前出站列表则明确列出 WireGuard、VLESS、Hysteria2、TUIC 和 AnyTLS 等类型。协议是否能用，还取决于传输层、TLS、Reality 参数、认证方式、客户端版本和服务端配置，不能只看协议名称。参考 sing-box 出站类型、Mihomo 代理通用字段 与 Mihomo TLS 与 Reality 配置说明。
4. TUN、DNS 和 IPv6：功能相似，排错入口不同
Mihomo 的 TUN 配置用于捕获系统流量、DNS 劫持和按应用路由；官方文档同时提醒，TUN 属于进阶用法。sing-box 也提供 TUN、DNS、路由规则和 FakeIP 等模块。实际连接失败时，应分别检查：TUN 是否获得系统权限、DNS 请求是否进入预期的 DNS 配置、规则是否命中、IPv6 是否走了另一条路径，以及日志中是否出现证书、解析或握手错误。
订阅能否直接导入：按这 6 步核验
- 先备份现有配置。复制原 YAML 或 JSON 文件，保留一份可以恢复的版本，不要直接覆盖。
- 识别订阅输出格式。查看客户端导入选项或订阅说明，确认它输出的是 Mihomo/Clash YAML、sing-box JSON、单节点 URI，还是需要转换的格式。
- 确认客户端使用的内核。一个图形客户端可能支持切换内核，也可能只内置其中一种；“能打开订阅链接”不等于“能解析所有字段”。
- 先导入一个最小配置。只保留一个已知可用节点、一个出站或代理组，以及最基本的 DNS 和路由，避免一次加入大量规则导致错误难定位。
- 保存并校验。检查 YAML 缩进、JSON 括号、字段拼写、节点类型、端口、UUID、TLS 参数和规则引用。不要把敏感 token、Cookie 或完整订阅地址发布到公开平台。
- 重新载入并查看日志。依次观察配置加载、DNS 解析、节点握手、规则命中和业务访问结果。若日志显示字段未知、类型不匹配或规则集加载失败，应回退到备份并逐项迁移。
判断结果可以简单分为三类：如果订阅格式与内核原生匹配，通常可以直接导入；如果是通用节点链接，可能需要客户端重新生成配置；如果依赖特定代理组、规则提供者或旧字段，则需要转换或手工重写。没有看到订阅内容和客户端版本时，不能直接保证兼容。
性能怎么比较：不要把单次测速当成通用结论
Mihomo 与 sing-box 的性能差异应至少拆成吞吐、延迟、丢包、内存、CPU、耗电和业务结果。单独看到某篇文章的峰值速度，无法推出所有设备上的结果，因为测试还会受到节点协议、线路、MTU、DNS、TUN、规则数量、后台任务和运营商网络影响。
| 测试维度 | 统一条件 | 建议记录 | 如何解读 |
|---|---|---|---|
| 延迟 | 同一设备、同一节点、同一时间段 | 连接延迟、首包时间、波动 | 延迟低不代表下载速度一定高 |
| 丢包 | 同一目标地址与相同探测次数 | 丢包率、连续超时、重连次数 | 丢包高时先查线路、Wi-Fi、MTU 和 UDP |
| 速度 | 同一节点、同一协议、相同并发 | 单流、多流、上下行结果 | 不要混用不同节点或不同协议 |
| 资源占用 | 相同规则、日志和 TUN 设置 | 空闲与高负载时的 CPU、内存、耗电 | 手机与路由器的结果不能直接类比 |
| 业务结果 | 相同网站、应用或办公系统 | 打开时间、上传下载、长连接稳定性 | 业务体验比单一峰值速度更有参考价值 |
截至 2026 年 10 月 27 日，本文不采用未公开完整环境、配置和原始数据的第三方精确测速结论。更稳妥的做法是先用同一节点分别运行两个内核，再记录日志、规则命中和业务结果。
按设备与用户类型给出选择建议
- Windows 新手：如果已有 Clash/Mihomo 配置或只想导入常见订阅，先选能直接解析现有格式的客户端与 Mihomo；如果新建 JSON 配置并需要更细的路由模块，再考虑 sing-box。
- macOS 用户：先确认图形客户端是否内置目标内核、是否支持 TUN、系统权限和 DNS 设置，再决定配置格式。不要因为客户端名称相同就假定字段完全兼容。
- Android 用户：优先选择能清楚展示 VPN 权限、TUN、DNS、日志和配置导入状态的客户端。遇到无网络时，先关闭 TUN 或恢复系统网络，确认是内核配置还是节点本身的问题。
- iOS 用户：重点看客户端对订阅格式、系统 VPN 权限、DNS 和规则更新的支持，内核选择必须服从客户端实际提供的导入方式。
- Linux 或路由器用户：如果需要服务化运行、脚本管理或精确拆分入站与出站，可重点比较配置模块、日志和系统集成；如果依赖成熟的代理组和规则提供者结构，则先评估迁移工作量。
- 复杂规则用户：选择前先列出必须保留的功能：代理组、规则提供者、FakeIP、DNS 分流、IPv6、TUN、WireGuard 或特定协议，再逐项核对官方文档，而不是只比较“哪个更快”。
从 Mihomo 迁移到 sing-box，最容易出错的地方
- 把 YAML 直接改成 JSON。这只能改变表现形式，不能完成字段映射。
- 把代理组当成普通节点。Mihomo 的代理组与 sing-box 的 selector、urltest 等出站类型不是一一同名对应。
- 忽略规则格式。旧的 Geosite 或规则提供者引用可能需要改为 sing-box 的 Rule Set。
- 照抄 TLS 参数。server_name、Reality、ALPN、证书校验和传输层字段必须按目标内核文档重写。
- 只看启动成功。配置能载入不代表 DNS、TUN、IPv6、规则命中和真实业务都正常。
建议采用“编辑配置—保存—校验—重新载入—查看日志—验证业务”的顺序。先迁移一个节点和一条规则，确认访问结果后，再逐步加入 DNS、TUN、代理组和规则集。
本文的选择速查卡
选 Mihomo：你已有 Clash/Mihomo YAML、代理组和规则提供者，希望少改配置并快速继续使用。
选 sing-box：你愿意使用 JSON，重视模块化 DNS、路由、规则集和入站/出站结构，或准备围绕 sing-box 重新整理配置。
先不选内核：你还不知道订阅输出格式、客户端支持什么，或者当前问题其实是节点失效、DNS 错误、IPv6 路由或 MTU 不匹配。此时先完成连接排查，比迁移内核更有效。
常见问题
Mihomo 和 sing-box 哪个速度更快？
没有脱离测试条件的通用答案。速度会受到节点、协议、线路、设备、TUN、DNS、MTU 和规则数量影响。若要比较，应固定同一设备、同一节点和同一配置，并同时记录延迟、丢包、速度、CPU、内存和业务结果。
Mihomo 的 YAML 能直接导入 sing-box 吗？
通常不能直接导入。两者的配置结构和字段模型不同，尤其是代理组、DNS、路由、规则提供者和 TUN 部分。应先确认订阅输出格式，再使用对应客户端支持的转换方式，最后通过校验和日志逐项检查。
订阅链接能不能同时用于 Mihomo 和 sing-box？
不能只看链接本身判断。若服务端提供多种格式，可能分别生成 Mihomo/Clash YAML、sing-box JSON 或通用节点链接；如果只提供一种格式，就要确认目标客户端是否支持解析，必要时进行转换。具体以订阅提供方和客户端当前支持为准。
Reality、Hysteria2、TUIC 和 WireGuard 两边都支持吗？
官方文档可以确认两者都覆盖多种现代协议，但具体支持边界取决于内核版本、客户端封装、传输层和服务端参数。不要只复制协议名称，必须逐项核对节点类型、TLS、认证、UDP、端口和路由配置。
从 Mihomo 迁移到 sing-box，应该先改什么？
先备份原配置，再只迁移一个节点和最简单的出站，确认配置能加载并完成一次业务访问；之后依次迁移 DNS、路由规则、代理组、TUN 和规则集。每完成一层就查看日志，避免一次迁移全部配置后无法定位错误。