digital

Debian & Ubuntu 搭建部署 sing-box 的 NaiveProxy 代理服务

本文最后更新于 2026 年 5 月 14 日

本文以 Debian 13 为例，介绍如何使用 sing-box 搭建 NaiveProxy 兼容服务端，并在客户端使用 sing-box 的 naive outbound 连接。本文同样适用于 Ubuntu 24.04 及以上系统。

本方案有以下特点：

  1. 服务端与客户端均使用 sing-box，无需 Caddy、Nginx、HAProxy 或 Go 编译环境
  2. 使用 sing-box 内置 ACME DNS-01 自动申请和续签真实 TLS 证书，无需开放 TCP 80
  3. 服务端同时监听 TCP 443 与 UDP 443，支持 HTTP/2 与 HTTP/3；客户端默认使用 HTTP/3
  4. 两端均为 sing-box 时可启用 UDP over TCP，兼顾 UDP 应用兼容性
  5. DNS 记录使用 Cloudflare 托管时必须保持 DNS only / 灰云，不要开启橙云代理

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

背景与原理

整体架构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
客户端 sing-box
   │ TUN / mixed / socks 入站
   ▼
sing-box Naive outbound
   │ HTTP/3 CONNECT over QUIC / UDP 443
   │ SNI: naive.example.com
   ▼
VPS 公网 IP:443
   │
   ▼
sing-box Naive inbound
   │ 用户名 + 密码认证
   ▼
direct outbound
   │
   ▼
目标网站

NaiveProxy 的设计目标是将代理流量伪装成普通浏览器与 Web 服务器之间的 HTTP/2 或 HTTP/3 流量。sing-box 的 naive inbound / outbound 实现了兼容 NaiveProxy 的服务端与客户端。

需要注意：sing-box 的 Naive inbound 是纯代理入口，没有 Caddy forwardproxy 那样的伪装站 fallback。浏览器直接访问 https://naive.example.com 不一定显示正常网页。若强依赖伪装站 fallback，需要另行评估 Caddy forwardproxy 或 HAProxy 方案；本文不使用它们。

关于 HTTP/3

本文默认客户端启用 HTTP/3 / QUIC：

1
"quic": true

HTTP/3 更接近现代 Chrome 访问大量网站时的网络行为，在移动网络、跨国链路或丢包网络下也可能表现更好。但 H3 依赖 UDP 443，如果本地网络或 VPS 商家对 UDP 限速、QoS 或阻断，表现可能不如 H2。遇到连接失败、速度波动或间歇性断流时，删除客户端中的 "quic": true 即可回退到 HTTP/2。

本方案不适用的场景

  1. 必须隐藏 VPS 真实 IP 的场景
  2. 必须通过 Cloudflare Tunnel / CDN 的场景
  3. 必须让浏览器直接访问代理域名显示伪装站的场景
  4. 无法开放公网 TCP 443 与 UDP 443 的 NAT VPS 场景

Read More

digital

Debian 或 Ubuntu 自建 RustDesk 服务

本文介绍如何在 VPS 上搭建 RustDesk 服务，本文适用于 Debian 13 以及 Ubuntu 24.04 系统。

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

尤其注意进行 UFW 针对 Docker 的配置，这是前置条件。

VPS 的规格要求：

  1. 512MB 及以上内存
  2. 固定公网 IP

Read More

digital

Debian & Ubuntu 搭建部署 Xray 的 VLESS + XHTTP + TLS + Nginx 并使用 Cloudflare

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

本文以 Debian 13 为例，介绍如何搭建 Xray-core 的 VLESS + XHTTP 服务端，使用 Nginx 反代，并通过 Cloudflare 橙色云隐藏源站 IP。本文同样适用于 Ubuntu 24.04 及以上系统。

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

本方案采用：

1
2
3
4
客户端 Xray
  → Cloudflare 橙色云
  → Nginx TLS + HTTP/2
  → Xray VLESS + XHTTP

本方案特点：

  1. XHTTP 使用 H2/gRPC-like 流量形态，适合 Cloudflare 橙色云直回源
  2. Nginx 负责 TLS、HTTP/2、伪装站和路径分流
  3. Xray 只监听本地回环地址，不直接暴露公网
  4. VPS 443 端口只允许 Cloudflare IP 访问
  5. 客户端启用 ECH、uTLS Chrome、XHTTP padding obfs
  6. 证书使用 acme.sh + Cloudflare DNS-01 自动续期

与 Cloudflare Tunnel 方案相比，本方案性能更直接，XHTTP 兼容性更好；代价是源站必须开放 443 给 Cloudflare，并且需要管理源站证书。

Read More

digital

Debian & Ubuntu 搭建部署 sing-box 的 Hysteria2 服务

本文最后更新于 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

Mastodon