Cloudflare 上生产前，这些配置一定要先弄明白

发布人：慈云数据-客服中心发布时间：24小时前阅读量：4

Cloudflare 生产环境部署指南｜生产环境实测

在现代 Web 架构中，Cloudflare 已经不仅仅是一个“CDN 加速服务”，而是逐渐演变为集 DNS、CDN、WAF、安全防护、边缘计算、零信任访问、对象存储、图片优化、DDoS 防护和流量治理于一体的全球边缘网络平台。对于生产环境而言，正确部署 Cloudflare 可以显著提升网站的访问速度、安全性和可用性；但如果配置不当，也可能引发缓存异常、HTTPS 回源失败、真实 IP 暴露、业务接口被误拦截等问题。

本文基于生产环境实测经验，系统梳理 Cloudflare 在企业网站、API 服务、管理后台以及静态资源业务中的部署方法与注意事项，适合准备将业务正式接入 Cloudflare 的开发、运维、架构师和技术负责人参考。

一、为什么生产环境要使用 Cloudflare？

在生产环境中，业务通常面临以下几类问题：

全球访问速度不稳定
用户分布在不同国家或地区，源站如果只部署在单一区域，跨境访问延迟较高。
DDoS 与恶意流量风险
暴露在公网的源站很容易遭遇扫描、CC 攻击、恶意爬虫、暴力破解等行为。
TLS/HTTPS 配置复杂
证书申请、续期、协议兼容、安全加固等都需要持续维护。
静态资源带宽成本较高
图片、CSS、JS、字体文件等静态资源如果全部从源站返回，会增加源站压力和带宽费用。
源站真实 IP 容易暴露
一旦真实 IP 被攻击者获取，即使前面接入了 CDN，也可能被直接绕过攻击。

Cloudflare 的价值在于：它作为用户与源站之间的边缘代理层，可以在全球节点就近响应请求、缓存静态内容、过滤恶意流量、终止 TLS，并将合法请求转发给源站。对于大多数中小型业务，Cloudflare 免费版已经能覆盖基础场景；对于大型生产环境，则可以结合 Pro、Business、Enterprise 版本使用更高级的安全和性能能力。

二、生产环境部署前的准备工作

在正式接入 Cloudflare 前，不建议直接修改线上域名 DNS。正确做法是先完成以下准备。

1. 梳理域名与业务类型

先列出当前所有域名和子域名，例如：

example.com
www.example.com
api.example.com
admin.example.com
static.example.com
img.example.com
docs.example.com

然后给每个域名标注业务类型：

域名	类型	是否适合代理	说明
www.example.com	官网	是	适合开启 CDN 和缓存
api.example.com	API 服务	视情况	通常不开强缓存，重点做 WAF 和限速
admin.example.com	管理后台	是	建议结合 Zero Trust 或访问控制
static.example.com	静态资源	是	非常适合缓存
img.example.com	图片资源	是	可结合图片压缩和缓存
mail.example.com	邮件服务	否	邮件相关记录通常不走代理

需要特别注意：并不是所有 DNS 记录都应该开启 Cloudflare 代理，也就是橙色云朵。比如邮件服务的 MX、SMTP、IMAP、POP3 等相关域名通常不能走 Cloudflare HTTP 代理，否则可能导致邮件收发异常。

2. 确认源站 HTTPS 配置

生产环境强烈建议源站本身也部署 HTTPS，而不是只依赖 Cloudflare 到用户侧的 HTTPS。

Cloudflare 的 SSL/TLS 模式主要有：

模式	含义	是否推荐生产使用
Off	不启用 HTTPS	不推荐
Flexible	用户到 Cloudflare 是 HTTPS，Cloudflare 到源站是 HTTP	不推荐
Full	用户到 Cloudflare 是 HTTPS，Cloudflare 到源站也是 HTTPS，但不校验证书	可临时使用
Full Strict	用户到 Cloudflare 是 HTTPS，Cloudflare 到源站 HTTPS 且校验证书	强烈推荐

