Cloudflare 生产环境部署指南｜2026最新版

Cloudflare 已经从“CDN 加速工具”演进为覆盖 DNS、CDN、WAF、安全防护、零信任访问、边缘计算、对象存储、流量分析、Bot 管理 等能力的一体化全球网络平台。对于生产环境而言，Cloudflare 的价值不仅在于提升访问速度，更在于增强网站可用性、安全性、抗攻击能力和运维效率。

本文面向准备在生产环境中接入 Cloudflare 的团队，系统介绍从域名接入、DNS 配置、SSL/TLS、缓存策略、安全规则、WAF、DDoS 防护、监控告警到上线灰度的完整部署流程，适合作为 2026 年生产环境落地 Cloudflare 的实践参考。

一、生产环境使用 Cloudflare 前的准备

在正式接入 Cloudflare 之前，建议先完成以下准备工作，避免上线过程中出现解析异常、证书错误、缓存污染或业务中断。

1. 明确业务架构

首先需要梳理当前业务的访问链路：

用户浏览器
   ↓
DNS 解析
   ↓
CDN / 反向代理
   ↓
负载均衡
   ↓
应用服务
   ↓
数据库 / 缓存 / 对象存储

接入 Cloudflare 后，常见链路会变为：

用户浏览器
   ↓
Cloudflare DNS
   ↓
Cloudflare Edge
   ↓
源站负载均衡 / 源站服务器

需要提前明确：

• 哪些域名需要经过 Cloudflare 代理；
• 哪些域名只使用 Cloudflare DNS；
• 源站是否支持 HTTPS；
• 是否存在 WebSocket、gRPC、API 长连接；
• 是否有文件上传、大文件下载、视频播放等特殊场景；
• 是否使用第三方回调，例如支付、短信、OAuth、Webhook。

2. 备份原 DNS 记录

接入 Cloudflare 的第一步通常是迁移 DNS。生产环境务必在迁移前备份原有 DNS 记录，包括：

• A 记录；
• AAAA 记录；
• CNAME 记录；
• MX 邮件记录；
• TXT 验证记录；
• SPF、DKIM、DMARC 邮件安全记录；
• SRV 记录；
• CAA 证书授权记录。

建议导出当前 DNS 服务商的完整配置，并保留截图或文本备份。Cloudflare 自动扫描 DNS 记录时可能会遗漏部分记录，尤其是邮件、安全验证、内部服务相关记录，因此不能完全依赖自动导入。

3. 降低 DNS TTL

如果你的域名当前不在 Cloudflare 上，建议提前 24～48 小时将关键记录 TTL 降低到 300 秒或更低。这样在切换 NS 服务器或调整解析时，可以减少全球 DNS 缓存带来的影响。

二、接入 Cloudflare DNS

1. 添加站点

登录 Cloudflare 后，选择 Add a site，输入主域名，例如：

example.com

Cloudflare 会扫描该域名已有 DNS 记录，并生成一组新的 Nameserver，例如：

ada.ns.cloudflare.com
mark.ns.cloudflare.com

然后需要到域名注册商后台，将原有 NS 修改为 Cloudflare 提供的 NS。

2. 核对 DNS 记录

Cloudflare DNS 记录主要分为两种代理状态：

生产环境中建议遵循以下原则：

• Web 站点使用橙色云朵；
• API 域名根据业务情况决定是否代理；
• 邮件相关记录必须保持 DNS only；
• 数据库、SSH、FTP 等非 HTTP 服务通常不应使用橙色云朵；
• 内部系统如需保护，建议使用 Cloudflare Zero Trust，而不是直接暴露公网。

示例：

A      @        203.0.113.10      Proxied
CNAME  www      example.com       Proxied
A      api      203.0.113.20      Proxied
MX     @        mail.example.com  DNS only
TXT    @        v=spf1 include:_spf.example.com ~all

3. 使用 CNAME Flattening

