# 代理方案对比：WS+TLS (方案B) vs Hysteria2 (方案C)

> **背景：** 香港服务器，已有 OpenResty 占用 443 端口跑反向代理服务。个人使用（不共享、不盈利），需要通过 Clash 客户端（手机 + 电脑）访问 GitHub、Netflix、Telegram 等。
>
> **审计方：** GPT-5.5 (openai/gpt-5.5) — 2026-04-29
>
> **审计结论：** 经修复后通过。文档覆盖维度全面，技术细节经修正后基本准确，建议结合自身 ISP 和网络环境做最终判断。

---

## 方案概览

| 维度 | 方案B: VLESS+WebSocket+TLS (通过 OpenResty 反代) | 方案C: Hysteria2 (独立 UDP 端口) |
|------|---------------------------------------------------|----------------------------------|
| 传输层 | TCP + WebSocket (HTTP Upgrade) | UDP + QUIC |
| 端口 | 占 443（借用 OpenResty TLS 终止） | 独立 UDP 端口（如 8443/udp） |
| 加密 | 外层 TLS 1.3（由 OpenResty 管理）+ 内层 VLESS 认证 | 自带 TLS 1.3 + QUIC 传输加密 |
| 核心软件 | Sing-box / Xray (后端) + OpenResty (前端) | Hysteria2 (单进程) |
| 域名需求 | **需要域名 + DNS 指向**（用于 TLS 证书） | **推荐域名 + 有效证书**，可用自签证书但不建议长期使用 |
| 干预现有服务 | 需要修改 OpenResty 配置 | 完全不干预 |
| 证书管理 | 由 OpenResty + certbot 统一管理 | 可使用 acme.sh 独立签发或 certbot standalone |

---

## 1. 架构与共存性

### 方案B: WS+TLS 通过 OpenResty 反代

```
Internet → :443 → OpenResty（统一 TLS 终止）
                      ├── /api/xxx → 后端服务容器
                      ├── /vless-path → localhost:2000（Sing-box WS 入站）
                      └── 其他 location → 现有静态/反代服务
```

**工作原理：**
- 所有流量到 443 端口，OpenResty 统一做 TLS 终止
- VLESS+WS 入站监听 `127.0.0.1:2000`（无 TLS，纯 WebSocket）
- OpenResty 通过 `proxy_pass` 将特定路径的 WebSocket 升级请求转发给 Sing-box
- **注意：** TLS 在 OpenResty 处终止，OpenResty 到后端 Sing-box 是本机明文 WebSocket。因为监听在 `127.0.0.1`（回环接口），本地明文通信风险可接受，但这不是端到端加密。

**OpenResty 关键配置片段：**

```nginx
location /vless-ws {
    proxy_redirect off;
    proxy_pass http://127.0.0.1:2000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    # WebSocket 超时设长
    proxy_read_timeout 3600s;
    proxy_send_timeout 3600s;
}
```

> **⚠️ 配置风险提示：** WS 反代需要正确设置 `Upgrade`、`Connection`、`Host` 头部和长超时。路径不要使用明显名称如 `/vless-ws`，建议使用随机路径（如 `/sD7k3m`）。另外建议对代理路径单独关闭或最小化 access log，避免路径泄露。

### 方案C: Hysteria2 独立端口

```
Internet → :8443/udp → Hysteria2（自带 TLS 1.3 + masquerade）
                     → OpenResty 完全不受影响
```

**工作原理：**
- Hysteria2 监听独立 UDP 端口（如 8443）
- 自带 TLS 1.3 握手，不需要 OpenResty 干预
- masquerade 功能：被主动探测时返回一个伪装网页（如 nginx 默认页）
- 与 OpenResty 零交互，完全隔离
- 推荐使用域名 + 有效证书（acme.sh），自签证书 + `skip-cert-verify` 虽可用但不推荐作为长期配置

> **⚠️ 防火墙注意：** 云厂商安全组 + 服务器 iptables/nftables 都需要开放 **UDP** 端口（不仅是 TCP），Hysteria2 使用 UDP 传输，很多默认安全组只开 TCP。

---

## 2. GFW 抗检测能力

| 维度 | WS+TLS | Hysteria2 |
|------|--------|-----------|
| 传输层可见性 | 外层是 TLS 1.3，内层 WebSocket Upgrade | QUIC (HTTP/3) 协议 |
| 指纹特征 | 非浏览器 TLS 指纹（Clash 的 uTLS 有特征，可能被 JA3/JA4 数据库标记） | Hysteria2 的 QUIC/TLS 行为不等于 Chrome HTTP/3 浏览器流量 |
| 主动探测 | OpenResty 返回 404/403（但探测风险不止状态码，还包括路径行为、Upgrade 响应差异、后端握手失败模式） | Masquerade 返回伪装网页（可降低但不能完全消除风险） |
| 熵分析 | WS 隧道流量机器加密 vs 人工浏览具有可区分性 | QUIC 填充机制使熵分布更自然 |
| 综合评分 | ~7/10（需配合路径混淆） | ~7/10（UDP/QUIC 审查在持续演进中） |