生产环境建议使用 Full Strict。这要求源站必须配置有效证书，可以是 Let’s Encrypt 证书，也可以使用 Cloudflare Origin Certificate。

如果使用 Cloudflare Origin Certificate，需要注意它只被 Cloudflare 信任，浏览器直接访问源站 IP 时通常不被信任。因此，它适合源站只允许 Cloudflare 回源访问的场景。

3. 备份原有 DNS 配置

接入 Cloudflare 时，需要将域名 NS 服务器切换到 Cloudflare。切换前务必导出现有 DNS 记录，避免记录丢失。

建议备份内容包括：

A 记录
AAAA 记录
CNAME 记录
MX 记录
TXT 记录
SPF、DKIM、DMARC 邮件认证记录
CAA 记录
SRV 记录
第三方验证记录

Cloudflare 自动扫描 DNS 记录时并不一定完整，尤其是一些验证 TXT 记录、子域名记录、内部服务记录，最好人工核对。

三、正式接入 Cloudflare 的步骤

1. 添加站点

example.com

Cloudflare 会扫描现有 DNS 记录。扫描完成后，进入 DNS 配置页面。

2. 核对 DNS 记录

重点检查以下内容：

A     @        192.0.2.10
CNAME www      example.com
A     api      192.0.2.20
A     admin    192.0.2.30
MX    @        mail.example.com
TXT   @        v=spf1 include:xxx ~all
TXT   _dmarc   v=DMARC1; p=none;

对于 HTTP/HTTPS 网站服务，可以开启橙色云朵代理；对于邮件、数据库、SSH、FTP 等非 HTTP 服务，通常保持灰色云朵，仅 DNS 解析。

推荐策略：

官网、静态资源、图片资源：开启代理
API：可开启代理，但缓存要谨慎
管理后台：开启代理，并加强访问控制
邮件服务：不要开启代理
SSH、数据库：不要通过普通 DNS 代理暴露

3. 修改域名 NS

Cloudflare 会提供两个名称服务器，例如：

amy.ns.cloudflare.com
mark.ns.cloudflare.com

到域名注册商处修改 NS。NS 生效时间通常为数分钟到 24 小时不等，具体取决于注册商和上级 DNS 缓存。

在切换过程中，建议选择业务低峰期操作，并保持原源站稳定运行。

可以使用以下命令检查 NS 是否生效：

dig NS example.com +short

也可以检查具体解析：

dig www.example.com +short

四、SSL/TLS 生产环境配置

进入 Cloudflare 后，首先要配置 SSL/TLS。

1. 设置加密模式为 Full Strict

路径：

SSL/TLS → Overview → Full (strict)

生产环境不推荐使用 Flexible。因为 Flexible 模式下，Cloudflare 到源站是 HTTP，容易出现以下问题：

用户看到 HTTPS，但回源链路未加密
WordPress、Laravel、Spring Boot 等应用可能产生 HTTPS 重定向循环
安全合规不足
Cookie Secure 策略可能异常

Full Strict 是更安全、更稳定的选择。

2. 开启 Always Use HTTPS

路径：

SSL/TLS → Edge Certificates → Always Use HTTPS

开启后，Cloudflare 会将 HTTP 请求重定向到 HTTPS。

如果源站本身也做了 HTTP 到 HTTPS 跳转，需要确认不会产生重复跳转或循环跳转。

3. 开启 HSTS 需谨慎

HSTS 可以强制浏览器未来只通过 HTTPS 访问网站，提高安全性。但生产环境开启前必须确认：

所有子域名都支持 HTTPS
不存在仍需 HTTP 访问的旧系统
证书续期机制稳定
已测试完毕

尤其是开启 includeSubDomains 和 preload 后，回滚成本很高。建议先从较短时间开始，例如 1 天或 1 周，验证稳定后再逐步加长。

五、缓存策略设计

