Cloudflare 生产环境部署指南｜适合站长

Cloudflare 是目前站长、开发者和企业网站常用的全球性网络服务平台，提供 DNS 托管、CDN 加速、DDoS 防护、Web 应用防火墙、SSL/TLS 证书、缓存优化、Zero Trust 安全访问等能力。对于站长来说，Cloudflare 最大的价值并不只是“加速网站”，而是帮助网站在生产环境中获得更稳定、更安全、更易维护的访问体验。

很多人第一次接入 Cloudflare 时，只是简单地把域名 DNS 改到 Cloudflare，然后开启“小橙云”。这样虽然可以让流量经过 Cloudflare，但并不代表生产环境已经配置完善。如果 SSL 模式错误、缓存规则不合理、防火墙策略过于宽松或过于激进，都可能导致网站出现访问异常、登录失效、接口报错、SEO 收录波动甚至安全风险。

本文将从站长视角出发，系统介绍 Cloudflare 在生产环境中的部署思路、配置步骤、常见优化项和注意事项，适合个人站长、中小企业网站、WordPress 站点、静态博客、电商站点以及 API 服务参考。

一、生产环境接入 Cloudflare 前的准备

在正式将网站切换到 Cloudflare 之前，建议先做好基础信息梳理。生产环境不同于测试环境，一旦配置错误，可能影响真实用户访问，因此不要直接盲目切换。

1. 确认网站当前架构

接入 Cloudflare 前，建议明确以下信息：

• 网站源站服务器 IP 地址；
• 网站是否使用 Nginx、Apache、宝塔面板、Docker、Kubernetes 等部署方式；
• 是否存在多个子域名，例如 www.example.com、api.example.com、static.example.com；
• 是否使用了第三方服务，例如对象存储、邮件服务、支付回调、统计平台；
• 网站是否有后台登录、会员系统、购物车、评论系统等动态功能；
• 是否已经部署 HTTPS 证书；
• 是否有特殊端口服务。

这些信息会影响 Cloudflare 的 DNS、SSL、缓存和安全策略配置。尤其是动态网站和电商网站，缓存规则需要谨慎，否则可能出现用户登录状态错乱、购物车内容异常等问题。

2. 备份现有 DNS 记录

在将域名 NS 服务器切换到 Cloudflare 之前，应先导出现有 DNS 记录。常见记录包括：

很多站长在接入 Cloudflare 时只关注网站访问，忽略了邮件相关记录，导致域名邮箱无法收发邮件。因此，在切换之前一定要确认 MX、TXT、SPF、DKIM、DMARC 等记录是否完整迁移。

3. 确认源站可独立访问

Cloudflare 是反向代理和 CDN 服务，最终还是要回源访问你的网站服务器。如果源站本身不稳定，接入 Cloudflare 只能缓解部分问题，不能从根本上解决源站故障。

建议在部署前检查：

curl -I https://example.com
curl -I http://example.com
ping your-origin-ip

同时确认源站防火墙、安全组、Nginx 配置正常。生产环境中，如果启用了只允许 Cloudflare IP 访问源站，也要确保 Cloudflare IP 段配置完整，否则可能出现回源失败。

二、注册并添加站点

进入 Cloudflare 官网注册账号后，点击“Add a site”添加你的域名。注意这里填写的是根域名，例如：

example.com

而不是：

https://www.example.com

Cloudflare 会自动扫描当前 DNS 记录。扫描结果不一定完整，因此你需要手动核对所有记录，尤其是邮件、验证类 TXT 记录和子域名记录。

DNS 代理状态说明

Cloudflare DNS 记录旁边通常有两种状态：

• 橙色云朵：Proxied，流量经过 Cloudflare
• 灰色云朵：DNS only，仅解析 DNS，不代理流量

对于网站访问域名，例如 example.com、www.example.com，一般建议开启橙色云朵。对于邮件服务、FTP、部分验证服务、非 HTTP/HTTPS 服务，通常建议保持灰色云朵。

常见建议如下：

三、切换域名 NS 服务器

Cloudflare 添加站点后，会提供两条 NS 服务器地址，例如：

alex.ns.cloudflare.com
lisa.ns.cloudflare.com

你需要到域名注册商后台，把原来的 NS 服务器修改为 Cloudflare 提供的 NS。修改后，DNS 生效时间一般为数分钟到 24 小时不等，取决于注册商、TTL 和全球 DNS 缓存情况。

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

dig NS example.com

或使用在线工具检查全球解析状态。

生产环境建议选择低流量时段进行切换，例如凌晨或业务访问低峰期。切换后要持续观察网站访问、后台登录、支付回调、邮件收发、API 请求等关键功能。

四、SSL/TLS 配置：生产环境最关键的一步