**关键分析：**

**WS+TLS 的风险：**
- Clash/Mihomo 的 TLS ClientHello、HTTP 头部行为不等于真实浏览器流量，部分 uTLS 指纹已被 GFW 数据库记录
- WebSocket 本身的 HTTP Upgrade 协议与普通 HTTPS 访问流量有结构差异
- WS 路径如果被扫描到（返回 404 vs 200），暴露代理存在
- 但如果藏在 OpenResty 后面，众多合法路径会稀释探测精度

**Hysteria2 的风险：**
- 2024 年 4 月起，GFW 开始大规模部署 QUIC SNI 审查（USENIX Security 2025 论文有详细分析）
- GFW 会解密 QUIC Initial 包提取 SNI，匹配阻断列表后丢包 180 秒
- 但有时间窗口漏洞：非高峰时段阻断率更高，说明 GFW 的 QUIC 解密容量有限
- **实测可用策略（需客户端支持）：** 使用非标准 SNI（不在阻断列表中的域名）、选择 QUIC v2（GFW 暂不检查 v2）
- Hysteria2 的 masquerade 能防御主动探测——被 GFW 主动连接时返回正常页面

> **参考：** 2026-04 协议矩阵实测（实验室数据，结果因 ISP 和线路质量而异）
> - VLESS-Reality（TCP 纯仿冒）：**隐身评分 9/10**，延迟 160-210ms
> - Hysteria2（UDP+QUIC）：**隐身评分 7/10**，延迟 110-150ms
> - WS+TLS：未独立列项，参考 VLESS 系列约 7/10

---

## 3. 性能对比

| 指标 | WS+TLS | Hysteria2 | 差距 |
|------|--------|-----------|------|
| 首字节延迟 | ~3 RTT（TCP + TLS + WS Upgrade） | ~1 RTT（QUIC 0-RTT 恢复连接时） | H2 通常更快 |
| 丢包环境吞吐 | TCP 拥塞控制随丢包线性下降 | Brutal 算法更激进，按目标带宽发送 | 高丢包时 H2 优势明显 |
| 移动网络体验 | TCP 弱信号下表现差 | QUIC + 0-RTT 重连更优 | H2 显著更优 |
| 4K 流媒体 | 够用，取决于线路 | 在 UDP 未被限速、线路质量正常时体验更好 | H2 通常更优 |
| 多路复用 | TCP 连接复用（受队头阻塞影响） | QUIC 原生多路复用 | H2 更优 |
| CPU 开销 | 低（TLS 由 OpenResty 处理） | 中（QUIC 加密 + Brutal 算法） | WS 略低 |

> **延迟分解 (RTT ~50ms 香港→大陆，仅供参考)：**
>
> | 阶段 | WS+TLS | Hysteria2 |
> |------|--------|-----------|
> | TCP SYN/SYN-ACK | ~50ms | —（UDP 无握手） |
> | TLS 1.3 握手 | ~50ms (1 RTT) | ~50ms (1 RTT) |
> | WebSocket Upgrade | ~50ms (1 RTT) | — |
> | **首字节数据** | **~150ms** | **~50ms** |
> | 后续请求（持续连接） | ~50ms | ~50ms |
>
> 0-RTT 仅减少恢复连接时的握手延迟。物理链路延迟（香港→大陆的 50ms）始终存在，不会降到 0ms。
>
> **Brutal 拥塞控制说明：** Brutal 不是"无视丢包"。它按配置的目标带宽发送数据，更激进、RTT 容忍度更高，但可能导致丢包放大、UDP QoS 触发、或运营商误判为异常流量进行限速。

---

## 4. 部署与维护

### 方案B: WS+TLS

**步骤：**
1. 安装 Sing-box（或 Xray）
2. 配置 VLESS+WS 入站，监听 `127.0.0.1:2000`
3. 修改 OpenResty 配置，添加 WebSocket 反代路径（使用随机路径名）
4. 设置防火墙允许 443（TCP，已有）
5. `nginx -s reload`
6. Clash 客户端配置 WS+TLS（含域名、路径、TLS 开关）

**维护成本：**
- **中高。** 每个 Clash 配置都要写 WS 路径 + TLS 域名
- 证书由 OpenResty 自动续期（certbot），免操心
- WS 路径暴露在 access log 中（建议关闭或最小化该路径日志）