Cloudflare 支持根域名 CNAME Flattening，即可以让根域名指向一个 CNAME，而不是传统 A 记录。这对使用云负载均衡、容器平台、PaaS 服务的团队非常有用。

例如：

CNAME  @  app-loadbalancer.example.net

Cloudflare 会在 DNS 查询层面返回解析结果，同时保持根域名可用。

三、SSL/TLS 配置

SSL/TLS 是生产环境部署 Cloudflare 的核心步骤。如果配置不当，常见问题包括重定向循环、证书错误、混合内容、源站连接失败等。

1. 选择 Full 或 Full Strict

Cloudflare 提供多种 SSL/TLS 模式：

生产环境推荐使用：

SSL/TLS encryption mode: Full (strict)

这意味着：

• 用户到 Cloudflare 使用 HTTPS；
• Cloudflare 到源站也使用 HTTPS；
• 源站必须有有效证书；
• 证书域名必须匹配；
• 证书未过期；
• 证书由受信任 CA 签发，或使用 Cloudflare Origin CA。

2. 部署源站证书

源站证书可以使用以下方式：

• Let’s Encrypt；
• 商业 CA 证书；
• Cloudflare Origin Certificate。

如果源站只接受 Cloudflare 回源访问，Cloudflare Origin Certificate 是非常适合的方案。它的有效期较长，配置简单，但该证书只被 Cloudflare 信任，不适合用户直接访问源站。

