sing-box 1.14.0-alpha.38 之后，Snell 可以开始看，但不要急着把 Surge 里的 Snell 配置整段搬过去。github.com release notes 写的是新增 Snell protocol support；真正落到你手里，还要过三关：内核版本、GUI 适配、Snell 版本字段。

这篇按 2026-07-08 核对的 github.com release 和 Snell inbound/outbound 文档写。下面的 JSON 只做字段形态示例，不是生产模板。字段名、默认值和限制以后可能变，最后仍以 sing-box 当前官方文档为准。

alpha.38 到底加了什么？

1.14.0-alpha.38 的关键变化只有一句话最重要：sing-box 增加 Snell 协议支持。官方说明里还补了实现口径：除 v5 QUIC proxy 外，尽量让行为贴近原实现，并把性能目标放到至少不低于原实现。

这句话别读过头。它说明 sing-box 内核已经有 Snell inbound 和 Snell outbound 的配置入口，也说明项目维护者已经给出文档页面。它没有说明所有图形客户端已经支持 Snell，也没有说明所有 Snell 版本、所有 Surge 写法都能原样迁移。

更具体一点，官方文档把 Snell 拆成两边：

位置sing-box 文档入口你要看什么不能自动推导什么
服务端入口Snell inboundversion、psk、users、obfs_mode 或 mode不能推导 GUI 已经能生成这段配置
客户端出口Snell outboundserver、server_port、version、psk、userkey、network不能推导 Surge 配置行能直接复制
v5 相关能力changelog 和字段说明v5 QUIC proxy 被排除不能写成完整 Snell v5 能力覆盖
v6 字段inbound/outbound 文档v6 使用 mode，并对 psk 长度有要求不能拿旧 v4/v5 obfs 写法套上去

读 release notes 的顺序也很重要。先看 1.14.0-alpha.38 是否包含 Snell，再看你实际下载的二进制是不是这个版本或更新版本。只看文档页面，不看本机内核版本，后面所有排查都容易歪。

怎么判断你手里的 sing-box 能不能用 Snell？

判断标准不要从订阅链接开始。先从本机内核开始。

在测试机上看版本，最低要求是 1.14.0-alpha.38 或之后的 1.14.0-alpha.*。如果你运行的是 1.13.x 稳定版，它没有这次 Snell 支持，不要继续改 JSON。

可以先跑这两个动作：

sing-box version
sing-box check -c /etc/sing-box/config.json

macOS 用户如果用的是手动配置，文件可能在 ~/.config/sing-box/config.json。Linux 服务端常见路径是 /etc/sing-box/config.json。GUI 客户端用户要看客户端内置的 core 版本，不要只看 App 版本号。

判断表按这个顺序走：

现象更可能原因先检查什么
unknown outbound type: snell内核版本太旧sing-box version 是否低于 1.14.0-alpha.38
GUI 表单里没有 Snell客户端界面没适配客户端 release notes 是否提到 Snell
JSON 校验过了但连不上Snell 版本或密钥字段不匹配inbound/outbound 的 version、psk、userkey
只在某些 UDP 应用异常network 或 v5 QUIC proxy 预期不一致是否依赖官方明确未支持的 QUIC proxy
Surge 可用，sing-box 不通两边字段语义不完全一致不要按「完全兼容」排查，逐项比对字段

能不能用，最后看日志。sing-box check 只能证明配置语法过了，不能证明服务端和客户端握手成功。启动后至少看一条 outbound 连接日志，再决定下一步。

为什么 GUI 支持会慢半拍？

因为 Snell 支持先进入 sing-box 内核，不会自动长到每个 GUI 客户端里。图形客户端要做的事情比「内核能解析 JSON」多得多。

它至少要处理四件事：订阅格式怎么表示 Snell、界面表单怎么展示 v4/v6 字段、配置校验怎么提示错误、日志里怎么把 Snell outbound 的失败原因露出来。任何一层没做，用户看到的结果都可能是「核心支持了，但我导入不了」。

所以 GUI 用户判断时看两组版本：

你用的入口要看的版本通过标准
直接运行 sing-boxsing-box version1.14.0-alpha.38 或更新 alpha
GUI 内置 core客户端关于页或日志里的 core version内置 core 已经更新到支持 Snell 的版本
远程订阅订阅转换或订阅源输出输出格式里确实有 sing-box Snell outbound 字段
手写 JSONsing-box check -c校验通过，并且启动日志能看到对应 tag

不要把 App Store、GitHub Release、内置 core 三个版本混成一个版本。很多客户端外壳更新了，内核不一定同步；也有客户端内核支持了，但导入器还没支持新协议字段。

最小配置长什么样？