### 方案C: Hysteria2

**步骤：**
1. 安装 Hysteria2（单二进制，或使用 Docker 运行）
2. 使用 acme.sh 签发正式证书（或短期自签证书过渡）
3. 配置 Hysteria2 服务端（单 YAML 文件，约 20 行）
4. 开放 UDP 端口：云安全组 + 服务器防火墙 + Docker 端口映射（确保 UDP 放行）
5. Clash Meta / Mihomo 客户端配置

**维护成本：**
- **低。** 单进程，配置极其简单
- 端口独立，不影响任何现有服务
- 维护主要是证书续期（acme.sh 自动）、进程保活（systemd/Docker）

---

## 5. 扩展维度

| 维度 | WS+TLS | Hysteria2 |
|------|--------|-----------|
| **证书与域名** | 必须：有效域名 + Let's Encrypt 证书，经 OpenResty 管理 | 推荐：域名 + 有效证书（acme.sh）。自签 + `skip-cert-verify` 技术上可行但增加指纹风险 |
| **防火墙/NAT** | 仅需 443/TCP（通常已开放） | 需开放 UDP 端口（很多默认安全组只放行 TCP） |
| **CDN 兼容性** | 可通过 Cloudflare / CDN 中转 WebSocket（但会引入额外延迟） | 通常不能走传统 CDN（除非使用支持 UDP/QUIC 转发的特殊服务） |
| **断流恢复** | 依赖 TCP 重连，断线后体验较差 | 移动网络切换、弱网恢复时体验更好（0-RTT 重连） |
| **UDP QOS** | 不受影响（纯 TCP） | 国内部分 ISP（如教育网、校园网、公司内网、酒店 Wi-Fi）可能限制 UDP 或对 QUIC 进行 QoS |
| **日志泄露** | OpenResty access log 记录 WS 路径、IP、UA — 建议对代理路径单独关闭日志 | 默认日志较少，但仍需检查 systemd journal / Docker logs |
| **路径隐蔽性** | 需要隐藏 WS 路径；路径暴露后易被扫描确认 | 端口独立，masquerade 提供一层防御 |

---

## 6. Clash 客户端兼容性

| 维度 | WS+TLS | Hysteria2 |
|------|--------|-----------|
| Clash 内核 | 全版本支持 | 仅 Clash Meta / Mihomo 内核 |
| Mihomo (原 Clash Meta) | ✅ | ✅ |
| Clash Verge (PC) | ✅ | ✅ |
| Stash (iOS) | ✅ | ✅ |
| Clash for Android | ✅ | ✅，需较新版本 |
| Shadowrocket (iOS) | ✅ | ✅ |

> **结论：** 两者在所有主流 Clash 系客户端上均被良好支持。Hysteria2 需要 Clash Meta 内核（Mihomo），但自 2024 年起几乎所有活跃的 Clash 发行版都已迁移到 Meta 内核。

---

## 7. 资源占用

| 指标 | WS+TLS | Hysteria2 |
|------|--------|-----------|
| 额外进程 | 2（Sing-box + OpenResty 配置修改） | 1（Hysteria2 单进程） |
| 内存 | ~60-120 MB | ~40-80 MB |
| CPU | 低（TLS 卸载到 OpenResty） | 中（QUIC 加密 + Brutal 算法） |
| 加密架构 | 外层 TLS（OpenResty 终止）→ 内层 VLESS 认证（127.0.0.1 明文传输到后端） | TLS 1.3 全过程加密 |

---

## 8. 安全与隐私

| 维度 | WS+TLS | Hysteria2 |
|------|--------|-----------|
| 中间人攻击 | 由 Let's Encrypt 证书 + CA 验证防御 | TLS 1.3 + 证书固定（可选） |
| 加密模型 | VLESS 认证/承载 + TLS 1.3（注意：TLS 在 OpenResty 终止，OpenResty 到后端是本地明文） | TLS 1.3 + QUIC 传输加密（全过程加密） |
| 日志 | OpenResty access log 会记录 WS 路径访问，有路径泄露风险 | 日志较少，但仍需检查服务日志（systemd / Docker / 服务端配置） |
| 端口识别 | 443 端口服务类型可被识别为 Web 服务器 | UDP 端口难以识别具体服务类型 |

---

## 9. 决策树

```
你有域名指向这台服务器吗？
├── 有 → 继续
│     你能忍受修改 OpenResty 配置吗？
│     ├── 能 → 你确定 WS+TLS 而不是 Reality 吗？
│     │    ├── 是 → 方案B (WS+TLS) — 注意路径命名和日志
│     │    └── 否 → 见附录：方案A (VLESS+Reality)
│     └── 不能 → 方案C (Hysteria2) — 检查 UDP 放行
└── 没有 → 跳过方案B，直接方案C (Hysteria2) — 推荐域名+证书
```