Cloudflare 的核心能力之一是缓存。但生产环境中，缓存不是“开得越多越好”，而是要根据业务类型设计。

1. 静态资源缓存

适合缓存的资源包括：

.css
.js
.png
.jpg
.jpeg
.webp
.svg
.ico
.woff
.woff2
.mp4

建议源站为静态资源设置合理的 Cache-Control：

Cache-Control: public, max-age=31536000, immutable

如果文件名带 hash，例如：

app.8f3a9c.js
style.91ad2.css

可以设置长期缓存，因为文件内容变更时文件名也会变化。

2. HTML 页面缓存

HTML 是否缓存要视业务而定。

适合缓存的 HTML：

企业官网
文档站
博客
营销落地页
不包含用户个性化内容的页面

不适合直接缓存的 HTML：

用户中心
订单页面
后台管理页面
购物车页面
登录后个性化首页

如果要缓存 HTML，可以使用 Cache Rules 或 Page Rules，针对特定路径设置，例如：

https://www.example.com/blog/*
https://www.example.com/docs/*

不要盲目对全站设置 Cache Everything，否则可能出现用户看到他人页面、登录状态错乱、后台内容被缓存等严重问题。

3. API 缓存

API 默认不建议缓存，除非它是明确的公开只读接口，例如：

GET /api/public/config
GET /api/articles
GET /api/categories

对于需要鉴权的接口，建议设置：

Cache-Control: no-store

或者：

Cache-Control: private, no-cache

特别注意带有以下 Header 的请求：

Authorization
Cookie
Set-Cookie

这类请求通常不应该被公共 CDN 缓存。

4. 缓存清理策略

生产发布时，建议配合缓存清理策略：

静态资源文件名带 hash：通常无需主动清理
HTML 页面更新：按 URL 清理
紧急回滚：可 Purge Everything
图片资源更新：避免同名覆盖，优先使用版本化 URL

Cloudflare 支持按 URL、Host、Prefix、Tag 等方式清理缓存。生产环境不建议频繁 Purge Everything，因为会导致大量请求同时回源，增加源站压力。

六、安全配置：WAF、防火墙与限速

Cloudflare 在生产环境中的安全价值非常明显，尤其适合暴露公网的 Web 服务。

1. 开启 WAF Managed Rules

路径：

Security → WAF → Managed Rules

建议开启 Cloudflare 托管规则集，用于防御常见攻击：

SQL 注入
XSS
RCE
LFI/RFI
WordPress 漏洞扫描
CMS 常见攻击
机器人恶意请求

上线初期建议先使用 Log 或 Challenge 模式观察，确认没有误伤后再提高拦截等级。

2. 设置安全级别

Cloudflare 提供不同安全等级。对于普通网站，可以设置为 Medium；对于遭受攻击时，可以临时提高到 High 或启用 Under Attack Mode。

但 Under Attack Mode 会对访问者增加 JavaScript 挑战，不适合长期对 API 或移动端 App 接口开启，否则可能导致正常客户端无法访问。

3. 管理后台访问控制

管理后台是生产环境重点保护对象。假设后台路径为：

https://admin.example.com

建议至少做以下限制：

只允许公司办公 IP 访问
对非白名单 IP 启用登录挑战
配置 Cloudflare Access 零信任认证
后台登录接口加限速
禁止搜索引擎收录

可以在 WAF 中添加规则：

if hostname eq "admin.example.com" and ip.src not in {公司出口IP}
then block

如果团队成员经常远程办公，可以使用 Cloudflare Zero Trust Access，接入 Google Workspace、GitHub、Azure AD 等身份源，实现登录前身份认证。

4. API 限速

对于 API 服务，建议配置 Rate Limiting。重点保护：

/api/login
/api/register
/api/send-code
/api/password/reset
/api/order/create

示例策略：

同一 IP 1 分钟内登录失败超过 10 次，触发 Challenge 或 Block
同一 IP 5 分钟内发送验证码超过 5 次，直接阻断
同一 IP 每秒请求 API 超过指定阈值，触发限速

