《林一的 Cloudflare 通关记》第 2 篇-网站"裸奔"太危险——SSL/TLS 加密初体验
《林一的 Cloudflare 通关记》第 2 篇
上回说到，林一把域名托管到了 Cloudflare，网站能访问了，但浏览器地址栏却亮起了"不安全"的红灯。今天，老张要给网站穿上一件看不见的盔甲。
第二天一早，林一到办公室的第一件事就是打开浏览器，输入 http://xinghuo-ai.com。
页面倒是能打开，但地址栏左边那个醒目的"不安全"标签，像一块狗皮膏药一样贴在那里，格外碍眼。
一、"不安全"三个字，吓走了第一个用户
更糟的是，昨晚 CEO 把网站链接发给了几个潜在客户，有一个直接回复："你们这网站不安全啊，我不敢注册。"
林一有点慌。他找到老张："张哥，那个'不安全'的提示……"
"看到了，"老张头也不抬，"你的网站现在用的是 HTTP，明文传输。用户的密码、聊天内容，在网络上裸奔，谁截获了谁就能看。"
"那怎么搞？加个 SSL 证书？"
"对，但你知道 SSL 证书是怎么加密的吗？不只是'装个证书'这么简单。"老张转过椅子，"来，今天给你讲明白。"
二、HTTPS 不就是加个锁吗？锁里面大有文章
"你知道 HTTPS 和 HTTP 的区别吧？"老张问。
"知道，就是加了一层 SSL/TLS 加密嘛。"林一理所当然地回答。
"没错。但你有没有想过一个问题——浏览器和服务器之间隔着千山万水，中间经过无数路由器、运营商、CDN 节点，它们是怎么安全地商量出一个'加密密钥'的？如果密钥直接在网上传输，中间人不就截获了吗？"
林一愣住了。对啊，密钥怎么传？
"这就是 SSL/TLS 握手要解决的核心问题。"老张在白板上画了起来。
TLS 握手：非对称加密换密钥，对称加密传数据
"SSL/TLS 握手用了一个很巧妙的设计——两种加密方式配合使用。"
第一步：非对称加密——安全地交换密钥
非对称加密有一对密钥：公钥和私钥。公钥可以公开给任何人，私钥只有服务器自己知道。用公钥加密的数据，只有私钥能解密；反过来，用私钥签名的东西，公钥可以验证。
握手过程简化来说是这样的：
- 浏览器连接服务器，说："我想跟你建立加密通信，这是我支持的加密算法列表。"
- 服务器回复："好的，这是我的数字证书（里面包含公钥）。"
- 浏览器验证证书是否可信（检查证书颁发机构、有效期、域名是否匹配）
- 浏览器生成一个随机的"会话密钥"，用服务器的公钥加密后发过去
- 服务器用自己的私钥解密，拿到会话密钥
第二步：对称加密——用密钥传输数据
双方都拿到了会话密钥之后，后续的所有通信都改用对称加密——同一把密钥加密和解密，速度比非对称加密快得多。
握手阶段（慢，但只做一次） 传输阶段（快，持续使用）
浏览器 ←→ 服务器 浏览器 ←→ 服务器
非对称加密：安全交换会话密钥 对称加密：高速传输数据
"为什么不直接用非对称加密传所有数据？"林一问。
"因为非对称加密的运算量是对称加密的几百倍，拿来传网页内容会慢到没法用。所以用非对称加密只做一件事——安全地把会话密钥交给对方——然后切换到对称加密，兼顾安全和性能。"
林一恍然大悟。这个设计确实巧妙：用慢但安全的方式交换密钥，用快的方式传数据。
"当然，实际 TLS 1.3 的握手过程比这更精简，"老张补充道，"TLS 1.3 把握手从两轮往返压缩到一轮，而且引入了前向安全性——即使以后私钥泄露了，之前截获的通信也无法被解密。Cloudflare 默认支持 TLS 1.3，这个不用你操心。"
💡 国内类比：国内云服务商（阿里云、腾讯云）也提供免费 DV 证书，但通常需要你手动申请、手动部署、手动续期。Cloudflare 的 Universal SSL 是全自动的——证书签发、部署、续期都不用你管，域名激活后自动生效。
三、Cloudflare 的"两段加密"模型
"好了，原理讲完了。现在说 Cloudflare 特有的部分——这也是新手最容易搞混的地方。"
老张在白板上画了一张图：
用户浏览器 ──HTTPS──→ Cloudflare 边缘节点 ──???──→ 你的源服务器
边缘证书 源服务器证书
(Edge Certificate) (Origin Certificate)
"还记得昨天说的代理模式吗？橙色云朵。开了代理之后，用户访问的不再是你的源服务器，而是 Cloudflare 的边缘节点。所以整个加密链路被分成了两段："
第一段：用户 → Cloudflare（边缘证书）
这一段的加密由 Cloudflare 负责。Cloudflare 会自动给你签发一张 Universal SSL 证书——免费的、公开信任的、自动续期的。用户在浏览器里看到的小锁图标，靠的就是这张证书。
Universal SSL 覆盖你的根域名（xinghuo-ai.com）和一级子域名（www.xinghuo-ai.com）。如果你的域名是 Cloudflare 托管的（昨天做的 Full Setup），证书的域名验证（DCV）也是全自动的——因为 DNS 都在 Cloudflare 手里，验证自然水到渠成。
"这就是昨天说的'域名托管在 Cloudflare，后面一顺百顺'的另一个体现，"老张说，"如果你的 DNS 不在 Cloudflare，DCV 就得手动做——加 TXT 记录、等验证、可能续期的时候还得再来一遍。麻烦。"
第二段：Cloudflare → 你的源服务器（源服务器证书）
这一段的加密由你负责。你需要在源服务器上安装一张 SSL 证书。Cloudflare 提供了一个免费的 Origin CA 证书服务，可以给你签发一张只被 Cloudflare 信任的证书——有效期最长 15 年，装一次基本不用管了。
"等等，"林一举手，"只被 Cloudflare 信任？什么意思？"
"意思是这张证书不是公开信任的——如果你把 Cloudflare 代理关掉，用户直连你的服务器，浏览器会报证书不可信。但只要你走 Cloudflare 代理，用户看到的是 Cloudflare 的边缘证书（公开信任的），源服务器证书只是 Cloudflare 和你之间内部用的，不需要公开信任。"
"这不就是内部通行证吗？"
"对，就是内部通行证。外面的人看的是大门的证件（边缘证书），大门到办公室之间的内部通行证（源服务器证书）只需要内部认就行。"
四、三种 SSL 模式：Flexible、Full、Full (strict)
"理解了两段加密模型，"老张说，"SSL 模式就好理解了。Cloudflare 有几种加密模式，核心区别就是这两段加密各怎么处理。"
Flexible（灵活模式）
用户 ──HTTPS──→ Cloudflare ──HTTP──→ 源服务器
✅ 加密 ❌ 不加密
用户到 Cloudflare 是加密的，但 Cloudflare 到你的源服务器是明文 HTTP。
"这种模式适合什么场景？"老张自问自答，"源服务器没有 SSL 证书、又想快速让用户看到 HTTPS 的小锁。很多人刚接入 Cloudflare 时先用 Flexible 顶着。"
"但有问题？"
"有大问题。"老张竖起三根手指：
- 安全漏洞：Cloudflare 到源服务器这段是明文的，用户的密码、Cookie 等敏感数据在这一段仍然裸奔。攻击者只要在这段路上截获流量，一样能看
- 重定向地狱：很多网站框架（WordPress、Django 等）会检测请求是否是 HTTPS，如果不是就重定向到 HTTPS。但 Cloudflare 到源服务器走的是 HTTP，框架一看不是 HTTPS 就重定向，Cloudflare 又把重定向转给用户——结果就是无限重定向循环，浏览器报
ERR_TOO_MANY_REDIRECTS - 协议误判：源服务器收到的请求是 HTTP 的，应用层可能会误认为用户在用 HTTP 访问，生成
http://的链接、设置不安全的 Cookie——各种奇怪的问题
"所以 Flexible 只能当临时过渡，不能长期用。"
Full（完全模式）
用户 ──HTTPS──→ Cloudflare ──HTTPS──→ 源服务器
✅ 加密 ✅ 加密（但不验证证书）
两段都加密了，但 Cloudflare 不验证源服务器的证书是否有效。源服务器上可以是自签名证书、过期证书、甚至域名不匹配的证书——Cloudflare 都不管，只要能加密就行。
"适合什么场景？源服务器装了证书，但证书可能不太正规——比如自签名的。比 Flexible 安全，但不如 Full (strict)。"
Full (strict)（完全严格模式）
用户 ──HTTPS──→ Cloudflare ──HTTPS──→ 源服务器
✅ 加密 ✅ 加密 + 证书验证
两段都加密，而且 Cloudflare 会验证源服务器的证书是否有效——必须是受信任的 CA 签发的、未过期的、域名匹配的证书。
"这是最安全的模式，"老张说，"也是 Cloudflare 官方推荐的。你的源服务器证书可以是 Let's Encrypt 的免费证书，也可以是 Cloudflare Origin CA 签发的——都行，只要是合法的。"
林一总结了一下：
| 模式 | 用户→CF | CF→源站 | 安全级别 |
|---|---|---|---|
| Flexible | HTTPS | HTTP | ⚠️ 有安全漏洞 |
| Full | HTTPS | HTTPS（不验证证书） | 🔒 较安全 |
| Full (strict) | HTTPS | HTTPS（验证证书） | 🔒🔒 最安全 |
"选哪个？"
"当然是 Full (strict)。"老张说，"我们用 Cloudflare Origin CA 签一张证书装到源服务器上，然后开 Full (strict)，全链路加密 + 证书验证，完美。"
顺便提一下：Automatic SSL/TLS
"对了，"老张补充道，"Cloudflare 最近推出了一个 Automatic SSL/TLS 功能，正在逐步推广。它会自动检测你源服务器的证书情况，帮你选最安全的 SSL 模式。如果你的源站已经有有效证书，它会自动帮你从 Flexible 升级到 Full (strict)。升级是灰度的——先从 1% 的流量开始，没问题再加到 10%、20%……一直到 100%。如果中间出了问题，自动回滚。"
"听起来挺智能的。"
"是挺智能，但我们还是手动配，知其然也要知其所以然。而且新功能还在推广期，不一定每个账号都有了。"
五、实操：配置 Full (strict) 模式
"动手吧。"老张拍了拍林一的肩膀。
第 1 步：生成 Origin CA 证书
- 登录 Cloudflare 控制台 → 选择
xinghuo-ai.com→ 左侧菜单 SSL/TLS → Origin Server - 点击 Create Certificate
- 选择 Let Cloudflare generate a private key and a CSR（让 Cloudflare 帮你生成私钥和签名请求）
- 私钥类型选 RSA (2048)（兼容性最好）或 ECDSA（更轻量更快，但老服务器可能不支持）
- Hostnames 列表默认包含
xinghuo-ai.com和*.xinghuo-ai.com，够用了 - 证书有效期选 15 years（最长，装一次管 15 年）
- 点击 Create
- 页面会显示 Origin Certificate（证书）和 Private Key（私钥），立刻复制保存——私钥离开这个页面就再也看不到了
"私钥一定要保管好，"老张叮嘱，"泄露了就得吊销重来。"
第 2 步：安装到源服务器
林一公司的源服务器跑的是 Nginx。他把证书和私钥分别保存为 /etc/ssl/cloudflare/origin.crt 和 /etc/ssl/cloudflare/origin.key，然后修改 Nginx 配置：
server {
listen 443 ssl http2;
server_name xinghuo-ai.com;
ssl_certificate /etc/ssl/cloudflare/origin.crt;
ssl_certificate_key /etc/ssl/cloudflare/origin.key;
# 其他配置...
}
"如果你想让 Nginx 只信任 Cloudflare 的请求（防止有人绕过 Cloudflare 直连源服务器），还可以配置 mTLS 互信，"老张说，"不过这个后面讲 Zero Trust 的时候再说，现在先不加。"
第 3 步：切换 SSL 模式为 Full (strict)
- 回到 Cloudflare 控制台 → SSL/TLS → Overview
- 如果看到 Automatic SSL/TLS 选项，先切换为 Custom SSL/TLS
- 选择 Full (strict)
"等几分钟生效，"老张说，"然后试试访问。"
林一在浏览器输入 https://xinghuo-ai.com——小锁出现了，"不安全"标签消失了。点开锁图标，查看证书，显示的是 Cloudflare 签发的 Universal SSL 证书。
"成了！"林一有点激动。
"别急，还有一步。"
六、Always Use HTTPS：堵住最后一个漏洞
"你现在访问 http://xinghuo-ai.com 试试。"老张说。
林一输入了 HTTP 地址——页面能打开，但没有自动跳转到 HTTPS。
"这有个问题，"老张解释，"如果用户手动输入 http:// 或者从某个 HTTP 链接点过来，他们还是会走明文 HTTP。虽然有 Cloudflare 代理，但第一段（用户到 Cloudflare）如果是 HTTP 的话，这段就不加密。"
"加个 301 重定向？"
"不用改服务器配置，Cloudflare 一个开关搞定。"
- 进入 Cloudflare 控制台 → SSL/TLS → Edge Certificates
- 找到 Always Use HTTPS，打开开关
"开了之后，所有 HTTP 请求都会被 Cloudflare 自动 301 重定向到 HTTPS。你不需要在源服务器上做任何重定向配置——实际上，Cloudflare 官方建议你不要在源服务器上做 HTTP→HTTPS 重定向，因为那容易和 Cloudflare 的重定向冲突，导致重定向循环。"
"还有什么能开的？"
老张扫了一眼 Edge Certificates 页面上的其他选项：
- Minimum TLS Version：可以设置最低 TLS 版本。建议设为 TLS 1.2，禁用不安全的 TLS 1.0 和 1.1。Cloudflare 免费版就支持这个功能
- Automatic HTTPS Rewrites：自动把页面里的
http://链接改写成https://，解决混合内容（Mixed Content）问题。建议开启 - HSTS：HTTP Strict Transport Security，告诉浏览器"以后这个域名只准用 HTTPS 访问"。不过开启前要确保所有子域名都支持 HTTPS，否则可能锁死。建议网站稳定后再开
"Minimum TLS Version 设 1.2，Automatic HTTPS Rewrites 开了，HSTS 先不动。"老张快速过了一遍。
七、小结：盔甲穿好了
下班前，林一总结今天的收获：
- 理解了 TLS 握手原理——非对称加密安全交换会话密钥，对称加密高速传输数据，两种方式各司其职
- 搞懂了 Cloudflare 的两段加密模型——边缘证书（用户→Cloudflare）+ 源服务器证书（Cloudflare→源站），各管一段
- 明白了三种 SSL 模式的区别——Flexible（有安全漏洞）、Full（不验证证书）、Full (strict)（最安全，推荐）
- 用 Origin CA 生成了源服务器证书——免费、有效期 15 年、只被 Cloudflare 信任
- 配置了 Full (strict) 模式——全链路加密 + 证书验证
- 开启了 Always Use HTTPS——所有 HTTP 请求自动 301 到 HTTPS
- 设置了 Minimum TLS Version 为 1.2——禁用不安全的旧版 TLS
"不错，"老张点了点头，"网站现在有了加密，用户看到小锁也放心了。"
"那是不是可以开始写代码了？"
"急什么，"老张笑了，"你的网站现在虽然加密了，但打开速度……你自己试试。"
林一刷新了一下页面。确实，慢。服务器在国内，Cloudflare 的边缘节点在海外，用户请求要先绕到海外节点再转回来——这个延迟，肉眼可感。
"明天，我教你让网站飞起来。"老张拿起保温杯，慢悠悠地走了。
本篇知识点回顾
| 知识点 | 说明 |
|---|---|
| TLS 握手原理 | 非对称加密安全交换会话密钥 → 对称加密高速传输数据，兼顾安全与性能 |
| Cloudflare 两段加密 | 边缘证书（用户→CF，Universal SSL 免费）+ 源服务器证书（CF→源站，Origin CA 免费） |
| SSL 模式 | Flexible（CF→源站不加密，不推荐）；Full（加密但不验证证书）；Full (strict)（加密且验证证书，推荐） |
| Flexible 的坑 | 安全漏洞、重定向循环（ERR_TOO_MANY_REDIRECTS）、协议误判 |
| Origin CA 证书 | Cloudflare 免费签发，最长 15 年有效期，只被 CF 信任（需走代理才有效） |
| Always Use HTTPS | 一键开启 HTTP→HTTPS 301 重定向，源服务器不需要自己做重定向 |
| Minimum TLS Version | 建议设为 TLS 1.2，禁用不安全的旧版本 |
动手挑战
如果你的网站已经接入了 Cloudflare，试试把 SSL 配置升级到最安全状态：
- 在 SSL/TLS → Origin Server 中生成一张 Origin CA 证书
- 把证书安装到你的源服务器（Nginx/Apache）
- 把 SSL/TLS 模式切换为 Full (strict)
- 在 Edge Certificates 中开启 Always Use HTTPS
- 把 Minimum TLS Version 设为 1.2
- 开启 Automatic HTTPS Rewrites
- 用浏览器的开发者工具检查证书信息，确认是 Cloudflare 签发的
下回预告
网站加密搞定了，但速度还是慢——用户请求要绕到海外节点再回来。下篇，老张要给网站装上"加速器"：CDN 缓存。林一将了解 Cloudflare 的缓存机制、Cache Rules 的配置方法，以及如何让静态资源在全球边缘节点秒开。还有那个让无数新手头疼的"缓存命中率"到底怎么提升。
敬请关注《林一的 Cloudflare 通关记》第 3 篇：让网站飞起来——CDN 缓存与加速。