SSL/TLS 是 Cloudflare 部署中最容易出问题的部分。很多站长遇到的“重定向循环”“访问 525/526 错误”“HTTPS 异常”，都与 SSL 模式配置不当有关。

Cloudflare 常见 SSL 模式包括：

推荐配置：Full Strict

生产环境建议使用：

SSL/TLS encryption mode: Full (strict)

这要求你的源站也必须安装有效证书。源站证书可以是：

• Let’s Encrypt 免费证书；
• 商业 SSL 证书；
• Cloudflare Origin Certificate。

如果你只希望源站被 Cloudflare 访问，可以使用 Cloudflare Origin Certificate。它由 Cloudflare 签发，浏览器不直接信任，但 Cloudflare 信任，因此适合“用户 → Cloudflare → 源站”的架构。

避免使用 Flexible 模式

Flexible 模式看似方便，因为源站不需要 HTTPS，但它容易引发问题：

• WordPress 后台可能出现 HTTPS 重定向循环；
• 网站程序识别协议错误；
• 登录 Cookie 安全属性异常；
• 支付回调、OAuth 登录可能失败；
• 安全性不足，Cloudflare 到源站仍是明文 HTTP。

因此，生产环境不建议使用 Flexible。

五、源站服务器配置建议

Cloudflare 接入后，用户真实 IP 会被 Cloudflare 代理 IP 替代。如果站长不做额外配置，服务器日志中看到的访问 IP 可能都是 Cloudflare 的节点 IP，而不是用户真实 IP。

1. 恢复真实访客 IP

Cloudflare 会在请求头中传递真实 IP，例如：

CF-Connecting-IP
X-Forwarded-For

如果使用 Nginx，可以配置：

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;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 131.0.72.0/22;

real_ip_header CF-Connecting-IP;

Cloudflare IP 段可能更新，生产环境建议定期同步官方 IP 列表。

2. 限制源站只允许 Cloudflare 访问

为了防止攻击者绕过 Cloudflare 直接攻击源站，可以在服务器防火墙或云服务器安全组中限制 80/443 端口只允许 Cloudflare IP 段访问。

这样做的好处是：

• 避免源站 IP 暴露后被直接攻击；
• 强制所有流量经过 Cloudflare 安全策略；
• 降低 DDoS、扫描、暴力破解风险。

但配置前必须确保：

• Cloudflare IP 段完整；
• 运维人员有备用 SSH 管理通道；
• 不要误封自己的管理端口；
• 如果有第三方回调直连源站，需要提前调整。

六、缓存策略配置

Cloudflare 的缓存能力是提升网站性能的重要工具，但生产环境不能简单地“全站缓存”。不同类型的网站应采用不同策略。

1. 静态资源缓存

适合缓存的内容包括：

• 图片：.jpg、.png、.webp、.gif、.svg
• CSS 文件；
• JavaScript 文件；
• 字体文件；
• 下载文件；
• 静态 HTML 页面。

建议设置较长缓存时间，例如 7 天、30 天甚至更长。如果静态资源文件名带版本号，例如：

/app.20250101.css
/main.v2.js

可以设置更长缓存，因为文件变化时 URL 也会变化。

2. 动态页面谨慎缓存

对于以下页面，不建议缓存：

• 登录页；
• 用户中心；
• 购物车；
• 订单页面；
• 支付页面；
• 后台管理；
• 评论提交接口；
• 搜索结果；
• API 写操作接口。

如果错误缓存这些页面，可能导致用户看到他人的数据，或提交操作异常。尤其是 WordPress、Discuz、电商系统和会员网站，应特别注意。

3. WordPress 推荐缓存规则

如果是 WordPress 站点，建议排除以下路径：