限速策略不要设置得过于激进，尤其是企业客户、校园网、运营商 NAT 出口可能存在大量用户共用一个 IP 的情况。

七、源站安全：只允许 Cloudflare 回源

接入 Cloudflare 后，一个常见错误是：虽然域名走了 Cloudflare，但源站 IP 仍然可以被直接访问。一旦攻击者知道源站 IP，就可以绕过 Cloudflare 直接攻击。

生产环境建议在源站防火墙中只允许 Cloudflare IP 段访问 80/443。

Cloudflare 官方会公布 IP 段，例如：

https://www.cloudflare.com/ips/

服务器防火墙、云安全组、Nginx 层都可以做限制。

Nginx 示例思路：

allow 173.245.48.0/20;
allow 103.21.244.0/22;
allow 103.22.200.0/22;
allow 103.31.4.0/22;
deny all;

实际配置时需要使用 Cloudflare 官方最新 IP 列表，不要直接复制过期示例。

同时，源站应该正确获取用户真实 IP。Cloudflare 会通过请求头传递真实客户端 IP：

CF-Connecting-IP
X-Forwarded-For

Nginx 中可以结合 real_ip_header 配置：

real_ip_header CF-Connecting-IP;

并为 Cloudflare IP 段设置 set_real_ip_from，否则应用日志里看到的可能都是 Cloudflare 节点 IP。

八、性能优化配置

1. Brotli 压缩

建议开启 Brotli：

Speed → Optimization → Brotli

Brotli 对文本类资源压缩效果较好，例如：

HTML
CSS
JavaScript
JSON
SVG

2. HTTP/2 与 HTTP/3

Cloudflare 支持 HTTP/2 和 HTTP/3。生产环境建议开启 HTTP/2，HTTP/3 可根据客户端兼容情况开启。

HTTP/3 基于 QUIC，在弱网和高延迟场景下可能改善体验，但部分企业网络、防火墙或旧设备对 UDP 支持不佳。开启后应观察错误率和用户反馈。

3. Early Hints

Early Hints 可以让浏览器更早发现需要加载的资源，提升页面加载速度。对于结构稳定的站点，可以开启测试。

但它不是万能优化项，前端资源引用、缓存策略、图片大小、首屏渲染路径才是性能优化重点。

4. 图片优化

如果业务中图片较多，可以考虑：

使用 WebP/AVIF
开启 Polish
使用 Image Resizing
静态图片使用长缓存
图片 URL 版本化
避免源站动态压缩过重导致 CPU 压力增加

如果使用免费版，部分图片优化能力可能不可用，需要结合套餐选择。

九、生产环境发布流程建议

为了降低风险，Cloudflare 接入应当按阶段推进。

阶段一：测试域名验证

先使用测试域名，例如：

cf-test.example.com

指向生产源站或预发布源站，开启 Cloudflare 代理后测试：

HTTPS 是否正常
登录是否正常
Cookie 是否正常
API 是否正常
上传下载是否正常
缓存是否符合预期
后台是否被误拦截
WebSocket 是否可用
大文件下载是否稳定

阶段二：低风险子域名上线

优先接入静态资源或文档站，例如：

static.example.com
docs.example.com

这类业务风险较低，也更容易观察缓存效果和访问性能。

阶段三：主站上线

主站上线时建议选择业务低峰期。上线前准备回滚方案：

保留原 DNS 记录
缩短 DNS TTL
确认源站可直接访问
准备关闭代理的操作步骤
监控错误率和响应时间

上线后重点观察：

5xx 错误
403/429 请求
登录失败率
支付回调是否正常
搜索引擎抓取是否正常
海外访问延迟是否改善
源站带宽是否下降

十、常见故障与处理方法

1. 出现 521 错误

521 通常表示 Cloudflare 无法连接源站，可能原因：