下面这段只用来让你认字段，不建议直接丢到生产设备。它把一个 Snell inbound 和一个 Snell outbound 放在同一份 JSON 里，目的是展示字段形态；真实部署时，服务端和客户端通常是两台机器，两边也会有独立的 route、dns、log 和权限配置。

以当前官方文档为准，Snell v6 字段大致长这样：

{
  "log": {
    "level": "info"
  },
  "inbounds": [
    {
      "type": "snell",
      "tag": "snell-in",
      "listen": "::",
      "listen_port": 23456,
      "version": 6,
      "psk": "0123456789abcdef",
      "users": [
        {
          "name": "test-user",
          "userkey": "client-user-key"
        }
      ],
      "mode": "default"
    }
  ],
  "outbounds": [
    {
      "type": "snell",
      "tag": "snell-out",
      "server": "203.0.113.10",
      "server_port": 23456,
      "version": 6,
      "psk": "0123456789abcdef",
      "userkey": "client-user-key",
      "network": "tcp",
      "mode": "default"
    },
    {
      "type": "direct",
      "tag": "direct"
    }
  ],
  "route": {
    "final": "snell-out"
  }
}

这里最容易写错的是 version。Snell inbound 文档里的 v5 结构和 outbound 文档里的 v4 结构不是简单同名；官方还说明没有单独提供 v4 server 或 v5 client，因为 v5 在排除 QUIC proxy 后，线上协议效果等同于 v4。你如果不想在这个差异上消耗时间，测试 v6 会更直观。

第二个坑是 psk 和 userkey。psk 是服务端预共享密钥；多用户模式下，userkey 是用户侧密钥。两者不是一个字段改两个名字。服务端开了 users，客户端就要填对应的 userkey。

第三个坑是 mode 和 obfs_mode。v6 用 mode；旧版本写法里常见的 HTTP obfs 相关字段，不要不看版本就往 v6 里塞。

Surge/Snell 能不能写成完全兼容？

不能。这个结论要写硬一点，因为误写成「完全兼容」会直接误导迁移。

Surge 是 Snell 的原生生态，Snell 配置、版本演进和 GUI 行为都围绕 Surge 自己的客户端体验展开。sing-box 这次是实现 Snell 协议支持，并且官方说行为尽量贴近原实现。两句话差一个层级：前者是原生生态，后者是另一个内核里的协议实现。

尤其别忽略 v5 QUIC proxy。官方 changelog 和 Snell 文档都把它排除在支持范围外。只要你的 Surge 配置依赖这个能力，就不能把 sing-box 当成等价替代。

更稳的写法是：

可以说不要说
sing-box 从 1.14.0-alpha.38 开始加入 Snell 协议支持sing-box 已经完整兼容 Surge Snell
官方实现排除了 v5 QUIC proxySnell v5 能力全部可用
字段要按 sing-box inbound/outbound 文档重写Surge 配置可以原样复制
GUI 支持取决于具体客户端所有 sing-box GUI 立刻可用

协议支持不等于生态迁移。这个边界写清楚，读者后面排错会少走很多弯路。

在测试机怎么验收？

验收只看四个点，不要一次改一整套主配置。

第一，看版本。sing-box version 里必须能确认当前 core 是支持 Snell 的 alpha。GUI 客户端要从日志或关于页里看内置 core，不能只看应用壳版本。

第二，看配置校验。把 Snell outbound 单独放进一份最小 JSON，先跑 sing-box check -c。如果这里都过不了，先别加 DNS、rule-set、TUN。

第三，看启动日志。启动后确认 snell-out 或你自己的 tag 被加载。日志里如果出现 unknown type、missing required field、invalid version，按字段修，不要换别的协议试运气。

第四，看连接行为。先走一个固定测试域名，再看 outbound tag 是否命中。这里不评价速度，因为我没有在 2026-07-08 做吞吐量基准测试；官方的性能说法可以引用，但不能替你本机环境下的结果背书。

哪些情况先别上生产配置？

有三类情况先别迁。

第一，你只通过 GUI 导入订阅，平时不碰 JSON。等 GUI 客户端明确写出支持 Snell，再动主配置。内核支持和导入器支持是两件事。

第二，你现有 Surge Snell 配置依赖 v5 QUIC proxy。sing-box 这次明确没有支持这个能力，继续等后续说明，或者保留原客户端。

第三，你的服务端目前只有一份主配置，没有测试机，也没有回滚文件。alpha 分支适合验证新能力，不适合在没有回滚路径的机器上赌。

比较稳的落地方式是：保留原 sing-box 稳定版配置，新建一份 config.snell-test.json；只放 mixed inbound、一个 Snell outbound 和一个 direct outbound；验证 tag 命中后，再决定是否把这段字段并回主配置。不看日志的排查都是玄学，这次尤其是。

相关阅读