/wp-admin/*
/wp-login.php
/wp-json/*
/cart/*
/checkout/*
/my-account/*

同时，对于已登录用户、评论用户、购物车用户，建议通过 Cookie 判断不缓存。Cloudflare 的 Cache Rules 可以设置更精细的条件，例如根据路径、查询参数、Cookie、请求方法进行缓存控制。

4. 开启 Brotli 和 HTTP/2/HTTP/3

在 Cloudflare 后台可以开启：

• Brotli 压缩；
• HTTP/2；
• HTTP/3；
• 0-RTT Connection Resumption。

对于大多数站点来说，Brotli 和 HTTP/2/HTTP/3 可以提升加载速度。但 0-RTT 在某些涉及敏感提交的场景中需要谨慎，如果网站有复杂支付、登录、交易逻辑，可先观察后再开启。

七、安全防护策略

Cloudflare 的安全能力非常适合站长使用，但生产环境需要平衡“安全”和“可用性”。过于严格会误伤正常用户，过于宽松则无法防护攻击。

1. 设置安全级别

Cloudflare 提供 Security Level，可根据网站情况调整。一般生产网站可设置为：

Medium

如果正在遭受攻击，可以临时提升到：

High

或开启：

I'm Under Attack Mode

但“Under Attack Mode”会给访客增加 JavaScript 挑战页面，可能影响用户体验和搜索引擎抓取，因此不建议长期启用。

2. Web Application Firewall

如果使用 Cloudflare Pro 或更高套餐，可以启用 WAF 托管规则，对常见攻击进行防护，例如：

• SQL 注入；
• XSS 攻击；
• 路径穿越；
• 命令注入；
• 恶意爬虫；
• CMS 漏洞扫描。

对于 WordPress 站点，建议启用 WordPress 相关规则集。对于自研网站，建议先使用模拟或日志观察模式，确认没有误伤后再开启阻断。

3. 后台路径保护

站长后台是攻击者重点扫描对象。可以通过 Cloudflare Rules 对后台路径增加保护，例如：

URI Path contains /wp-admin

然后设置：

• 只允许指定国家或地区访问；
• 只允许指定 IP 访问；
• 增加 Turnstile 验证；
• 增加 Managed Challenge；
• 使用 Cloudflare Access 做身份认证。

如果是个人站长，最简单实用的方式是：后台路径仅允许自己的固定 IP 访问。如果没有固定 IP，可以使用 Cloudflare Access 或 VPN。

4. 防止恶意爬虫

恶意爬虫会消耗服务器资源，影响正常用户访问。可以根据以下条件建立规则：

• User-Agent 异常；
• 请求频率过高；
• 访问大量不存在页面；
• 高频访问搜索页；
• 高频访问登录接口；
• 非正常地区访问后台。

但要注意不要误封搜索引擎爬虫。对于 Googlebot、Bingbot 等，应结合反向 DNS 或 Cloudflare Bot 管理能力判断，不建议仅凭 User-Agent 放行，因为 User-Agent 很容易伪造。

八、页面规则与重定向

Cloudflare 可以实现常见重定向需求，例如：

• HTTP 自动跳转 HTTPS；
• 裸域跳转 WWW；
• WWW 跳转裸域；
• 旧域名跳转新域名；
• 特定路径 301 跳转。

1. 开启 Always Use HTTPS

如果网站已经正确配置 SSL，建议开启：

Always Use HTTPS

这样用户访问 HTTP 时会自动跳转到 HTTPS。

2. 配置规范域名

SEO 角度建议全站只保留一个规范域名。例如选择：

https://www.example.com

那么：

http://example.com
https://example.com
http://www.example.com

都应 301 到：

https://www.example.com

反之，如果选择裸域：

https://example.com

则应将 WWW 跳转到裸域。

Cloudflare 的 Redirect Rules 可以完成这些配置。注意使用 301 永久重定向时要谨慎，错误配置后会被浏览器和搜索引擎缓存，修改起来相对麻烦。上线前可先用 302 测试，确认无误后再改为 301。

九、DNS 与子域名管理

生产环境中，DNS 管理应保持清晰规范。建议站长遵循以下原则：

1. 子域名按用途拆分

例如：

www.example.com      主站
api.example.com      API 服务
static.example.com   静态资源
img.example.com      图片资源
admin.example.com    管理后台
status.example.com   状态页

这样便于分别设置缓存、安全、回源、访问控制策略。

2. 不暴露源站 IP

不要使用容易泄露源站 IP 的子域名，例如：

origin.example.com
server.example.com
direct.example.com

如果必须使用源站直连域名，应做好访问控制，不要公开传播。

3. 邮件记录不要代理

邮件相关记录通常包括：

MX
SPF
DKIM
DMARC

这些记录不需要也不能通过 Cloudflare HTTP 代理。mail.example.com 如果指向邮件服务器，通常应保持 DNS only。

十、监控与日志

生产环境部署完成后，监控非常重要。Cloudflare 可以承担一部分监控和分析工作，但站长仍需要结合源站监控。

建议监控以下指标：

• 网站可用性；
• 页面响应时间；
• 5xx 错误数量；
• 4xx 错误数量；
• 缓存命中率；
• 带宽消耗；
• 请求量变化；
• 攻击事件；
• WAF 拦截记录；
• 源站 CPU、内存、磁盘、网络；
• 数据库连接数和慢查询。

Cloudflare 后台 Analytics 可以查看流量、缓存、安全事件等数据。如果网站要求更高，可以接入 UptimeRobot、Better Stack、Grafana、Prometheus、ELK、OpenTelemetry 等监控体系。

常见状态码排查

如果出现 5xx，不要只看 Cloudflare，还要同步查看 Nginx、应用程序、数据库和服务器日志。

十一、上线检查清单

正式将生产环境流量切到 Cloudflare 后，建议按照以下清单逐项检查。

DNS 检查

• [ ] NS 是否已切换到 Cloudflare；
• [ ] A、CNAME 记录是否正确；
• [ ] MX、TXT 邮件记录是否完整；
• [ ] 需要代理的域名是否开启橙色云朵；
• [ ] 不应代理的服务是否保持 DNS only。

HTTPS 检查

• [ ] SSL 模式是否为 Full Strict；
• [ ] 源站证书是否有效；
• [ ] HTTP 是否自动跳转 HTTPS；
• [ ] 是否存在重定向循环；
• [ ] HSTS 是否谨慎配置。

功能检查

• [ ] 首页能否访问；
• [ ] 静态资源是否加载正常；
• [ ] 后台能否登录；
• [ ] 用户登录和退出是否正常；
• [ ] 表单提交是否正常；
• [ ] 支付回调是否正常；
• [ ] API 请求是否正常；
• [ ] 邮件收发是否正常。

缓存检查

• [ ] 静态资源是否命中缓存；
• [ ] 动态页面是否未被错误缓存；
• [ ] 登录用户页面是否不会被缓存；
• [ ] 缓存清理机制是否可用；
• [ ] 更新文章或商品后页面是否能及时刷新。

安全检查

• [ ] WAF 是否启用；
• [ ] 后台路径是否增加访问控制；
• [ ] 源站是否限制 Cloudflare IP 访问；
• [ ] 是否恢复真实访客 IP；
• [ ] 是否存在源站 IP 泄露；
• [ ] 是否有异常拦截或误伤。

十二、常见误区

误区一：开启 Cloudflare 就一定会变快

Cloudflare 能提升全球访问速度，但效果取决于用户位置、源站位置、缓存命中率、页面结构和资源大小。如果网站大量内容是动态页面且无法缓存，加速效果可能有限。优化网站性能仍需要从前端、后端、数据库、图片压缩等多个方面入手。

误区二：全站缓存一定最好

全站缓存适合静态网站或匿名访问内容较多的站点，不适合所有业务。会员站、电商站、论坛、后台系统都需要谨慎设置缓存排除规则。

误区三：Flexible SSL 足够使用

Flexible 只加密用户到 Cloudflare 的连接，Cloudflare 到源站仍可能是 HTTP，不适合生产环境。建议尽快升级到 Full Strict。

误区四：源站 IP 暴露无所谓

如果攻击者知道源站 IP，就可以绕过 Cloudflare 直接攻击服务器。生产环境应尽量隐藏源站 IP，并通过防火墙限制只允许 Cloudflare 回源访问。

误区五：安全规则越严格越好

安全规则过严会导致正常用户、搜索引擎、第三方回调被拦截。生产环境应先观察日志，再逐步收紧策略。

十三、推荐生产环境配置方案

对于大多数站长，可以采用以下基础配置：

DNS：
主站和静态资源开启代理，邮件和非 HTTP 服务保持 DNS only。

SSL：
Full Strict，源站安装有效证书。

HTTPS：
开启 Always Use HTTPS，谨慎开启 HSTS。

缓存：
静态资源长期缓存，动态页面和后台路径不缓存。

安全：
开启基础 WAF，后台路径增加挑战或 IP 限制。

源站：
恢复真实 IP，限制 80/443 仅允许 Cloudflare IP。

监控：
同时监控 Cloudflare 分析数据和源站服务器状态。

如果是 WordPress 站点，可以额外配置：

/wp-admin/* 不缓存并增加访问控制
/wp-login.php 不缓存并增加挑战
/wp-json/* 根据业务决定是否缓存
静态资源设置较长 Edge Cache TTL
登录用户 Cookie 下跳过缓存

如果是静态博客，例如 Hexo、Hugo、Astro、VitePress，则可以更激进地使用缓存：

HTML 页面适度缓存
CSS/JS/图片长期缓存
开启 Brotli、HTTP/3
使用 Cache Reserve 或 R2 优化静态资源分发

结语

Cloudflare 是站长部署生产环境时非常强大的工具，但它不是简单的“一键加速插件”。真正稳定可靠的部署，需要同时考虑 DNS、SSL、缓存、安全、源站防护、真实 IP、SEO、监控和回滚策略。

对于普通站长来说，最重要的原则有三点：第一，SSL 使用 Full Strict，避免 Flexible；第二，缓存规则要区分静态和动态内容，不能盲目全站缓存；第三，源站要做好保护，尽量让所有 Web 流量都经过 Cloudflare。

只要按照合理步骤部署，Cloudflare 不仅可以提升网站访问速度，还能显著增强抗攻击能力、降低源站压力，并让网站在全球范围内获得更稳定的访问体验。对于希望长期运营网站的站长来说，Cloudflare 值得作为生产环境基础设施的一部分认真配置和持续优化。