本文最后更新于 2026 年 4 月 26 日

本文以 Debian 13 为例，介绍如何搭建 sing-box 的 Hysteria2 服务端，并说明对应的客户端配置文件的格式。本文同样完全适用于 Ubuntu 24.04 及以上系统。

本方案有以下特点：

1. 基于 QUIC（UDP）传输，配合 Brutal 拥塞控制可在高丢包环境下维持较高吞吐
2. 需要域名，需要 TLS 证书（本文使用 ACME DNS-01 自动签发）
3. 启用 salamander 混淆以规避按标准 QUIC Initial 提取 SNI 的审查
4. 配合端口跳跃以缓解运营商单端口 UDP 阻断
5. 无需 Nginx 或其他 Web 服务器，客户端与 VPS 直连

该方案适用于需要 UDP 吞吐、线路存在拥塞或 QoS 的场景。对于 UDP 环境恶劣、更重视长期隐蔽性的场景，建议考虑 AnyTLS + REALITY 方案 等基于 TCP 的方案。

注：请先参照 Debian & Ubuntu 服务器的初始化配置 一文对服务器进行各种必要的配置。本文以 sammy 用户为例，进行 sing-box 的部署，并默认已按初始化配置文章对服务器进行了配置。

背景与原理

Hysteria2 与审查现状

Hysteria2 基于 QUIC 协议。有些研究显示，自 2024 年 4 月起，已开始针对特定域名实施 QUIC SNI 审查：虽然 QUIC Initial 是加密的，但其密钥可由被动观察者派生，因此审查设备可以解密 Initial 包并提取 SNI。命中规则后，会对对应的源 IP、目的 IP、目的 UDP 端口三元组实施约 180 秒的残留丢包。

这说明标准 QUIC Initial 中的 SNI 已不能视为对被动审查者不可见。需要注意的是，公开研究主要证明的是 对 QUIC Initial/SNI 的解析与阻断机制，并不等于所有未混淆 Hysteria2 流量都会被稳定识别和封锁。

因此，本文默认启用 salamander 混淆。salamander 会使外层 UDP payload 不再呈现标准 QUIC/HTTP3 形态，从而避免被按标准 QUIC Initial 提取 SNI。但这不代表流量不可检测；它仍可能表现为随机 UDP，并受到基于流量统计、持续速率或运营商 UDP 策略的影响。

在运营商层面，中国用户长期存在持续 UDP 连接被限速或单端口阻断的反馈。Hysteria 官方文档也提到，中国用户有时会遇到 ISP 阻断或限速持续 UDP 连接，且此类限制往往只作用于当前端口。因此，本文采用高位端口配合端口跳跃，作为对单端口 UDP 限制的缓解手段。

启用 salamander 后，服务器对不知道 obfs 密码的普通探测者不再表现为有效 HTTP/3 服务，因此 masquerade 不应被视为主要伪装手段。两者不是配置项互斥，但在 salamander 模式下，masquerade 的实际作用有限。

拥塞控制选择

Hysteria2 内置两种拥塞控制模式：

BBR：主流拥塞控制算法之一，不需要用户手动声明带宽，行为通常比 Brutal 更接近常规 QUIC/TCP 拥塞响应。FOCI 2025 的实验表明 Brutal 的自定义拥塞控制更容易产生可分类的统计特征；但这并不代表 BBR 完全不可被区分，只能说相对 Brutal 指纹风险更低。配置简单，适合作为首次部署的默认选择。

Brutal：用户声明目标带宽，丢包时不降速而是补偿发送。适用于骨干网拥塞（高 RTT、高丢包）场景，前提是准确声明带宽。声明值高于实际会导致大量无效重传。Brutal 只在实际传输数据时按目标速率发包，空闲时不产生额外流量。需注意 FOCI 2025 论文已在实验室环境中证明 Brutal 的恒速率行为可与标准拥塞控制统计区分，存在指纹风险。

选择建议：首次部署、免费实例、小流量配额、弱性能节点或更重视隐蔽性的场景用 BBR；优化线路或需要吞吐的普通线路，且能准确声明带宽时，可切换为保守 Brutal。

本方案不适用的场景

1. 运营商实施 UDP 白名单策略（仅放行可识别协议的 UDP、阻断其余所有 UDP）
2. VPS IP 已被标记为全端口 UDP 封锁
3. 公司、校园、酒店等 UDP 受限网络环境（应改用 TCP 方案）

Read More

本文最后更新于 2026 年 4 月 22 日

本文以 Debian 13 为例，介绍如何搭建 sing-box 的 VLESS + HTTPUpgrade 服务端，通过 Cloudflare Tunnel 隐藏源站 IP，使用 Caddy 建立伪装站，并在客户端启用 ECH 加密 SNI。本文同样完全适用于 Ubuntu 24.04 及以上系统。

本方案有以下特点：

