ki 的折腾笔记.

VPSsing-box玩机Python

← 返回首页

sing-box 抗封锁武器库：AnyTLS 协议、TLS 分片与伪造 ClientHello 全解析

sing-box代理抗封锁
sing-box 抗封锁武器库：AnyTLS 协议、TLS 分片与伪造 ClientHello 全解析

背景

sing-box 是一个开源的通用代理平台：既可以在 VPS 上跑作服务端（VLESS、Trojan、Hysteria2 等入站），也可以在电脑、手机上跑作客户端（路由、分流、TUN 透明代理）。自建节点的玩家大多用它当主力。

近两年的趋势很明显：封锁手段从"封 IP、封端口"转向了流量特征识别——即便你用的是正规 TLS 协议，对方也能从握手的流量特征里分辨出"这是代理流量还是真网页流量"。sing-box 的回应是一连串藏在 TLS 层的反识别特性：1.12 加入了 AnyTLS 协议和 TLS 分片，1.14 加入了伪造 ClientHello（spoof）。这篇把三件套的原理、适用场景和配置一次讲清。

前置知识：一台能装软件的 VPS（Debian/Ubuntu 最常见），能用 SSH 登录，sing-box 建议升级到 1.14.3（当前最新稳定版）。TLS 层相关的特性全部配置在客户端的 tls 字段里。

1. AnyTLS 协议：让代理流量不像代理流量

AnyTLS 是 sing-box 1.12 引入的新协议。官方更新日志的说法很克制："claims to mitigate TLS proxy traffic characteristics"（声称能缓解 TLS 代理的流量特征问题），并带了一套新的多路复用方案。

它解决了哪类问题？传统代理协议（如 VMess、Trojan）要么握手包有固定特征，要么在一条连接上传很多流，流量模式一眼可辨。AnyTLS 的思路是在 TLS 之上再做一层填充（padding）和随机化，让代理连接的包长、发包节奏更接近普通 HTTPS 流量。它不是"隐形"，而是"降噪"——减少被特征引擎盯上的概率。

服务端配置（VPS 上）：

{
  "type": "anytls",
  "tag": "anytls-in",
  "listen": "::",
  "listen_port": 443,
  "users": [
    { "name": "user1", "password": "<你的密码>" }
  ],
  "tls": {
    "enabled": true,
    "server_name": "你的域名",
    "certificate_path": "/etc/sing-box/cert.pem",
    "key_path": "/etc/sing-box/key.pem"
  }
}

padding_scheme 是填充方案数组，默认已经有一套官方调优的方案，不懂的话不要改。

客户端配置：

{
  "type": "anytls",
  "tag": "anytls-out",
  "server": "你的服务器地址",
  "server_port": 443,
  "password": "<你的密码>",
  "tls": {
    "enabled": true,
    "server_name": "你的域名"
  }
}

小提醒：AnyTLS 客户端早期版本默认会上传一些客户端元数据，但这些数据开源服务端根本用不到，还有厂商拿它做识别用途的报告。所以官方从 1.13.16 起把它挪到 client_metadata 字段、默认不再上传。升级到新版客户端就能白嫖这个改进，不用手动改。

AnyTLS 与 VLESS+Reality 的关系：两者不冲突。VLESS+Reality 解决的是"服务端伪装"（让握手看起来像在访问真网站），AnyTLS 解决的是"流量特征降噪"，可以配合使用，也可以单独用 AnyTLS+普通 TLS（适合没有域名的场景）。

2. TLS 分片：先试 record_fragment

有些网络环境做的是"明文包匹配"：防火墙直接读 TCP 包里的明文字节，看 ClientHello 里有没有被标记的域名，一匹配就掐。对付这种粗糙但有效率的手段，sing-box 1.12 引入了两种分片：

  • record_fragment：把 TLS 握手拆成多个 TLS 记录发送。实现成本低、性能影响小，官方建议先用它。
  • fragment：把 TCP 数据包本身切碎，配合延迟探测。性能较差，是备选方案。

配置很简单，客户端 outbound 的 tls 里加一行：

"tls": {
  "enabled": true,
  "server_name": "你的域名",
  "record_fragment": true
}

注意两个细节：

  1. 这两个特性只适用于基于明文匹配的简单防火墙——sing-box 官方文档原话："should not be used to circumvent real censorship"（不适用于对抗真正的审查手段）。别把它当成万能药。
  2. 不要全局开：它只对握手阶段有用，开给全部连接只会拖慢速度。可以配合路由动作，只对被拦截的域名启用——1.12 起路由 action 也支持 TLS 分片选项。分流路由的玩法可以参考站内文章 sing-box 1.14 新特性解读：Snell 协议、远程面板与升级要点 里的路由写法思路。

3. 伪造 ClientHello：骗过 SNI 白名单（spoof）

1.14 的新特性 spoof 是三件套里最"黑科技"的一个，用来对付 SNI 白名单式的中间盒：只允许访问名单里的域名（比如知名大站），其他 SNI 一律阻断。

原理分两步：

  1. 客户端在真正的 ClientHello 之前，先注入一段伪造的 ClientHello，里面带一个白名单里的 SNI（比如某个大公司的域名）。中间盒看到白名单域名，放行。
  2. 真服务器收到这段伪造的包，会因为 spoof_method 指定的"拒绝方式"把它丢弃（默认 wrong-sequence：把伪造包的 TCP 序列号放在服务器接收窗口之外，服务器直接忽略），然后继续处理真正的 ClientHello。

配置同样在客户端 tls 里：

"tls": {
  "enabled": true,
  "server_name": "你的域名",
  "spoof": "白名单里的域名"
}

硬性要求：注入伪造包需要提权——Linux 需要 CAP_NET_RAW 和 CAP_NET_ADMIN 能力，macOS 需要 root，Windows 需要管理员权限（ARM64 的 Windows 不支持）。手机客户端基本用不上这个特性，它是给桌面端和网关设备准备的。

spoof_method 一共有五种拒绝方式（wrong-sequence 默认、wrong-checksum、wrong-ack、wrong-md5、wrong-timestamp），默认一般不用改；如果默认方式在你的网络里不起作用，再逐个试。

4. 选购顺序：按"成本从低到高"叠加

三件套不是三选一，而是可以按顺序叠加，成本从低到高：

  1. record_fragment：零成本，先开，尤其适合明文 SNI 匹配的网络。
  2. AnyTLS：换协议，把流量特征压低。需要服务端配合部署。
  3. spoof：对抗 SNI 白名单的利器，但需要提权、只支持桌面/网关客户端。

一个务实的组合：服务端 AnyTLS + 普通 TLS（免去域名和证书麻烦），客户端开 record_fragment。这是目前折腾成本最低、隐蔽性还不错的方案。

顺带一提，sing-box 1.15 测试版还在憋大招：MASQUE（基于 HTTP 的 CONNECT-IP 代理）、HTTP 代理的 HTTP/2、HTTP/3 和 UDP 支持、全证书 pinning。等 1.15 正式版发布，本站会再出一篇解读。

相关阅读