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

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

本方案有以下特点：

1. VPS 不开放任何公网入站端口（防火墙仅允许 SSH 和出站），真实 IP 完全不出现在 DNS 记录、证书或任何公开信息中
2. 无需申请 TLS 证书（外层 TLS 由 Cloudflare 边缘节点处理，VPS 内部全程明文 HTTP 回环通信）
3. 浏览器直接访问域名显示真实的伪装网站，代理路径隐藏在特定 URI 下
4. 客户端启用 ECH 后，中间人仅能看到 cloudflare-ech.com 的外层 SNI，无法得知实际访问的域名

注：请先参照 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

在 Ubuntu 24.04 上使用 Codex CLI 时，可能会看到如下提示：

1

⚠ Codex's Linux sandbox uses bubblewrap and needs access to create user namespaces.

系统中已经安装了 bubblewrap，但进一步测试：

1
2
3
4

which bwrap
# /usr/bin/bwrap

codex sandbox linux /bin/true

仍会出现错误：

1

bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted

Read More

本文作为笔记，以便部署新环境时使用。

Read More