1. 除 SSH 管理端口外，VPS 无需开放任何业务入站端口（代理流量通过 cloudflared 主动出站连接进入），真实 IP 完全不出现在 DNS 记录、证书或任何公开信息中
2. 无需申请 TLS 证书（外层 TLS 由 Cloudflare 边缘节点处理，VPS 内部全程明文 HTTP 回环通信）
3. 浏览器直接访问域名显示真实的伪装网站，代理路径隐藏在特定 URI 下
4. 客户端启用 ECH 后，TLS 握手中的真实 SNI 被加密，中间人仅能看到 cloudflare-ech.com 的外层 SNI（需配合加密 DNS 避免域名解析泄漏）

注：请先参照 Debian & Ubuntu 服务器的初始化配置 一文对服务器进行各种必要的配置。本文以 sammy 用户为例，并默认已按初始化配置文章对服务器进行了配置。

背景与原理

整体架构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

客户端 sing-box (VLESS + HTTPUpgrade)
   │ TLS 1.3 + ECH（外层 SNI: cloudflare-ech.com）
   ▼
Cloudflare 边缘节点
   │ CF 内部协议（Tunnel）
   ▼
VPS 上 cloudflared 守护进程（主动出站长连接）
   │ 明文 HTTP（本机回环）
   ▼
Caddy（127.0.0.1:8080）
   ├─ 其他请求 → 伪装静态网站
   └─ /你的隐藏路径 + Upgrade 头 → sing-box VLESS inbound
             │
             ▼
sing-box（127.0.0.1:8443）→ direct outbound → 目标网站

关于 TLS-in-TLS

本方案中，用户访问 HTTPS 网站时产生的内层 TLS 流量被封装在 Cloudflare 的外层 TLS 连接中，TLS-in-TLS 特征不可避免。sing-box 的 multiplex.padding 可在多路复用层添加随机填充以缓解长度特征，但无法完全消除。需要消除 TLS-in-TLS 的场景应选择 AnyTLS + REALITY 或者 VLESS + Vision + REALITY（两者都是直连方案，无法过 CDN）。

本方案不适用的场景

1. VPS 无法出站连接 Cloudflare 的场景（极少数网络环境）
2. 需要完全消除 TLS-in-TLS 特征的场景
3. 追求极致低延迟的场景（CF Tunnel 多一跳，延迟略高于直连）

Read More

本文最后更新于 2026 年 4 月 20 日

本文以 Debian 13 为例，介绍如何搭建 sing-box 的 AnyTLS + REALITY 服务端，并说明对应的客户端配置文件的格式。本文同样完全适用于 Ubuntu 24.04 及以上系统。

本方案有以下特点：

1. 无需域名，无需解析
2. 无需申请 TLS 证书（REALITY 借用第三方站点的真实 TLS 握手）
3. 无需 Nginx 或其他 Web 服务器（REALITY 自己负责处理握手层的伪装与转发）
4. 无需 CloudFlare 中转，客户端与 VPS 直连

该方案对 VPS 的 IP 质量要求较高，需要选择合理的 SNI 目标站，并定期维护配置以应对长期可用性风险。

注：请先参照 Debian & Ubuntu 服务器的初始化配置 一文对服务器进行各种必要的配置。本文以 sammy 用户为例，进行 sing-box 的部署，并默认已按初始化配置文章对服务器进行了配置。

背景与原理

介绍 AnyTLS + REALITY

AnyTLS 与 REALITY 的组合具有以下特性：

1. REALITY 将 TLS ClientHello 的 SNI 指向一个真实的第三方站点（称为 handshake server），由服务端完成密钥协商。若客户端认证成功则走代理通道，否则将连接完整转发给该第三方站点。这使得主动探测者获取的是真实站点的证书与响应，握手层难以区分真实访问者与代理用户。
2. AnyTLS 协议本身在 TLS 之上提供了 padding_scheme 机制，用于在协议层对数据包长度进行随机填充，以对抗基于包长分布的被动流量识别。
3. 整个协议链路在直连场景下不引入额外的 transport（如 WebSocket、HTTPUpgrade、gRPC），客户端发出的流量经 REALITY 握手后直接承载 AnyTLS 内容，延迟与吞吐无额外损耗。

本方案不适用的场景

1. VPS IP 本身已被封锁或严重干扰的情况。REALITY 无法修复 IP 层的封锁。
2. 需要借助 CDN 隐藏源站 IP 的场景。REALITY 的工作方式与 CDN 反代不兼容。
3. 使用的第三方客户端版本过旧不支持 AnyTLS 协议的场景。在配置前请先确认目标客户端支持 AnyTLS，否则考虑改用 VLESS + Vision + REALITY 方案。

Read More

本文最后更新于 2026 年 4 月 20 日

本文以 Debian 13 为例，介绍如何搭建 sing-box 的 VLESS + Vision + REALITY 服务端，并说明对应的客户端配置文件的格式。本文同样完全适用于 Ubuntu 24.04 及以上系统。

本方案有以下特点：

1. 无需域名，无需解析
2. 无需申请 TLS 证书（REALITY 借用第三方站点的真实 TLS 握手）
3. 无需 Nginx 或其他 Web 服务器（REALITY 自己负责处理握手层的伪装与转发）
4. 无需 CloudFlare 中转，客户端与 VPS 直连

该方案对 VPS 的 IP 质量要求较高，需要选择合理的 SNI 目标站，并定期维护配置以应对长期可用性风险。