源站服务器宕机
防火墙拒绝 Cloudflare IP
Nginx/Apache 未监听对应端口
云安全组未放行 80/443

处理方法：检查源站服务状态、防火墙规则和安全组配置。

2. 出现 522 错误

522 表示连接源站超时，常见原因：

源站响应太慢
网络链路异常
防火墙丢弃连接
源站负载过高

需要检查源站 CPU、内存、连接数、Nginx 日志和应用日志。

3. 出现 525 或 526 错误

这通常与 SSL 握手或证书校验有关。

525：SSL 握手失败
526：证书无效，常见于 Full Strict 模式

处理方式：

检查源站证书是否过期
检查证书域名是否匹配
检查中间证书链是否完整
如果使用 Origin Certificate，确认配置正确

4. 页面内容更新后用户仍看到旧内容

这是缓存策略导致的典型问题。处理方式：

检查 Cache-Control
检查 Cloudflare Cache Rules
对指定 URL 执行 Purge
静态资源使用 hash 文件名
避免 HTML 被意外 Cache Everything

5. 获取不到真实用户 IP

如果应用日志中全是 Cloudflare IP，需要在 Web 服务器中配置真实 IP 还原。

Nginx 需要：

real_ip_header CF-Connecting-IP;
set_real_ip_from Cloudflare_IP段;

应用层也需要确认使用的是正确的 Header。

十一、生产实测配置推荐

以下是一个较通用的生产环境推荐配置，可作为基线参考。

DNS

官网、静态资源、图片域名：开启代理
API：开启代理，但禁用缓存或仅缓存公开 GET 接口
邮件服务：不开代理
源站 IP：不要在公开记录中暴露无关服务

SSL/TLS

模式：Full Strict
Always Use HTTPS：开启
TLS 1.0/1.1：关闭
HSTS：测试稳定后逐步开启
Origin Certificate：适合源站仅允许 Cloudflare 回源场景

缓存

静态资源：长缓存
HTML：仅对公开页面缓存
API：默认不缓存
后台：不缓存
发布流程：优先使用文件名 hash，减少清缓存依赖

安全

WAF Managed Rules：开启
后台：IP 白名单或 Cloudflare Access
登录、验证码、注册接口：限速
源站：只允许 Cloudflare IP 回源
Bot 防护：根据业务情况开启

性能

Brotli：开启
HTTP/2：开启
HTTP/3：建议测试后开启
图片优化：按业务规模选择
WebSocket：上线前测试

十二、上线检查清单

正式上线前，可以按以下清单逐项确认。

[ ] DNS 记录已完整备份
[ ] MX/TXT 邮件记录已核对
[ ] SSL/TLS 已设置为 Full Strict
[ ] 源站 HTTPS 证书有效
[ ] HTTP 自动跳转 HTTPS 正常
[ ] 登录、注册、支付、回调流程测试通过
[ ] API 未被错误缓存
[ ] 后台页面未被公开缓存
[ ] 静态资源缓存策略正确
[ ] WAF 初期已观察误杀情况
[ ] 源站防火墙已允许 Cloudflare IP
[ ] 应用日志可获取真实用户 IP
[ ] 监控告警已配置
[ ] 回滚方案已准备

十三、总结

Cloudflare 接入生产环境的核心原则不是“全部开启”，而是“按业务场景精细化配置”。对于静态资源和公开页面，可以充分利用 Cloudflare 的全球缓存能力；对于 API、后台、登录态页面，则应优先考虑安全、鉴权和缓存隔离；对于源站，则必须避免真实 IP 暴露，并确保只允许 Cloudflare 回源。

从生产实测角度看，最容易出问题的地方主要集中在四类：SSL 模式选错、缓存规则过于激进、WAF 误拦截正常请求、源站真实 IP 未保护。只要在上线前做好测试和回滚预案，Cloudflare 可以非常稳定地承担生产流量入口角色，并为业务带来明显的安全和性能收益。

对于大多数业务，建议按照以下顺序推进：