sing-box 是 SagerNet 维护的通用代理平台（The universal proxy platform）：用一份 JSON 配置，把流量入口、规则路由、协议出口和 DNS 解析组装成可运行的核心。它不是某一种隧道协议，也不是图形客户端本身。用户口中的 “开了 sing-box”，通常是指某个界面程序把这份核心跑了起来。

它解决的问题：协议碎片化

过去十年，代理生态被拆成几套几乎平行的栈：

  • Shadowsocks 及其变体解决轻量加密代理；
  • VMess/VLESS/Trojan 走 TLS 伪装与传输层组合；
  • Hysteria2、TUIC 走 QUIC，强调差网吞吐；
  • WireGuard 提供精简的三层 VPN 数据平面；
  • Clash 系客户端用规则文件管理 “哪些流量走哪条路”。

对使用者来说，这意味着为切换协议或设备而更换内核、重写配置、学习不同字段名。sing-box 的核心提案是：用统一的 inbound / route / outbound 模型容纳这些能力，同一二进制既可做本地客户端，也可做服务端。

项目使用 Go 编写，配置为 JSON，许可证为 GPLv3。官方文档与配置参考见 sing-box.sagernet.org，源码见 SagerNet/sing-box。

一张表看清它在生态里的位置

角色是什么不是什么
核心处理连接、路由、DNS、协议封装的引擎不是机场，也不自带节点列表
配置JSON：inbounds、outbounds、route、dns、experimental不是 Clash YAML，也不能直接当 Xray JSON 用
客户端官方有 SFA（Android）、SFI（iOS）、SFM（macOS）、SFT（tvOS）等配套应用不是所有 “支持 sing-box” 的第三方 App 都等于官方实现
协议可承载多种入站/出站协议不等价于其中任意一种协议的安全性或抗识别能力

所以评估 “好不好用” 时，要拆开三层：核心是否稳定、配置是否正确、具体出口协议和节点是否匹配当前网络。把三者混成一句 “sing-box 快/稳”，通常没有解释力。

数据面管线：inbound → router → outbound

官方客户端文档把流量管线画得很清楚。所有连接几乎都走同一条逻辑：

  1. Inbound 接收流量。可以是本机 SOCKS/HTTP 端口，也可以是 TUN 虚拟网卡，还可以是 Redirect/TProxy 这类系统层透明代理。
  2. Router 按规则决定去向。匹配域名、IP、端口、协议、进程名、Clash 模式等，动作包括转发到某个 outbound、拦截、嗅探或劫持 DNS。
  3. Outbound 真正把流量送走。可以是 direct 直连、block 丢弃，或某个代理/VPN 协议出口。

与此并行的是 DNS 子系统：名字解析有独立的 server 列表和 rules，不必与数据路由完全相同。例如：解析国内域名走本地 DNS，解析境外域名走加密 DNS；解析完成后再由路由规则决定连接本身走直连还是代理。

这套结构直接继承并发展了 Clash Premium 的思路：核心价值不在 “又实现了一个协议”，而在 把协议当作可插拔出口，把决策权交给路由和 DNS。

为什么这个模型重要

没有路由层，多协议只是一堆互不往来的客户端。有了路由层，才能表达真实需求：

  • 公司内网和私有地址直连，避免把局域网流量送出隧道；
  • 按域名而不是按 IP 分流，适应 CDN 反复变解析；
  • DNS 查询本身被劫持进核心，减少系统解析器造成的污染或泄漏；
  • 一组节点做自动测速或手动选择，而不改动每条规则。

Inbound：流量从哪里进入

官方 inbound 类型覆盖两类入口。

应用层入口：mixed、socks、http 等。浏览器、终端或系统代理设置主动连过来。权限要求低，但只能接管 “认代理” 的程序。

系统层入口：

  • tun：创建虚拟网卡，把操作系统路由过来的 IP 包还原成 TCP/UDP 连接（L3 到 L4）；
  • redirect / tproxy：Linux 上由 iptables/nftables 把已有连接改写入核心，常见于网关或软路由。

此外，同一核心还可以作为 服务端 inbound 接受 Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC、Naive、ShadowTLS、AnyTLS 等协议的入站连接。这也是 “同一个二进制既能当客户端又能当服务端” 的来源：角色差异主要是配置，而不是换软件。

TUN 模式是桌面/手机 “全局” 体验的关键。官方说明它继承并发展了 Clash Premium 的 TUN inbound，认为这是做透明代理较合理的方法。创建 TUN 之后，核心还要把 IP 包重组为连接，再交给路由器。栈的实现可选系统协议栈或 gVisor 一类用户态栈，在兼容性、性能和隔离之间取舍。更底层的虚拟网卡原理见 TUN 全局代理是什么。

Linux 上，官方还推荐在合适场景启用 auto_redirect：相对传统 TProxy，路由更完整、性能更好，并减少 TUN 与 Docker 桥接网络抢规则的冲突。这是运维层细节，但说明 sing-box 把 “接管系统流量” 当成一等能力，而不是附赠开关。