注：请先参照 Debian & Ubuntu 服务器的初始化配置 一文对服务器进行各种必要的配置。本文以 sammy 用户为例，进行 sing-box 的部署，并默认已按初始化配置文章对服务器进行了配置。

背景与原理

介绍 VLESS + Vision + REALITY

VLESS + Vision + REALITY 是代理中成熟、部署广泛的组合之一，具有以下特性：

1. REALITY 将 TLS ClientHello 的 SNI 指向一个真实的第三方站点（称为 handshake server），由服务端完成密钥协商。若客户端认证成功则走代理通道，否则将连接完整转发给该第三方站点。这使得主动探测者获取的是真实站点的证书与响应，握手层难以区分真实访问者与代理用户。
2. Vision（xtls-rprx-vision）是 VLESS 的一个子协议流控，它在内层 TLS 握手完成后识别出握手边界，将后续数据从 TLS record 封装中剥离出来，直接通过底层 TCP 传输。这消除了"内层 TLS 报文结构穿透到外层"的特征——即 TLS-in-TLS 的典型包长分布——使代理流量的数据段行为与普通 HTTPS 直连流量趋同。
3. 整个协议链路在直连场景下不引入额外的 transport，客户端发出的流量经 REALITY 握手后直接承载 VLESS 内容，延迟与吞吐无额外损耗。

本方案不适用的场景

1. VPS IP 本身已被封锁或严重干扰的情况。REALITY 无法修复 IP 层的封锁。
2. 需要借助 CDN 隐藏源站 IP 的场景。REALITY 的工作方式与 CDN 反代不兼容，此外 Vision 流控本身也要求底层是裸 TCP，与 CDN 所需的 transport 层（WebSocket、HTTPUpgrade、gRPC 等）不兼容。如需通过 CDN，请改用 VLESS + WebSocket/HTTPUpgrade + TLS 的方案，而非本文的 Vision 方案。
3. 需要代理 UDP 流量但客户端不支持 XUDP 的场景。Vision 基于 TCP，UDP 通过 VLESS 的 packet_encoding 机制封装传输，客户端需要支持 xudp 或 packetaddr。

Read More

本文最后更新于 2026 年 4 月 18 日

本文以 Debian 13 为例，介绍如何搭建 sing-box 的 VLESS + WebSocket 服务端，通过 Cloudflare Tunnel 隐藏源站 IP，使用 Caddy 建立伪装站，并在客户端启用 ECH 加密 SNI。本文同样完全适用于 Ubuntu 24.04 及以上系统。

本方案有以下特点：

1. 除 SSH 管理端口外，VPS 无需开放任何业务入站端口（代理流量通过 cloudflared 主动出站连接进入），真实 IP 完全不出现在 DNS 记录、证书或任何公开信息中
2. 无需申请 TLS 证书（外层 TLS 由 Cloudflare 边缘节点处理，VPS 内部全程明文 HTTP 回环通信）
3. 浏览器直接访问域名显示真实的伪装网站，代理路径隐藏在特定 URI 下
4. 客户端启用 ECH 后，TLS 握手中的真实 SNI 被加密，中间人仅能看到 cloudflare-ech.com 的外层 SNI（需配合加密 DNS 避免域名解析泄漏）

本文提供的是 WebSocket 传输版本，客户端兼容性最广。如果客户端全程使用 sing-box，也可参考 HTTPUpgrade 版本，协议开销更小。两者在隐蔽性上没有差异。

注：请先参照 Debian & Ubuntu 服务器的初始化配置 一文对服务器进行各种必要的配置。本文以 sammy 用户为例，并默认已按初始化配置文章对服务器进行了配置。

背景与原理

整体架构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

客户端 sing-box (VLESS + WebSocket)
   │ TLS 1.3 + ECH（外层 SNI: cloudflare-ech.com）
   ▼
Cloudflare 边缘节点
   │ CF 内部协议（Tunnel）
   ▼
VPS 上 cloudflared 守护进程（主动出站长连接）
   │ 明文 HTTP（本机回环）
   ▼
Caddy（127.0.0.1:8080）
   ├─ 其他请求 → 伪装静态网站
   └─ /你的隐藏路径 + WebSocket Upgrade → sing-box VLESS inbound
             │
             ▼
sing-box（127.0.0.1:8443）→ direct outbound → 目标网站

关于 TLS-in-TLS

本方案中，用户访问 HTTPS 网站时产生的内层 TLS 流量被封装在 Cloudflare 的外层 TLS 连接中，TLS-in-TLS 特征不可避免。sing-box 的 multiplex.padding 可在多路复用层添加随机填充以缓解长度特征，但无法完全消除。需要消除 TLS-in-TLS 的场景应选择 AnyTLS + REALITY 或者 VLESS + Vision + REALITY（两者都是直连方案，无法过 CDN）。

本方案不适用的场景

1. VPS 无法出站连接 Cloudflare 的场景（极少数网络环境）
2. 需要完全消除 TLS-in-TLS 特征的场景
3. 追求极致低延迟的场景（CF Tunnel 多一跳，延迟略高于直连）

Read More