TLS 证书与 CDN 架构：理解加密链路的每一环
上一章讲解了 VLESS + Reality 方案。但当你需要隐藏 VPS 真实 IP 时，就需要走 CDN（如 Cloudflare）中转流量。这要求你理解 TLS 证书体系和 CDN 的加密架构——搞不清楚这些，配置时一定会踩坑。
本章解析 TLS 证书从签发到验证的完整流程，Cloudflare 的两段式加密模型，以及 GFW 能从 TLS 连接中获取哪些信息。
证书颁发机构（CA）的角色
CA（Certificate Authority）是 TLS 信任体系的基石。它的工作是：为域名签发数字证书，证明"这个公钥确实属于这个域名"。
浏览器和操作系统内置了一个受信任 CA 列表，只有这些 CA 签发的证书才会被自动信任。
常见 CA
| CA | 特点 | 适用场景 |
|---|---|---|
| Let's Encrypt | 免费、自动化、90 天有效期 | 个人网站、小项目 |
| Cloudflare | 免费、自动管理、15 年有效 | Cloudflare 用户 |
| DigiCert | 商业、高可信度 | 企业 |
| ZeroSSL | 免费，Let's Encrypt 的替代 | Let's Encrypt 受限时 |
TLS 握手：GFW 能看到什么
TLS 连接建立时，有一些信息是明文传输的：
GFW 能获取的信息：
| 可见 | 不可见 |
|---|---|
| 目标 IP 地址 | URL 路径（/path/to/page） |
| SNI 域名 | 请求正文 |
| 证书签发者 | Cookie / Token |
| TLS 版本 | 响应内容 |
| 连接时间和数据量 | — |
这就是为什么单纯使用 HTTPS 不等于安全——GFW 知道你连了哪个域名（通过 SNI），只是不知道你在域名下访问了什么内容。
Cloudflare 的两段式 TLS 架构
当你使用 Cloudflare 代理（橙色云朵）时，一个 HTTPS 请求实际经历了两段独立的 TLS 连接：
第一段：用户 → Cloudflare
- 证书签发者：Cloudflare Inc.（不是 Let's Encrypt）
- 用户浏览器看到的始终是 Cloudflare 的证书
- IP 地址是 Cloudflare 的 CDN 节点（全球数百万网站共用）
第二段：Cloudflare → 你的 VPS
- 这一段用什么证书取决于你的 SSL/TLS 设置
- 可以是 Cloudflare Origin Certificate（免费，15 年有效）
- 也可以是 Let's Encrypt 证书
- 甚至可以是自签名证书（Full 模式）
关键理解：用户看到的证书是 Cloudflare 签的，不管你的 VPS 上用的是什么证书。你服务器上的证书只需要让 Cloudflare 满意就行。
对 GFW 的意义
理解两段式架构后，来分析 GFW 在不同配置下能看到什么：
| 配置方案 | GFW 看到的 IP | GFW 看到的证书 | 风险评估 |
|---|---|---|---|
| VPS 直连 + Let's Encrypt | 你 VPS 的真实 IP | Let's Encrypt 签发 | 高——IP 暴露，可直接封 |
| VPS 直连 + Cloudflare Origin Cert | 你 VPS 的真实 IP | Cloudflare 签发 | 高——同上 |
| Cloudflare 代理（橙云） | Cloudflare CDN IP | Cloudflare Inc. 签发 | 低——等于封 Cloudflare |
结论很清晰：使用 Cloudflare 代理后，GFW 看到的只是你在访问 Cloudflare——而全球有数百万网站都在用 Cloudflare。封 Cloudflare 的代价极高（等于封掉大量正常网站）。
子域名代理架构
实际部署中，常见的架构是：主域名运行正常网站，子域名用于代理。
GFW 主动探测的行为
当 GFW 发现可疑流量来自 proxy.example.com:443 时：
真正决定探测结果的是"回落配置"：
即使你的子域名走 Cloudflare 代理（橙云），VPS 上的 Nginx 也应该配置合理的回落。因为 VPS 的真实 IP 可能通过其他途径泄露（历史 DNS 记录、邮件头等），此时直连探测仍可能发生。
DNS Only vs Proxied 的选择
Cloudflare 的 DNS 记录有两种模式：
| 模式 | 图标 | 流量路径 | 适用场景 |
|---|---|---|---|
| Proxied（橙云） | 🟠 | 客户端 → CF CDN → VPS | 正常网站、需要隐藏 IP |
| DNS Only（灰云） | ⚪ | 客户端 → 直连 VPS | 代理节点（需要真实连接） |
代理节点为什么用 DNS Only？
WebSocket 代理需要客户端与服务器之间建立持久的全双工连接。虽然 Cloudflare 支持 WebSocket，但：
- 免费计划限制：Cloudflare 免费版对 WebSocket 连接数和持续时间有限制
- 延迟增加：多经过一跳 CDN，延迟增加 30-100ms
- 流量审查风险：Cloudflare 可能检测到非常规的 WebSocket 使用模式
策略建议：平时用 DNS Only（直连，延迟低），如果 VPS IP 被封了再切到 Proxied（走 CDN 续命）。Cloudflare 面板切换只需几秒。
证书方案选择
对于代理节点，证书配置有几种选择：
方案一：Cloudflare Origin Certificate（推荐）
优点：
- 免费、有效期极长（15 年）
- 一个通配符证书覆盖所有子域名
- 不需要续期脚本
缺点：
- 只有 Cloudflare 信任这个证书（浏览器直连不信任）
- DNS Only 模式下，代理客户端需要
skip-cert-verify: true
方案二：Let's Encrypt
优点：
- 全球信任（浏览器也认）
- 免费
缺点：
- 90 天过期，需要自动续期
- 每个子域名单独申请
- 暴露你在使用 Let's Encrypt（GFW 可能标记）
实际推荐
| 场景 | 推荐证书 |
|---|---|
| 代理节点（走 Cloudflare 代理或客户端 skip-cert-verify） | Cloudflare Origin Certificate |
| 需要浏览器直接信任（如伪装网站） | Let's Encrypt |
| 不想要域名和证书 | 直接用 Reality（回到上一章方案） |
WebSocket + TLS 的加密层次
最后明确一下 WebSocket + TLS 方案的完整加密结构：
外部观察者（包括 GFW）抓包能看到的：
- ✅ 一个标准的 TLS 1.3 连接
- ✅ SNI 是你的子域名
- ❌ 看不到 WebSocket 帧内容
- ❌ 看不到代理协议数据
- ❌ 看不到你实际访问的目标网站
这就是 wss://（WebSocket Secure）的安全保证——本质上和你打开任何 HTTPS 网站一样安全。
三种方案最终对比
| 维度 | VLESS + TCP + TLS | VLESS + WS + TLS (+ CDN) | VLESS + Reality |
|---|---|---|---|
| 需要域名 | ✅ | ✅ | ❌ |
| 需要证书 | ✅ | ✅（CDN 代管可省） | ❌ |
| 能过 CDN | ❌ | ✅ | ❌ |
| 抗主动探测 | 中 | 高（有回落） | 最高（回落到大站） |
| 隐藏 VPS IP | ❌ | ✅ | ❌ |
| 性能 | 好 | 中（多层开销） | 最好 |
| IP 被封恢复 | 换 VPS | 切 CDN 代理即可 | 换 VPS |
选择决策树
小结
本章讲解了 TLS 证书、CDN 架构和 GFW 分析手段的核心知识。关键要点：
- Cloudflare 橙云代理让 GFW 只能看到 Cloudflare 的 IP 和证书，无法定位你的 VPS
- 回落配置是对抗主动探测的关键——让非法请求得到正常网站的响应
- Origin Certificate 是代理节点最省心的证书方案
- DNS Only + 备用 Proxied 是灵活的运维策略
理论基础已经足够，下一章进入实操——在一台已有 Web 项目的 VPS 上搭建完整的代理节点。
下一章是动手环节：在已部署 Web 项目的 VPS 上搭建 Trojan + WebSocket + TLS 代理，与现有网站共存。