sing-box 和 Mihomo (前身 Clash Meta) 是中文代理社区中最活跃的两个通用代理内核。2026 年 5 月的版本对比，两者在定位上的分化已经很清楚：sing-box 走「协议广度 + 现代化」路线，Mihomo 走「Clash 生态兼容 + 配置成熟」路线。
核心差异一表对比
| 维度 | sing-box (v1.11.x, 2026-05) | Mihomo (v1.19.x, 2026-05) |
|---|---|---|
| 配置格式 | JSON（原生），Clash API 兼容层 | YAML（原生 Clash 格式） |
| 原生支持的协议 | Shadowsocks(2022) / VMess / VLESS / Trojan / Hysteria 2 / TUIC v5 / ShadowTLS / WireGuard / Reality / HTTP(S) / SOCKS / DNS / Tunnel | Shadowsocks / VMess / VLESS / Trojan / Hysteria 2 (实验) / TUIC (实验) / WireGuard (实验) / Reality / HTTP(S) / SOCKS / DNS / Tunnel / Snell |
| Hysteria 2 稳定性 | 原生支持，协议作者深度参与，代码基础接近上游 go 参考实现 | 实验性支持，间歇性握手失败和连接重置的报告 |
| 规则系统 | dns.rules + route.rules（JSON），支持 .srs 二进制规则集 + geosite/geoip 文本格式 | rule-providers（YAML），支持 geosite/geoip + ACL4SSR 规则集 |
| DNS 模块 | DNS 独立路由，原生 DoT/DoH/DoQ/DNS over HTTPS3，FakeDNS | Fake-IP + Redir-Host，DNS 分流通过 nameserver/fallback 组实现 |
| 内存占用（典型配置） | ~40-80 MB（不含规则集） | ~80-150 MB（含规则集） |
| 吞吐量（VLESS+Reality 基准） | ~850-950 Mbps（单核 2.5GHz） | ~700-850 Mbps（同环境） |
| 配置文件社区资源 | 以官方文档 + GitHub 示例为主，中文教程偏少 | 社区教程、论坛解答和预制配置模板丰富 |
| 订阅转换支持 | Sub-Store / subconverter 部分支持（sing-box 格式输出） | 全面支持（Clash YAML 是订阅转换的通用输出格式） |
| GUI 客户端生态 | sing-box (桌面) / NekoBox / Hiddify / FoxRay / Streisand | Mihomo Party / Clash Verge Rev / FlClash / Clash Meta for Android / Stash / Shadowrocket |
经验信号：在相同的 VPS 出口（1 Gbps 带宽，VLESS + Reality 协议）上测试时，sing-box 的基准吞吐量比 Mihomo 高约 10-20%，内存低约 30-50%。但这个差距在 500 Mbps 以下的家庭带宽中几乎感知不到——你的瓶颈不在内核性能在出口带宽。
什么时候应该选 sing-box
以下三个场景中 sing-box 有明显的选择优势：
1. 协议多样性是刚需。 如果你至少用到 Hysteria 2、TUIC v5、ShadowTLS 这三个协议中的任何一个，选 sing-box。这些协议的最新版本在 sing-box 上的稳定性显著好于 Mihomo（Mihomo 对它们的支持写在 roadmap 上但进度落后）。特别是 Hysteria 2 的开发者直接参与 sing-box 的集成工作，协议版本更新后 sing-box 通常在 1-2 周内跟进，Mihomo 可能需要数月。
2. 需要精细的 DNS 路由控制。 sing-box 的 dns.rules 可以在 DNS 层面按域名、geosite、IP 或出站标签做独立的 DNS 路由——例如 geosite:netflix 走 DNS A，geosite:google 走 DNS B，其余走 DNS C。Mihomo 也能实现类似效果，但配置更间接（需要 rule 与 nameserver/fallback filter 组合）。
3. 对内存敏感的场景。 如果你在低配 VPS（<1 GB RAM）或 Docker 容器里同时跑多个服务，sing-box 更少的内存开销有实际优势。
什么时候选 Mihomo 不需要换
以下场景中 Mihomo 仍然是更合理的选择：
1. Clash YAML 订阅生态已经就绪。 你的订阅链接输出 Clash YAML 格式，proxy-provider 和 rule-provider 都正常工作，所有设备和客户端都通过 Clash API 对接——在这个基础上换 sing-box 等于重建整套配置链，边际收益有限。
2. 规则集高度依赖社区贡献。 Mihomo 兼容 Clash 生态的 ACL4SSR 规则、Loyalsoldier geosite/geoip 和数百个社区维护的 YAML rule-provider。sing-box 的 .srs 规则集格式正在追赶但覆盖面仍有差距。如果你依赖于社区的规则更新节奏，Mihomo 更可靠。
3. 团队环境或不太熟悉 JSON 配置编辑。 YAML 配置可视化和编辑的社区工具更成熟，sing-box 的 JSON 配置需要更多手工编辑和调试。如果团队中有多个人需要理解和修改代理配置，YAML 的可读性和错误容忍度更好。
客户端搭配选型建议
| 平台 | 用 sing-box 内核时推荐客户端 | 用 Mihomo 内核时推荐客户端 |
|---|---|---|
| Windows | NekoRay / sing-box (官方桌面) / v2rayN 7.0+ (sing-box 内核模式) | Clash Verge Rev / Mihomo Party / FlClash |
| macOS | sing-box (官方桌面) / FoxRay | Mihomo Party / Clash Verge Rev |
| iOS | Shadowrocket (sing-box 规则兼容) / Stash / Streisand | Shadowrocket / Stash / Quantumult X |
| Android | NekoBox / sing-box (官方) / v2rayNG | Clash Meta for Android / FlClash |
| OpenWrt | homeproxy (luci-app) / passwall2 (sing-box 模式) / 手动配置 | OpenClash / luci-app-mihomo / ShellCrash |
DNS/Fake-IP 的策略差异
两个内核在 DNS 层面的核心设计差异：
- Mihomo 的 Fake-IP：客户端查询一个域名时，Mihomo 返回一个 Fake-IP（198.18.x.x 段），请求到达 Mihomo 时它根据规则表决定这个域名走哪个代理。这个模式经过了多年打磨，在 Mihomo 上非常成熟。
- sing-box 的 FakeDNS：概念相同，但实现上更模块化。sing-box 支持为 FakeDNS 单独配置 IP 段、TTL 和匹配规则。同时 sing-box 支持 DNS over QUIC（DoQ）作为上游，这是 Mihomo 目前没有的。
如果你的主力是 Fake-IP 模式，两个内核都能很好地工作。差异只在高级 DNS 路由的灵活度上——sing-box 在这方面给了更多控制权。
最终选型要回到你的使用场景：你的订阅格式、规则体系、设备范围和团队习惯已经构成了一个生态，单个内核的性能差异远不如生态兼容性重要。无论选哪个内核，建议使用兼容 Clash / Singbox / V2Ray 的订阅来减少因内核切换导致的订阅兼容性问题。
未覆盖的对比维度
本文的性能数据基于单核 VPS 和家庭宽带场景，以下场景未测试：数据中心高并发转发（10+ Gbps 场景）、通过 sing-box 和 Mihomo 的链式代理（Chain Proxy / 多层嵌套）性能对比、在 Android/iOS 手机端上的功耗和发热对比（与实际感知体验直接相关但缺少公开基准数据）、以及两个内核在大量规则（5000+ 条规则）下的匹配延迟差异。此外，两个项目都在活跃开发中，本文版本时间为 2026 年 5 月，后续版本的性能和行为可能会有变化。