sing-box 与 Clash（Mihomo）怎么选？协议、性能与上手门槛对比
简答：sing-box 更适合需要精细路由、较新协议和多平台统一配置的用户；Clash 生态通常指 Mihomo，更适合依赖订阅、图形客户端和成熟规则组的用户。性能不能只看核心名称，应在同节点、同时间和同模式下实测。
定义：本文所说的 Clash，具体指当前仍在维护的 Mihomo 核心及其相关客户端生态，而不是某一个单独的图形客户端。
先看结论：按使用场景选择，不要先按“谁更快”选择
本站是第三方使用指南站，本文只比较公开文档能够核对的功能与配置方式，不把某个客户端、订阅或线路的表现直接归因于核心名称。
最快判断：如果你主要使用订阅链接、希望少改配置、依赖策略组和图形界面，优先从 Mihomo 生态开始；如果你需要更细的路由动作、跨平台统一 JSON 配置、WireGuard endpoint 或更丰富的网络组件，sing-box 更值得研究。
- 机场订阅和日常使用：先选支持 Mihomo 的客户端，确认订阅格式、策略组和规则能够正常加载。
- 自建、软路由或跨平台配置：优先比较 sing-box 与 Mihomo 是否都支持你的入站、出站、DNS、TUN 和路由需求。
- 只关心速度：不要依据“瑞士军刀”“性能更强”等口号下结论，按本文的同条件测试方法记录延迟、丢包、吞吐和内存。
- 已经有可用的 Clash 配置：除非遇到协议、路由或平台能力缺口，否则没有必要仅因为 sing-box 配置格式不同就立即迁移。
需要先分清三层关系：核心负责连接、DNS、路由和代理协议；客户端负责界面、权限、订阅管理与开关；订阅转换器或配置生成工具负责把服务端信息变成某种格式。Clash Verge Rev 是跨 Windows、macOS 和 Linux 的图形客户端，其项目说明和发行记录都显示它围绕 Mihomo 内核工作；sing-box Desktop 则是管理和运行 sing-box 配置的桌面客户端。可分别查看 Clash Verge Rev 项目说明、Clash Verge Rev 发行记录 和 sing-box Desktop 官方说明。
核心定位与协议能力：两者不是简单的“新旧替代关系”
sing-box 的官方定位是通用代理平台，配置模型以 JSON 为主，组件覆盖入站、出站、DNS、路由、规则集、TUN、endpoint 和图形客户端。其出站文档列出了 VLESS、VMess、Trojan、Shadowsocks、Hysteria、Hysteria2、TUIC、AnyTLS、NaiveProxy、WireGuard 等类型，但具体协议能否使用，还要同时满足客户端、核心版本、服务端参数和平台权限条件。详情可查看 sing-box 出站类型文档。
Mihomo 的配置模型以 YAML 为主，常见使用方式是代理节点、代理提供者、策略组、规则和 TUN 配置组合。官方代理文档提供了统一的 proxies 节点结构，并在公共字段中提供 UDP、接口绑定、路由标记、TCP Fast Open、MPTCP、dialer-proxy 和 smux 等选项。详情可查看 Mihomo 出站代理文档。
Reality 不能作为“sing-box 不支持”的依据。sing-box 的出站类型包含 VLESS，Mihomo 的 TLS 配置也明确提供 reality-opts.public-key 和 reality-opts.short-id 等字段。因此，VLESS + Reality 是否能用，应检查节点参数、客户端配置映射和服务端兼容性，而不是简单认为某个核心不支持。Mihomo 相关字段可参考 Mihomo TLS 与 Reality 配置。
WireGuard 要特别注意配置代际。sing-box 官方文档已将 WireGuard outbound 标记为弃用，并说明应迁移到 endpoint；WireGuard endpoint 同时具有入站和出站行为。Mihomo 则在代理节点中直接提供 type: wireguard 配置方式。因此，迁移 sing-box 配置时不要机械复制旧的 outbounds WireGuard 字段，应先按 sing-box 迁移文档 和 WireGuard endpoint 文档调整。
协议与功能对比表：只比较客户端出站能力
下面的表格统一采用“客户端出站”口径。服务端入站文档不能直接证明客户端出站能力，因此没有把入站监听器字段混入比较。
从功能覆盖看，两者在常见代理协议上有较大重叠；真正容易拉开差异的地方，通常是配置表达方式、订阅转换结果、规则模型、平台客户端和权限处理。
配置、订阅和生态：Mihomo 更像成熟配置生态，sing-box 更像组件化平台
Mihomo 的优势在于配置生态。代理提供者可以下载远程节点集合并设置健康检查，策略组可以通过 select、URL 测试、备用和负载均衡等方式组织节点。官方文档还提供了代理组的测试地址、超时、预期状态码和节点筛选字段，适合订阅节点较多、需要快速切换和自动测试的场景。可参考 Mihomo 代理提供者文档 和 Mihomo 策略组文档。
sing-box 的优势在于结构化和组合能力。它把路由、DNS、规则集、入站、出站、TUN 和 endpoint 作为独立组件组合，适合需要为不同域名、进程、网卡、网络类型或 DNS 请求设置精细动作的用户。代价是 JSON 层级更多，字段名称与 Mihomo YAML 不能直接一一替换，迁移时必须按功能重新映射。
订阅兼容不能只看文件后缀。一个订阅可能包含协议节点、策略组、规则集、重命名规则和客户端专用字段。导入后应检查四项：节点是否全部出现、策略组是否有成员、规则是否命中预期策略、日志中是否成功建立连接。只看到“订阅导入成功”并不等于每个节点都能连接。
如果你使用图形客户端，先确认客户端实际加载的是哪个核心、配置文件位于哪里、TUN 开关是否需要服务模式或系统扩展权限。Windows 的 TUN 或服务模式通常需要允许服务或核心程序运行；macOS 可能需要在“隐私与安全性”中放行应用或系统扩展；Linux 则要检查专用用户是否有配置文件、缓存目录和创建 TUN 所需的权限，必要时使用具备 CAP_NET_ADMIN 的服务方式运行。sing-box 的 TUN 文档和 Mihomo 的 TUN 文档分别列出了自动路由、DNS 劫持、严格路由、协议栈和平台限制，可对照 sing-box TUN 配置 与 Mihomo TUN 配置。
Mux、TUN 与性能：如何做一场可复现的对比
Mux 不是默认越开越快。sing-box 支持 smux、yamux 和 h2mux，并允许设置最大连接数、最小流数、最大流数和 padding；Mihomo 的公共代理字段也提供 smux、协议、连接数、流数、padding 和仅 TCP 等设置。两边的字段名称和默认行为不能直接照抄，尤其要确认服务端是否兼容、UDP 是否绕过 Mux，以及开启后是否增加队头阻塞或连接复用问题。可参考 sing-box Multiplex 文档 和 Mihomo 公共代理字段文档。
建议按下面步骤测试，而不是凭体感比较：
- 使用同一台设备、同一网络、同一个节点和同一协议参数，分别导入 sing-box 与 Mihomo 配置。
- 先关闭 Mux、TUN 和额外的 DNS 优化，只测试普通 HTTP 或 SOCKS 代理，避免多个变量同时变化。
- 在同一时间窗口重复测试至少三轮，记录连接建立时间、延迟、丢包、下载吞吐、上传吞吐和进程内存。
- 再分别打开 TUN，确认 DNS 模式、MTU、路由表和代理规则一致；Mihomo 的 TUN 文档提供了不同协议栈说明，sing-box 则提供自动路由、严格路由和 DNS 模式字段。
- 最后单独测试 Mux：关闭、开启默认协议、调整连接数，每次只改一个参数，并观察长连接、多个并发下载和 UDP 应用是否出现异常。
- 检查日志中的实际命中策略，或对比出口 IP，确认测试流量确实经过目标节点；不要只看客户端开关显示为“已连接”。
如果测试结果差异很小，优先选择配置更容易维护、平台权限更少、订阅转换更稳定的一方。如果某个核心在特定协议、TUN 栈、DNS 或路由规则上明显满足你的需求，则功能匹配比单次测速结果更重要。没有同条件实测数据时，不应声称 sing-box 或 Mihomo 在所有网络环境下更快、更省内存或延迟更低。
迁移前检查清单：先验证需求，再决定是否换核心
可以把迁移拆成“能力、配置、平台、回滚”四步，避免因为格式不同导致原本可用的连接中断。
- 能力：列出正在使用的协议、TLS、Reality、Mux、UDP、DNS、TUN、规则集和 WireGuard，逐项确认目标核心有对应的客户端出站或 endpoint 文档。
- 配置：不要直接把 YAML 顶层
proxies、rules或策略组复制到 sing-box JSON，也不要把 sing-box 的出站字段直接粘贴到 Mihomo。应按“节点、路由、DNS、策略选择、规则集”分别重建。 - 校验：sing-box 配置可使用
sing-box check -c config.json；Mihomo 可使用mihomo -t -f config.yaml。命令名称和参数应以当前二进制帮助信息为准。 - 平台：Windows 检查 TUN 服务和防火墙放行；macOS 检查系统扩展、应用隔离和网络权限；Linux 检查 TUN 设备、专用用户、配置目录权限以及
CAP_NET_ADMIN；Android 检查 VPN 权限和应用分流；iOS 不能直接套用桌面客户端配置，应使用对应平台支持的客户端和配置格式。 - 回滚：保留原配置、节点订阅和客户端设置，先用普通代理模式验证，再开启 TUN；每次只替换一个变量，出现连接失败时更容易定位。
遇到“能启动但打不开网页”，优先按顺序检查：节点参数是否完整、策略组是否选中有效节点、DNS 是否能解析、规则是否把流量送到正确策略、TUN 是否获得权限、MTU 是否导致大包丢失，以及日志中是否出现握手失败或连接超时。
sing-box 与 Mihomo 客户端出站及使用场景对比
| 比较维度 | sing-box | Mihomo（Clash 生态） | 如何选择 |
|---|---|---|---|
| 核心定位 | 组件化通用代理平台，配置围绕 JSON、路由、DNS、入站、出站和 endpoint 组织 | 以 YAML 代理节点、代理提供者、策略组、规则和 TUN 组合为主 | 需要精细组合和多组件编排选 sing-box；重视成熟配置生态选 Mihomo |
| 常见协议 | 官方出站列表包含 VLESS、VMess、Trojan、Shadowsocks、Hysteria、Hysteria2、TUIC、AnyTLS、NaiveProxy 等 | 官方代理文档提供多种节点类型，并通过统一 proxies 结构配置出站代理 | 先按实际节点协议核对，不按名称判断全面支持 |
| VLESS + Reality | 可通过 VLESS 出站及 TLS 相关字段配置，字段需按当前文档填写 | TLS 配置提供 reality-opts.public-key、short-id 等字段 | 两者都应以节点参数和当前文档为准 |
| WireGuard | 旧 WireGuard outbound 已弃用，官方迁移方向是 WireGuard endpoint | 代理节点中提供 type: wireguard 配置 | 新 sing-box 配置不要继续照搬旧 outbound 写法 |
| 订阅与策略组 | 可通过配置和客户端能力组合实现，但不同订阅格式需要转换或重建 | 代理提供者和策略组文档较完整，适合节点集合、健康检查和手动选择 | 依赖订阅与策略组时优先核对客户端兼容性 |
| Mux | 支持 smux、yamux、h2mux，可配置连接数和流数 | 公共代理字段提供 smux、协议、连接数、流数和仅 TCP 等选项 | 必须与服务端和 UDP 需求一起测试，不能只看开关 |
| TUN 与 DNS | 提供 TUN、自动路由、严格路由、DNS 模式等组件 | 提供 TUN 协议栈、自动路由、DNS 劫持、严格路由和平台差异说明 | 按操作系统权限和实际排障难度选择 |
| 性能判断 | 没有官方资料证明在所有场景下必然更快或更省内存 | 同样不能仅凭核心名称判断延迟、吞吐或内存 | 使用同节点、同时间、同模式的重复测试 |
| 适合人群 | 自建用户、软路由用户、需要精细路由或多平台统一配置的用户 | 订阅用户、规则组用户、希望使用成熟 GUI 和 YAML 生态的用户 | 先按维护成本和功能缺口选，不要为迁移而迁移 |
常见问题
sing-box 比 Mihomo 更快吗？
不能仅凭核心名称下结论。速度受节点、协议、线路、DNS、TUN、MTU、Mux、设备和时间段影响。应使用同一节点、同一协议和同一网络重复测试延迟、丢包、吞吐与内存。
已有 Clash YAML，是否必须改成 sing-box JSON？
不必。只要现有 Mihomo 配置能够满足协议、规则、DNS、TUN 和平台需求，就没有必须迁移的理由。需要迁移时应按节点、路由、DNS、策略和规则集重新映射，不能直接改文件后缀。
sing-box 和 Mihomo 都支持 VLESS Reality 吗？
两者的官方文档都提供了相关客户端配置路径，但字段结构不同。sing-box 应按 VLESS 出站和 TLS 文档配置，Mihomo 应按代理节点与 reality-opts 字段配置，最终还要核对服务端参数。
sing-box 的 WireGuard 配置为什么不能继续放在 outbounds？
sing-box 官方已将 WireGuard outbound 标记为弃用，并提供迁移到 endpoint 的文档。新配置应优先使用 WireGuard endpoint；旧字段是否仍能运行取决于所用核心版本，不宜作为长期配置格式。
Mux 应该在 sing-box 和 Mihomo 中都打开吗？
不建议默认打开。Mux 需要服务端兼容，并可能改变并发连接、长连接和 UDP 行为。先关闭 Mux 建立基线，再单独开启并比较网页加载、并发下载、长连接和 UDP 应用是否改善。
Windows、macOS、Linux 上哪个更容易使用？
不能只按核心判断，客户端和权限更关键。Windows 重点检查 TUN 服务与防火墙，macOS 检查系统扩展和安全放行，Linux 检查 TUN、专用用户与配置目录权限。选择能覆盖目标平台且文档清楚的客户端更稳妥。