Nginx 示例配置：

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    ssl_certificate     /etc/nginx/ssl/origin.pem;
    ssl_certificate_key /etc/nginx/ssl/origin.key;

    location / {
        proxy_pass http://app_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

3. 启用 HTTPS 重定向

生产环境建议开启：

• Always Use HTTPS；
• Automatic HTTPS Rewrites；
• HSTS。

不过 HSTS 需要谨慎配置。尤其是启用 includeSubDomains 和提交 HSTS Preload 前，必须确保所有子域名都支持 HTTPS，否则可能造成部分服务无法访问。

推荐初始 HSTS 配置：

max-age=15552000
includeSubDomains: 暂不启用
preload: 暂不启用

稳定运行一段时间后，再考虑扩大策略。

四、源站安全加固

接入 Cloudflare 后，很多攻击流量会先经过 Cloudflare，但这并不意味着源站可以裸奔。生产环境中最重要的一点是：源站必须只允许 Cloudflare 回源访问。

1. 限制源站 IP 访问

可以在防火墙、安全组或 Nginx 层只允许 Cloudflare IP 段访问 80/443 端口。

思路如下：

允许 Cloudflare IP 段访问 80/443
拒绝其他公网 IP 直接访问 80/443
允许运维 IP 访问 SSH

Cloudflare 官方会维护 IP 段列表，生产环境建议定期同步，避免 Cloudflare IP 变更导致回源失败。

2. 使用 Authenticated Origin Pulls

Authenticated Origin Pulls 可以让源站验证请求是否真的来自 Cloudflare。启用后，Cloudflare 回源时会携带客户端证书，源站验证证书后才接受请求。

这比单纯依赖 IP 白名单更安全，适合高安全要求场景。

3. 保护真实源站 IP

接入 Cloudflare 的安全收益很大程度依赖于隐藏源站 IP。因此要避免通过以下方式泄露源站地址：

• 历史 DNS 记录；
• GitHub 配置文件；
• 错误日志；
• 邮件头；
• 子域名解析；
• 第三方监控；
• 直接暴露的测试环境；
• 图片、下载、API 域名单独解析到源站。

建议使用安全扫描工具检查源站暴露情况，并定期排查新增子域名。

五、缓存策略设计

Cloudflare 的缓存能力可以显著降低源站压力，但生产环境不能简单地“全部缓存”。错误的缓存策略可能导致用户看到过期页面、接口数据错乱，甚至造成隐私泄露。

1. 区分静态资源与动态请求

通常建议缓存：

• CSS；
• JavaScript；
• 图片；
• 字体；
• 视频片段；
• 静态下载文件；
• 版本化构建产物。

通常不建议缓存：

• 登录页面；
• 用户中心；
• 购物车；
• 支付页面；
• 后台管理；
• 带用户身份的 API；
• 返回个人隐私数据的接口。

2. 使用 Cache Rules

2026 年生产实践中，建议优先使用 Cloudflare 的 Cache Rules，而不是旧版 Page Rules。可以按路径、请求头、主机名、查询参数进行精细化控制。

示例策略：

规则一：
if URI Path starts_with "/assets/"
then Cache eligibility: Eligible for cache
Edge TTL: 30 days
Browser TTL: 7 days

规则二：
if URI Path starts_with "/api/"
then Cache eligibility: Bypass cache

规则三：
if URI Path equals "/"
then Edge TTL: 5 minutes

3. 版本化静态资源

前端构建产物建议使用 hash 文件名，例如：

app.8fd3a2.js
style.a91bc7.css

这样可以安全设置较长缓存时间：

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

当文件内容变化时，文件名变化，用户自然会获取新版本。

4. 缓存清理策略

生产环境中不要频繁执行全站 Purge Cache，因为这会导致缓存雪崩，大量请求回源，增加源站压力。

推荐清理方式：

• 优先按 URL 清理；
• 其次按 Cache Tag 清理；
• 尽量避免全量清理；
• 发布系统中集成 Cloudflare API；
• 对首页、列表页设置较短 TTL；
• 对静态资源使用 hash 版本控制，避免清理。

六、WAF 与安全规则配置

Cloudflare WAF 是生产环境非常重要的防护层，能够拦截 SQL 注入、XSS、恶意爬虫、漏洞扫描、异常请求等。

1. 启用托管规则集

建议启用以下托管规则：

• Cloudflare Managed Ruleset；
• OWASP Core Ruleset；
• CMS 专项规则，例如 WordPress、Drupal；
• CVE 快速响应规则。

初次启用时建议使用观察模式或日志模式，观察误杀情况后再切换为阻断。

2. 自定义 WAF 规则

可以根据业务特征创建规则。例如限制后台路径：

if URI Path starts_with "/admin"
and IP not in allowed list
then Block

限制异常 User-Agent：

if User-Agent contains "sqlmap"
then Block

限制国家或地区访问：

if Country not in ["CN", "US", "SG"]
then Managed Challenge

需要注意的是，按国家封禁可能影响正常用户、搜索引擎或第三方服务，应结合业务实际使用。

3. Rate Limiting

生产环境推荐对高风险接口启用速率限制：

• 登录接口；
• 注册接口；
• 找回密码；
• 短信验证码；
• 邮件验证码；
• 搜索接口；
• 评论接口；
• 下单接口；
• 文件上传接口。

示例：

if URI Path equals "/api/login"
and requests > 10 per minute per IP
then Managed Challenge or Block

对于登录接口，建议结合应用层风控，不要完全依赖 IP 限速，因为大量攻击可能来自代理池。

七、Bot 管理与爬虫控制

Cloudflare 对 Bot 的处理能力很强，但生产环境需要平衡安全与可访问性。如果规则过严，可能会误伤搜索引擎、监控系统、合作方接口；如果过松，则可能被恶意爬虫消耗资源。

1. 允许可信爬虫

建议允许常见搜索引擎：

• Googlebot；
• Bingbot；
• Baiduspider；
• YandexBot；
• DuckDuckBot。

Cloudflare 支持识别 Verified Bot，可以通过规则放行可信机器人。

2. 对异常流量使用 Challenge

对以下请求可以使用 Managed Challenge：

• 无明显浏览器特征；
• 高频访问；
• 扫描路径；
• 异常 ASN；
• 数据中心 IP；
• 可疑国家来源；
• User-Agent 为空；
• 请求头明显伪造。

Managed Challenge 相比传统验证码体验更好，适合大多数生产环境。

八、DDoS 防护与高可用设计

Cloudflare 默认提供 L3/L4/L7 DDoS 防护，但生产环境仍然需要进行合理配置。

1. 配置 Under Attack Mode

当遭遇大规模攻击时，可以临时开启：

I’m Under Attack Mode

该模式会对访问者进行额外验证。它适合应急使用，不建议长期启用，否则可能影响用户体验和 SEO。

2. 使用 Load Balancing

对于重要业务，建议使用 Cloudflare Load Balancing 将流量分发到多个源站：

Pool A: 新加坡源站
Pool B: 东京源站
Pool C: 美国源站

并配置健康检查：

GET /healthz
Expected status: 200
Interval: 60s
Timeout: 5s
Retries: 2

当某个源站异常时，Cloudflare 可以自动切换到健康节点，提高整体可用性。

3. 开启 Argo Smart Routing

如果业务访问跨区域明显，例如全球用户访问亚洲源站，Argo Smart Routing 可以通过 Cloudflare 网络优化路径，减少延迟和丢包。对于跨境业务、SaaS、API 服务尤其有价值。

九、应用层兼容性配置

1. 获取真实客户端 IP

接入 Cloudflare 后，源站看到的请求 IP 默认是 Cloudflare 边缘节点 IP。应用需要通过请求头获取真实用户 IP。

常见请求头：

CF-Connecting-IP
X-Forwarded-For
True-Client-IP

Nginx 可配置 real_ip：

set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;

real_ip_header CF-Connecting-IP;

实际生产中应配置完整 Cloudflare IP 段，并定期更新。

2. WebSocket 支持

Cloudflare 支持 WebSocket，但需要确认：

• WebSocket 域名已开启代理；
• 源站支持 HTTPS；
• 空闲连接超时符合业务需求；
• 应用具备断线重连机制。

3. API 场景注意事项

对于 API 服务，需要特别关注：

• 是否需要缓存；
• 是否有大请求体；
• 是否有长耗时请求；
• 是否涉及签名校验；
• 是否依赖客户端真实 IP；
• 是否对请求头顺序敏感；
• 是否有第三方回调白名单。

如果第三方服务不支持 Cloudflare 代理后的 IP，可能需要使用独立回调域名，并设置为 DNS only，或调整应用层鉴权方式。

十、日志、监控与告警

生产环境部署 Cloudflare 后，必须建立监控闭环，不能只依赖控制台手动查看。

1. 关键监控指标

建议重点关注：

• 请求量；
• 4xx 错误；
• 5xx 错误；
• 缓存命中率；
• WAF 拦截量；
• Challenge 数量；
• 源站响应时间；
• 带宽消耗；
• DDoS 事件；
• 回源错误；
• 健康检查状态。

2. 日志分析

企业级场景可以使用 Logpush 将 Cloudflare 日志推送到：

• R2；
• S3；
• BigQuery；
• Elasticsearch；
• Splunk；
• Datadog；
• SIEM 平台。

通过日志可以分析：

• 攻击来源；
• 热门 URL；
• 缓存命中情况；
• 异常状态码；
• 恶意 User-Agent；
• Bot 行为；
• 误拦截规则。

3. 告警策略

建议配置以下告警：

• 5xx 错误率超过阈值；
• 源站健康检查失败；
• WAF 拦截量突增；
• 流量异常增长；
• 缓存命中率骤降；
• TLS 证书即将过期；
• 负载均衡池不可用；
• DDoS 攻击事件。

告警应接入企业常用渠道，例如邮件、Slack、飞书、钉钉、PagerDuty。

十一、上线灰度流程

生产环境切换 Cloudflare 不建议一次性完成所有域名代理，而应采用灰度方式。

1. 推荐上线步骤

第一步：接入测试域名
第二步：验证 DNS、HTTPS、缓存、WAF
第三步：接入低风险子域名
第四步：开启代理但关闭激进规则
第五步：观察日志和错误率
第六步：逐步接入主站和核心 API
第七步：启用完整安全策略
第八步：限制源站只允许 Cloudflare 访问

2. 回滚方案

上线前必须准备回滚方案：

• 保留原 DNS 配置；
• 记录源站直接访问方式；
• 暂不立即关闭原有 CDN；
• DNS TTL 保持较低；
• 重要规则变更前导出配置；
• 发布窗口安排在低峰期；
• 预留技术负责人值守。

如果出现严重问题，可以快速将代理状态从 Proxied 改为 DNS only，或切换回原 DNS 服务商。

十二、常见问题排查

1. 出现 521 错误

521 表示 Cloudflare 无法连接源站。常见原因：

• 源站服务未启动；
• 防火墙拦截了 Cloudflare IP；
• 源站拒绝连接；
• 80/443 端口未开放；
• 安全组配置错误。

2. 出现 522 错误

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

• 源站负载过高；
• 网络链路异常；
• 防火墙丢弃连接；
• 源站响应过慢；
• 后端服务阻塞。

3. 出现 525 错误

525 表示 SSL 握手失败。常见原因：

• 源站 TLS 配置错误；
• 证书链不完整；
• 协议版本不兼容；
• SNI 配置异常。

4. 出现 526 错误

526 表示源站证书无效。常见原因：

• 使用 Full Strict 但源站证书过期；
• 证书域名不匹配；
• 证书不是受信任 CA；
• 证书链缺失。

5. 出现重定向循环

常见原因是使用了 Flexible SSL，同时源站又强制 HTTPS。解决方式是改为：

SSL/TLS mode: Full Strict

并确保源站 HTTPS 正常。

十三、生产环境最佳实践清单

上线前可以使用以下清单进行检查：

• [ ] DNS 记录已完整备份；
• [ ] 关键域名 TTL 已降低；
• [ ] Web 域名已开启 Proxied；
• [ ] 邮件记录保持 DNS only；
• [ ] SSL/TLS 使用 Full Strict；
• [ ] 源站证书有效；
• [ ] 已开启 Always Use HTTPS；
• [ ] HSTS 配置经过评估；
• [ ] 源站已限制 Cloudflare IP 访问；
• [ ] 已配置真实客户端 IP；
• [ ] 静态资源缓存策略合理；
• [ ] API、登录、支付接口已绕过缓存；
• [ ] WAF 规则经过观察和调优；
• [ ] Rate Limiting 已覆盖高风险接口；
• [ ] Bot 策略不会误伤搜索引擎；
• [ ] 已配置日志和告警；
• [ ] 已准备回滚方案；
• [ ] 已完成灰度验证；
• [ ] 已记录所有配置变更。

十四、总结

Cloudflare 在生产环境中的价值并不只是“让网站访问更快”，更重要的是提供了一层全球化的安全与可用性基础设施。通过合理配置 DNS、SSL/TLS、缓存、WAF、DDoS 防护、Bot 管理、负载均衡和日志监控，团队可以显著降低源站压力，提高业务稳定性，并增强抵御攻击的能力。

不过，Cloudflare 并不是简单打开橙色云朵就万事大吉。生产部署的关键在于：先梳理架构，再灰度接入；先观察日志，再启用强规则；先保护源站，再开放业务；先设计缓存，再追求命中率。

对于 2026 年的生产环境而言，推荐的核心策略可以概括为：

DNS 稳定迁移
TLS 使用 Full Strict
源站只允许 Cloudflare 回源
静态资源长期缓存
动态接口谨慎绕过
WAF 先观察后阻断
关键接口启用限流
日志监控必须接入
上线必须具备回滚方案

只要按照上述方法逐步实施，Cloudflare 将不只是一个 CDN，而会成为企业 Web 架构中可靠的边缘安全与性能平台。