Outbound：协议丰富不等于可以混为一谈

出站侧同样是类型列表，而不是单一隧道。常见能力可以分成几簇：

簇代表数据面特征
传统代理Shadowsocks、VMess、VLESS、TrojanTCP 注入成熟，常叠加 TLS 与多种传输
QUIC 系Hysteria、Hysteria2、TUICUDP/QUIC，弱网吞吐通常更好，UDP 被限制时需要回退
VPN 数据平面WireGuard三层封装，协议本身不做浏览器伪装
伪装增强ShadowTLS、AnyTLS、Naive 入站等改善 TLS 外观或复用真实网络栈，代价和运维各不相同
逻辑出口direct、block、选择器、URL 测试组不传协议，只做策略组合

这里必须分开两件事：核心会不会说话，和 这句话在当前网络里好不好用。sing-box 支持 Naive 或 Hysteria2，并不自动获得对应协议的抗识别或速度表现；那些取决于对端实现、入口地址、TLS 指纹和路径质量。Naive 的设计逻辑见 NaiveProxy 协议科普；抗封锁则是持续对抗，见 VPN 抗封锁技术演进。

逻辑分组出口（选择器、自动测延迟）也很关键。很多图形客户端的 “手动选节点”“自动选最快” 并不在协议里，而在核心把多个 outbound 包成一组，再供规则引用。Clash API 的 clash_mode 也能作为路由条件：界面切换 Rule/Global/Direct 时，规则集可以跟着变，而不必重载整份配置。

路由：规则只是匹配器，动作才是决策

route.rules 按从上到下的顺序匹配。sing-box 1.8 之后用 rule_set 承载可下载、可复用的规则集；旧版 geoip / geosite 路径已被移除或迁移。对使用者这意味着：分流质量越来越依赖规则集的维护与更新，而不是核心内置一份永远过时的地理库。

常见匹配维度包括：

  • 域名、后缀、关键词、正则；
  • IP CIDR、是否私有地址、GeoIP 类规则集；
  • 端口、网络类型（tcp/udp）、嗅探得到的协议；
  • 进程名、包名、用户（平台能力不同，iOS 官方商店版通常弱于桌面或越狱版）；
  • Clash 模式。

动作不只是 “走哪个 outbound”。官方客户端示例里，TUN 场景的前两条往往是：

  1. sniff：从连接内容推断域名和协议；
  2. 对 DNS 协议做 hijack-dns：把本机 DNS 请求拉进核心，而不是让系统解析器自己问运营商。

没有嗅探，TUN 上很多域名规则会失效，因为你看见的只是 IP。没有 DNS 劫持，则会出现 “网页走了代理、解析还在本地” 的半接管状态。这两步不是高级玩法，而是 TUN 全局要工作完整的前提。

final 指定默认出口：规则都未命中时走哪里。auto_detect_interface 则绑定出站连接到系统默认网卡，避免 TUN 把 “去节点的包” 再次送进隧道形成环路。这与任何合格 VPN 客户端必须给节点留直连路由，是同一类工程问题。

DNS：独立路由器，而不是附属设置

sing-box 的 dns 块有自己的 servers、rules、final 和 strategy（ipv4_only、prefer_ipv6 等）。还可以启用 FakeIP：给域名分配虚拟地址，等连接到达核心时再反查真实目标。FakeIP 能让部分基于 IP 的系统更快进入代理路径，但也引入缓存、应用跳过系统 DNS、以及调试更困难等问题。

1.12/1.14 之后，域名解析与出站拨号进一步解耦，例如 default_domain_resolver 指定出站连节点时用哪台 DNS；optimistic cache 允许过期记录先应答再后台刷新。这些选项说明 DNS 已被当成性能与正确性的主路径，而不是 “填一个 8.8.8.8 就结束”。

实践上应同时问四个问题：

  1. 应用的 DNS 请求是否进入核心？
  2. 不同域名是否使用匹配其出口的解析器？
  3. IPv4/IPv6 策略是否与路由一致？
  4. 浏览器 DoH 是否绕过了系统解析？

现代 VPN 的完整链路讨论见 现代 VPN 技术架构。

Clash API：兼容的是面板，不是配置文件

experimental.clash_api 提供与 Clash 面板相近的 REST/WebSocket 接口：流量统计、节点选择、模式切换、连接列表。因此 Yacd 一类仪表盘可以监看 sing-box。这降低了从 Clash 图形习惯迁移的成本。

它 不 表示 Clash YAML 订阅可以直接当 sing-box 配置用。字段结构、规则语法、inbound 名称都不一样。第三方客户端如果声称 “导入 Clash 订阅”，通常是在界面层做了转换，转换质量因客户端而异，不能当成核心原生能力。

Clash API 若监听在所有网卡地址上，必须设置 secret。这是本地安全问题，与代理协议无关：未鉴权的控制面等于把选节点和看连接的权限交给局域网。

官方客户端与第三方套壳

图形层不是核心的一部分，但决定大多数人如何使用它：

