sing-box 对比 Mihomo：先分清内核、客户端和订阅格式
简答：一句话结论：已有 Clash/Mihomo YAML 配置、依赖规则提供者和策略组时，优先继续用 Mihomo；需要 JSON 配置、sing-box 原生规则集或与 sing-box 服务端保持同一套配置时，再考虑 sing-box。两者的速度不能脱离同一节点、同一设备和同一规则环境直接下结论，换内核前先确认客户端支持、订阅格式和回滚方式。
定义：sing-box 与 Mihomo 都属于代理内核，负责解析节点、DNS、路由和 TUN 等功能；客户端是承载内核的图形界面，订阅则是节点或配置分发格式，三者不能混为一谈。
三步速查：先按你的配置决定，不要先争论谁更快
第一步：看现有配置。如果手里已经是 Clash 风格 YAML，并且使用策略组、rule-providers、Fake-IP 或大量现成规则，先选 Mihomo，迁移成本通常更低。Mihomo 官方文档明确说明其配置文件使用 YAML，缩进和字段层级会直接影响解析结果，语法说明可作为校验依据。
第二步：看订阅与客户端。sing-box 使用自己的 JSON 配置结构，具有独立的 inbound、outbound、route、DNS 和 rule-set 体系。能导入某种订阅，不代表能完整保留策略组、脚本、规则集、DNS 和 TUN 参数；需要以具体客户端的导入说明为准。
第三步：看是否需要迁移。如果当前 Mihomo 已经能正常连接，且没有明确的协议、规则或部署需求，不建议仅凭“性能更强”这类未经同场景验证的说法更换内核。先备份原配置，再导入一个最小配置测试，失败时可以立即回滚。
核心对比表：配置、规则、DNS 和 TUN 的差异
| 比较项 | sing-box | Mihomo | 选择建议 |
|---|---|---|---|
| 配置格式 | JSON 结构，常见顶层模块包括 inbounds、outbounds、route、dns | YAML 结构，常见字段包括 proxies、proxy-groups、rules、dns、tun | 已有 Clash YAML 选 Mihomo；希望使用 sing-box 原生结构选 sing-box |
| 规则体系 | 支持 route rule 与 rule-set，规则动作包含 route、reject、hijack-dns、sniff 等 | 支持 rules、rule-providers、代理组和多种 Clash 风格匹配规则 | 规则迁移不能只改文件后缀，要逐项核对动作和匹配顺序 |
| DNS | 通过 DNS server、DNS rule 和 route 的 hijack-dns 等机制组合 | 提供 nameserver、fallback、nameserver-policy、Fake-IP 等配置项 | DNS 复杂、需要分流时，先按原配置逻辑重建，不要直接照抄字段 |
| TUN | 支持 TUN、auto_route、dns_mode、strict_route 等字段；官方文档注明 TUN 支持 Linux、Windows 和 macOS | 支持 TUN、自动路由、DNS 劫持、设备和应用范围控制 | 两者都能做透明接管，具体行为取决于系统权限、客户端实现和配置 |
| 规则资源 | 使用 local、remote、inline 等 rule-set 类型，可配置 source 或 binary 格式 | 使用 rule-providers，可选择 http、file、inline，并指定 domain、ipcidr 或 classical 行为 | 规则资源不能直接互换，先确认文件格式和匹配类型 |
| 协议字段 | 按 sing-box 自己的 outbound 结构配置 VLESS、Hysteria2、TUIC、WireGuard 等 | 按 Mihomo 的 proxies 结构配置相应节点类型和传输参数 | 同名协议不等于字段兼容，重点核对 TLS、Reality、传输层和 UDP 参数 |
上表中的规则动作和 TUN 行为应以当前版本文档为准。sing-box 官方规则动作文档列出了 sniff、hijack-dns、route 和 reject 等动作；Mihomo 官方文档则分别说明了 DNS、TUN 和 rule-provider 的配置方式。参考：sing-box Rule Action、sing-box Tun、Mihomo DNS、Mihomo Rule Providers。
配置格式怎么选：JSON 与 YAML 不是简单换后缀
Mihomo 配置通常以 YAML 表达，层级依赖缩进，字段名、冒号后的空格和列表结构都可能影响加载。sing-box 则使用 JSON 配置对象，官方示例把入站、出站和路由拆成不同模块。两者的节点信息即使都描述 VLESS、Hysteria2 或 WireGuard，也不意味着可以直接复制。
例如，Mihomo 的节点通常放在 proxies 下，代理组放在 proxy-groups 下；sing-box 则需要把节点转换为对应的 outbound，并在 route 中指定匹配后的目标。迁移时至少要核对以下字段：
- 服务器地址、端口、UUID、密码或密钥是否完整；
- TLS 的 server name、证书校验、Reality 公钥和 short ID 是否对应；
- WebSocket、gRPC、HTTP、H2 或 XHTTP 等传输层字段是否被目标内核支持；
- UDP、WireGuard AllowedIPs、MTU 和 DNS 处理方式是否改变；
- 策略组、订阅更新、规则集、脚本和分流逻辑是否需要重建。
如果订阅只能输出 Clash/Mihomo 格式，不能据此推断 sing-box 可以直接完整导入。更稳妥的做法是先询问订阅提供方支持的格式，再使用目标客户端提供的导入或转换功能，并检查转换后是否丢失策略组、DNS、规则集和特殊协议字段。
DNS、Fake-IP 与 TUN：连接异常时先看这三层
第一层是 DNS 解析。Mihomo 文档提供了 nameserver、fallback、nameserver-policy、proxy-server-nameserver 和 Fake-IP 等选项；其中 Fake-IP 还可以通过过滤规则决定哪些域名返回真实地址。sing-box 则通过 DNS server、DNS rule 和 route 规则分别处理查询路径。不要把某一套 DNS 字段原样粘贴到另一套配置中。
第二层是 DNS 劫持。启用 TUN 后，如果系统 DNS 请求没有进入内核的 DNS 模块，可能出现域名解析异常、规则匹配不符合预期或直连与代理结果不一致。sing-box 官方文档将 hijack-dns 定义为把 DNS 请求交给内部 DNS 模块；Mihomo 的 TUN 文档也说明了 DNS 劫持和系统 DNS 的关系。
第三层是路由接管。TUN 是否生效还取决于系统权限、自动路由、严格路由、网卡和防火墙。假如启用 TUN 后所有连接都失败，先关闭 TUN，只保留本地 HTTP 或 SOCKS 入站测试节点；如果本地代理正常，再单独检查 DNS 劫持、默认路由和系统权限。
建议按以下顺序验证：先确认节点自身能连接，再确认域名能解析，然后测试规则命中，最后才开启 TUN。这样可以把“节点问题、DNS 问题、规则问题、系统路由问题”分开。
按使用场景选择：谁更适合 Mihomo，谁更适合 sing-box
- 已有 Clash 配置或大量现成规则：优先 Mihomo。重点是减少迁移工作，继续使用已有 YAML、代理组和 rule-provider，并先验证当前客户端是否支持目标字段。
- 刚开始配置，且没有历史包袱：两者都可以。若更习惯图形客户端和现成规则生态，可先用 Mihomo；若愿意学习 JSON、route rule 和 rule-set，可从 sing-box 开始。
- 需要 VLESS、Reality、Hysteria2、TUIC 或 WireGuard：不要只看协议名称，分别检查目标客户端和内核文档中的字段。Mihomo 官方提供 VLESS 和 WireGuard 配置说明，sing-box 也提供对应 outbound 文档，最终以实际配置字段为准。
- 需要复杂 DNS、分流和 TUN：两者都能配置，但排查方式不同。优先选择你能看懂日志、能备份配置、能快速关闭 TUN 的那一个。
- 运行在 OpenWrt 或旁路由：先确认系统架构、安装包、权限、网卡和防火墙集成方式，再决定内核。不要仅凭桌面端体验推断路由器上的吞吐、延迟或稳定性。
- 重视可迁移性：保留原订阅、原配置和节点参数，逐项建立新配置。不要覆盖旧文件，迁移完成并验证后再考虑清理。
迁移实操：从 Mihomo 换到 sing-box，或反向迁移
- 备份：复制原配置、订阅链接、规则文件和客户端设置，记录当前使用的模式、DNS、TUN、端口和代理组。
- 列字段：把节点、传输层、TLS、DNS、规则、TUN 和系统代理分成清单，不要只复制节点地址。
- 先做最小配置：只保留一个节点、一个本地入站、一个默认出站和一条简单路由。先验证内核能启动，再逐步加入 DNS 和规则。
- 检查版本差异：sing-box 官方文档会标注字段的新增、弃用和移除版本；Mihomo 也可能随版本调整字段。发现弃用警告时，按当前文档迁移，不要继续堆叠旧字段。
- 分阶段启用：先测试本地代理，再启用规则模式，再启用 DNS 处理，最后启用 TUN。每一步都保留可回滚副本。
- 看日志：重点观察配置解析失败、DNS 超时、TLS 握手失败、规则未命中、TUN 权限不足和地址解析失败。
- 撤销：关闭新内核和系统代理，恢复原客户端配置，清理新建的虚拟网卡或路由，再重新打开原配置。
性能方面不要直接下结论。没有相同设备、相同节点、相同协议、相同 DNS、相同规则和相同时间段的复现实验，就不能把某个内核描述为一定更快、更省内存或更稳定。
最终决策：用这张清单避免选错
选 Mihomo：你已有 Clash 风格 YAML、策略组和 rule-provider，主要目标是导入后少改配置，并希望沿用现有规则维护方式。
选 sing-box：你愿意使用 JSON 配置，需要 sing-box 的 route rule、rule-set、DNS 结构，或希望客户端与服务端采用相近的配置模型。
暂时不要换：当前连接正常，只是看到别人声称某个内核“更快”或“更省资源”，但没有同环境、同节点、同配置的测试数据。
截至 2026年10月27日，两套项目的字段和客户端实现都可能继续变化。正式迁移前，应打开对应版本的官方文档和 Release 页面，确认配置字段、平台支持和弃用提示。
常见问题
sing-box 和 Mihomo 可以同时安装吗？
可以在同一设备上分别保存，但不要让两个内核同时占用相同本地端口、系统代理、TUN 接口或路由。测试时一次只启动一个，并记录端口和系统代理状态。
Clash 订阅能直接导入 sing-box 吗？
不能一概而论。Clash/Mihomo 和 sing-box 的配置结构不同，是否能导入取决于客户端是否提供转换、订阅服务是否输出目标格式，以及策略组、规则集和 DNS 字段能否完整保留。
哪个速度更快？
没有脱离测试条件的固定答案。速度和延迟还受到节点、协议、线路、DNS、MTU、设备性能、规则和拥塞状况影响。应使用同一节点、同一设备和同一时间窗口进行对照。
已有 Mihomo 配置，什么时候值得迁移到 sing-box？
当你有明确需求，例如目标客户端只支持 sing-box 格式、需要 sing-box 的规则集结构，或希望统一某套 JSON 配置时再迁移。仅为追求未经验证的性能差异，不建议直接覆盖原配置。
启用 TUN 后没网，先检查什么？
先关闭 TUN，确认本地 HTTP 或 SOCKS 代理能连接；随后检查系统权限、DNS 劫持、自动路由、严格路由、默认网卡和防火墙。通过“本地代理—规则—DNS—TUN”的顺序定位，比一次开启所有功能更容易复现。
常见问题
sing-box 和 Mihomo 的最大区别是什么？
主要区别在配置结构和生态：sing-box 使用独立 JSON、route 和 rule-set 体系；Mihomo 使用 YAML、代理组和 rule-provider 体系。
Mihomo 配置能直接改成 sing-box 配置吗？
不能只改文件后缀。需要重新映射节点、TLS、传输层、DNS、规则、代理组和 TUN 字段。
哪个更适合新手？
已有 Clash 配置的新手通常更适合先用 Mihomo；没有历史配置、愿意学习 JSON 和 route 规则的用户也可以选择 sing-box。
怎么判断是否值得迁移？
先写出明确目标：格式、协议、DNS、TUN、客户端或部署需求。没有明确目标时，备份原配置并继续使用当前可用内核更稳妥。