Cloudflare 使用避坑指南｜2026最新版

Cloudflare 是目前最受欢迎的全球边缘网络服务之一，很多个人站长、跨境业务、SaaS 产品、独立开发者和企业都会用它来做 DNS 托管、CDN 加速、DDoS 防护、WAF 防火墙、SSL 证书管理、访问控制、图片优化以及边缘计算。

但 Cloudflare 虽然强大，也非常容易“用错”。很多网站接入 Cloudflare 后，并没有真正变快，反而出现了访问异常、SSL 报错、缓存混乱、源站暴露、SEO 波动、接口被缓存、后台无法登录、国内访问不稳定等问题。

这篇文章将从实战角度出发，系统整理 Cloudflare 使用中的常见坑点、配置建议和排查思路，适合 2026 年仍在使用或准备接入 Cloudflare 的站长、开发者和运维人员参考。

一、Cloudflare 到底适合哪些场景？

在使用 Cloudflare 之前，首先要明确一点：Cloudflare 不是万能加速器，也不是所有网站都适合无脑接入。

Cloudflare 更适合以下场景：

1. 海外用户较多的网站
   比如面向欧美、东南亚、日本、韩国等地区的业务，Cloudflare 的全球节点覆盖可以显著改善访问体验。

2. 需要隐藏源站 IP 的网站
   通过 Cloudflare 代理访问，可以减少源站直接暴露的风险。

3. 容易被爬虫、恶意请求或 DDoS 攻击的网站
   Cloudflare 的 WAF、安全规则、速率限制和 Bot 防护可以降低压力。

4. 静态资源较多的网站
   图片、CSS、JS、字体文件、下载资源等可以通过 CDN 缓存，减少源站带宽消耗。

5. 需要快速部署 HTTPS 的网站
   Cloudflare 提供边缘 SSL，可以较方便地实现 HTTPS 访问。

但它不一定适合：

• 主要用户都在中国大陆的网站；
• 对低延迟极度敏感的实时业务；
• 强依赖 WebSocket、长连接、特殊端口的服务；
• 不理解 CDN、DNS、SSL 基础概念的新手直接全站代理；
• 必须严格控制数据路径、合规要求很高的业务。

尤其要注意：Cloudflare 免费版在中国大陆没有官方优化线路。 如果你的核心用户都在国内，接入 Cloudflare 后可能出现“海外变快、国内变慢”的情况。

二、DNS 接入避坑：不要随便打开“小云朵”

Cloudflare DNS 里最常见的图标就是“小云朵”：

• 橙色云朵：流量经过 Cloudflare 代理；
• 灰色云朵：仅使用 DNS 解析，不经过 Cloudflare 代理。

很多新手看到橙色云朵就全部打开，结果导致各种问题。

1. 哪些记录可以开代理？

通常可以开启代理的记录包括：

A     example.com
A     www.example.com
CNAME static.example.com
CNAME assets.example.com

适合代理的是 HTTP/HTTPS 网站访问域名，也就是主要用于网页访问的域名。

2. 哪些记录不建议开代理？

以下类型的记录一般不建议开启 Cloudflare 代理：

MX      邮件服务
TXT     SPF/DKIM/DMARC 验证
SRV     特殊服务
FTP     文件传输服务
SSH     远程登录服务
数据库连接域名
邮件收发域名
API 特殊端口服务

Cloudflare 免费版和常规代理主要支持 HTTP/HTTPS 流量，并不是任意 TCP/UDP 代理。你如果把 mail.example.com、ftp.example.com、ssh.example.com 这类域名开成橙色云朵，很可能会导致连接失败。

3. 源站 IP 暴露问题

很多人以为用了 Cloudflare 就一定隐藏了源站 IP，其实不一定。源站 IP 可能通过以下方式暴露：

• 历史 DNS 解析记录；
• 邮件服务器 IP；
• 旁站扫描；
• 子域名未代理；
• GitHub、配置文件、错误日志泄露；
• 源站直接响应 Host 访问；
• 证书透明日志记录；
• 旧的 A 记录缓存。

建议接入 Cloudflare 后：