名称平台作用
命令行 sing-boxLinux/Windows/macOS 等直接加载 JSON，适合网关、脚本与开发调试
SFAAndroid官方应用，提供 TUN 等平台实现
SFIiOS官方应用；大陆区 App Store 可用性受商店审核影响
SFMmacOS官方应用，也有独立安装方式
SFTtvOSApple TV 上的官方配套应用

官方 Apple 文档写明：SFI/SFM/SFT 用来管理并运行本地或远程配置，并提供 TUN 透明代理等平台相关实现。也就是说，手机上的 “系统 VPN 开关” 仍然由操作系统 API 提供，sing-box 负责后面的协议与路由。

第三方客户端可能嵌入旧版核心、修改默认路由，或同时兼容多种订阅格式。遇到 “同样的节点，A 应用能用、B 应用不能用”，应先核对核心版本、TUN/DNS 是否启用、规则是否被客户端改写，而不是先换节点。

和 Mihomo、Xray 怎么比

三者经常被放在一起评选 “最好的客户端”，比较对象其实错位。更准确的对照是核心路线：

维度sing-boxClash Meta / MihomoXray
配置JSON，inbound/outbound/routeYAML，代理组 + 规则JSON，inbound/outbound/routing
协议面代理、QUIC 系、WireGuard、TUN 等较全规则与订阅生态强，协议集不同深耕 VLESS/Vision/Reality 一类
角色同一二进制可作客户或服务端以客户端核心为主常见于服务端 + 各类套壳客户端
面板可选 Clash API原生 Clash 生态另有 V2Ray API 等
迁移成本需新配置或客户端转换机场最常直接提供VMess/VLESS 链接生态最大

选择建议可以写得很具体：

  • 需要 一份核心覆盖 Hysteria2、TUIC、WireGuard 和传统代理，并接受 JSON：sing-box 匹配度高；
  • 需要 现成 Clash 订阅、大规模规则集、成熟 GUI：Mihomo 系仍然省事；
  • 需要 与现有 Xray 服务端和对 Reality 配置的最大社区经验对齐：继续用 Xray 往往阻力更小。

没有必要把它们理解成更新换代关系。它们是对 “协议实现 + 流量决策 + 系统接管” 的不同拼装。

能力边界与常见误解

误解 1：换了 sing-box 就等于换了更隐蔽的协议。
核心不决定外层指纹。出口仍是 WireGuard，看见的就是 WireGuard；出口是 Reality 或 Naive，指纹才跟随那些协议。

误解 2：开了 TUN 就是全局且无泄漏。
IPv6 未接管、DNS 未劫持、节点缺少直连例外、浏览器 DoH、虚拟机桥接，都会造成旁路。这些是系统网络问题，见 TUN 全局代理 的排查层次。

误解 3：官方客户端和 “支持 sing-box 的 App” 行为相同。
默认规则、内核版本、进程规则是否生效、订阅转换是否丢字段，都会造成差异。

误解 4：规则越多越智能。
规则是顺序匹配。过长、互相覆盖、依赖过期 geosite 镜像，只会造成难调试的错误分流。rule_set 需要版本和来源可追踪。

sing-box 也不处理产品层问题：账号体系、节点质量、日志政策、法律合规都不在核心里。它只保证：在配置正确的前提下，把匹配到的流量按指定 outbound 转发出去。

适合谁，不适合谁

更适合：

  • 需要同一套配置逻辑覆盖电脑、软路由和部分移动端；
  • 要在一个进程里组合多种出口协议，而不是并排开多个内核；
  • 愿意阅读 JSON、理解 TUN/DNS/规则顺序的进阶使用者或网关维护者。

可以暂缓：

  • 只想导入一份机场 Clash 订阅并一键连接；
  • 设备性能很弱，TUN + 复杂规则集导致明显耗电；
  • 完全依赖某个 GUI 特有功能，而该 GUI 并未跟上当前核心版本。

读配置时的检查顺序

面对一份 sing-box JSON，比从第一行字段抠起更有效的顺序是：

  1. inbounds：流量从端口进来，还是从 TUN/TProxy 进来？
  2. dns：解析请求是否被劫持，默认策略是否关掉了 IPv6？
  3. route.rules 前几条：有没有 sniff 和 hijack-dns？私有 IP 是否直连？
  4. final / auto_detect_interface：默认出口和防环路是否存在？
  5. outbounds：真正出网的协议是哪一个，逻辑分组里有哪些成员？
  6. experimental：Clash API 是否只绑在本地、是否设置了 secret？

这条清单也适用于故障：ping 通节点但网页打不开，多半停在 DNS 或嗅探；能浏览器不能游戏，多半停在 inbound 类型而不是 outbound 协议。

一句话把握

把 sing-box 理解成 带独立 DNS 的可编程连接路由器：inbound 解决如何接管流量，outbound 解决如何说话，route 解决对谁说哪句话。协议名单会变长，这个三分结构相对稳定。理解它之后，再去看具体协议、节点和客户端包装，才不会把 “换内核” 误当成 “换网络环境”。

主要技术资料