Cloudflare 回源加密架构：访客请求经加密隧道回源到受保护的源站服务器

Cloudflare 回源加密与源站保护：免费证书配置实操

作者

Cloudflare 回源加密架构封面：访客经边缘节点加密回源到服务器

为什么打开小云朵后，源站反而更危险了

很多站长在接入 Cloudflare（CDN，内容分发网络）之后，以为网站已经披上了”隐身衣”，实际却常常埋着一个反直觉的坑：只要有人猜到你的真实源站 IP，就可以完全绕过 CDN，直接对源站发起扫描和攻击。更糟的是，如果回源这段路没有加密，访客与边缘节点之间虽然是 HTTPS（安全超文本传输协议），数据在节点回源时却可能以明文 HTTP 传输，等于在链路中间留了一段”裸奔”的通道。

这篇文章就是帮你解决这个问题：如何用 Cloudflare 提供的免费 Origin CA 证书完成回源加密，把 SSL/TLS 模式调成”完全（严格）”，再通过回源 IP 白名单把源站锁到只接受 Cloudflare 的请求。整个流程不需要花钱买证书——Origin CA 证书完全免费（截至 2026 年 10 月仍免费开放，具体以官方页面为准），一台普通的 VPS（虚拟专用服务器）就能完整跑通，全部操作大约 30 分钟。

先搞懂：回源加密到底加密了哪一段

一次被 Cloudflare 代理的访问，其实分成两段路：第一段是访客浏览器到 Cloudflare 边缘节点，第二段是边缘节点回源到你自己的服务器。”回源加密”指的就是第二段——节点与源站之间的 HTTPS 连接。Cloudflare 在 SSL/TLS（安全传输层协议，负责加密客户端与服务器之间的连接）设置里提供了几种模式，安全强度差别很大，选错模式是最常见的踩坑点。

下面这张对比图直观展示了三种主流模式在”访客到边缘”与”边缘到源站”两段路上的加密差异：

Cloudflare 三种加密模式对比：灵活、完全、完全严格的链路差异

三种模式的核心区别可以这样理解：

  • 灵活（Flexible）：只加密访客到边缘这一段，回源走明文 HTTP；如果源站强制跳转 HTTPS，会出现无限重定向循环
  • 完全（Full）：回源也走 HTTPS，但不校验证书有效性，自签证书也能通过，能加密却防不了中间人
  • 完全（严格）（Full Strict）：回源走 HTTPS 且校验证书，要求源站部署受信任的证书或 Cloudflare 签发的 Origin CA 证书

核心结论是：既要回源加密、又要防住中间人，目标模式只有一个——完全（严格）。这也是后面配置免费证书的意义所在：Origin CA 证书正是让”严格”模式能跑通的官方通行证。

实操：五步完成免费证书签发与部署

准备工作确认三件事：域名已接入 Cloudflare 且小云朵为橙色（代理开启）；你能登录源站服务器执行命令；服务器上已安装 Nginx 或 Apache 任一 Web 服务。下面以 Nginx 为例，Apache 的思路完全一致，只是证书路径写法不同。

第一步：在 Cloudflare 后台生成 Origin CA 证书

登录 Cloudflare 控制台，进入对应域名后依次点击：SSL/TLS → 源服务器（Origin Server）→ 创建证书。私钥类型选 RSA（2048 位），主机名保持默认的两条（*.yourdomain.com 和 yourdomain.com），有效期可以选 15 年。点击创建后，页面会分别给出”源证书”和”私钥”两段文本，把这两段文本分别复制保存为两个本地文件：

# 把复制的证书内容粘贴进去
vim /etc/ssl/cloudflare-origin.pem
# 把复制的私钥内容粘贴进去
vim /etc/ssl/cloudflare-origin.key
# 收紧权限，避免私钥被其他用户读取
chmod 600 /etc/ssl/cloudflare-origin.key

注意：私钥只在创建时显示这一次，关掉页面后无法再次查看。如果你没有当场保存，只能吊销重签。

第二步：配置 Nginx 启用证书

编辑站点配置文件（通常在 /etc/nginx/conf.d/ 或 /etc/nginx/sites-available/ 下），把监听改成 443 并挂上刚部署的证书：

server {
    listen 443 ssl;
    server_name yourdomain.com;

    ssl_certificate     /etc/ssl/cloudflare-origin.pem;
    ssl_certificate_key /etc/ssl/cloudflare-origin.key;

    root /var/www/html;
    index index.html;
}

改完执行 nginx -t 检查语法，确认 syntax is ok 后 systemctl reload nginx 平滑重载。这一步完成后，源站已经具备接收 HTTPS 回源请求的能力。