1. 检查所有子域名；
2. 邮件服务尽量和网站源站分离；
3. 源站防火墙只允许 Cloudflare IP 段访问 80/443；
4. 不要把真实 IP 写在公开配置中；
5. 定期使用外部工具检查域名历史解析记录。

三、SSL/TLS 避坑：不要再用 Flexible 模式

Cloudflare SSL/TLS 有几个常见模式：

• Off：关闭 HTTPS；
• Flexible：访客到 Cloudflare 是 HTTPS，Cloudflare 到源站是 HTTP；
• Full：访客到 Cloudflare 是 HTTPS，Cloudflare 到源站也是 HTTPS，但不严格验证证书；
• Full Strict：访客到 Cloudflare 是 HTTPS，Cloudflare 到源站是 HTTPS，并严格验证证书。

最推荐：Full Strict

2026 年仍然建议优先使用：

SSL/TLS encryption mode：Full (Strict)

也就是 完全严格模式。

源站可以使用：

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

其中 Cloudflare Origin Certificate 只适用于 Cloudflare 到源站之间的加密，浏览器不会直接信任。因此它适合源站只允许 Cloudflare 访问的场景。

为什么不推荐 Flexible？

Flexible 模式看起来方便，但坑很多：

1. 源站到 Cloudflare 之间是明文 HTTP
   安全性不足。

2. 容易出现重定向循环
   例如源站 Nginx 强制 HTTP 跳转 HTTPS，而 Cloudflare Flexible 又用 HTTP 回源，就可能不断循环。

3. 不适合严肃业务
   登录、支付、后台管理、会员系统都不建议使用 Flexible。

如果你看到网站出现：

ERR_TOO_MANY_REDIRECTS

很可能就和 SSL 模式、源站跳转规则、Cloudflare Page Rules/Redirect Rules 冲突有关。

四、缓存配置避坑：不是所有内容都应该缓存

Cloudflare 的 CDN 缓存是它的核心能力之一，但缓存设置错误会导致非常严重的问题。

1. 静态资源适合缓存

适合缓存的内容包括：

.jpg
.png
.webp
.gif
.svg
.css
.js
.woff
.woff2
.ico
.pdf
.zip

这些资源变化不频繁，缓存后可以明显降低源站压力。

2. 动态页面谨慎缓存

以下内容不建议无脑缓存：

• 用户后台；
• 登录页面；
• 购物车；
• 支付页面；
• 用户中心；
• 订单页面；
• 评论提交接口；
• 搜索结果页；
• 个性化推荐页面；
• 带有用户身份状态的页面。

如果你错误地缓存了动态页面，可能会出现：

• A 用户看到 B 用户的信息；
• 登录状态错乱；
• 后台修改后前台不更新；
• 支付状态异常；
• API 返回旧数据；
• 表单提交失败。

3. WordPress 常见缓存坑

WordPress 用户接入 Cloudflare 时尤其要注意：

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

这些路径通常不应被缓存，尤其是 WooCommerce 商城站。

建议规则：

• 后台路径绕过缓存；
• 登录用户绕过缓存；
• API 路径绕过缓存；
• 静态资源长缓存；
• HTML 页面根据业务情况谨慎缓存。

4. Cache Everything 要慎用

很多教程会推荐设置：

Cache Everything

这个选项确实可以大幅提高缓存命中率，但不适合所有网站。它会让 Cloudflare 尝试缓存 HTML 页面，如果没有配置好绕过规则，就很容易出问题。

更稳妥的做法是：

1. 先缓存静态资源；
2. 观察访问日志和命中率；
3. 再对部分公开页面启用 HTML 缓存；
4. 后台、接口、登录态页面明确排除；
5. 配合 Cache Rules 精细化控制。

五、WAF 防火墙避坑：规则不是越严越好

Cloudflare 的 WAF 很强，但规则设置过严会误伤正常用户。

常见误伤场景包括：

• 后台登录被拦截；
• API 请求被挑战；
• 海外用户访问正常，国内用户频繁验证；
• 搜索引擎蜘蛛被拦截；
• 支付回调被阻断；
• Webhook 请求失败；
• App 客户端接口无法访问。

1. 不要轻易全站开启高强度挑战

比如你设置：