---

## 10. 综合推荐

| 使用场景 | 推荐方案 | 理由 |
|----------|---------|------|
| GitHub / 普通网页浏览 | 均可 | 两者都足够，体验差异不大 |
| Netflix 4K 流媒体 | **Hysteria2** ☝️ | Brutal 保带宽，丢包环境优势明显（前提：UDP 未被限速） |
| Telegram 即时通信 | **Hysteria2** ☝️ | 0-RTT 重连适合移动网络频繁断连的场景 |
| 政治敏感期 / 极端隐匿 | WS+TLS 或 Reality | 443/TCP 比 UDP 更普遍，UDP/QUIC 可能被局部限速或封禁 |
| 不想动现有 OpenResty | **Hysteria2** ⭐ | 零干预，独立端口运行 |
| 维护简单 / 快速部署 | **Hysteria2** ⭐ | 单二进制 + 单 YAML 配置，10 分钟上线 |
| UDP 受限制的网络环境 | **WS+TLS** ⭐ | 纯 TCP 不受 UDP QoS 影响 |

### 最终建议

| 你的优先级 | 推荐方案 |
|-----------|---------|
| **不动 OpenResty、移动端体验、流媒体优先** | → **Hysteria2** |
| **443/TCP 可达性、保守网络环境、CDN/HTTPS 外观** | → **WS+TLS** |
| **追求最强隐匿、抗检测** | → **VLESS+Reality**（见附录） |
| **既能隐匿又能高速** | → **Reality(TCP) + Hysteria2(UDP) 双协议**，Clash 客户端自动切换 |

> **判断逻辑：**
> - 如果你的 ISP 对 UDP 友好（联通通常最好，电信次之，移动/教育网需测试）→ **Hysteria2**
> - 如果你的网络环境限制 UDP（公司/学校/酒店 Wi-Fi、移动 4G 限 UDP）→ **WS+TLS** 或 **Reality**
> - 如果想一步到位、双保险 → **Reality 主 + Hysteria2 备**

---

## 附录：方案A — VLESS+Reality（高位 TCP 端口）

> 本文核心对比 B vs C，但 Reality 在本场景中是不可忽略的第三选择。

**为何在 B vs C 对比中被提及？**
- Reality 的隐身评分 9/10（全场最高），高于 WS+TLS 和 Hysteria2 的 ~7/10
- 不需要域名、不需要证书、不需要改 OpenResty
- 高位 TCP 端口（如 8443/tcp），与 443 完全隔离
- Clash 客户端原生支持

**Reality vs WS+TLS vs Hysteria2 三者比较：**

| 维度 | Reality (高位 TCP) | WS+TLS (443) | Hysteria2 (UDP) |
|------|-------------------|--------------|-----------------|
| 隐身评分 | **9/10** | ~7/10 | ~7/10 |
| 域名需求 | **不需要** | 需要 | 推荐但不必须 |
| 改 OpenResty | **不需要** | 需要 | 不需要 |
| 性能（稳定网络） | 优秀 | 良好 | 优秀 |
| 性能（丢包网络） | 一般 | 一般 | **优秀** |
| 移动端体验 | 一般 | 一般 | **优秀** |

**建议：** 如果经过对比后发现最看重隐身性和简洁性（不需要域名和证书），可以回看方案A Reality，它在很多维度上是一个更好的"基线方案"。

---

## 参考来源

1. [China Protocol Comparison 2026: Lab Benchmarks](https://greatfirewallguide.com/lab/protocol-matrix) — 2026-04 实测数据（实验室环境，结果因 ISP 和线路质量而异）
2. [Hysteria 2 vs VLESS Reality: Protocol Comparison](https://lunaire.app/en/blog/hysteria-2-vs-vless-reality) — Lunaire, 2026-04（厂商视角）
3. [XTLS/Xray-core Discussion #2950](https://github.com/XTLS/Xray-core/discussions/2950) — 实际 ISP 对比测试（社区用户，伊朗 LTE 环境）
4. [Exposing and Circumventing SNI-based QUIC Censorship of the GFW](https://gfw.report/publications/usenixsecurity25/en/) — USENIX Security 2025（学术论文）
5. [Comparing VPN Protocols for Connectivity from China](https://lilting.ch/en/articles/china-vpn-protocol-comparison) — 2025 年实测（日本用户视角）

> **注：** 性能数据和评分来自公开资源和社区测试，不代表最终用户体验。建议在实际部署后根据自身 ISP（电信/联通/移动）和时段做验证。