第三步：切换 SSL/TLS 模式为完全（严格）

回到 Cloudflare 后台的 SSL/TLS → 概述页面，把加密模式从默认的”灵活”改成”完全（严格）”。改完不要急着关页面，先在浏览器里用无痕模式访问一次自己的网站，确认页面正常打开、地址栏显示安全锁标志。如果出现 525 或 526 错误码，说明源站证书这一步没配好，回到第一步检查证书文件是否完整、权限是否正确。

到这里，回源加密已经完成。但还有一半工作没做——源站现在对所有人生效，任何人直接访问你的源站 IP 依然能打开网站，下一节解决这个遗留问题。

源站保护：用防火墙把源站 IP 藏起来

回源加密解决的是”数据路上不被偷”，源站保护解决的是”路只有 Cloudflare 能走”。思路是把 Cloudflare 官方公布的回源 IP 段加进防火墙白名单，443 和 80 端口只对白名单放行，其余来源一律丢弃。

先在服务器上用 ufw（Ubuntu/Debian 常用防火墙工具）配置。Cloudflare 的最新 IP 段以官方页面 www.cloudflare.com/ips/ 实时公布为准，目前共 15 个 IPv4 段和 7 个 IPv6 段，逐段添加即可：

# 先放行 SSH，避免把自己锁在门外
ufw allow 22/tcp
# 放行 Cloudflare 回源段（以官方 ips 页面实时列表为准，逐段执行）
ufw allow proto tcp from 173.245.48.0/20 to any port 443
ufw allow proto tcp from 103.21.244.0/22 to any port 443
# 80 端口同理逐段放行，用于证书外的 HTTP 跳转
# 最后启动防火墙
ufw enable

配置完成后做一次验证：用手机流量（不走 Cloudflare 的网络）直接访问 https://你的源站IP，正常结果应该是连接超时或拒绝；再用正常域名访问，页面应照常打开。两个现象同时出现，说明白名单生效且没有误伤正常流量。

下面这张示意图概括了”只允许 CDN 回源、其余来源在防火墙层直接丢弃”的整体结构：

源站防火墙拓扑：仅允许回源节点访问 443 端口

如果你的源站是 Hostease 独立服务器，可以直接在 cPanel/WHM 面板里用防火墙管理工具配置同样的白名单规则，省去命令行操作；具体入口可以参考我们整理过的服务器配置相关文章。用虚拟主机的站长则不需要操心这层，回源保护由平台侧统一处理。

常见故障排查：三个最典型的问题现场

配置完成后如果站点异常，按下面三个现场对号入座，每一个都给出对应的检查动作：

  • 错误 525（SSL 握手失败）：源站 443 没有真正监听，或证书路径写错。在源站执行 ss -tlnp | grep 443 确认端口在监听，再执行 nginx -t 确认配置无语法错误
  • 错误 526（证书校验失败）：证书或私钥内容粘贴不完整，比如漏了 -----END CERTIFICATE----- 结尾行。重新打开证书文件核对首尾行，必要时重签
  • 无限重定向循环：源站还开着”HTTP 强制跳转 HTTPS”，而 Cloudflare 端模式仍是”灵活”。把模式切成”完全（严格）”，或关掉源站侧的强制跳转插件，二选一即可

排查时有个省时间的技巧：先看 Cloudflare 后台 SSL/TLS 模式，再看源站证书，最后查防火墙，按这个顺序排查能覆盖九成以上的现场。

验证收尾：三分钟确认全链路生效

最后做一组完整验证，确认加密和保护同时到位。在源站执行下面的命令检查真实回源请求是否都来自 Cloudflare 节点：

# 查看最近访问日志的来源 IP，应全部落在 Cloudflare 官方 IP 段内
tail -n 20 /var/log/nginx/access.log | awk '{print $1}'

同时在浏览器端确认：域名访问正常且显示安全锁；F12 打开开发者工具查看响应头里有 cf-ray 字段，说明请求确实经过了 Cloudflare 代理。两项都通过，说明”访客 → 边缘 → 源站”全链路加密和源站白名单都已生效。

总结一下这套方案的成本和收益：不花钱买证书，15 分钟完成回源加密，再花 10 分钟加上防火墙白名单，源站就同时获得了传输加密和入口收敛两层保护。如果你在配置过程中发现共享环境无法操作防火墙规则，或者需要一个对 CDN 回源更友好的运行环境，可以考虑迁移到 Hostease VPS，完整 root 权限让这类安全配置不再受限；更多站点加速技巧也可以延伸阅读我们的 TTFB 优化指南。如果你需要进一步确认自己的服务器是否适合这套方案，建议先在测试子域名上完整演练一遍，再应用到主站。

发表评论