所有非本国 IP：Managed Challenge
所有访问 /api/*：JS Challenge
所有 User-Agent 异常：Block

这类规则看似安全，但可能导致业务不可用。

更合理的策略是：

• 登录接口加强验证；
• 后台路径限制地区或 IP；
• 高频请求触发挑战；
• 明确恶意路径直接阻断；
• 搜索引擎蜘蛛放行；
• 支付、Webhook、回调接口白名单处理。

2. 常见推荐规则

例如后台保护：

URI Path starts with /admin
AND IP not in whitelist
Then Managed Challenge

例如阻断恶意扫描：

URI Path contains /.env
OR URI Path contains /wp-config.php
OR URI Path contains /phpinfo
Then Block

例如限制登录爆破：

URI Path equals /wp-login.php
Then Rate Limit

3. 小心误封搜索引擎

如果你的网站依赖 SEO，一定要避免误伤搜索引擎蜘蛛。建议不要仅凭 User-Agent 判断真假蜘蛛，因为 User-Agent 可以伪造。

更稳妥的方式：

• 使用 Cloudflare 的 Verified Bots 相关能力；
• 对可信搜索引擎放行；
• 检查防火墙事件日志；
• 出现收录波动时及时排查 WAF 规则。

六、性能优化避坑：打开越多不代表越快

Cloudflare 提供很多性能优化选项，例如：

• Auto Minify；
• Brotli；
• Rocket Loader；
• HTTP/2；
• HTTP/3；
• Early Hints；
• Polish；
• Mirage；
• APO；
• Image Resizing；
• Argo Smart Routing。

但并不是所有功能都适合你的网站。

1. Auto Minify 可能引发前端异常

Auto Minify 会压缩 HTML、CSS、JS。对于简单网站通常没问题，但对于复杂前端项目，可能导致：

• JS 报错；
• CSS 样式异常；
• 构建后的资源被二次压缩；
• 第三方脚本运行异常。

如果你的项目已经通过 Vite、Webpack、Next.js、Nuxt、Astro 等工具构建压缩，就没有必要再依赖 Cloudflare 的 Auto Minify。

2. Rocket Loader 慎用

Rocket Loader 会改变 JavaScript 加载方式，可能提升部分页面速度，但也可能导致：

• 广告脚本不加载；
• 统计代码异常；
• 轮播图失效；
• 表单组件无法初始化；
• Vue/React 页面闪烁或报错。

如果你发现前端功能异常，可以优先关闭 Rocket Loader 排查。

3. Brotli 建议开启

Brotli 压缩对文本资源有明显帮助，通常建议开启：

Speed → Optimization → Brotli：On

它对 HTML、CSS、JS、JSON 等资源压缩效果较好。

4. HTTP/3 可以开启但要观察

HTTP/3 在部分网络环境下体验更好，但也可能受到运营商、地区、浏览器、网络设备影响。如果开启后用户反馈访问异常，可以临时关闭验证。

七、国内访问避坑：Cloudflare 免费版不等于国内 CDN

这是很多中文站长最容易踩的坑。

Cloudflare 在全球范围内表现不错，但对于中国大陆用户，免费版并不能保证稳定高速访问。常见现象包括：

• 首次打开慢；
• 连接超时；
• 不同省份表现差异很大；
• 晚高峰延迟升高；
• 移动、电信、联通表现不一致；
• 某些节点绕路严重；
• 静态资源加载不完整。

如果你的网站核心用户在中国大陆，建议考虑：

1. 使用国内备案域名接入国内 CDN；
2. 国内外分线路解析；
3. 静态资源放到国内对象存储/CDN；
4. 海外用户走 Cloudflare，国内用户走国内 CDN；
5. 对登录、支付等关键业务使用更稳定的线路；
6. 不要把 Cloudflare 当作“国内加速神器”。

如果你的用户全球分布，可以使用智能 DNS 根据地区解析到不同 CDN 或不同源站，但这会增加运维复杂度。

八、源站配置避坑：Cloudflare 不是替你修服务器

很多性能问题不是 Cloudflare 的问题，而是源站本身的问题。

比如：

• 数据库慢；
• PHP-FPM 配置不足；
• Node.js 服务阻塞；
• Nginx 配置错误；
• 源站带宽太小；
• 图片没有压缩；
• 页面首屏依赖大量第三方脚本；
• 后端接口响应慢；
• TTFB 本身很高。

Cloudflare 能缓存和优化一部分内容，但如果源站动态响应很慢，用户首次请求、缓存未命中请求、后台操作、API 调用仍然会慢。

建议源站做好：

• 启用 HTTP/2 或 HTTP/3；
• 配置 Gzip/Brotli；
• 优化数据库索引；
• 减少慢查询；
• 使用对象存储管理大文件；
• 图片转 WebP/AVIF；
• 设置合理的缓存响应头；
• 使用 Redis/Memcached；
• 配置健康检查和监控；
• 源站只允许 Cloudflare IP 访问。

九、Page Rules、Cache Rules、Redirect Rules 不要混乱使用

早期很多教程都基于 Page Rules，但 Cloudflare 近年来逐步将很多功能拆分到更细的规则系统中，例如：

• Cache Rules；
• Redirect Rules；
• Transform Rules；
• WAF Custom Rules；
• Origin Rules；
• Configuration Rules。

新用户不应只依赖旧教程照抄 Page Rules，而应该理解每类规则的用途。

常见错误

1. 同一个路径同时设置多个冲突规则
   例如既设置缓存，又设置绕过缓存。

2. 重定向规则与源站重定向冲突
   导致 301 循环或跳转链过长。

3. HTTP 到 HTTPS 在多个地方重复设置
   Cloudflare、Nginx、应用程序都在跳转，容易出问题。

4. 缓存规则没有排除后台和接口
   导致动态内容异常。

建议原则

• HTTPS 强制跳转只在一个地方做；
• 缓存规则尽量按路径精确配置；
• 后台、API、登录、支付优先设置为绕过缓存；
• 每次只改一类规则，观察后再继续；
• 重要变更前截图或导出配置。

十、邮箱服务避坑：Cloudflare 代理不了 MX

如果你使用企业邮箱、自建邮箱或第三方邮件服务，务必正确配置 DNS。

常见邮箱记录包括：

MX
TXT SPF
TXT DKIM
TXT DMARC
CNAME 验证记录

这些记录一般保持 DNS-only，不需要也不能通过 Cloudflare HTTP 代理。

常见错误包括：

• MX 指向了橙色云朵域名；
• SPF 记录写错导致邮件进垃圾箱；
• DKIM 没配置导致验签失败；
• DMARC 过于严格导致正常邮件被拒；
• 邮件服务和网站源站共用 IP，导致源站 IP 暴露。

推荐做法：

1. 邮箱域名使用独立子域名；
2. 邮件服务和网站源站分离；
3. 正确配置 SPF、DKIM、DMARC；
4. 邮件相关记录保持灰色云朵；
5. 使用第三方邮件服务降低维护成本。

十一、API 和 WebSocket 避坑

如果你的网站包含 API 服务、App 后端、WebSocket 或实时通信功能，需要特别注意。

1. API 不要随便缓存

API 通常应该设置：

Cache：Bypass

尤其是：

• 用户信息接口；
• 登录接口；
• 支付接口；
• 订单接口；
• 权限接口；
• 消息接口。

可以缓存的 API 一般是公开、无状态、更新频率低的接口，例如公开配置、文章列表、商品公共信息等。

2. WebSocket 需要测试稳定性

Cloudflare 支持 WebSocket，但实际体验取决于套餐、网络环境、连接时长、业务设计和源站能力。

实时业务建议注意：

• 心跳机制；
• 断线重连；
• 超时策略；
• 源站连接数；
• 是否需要专门的实时通信服务；
• 不要把所有实时压力都压在普通 Web 服务上。

十二、安全设置避坑：不要只依赖 Cloudflare

Cloudflare 是一道很好的外层防护，但不能替代应用自身安全。

你仍然需要做好：

• 后台强密码；
• 多因素认证；
• 服务器 SSH 禁止密码登录；
• 定期更新系统和依赖；
• 数据库最小权限；
• 敏感文件不放公网目录；
• 上传文件类型校验；
• 防 SQL 注入；
• 防 XSS；
• 防 CSRF；
• 日志审计；
• 数据备份。

尤其是源站防火墙非常重要。如果你没有限制源站访问，即使 Cloudflare 配置再好，攻击者一旦找到真实 IP，仍然可以绕过 Cloudflare 直接攻击源站。

十三、排查问题的基本方法

遇到 Cloudflare 相关问题时，不要盲目改配置。建议按照以下顺序排查。

1. 判断是否是 Cloudflare 引起

可以临时将 DNS 记录从橙色云朵改为灰色云朵，绕过 Cloudflare 测试。

如果绕过后恢复正常，说明问题大概率在 Cloudflare 配置、缓存、安全规则或代理链路。

如果绕过后仍然异常，问题可能在源站、应用程序或 DNS 配置。

2. 查看响应头

使用浏览器开发者工具或 curl 查看：

curl -I https://example.com

重点关注：

cf-cache-status
cf-ray
cache-control
location
status code
server

常见 cf-cache-status 含义：

• HIT：命中 Cloudflare 缓存；
• MISS：未命中缓存；
• BYPASS：绕过缓存；
• EXPIRED：缓存过期；
• DYNAMIC：动态内容未缓存。

3. 查看 Cloudflare 事件日志

如果用户访问被拦截，应该查看：

Security → Events

确认是哪个规则触发了拦截、挑战或阻断。

4. 清理缓存

修改 CSS、JS、图片后没有生效，可以尝试：

• Purge Everything；
• Purge by URL；
• 给静态资源加版本号；
• 检查浏览器本地缓存；
• 检查源站缓存插件。

不要每次都无脑 Purge Everything，大站频繁全量清缓存可能导致源站瞬间压力升高。

十四、推荐的基础配置清单

下面是一套相对稳妥的 Cloudflare 基础配置思路，适合大多数普通网站参考。

DNS

• 网站主域名和 www 开启代理；
• 邮件、SSH、FTP、数据库相关记录保持 DNS-only；
• 删除不必要的历史解析；
• 子域名按用途分别管理。

SSL/TLS

• 使用 Full Strict；
• 开启 Always Use HTTPS；
• 源站配置有效证书；
• 避免 Flexible；
• 检查是否存在重复跳转。

缓存

• 静态资源缓存；
• 后台、登录、API、支付绕过缓存；
• 谨慎使用 Cache Everything；
• 修改资源时使用版本号；
• 根据业务设置 Edge TTL 和 Browser TTL。

安全

• 开启基础 WAF；
• 后台路径加访问限制；
• 登录接口做速率限制；
• 放行可信回调接口；
• 定期查看 Security Events；
• 源站防火墙只允许 Cloudflare IP。

性能

• 开启 Brotli；
• 根据情况开启 HTTP/3；
• 慎用 Rocket Loader；
• 前端已构建压缩时不必重复 Minify；
• 图片优化优先从源站和格式入手。

运维

• 重要配置变更前截图；
• 每次只改一个变量；
• 保留源站直接访问测试方式；
• 配置监控和备份；
• 定期检查 DNS、SSL、缓存和安全事件。

十五、总结：Cloudflare 好用，但不要迷信

Cloudflare 的确是一个非常优秀的网络平台，它能帮助网站提升安全性、降低源站压力、改善海外访问速度，并提供很多现代化边缘能力。

但 Cloudflare 不是“接入即变快”的魔法工具。真正稳定、高性能的网站，需要 DNS、SSL、缓存、安全、源站、应用代码和网络线路共同配合。

最重要的避坑原则可以总结为五句话：

1. 不要所有 DNS 记录都开橙色云朵。
2. SSL 尽量使用 Full Strict，不要依赖 Flexible。
3. 缓存要分清静态和动态，后台与 API 必须谨慎。
4. WAF 规则不要过度激进，避免误伤正常用户。
5. Cloudflare 不是国内 CDN，国内用户体验要单独评估。

如果你是新手，建议先用最保守的配置上线：只代理主站、开启 Full Strict、缓存静态资源、后台和 API 绕过缓存、开启基础安全防护。等网站稳定运行后，再逐步启用高级功能。

这样使用 Cloudflare，才能真正发挥它的价值，而不是把一个强大的工具变成新的故障来源。