Cloudflare 性能优化教程｜适合站长

在网站运营过程中，速度、稳定性和安全性往往是影响用户体验与搜索引擎表现的关键因素。对于站长来说，Cloudflare 是一个非常实用的工具：它不仅提供 CDN 加速，还包含 DNS 托管、缓存优化、图片优化、WAF 防护、DDoS 防御、规则配置等能力。合理使用 Cloudflare，可以让网站在全球范围内访问更快、更稳定，同时降低源站服务器压力。

本文将从站长视角出发，系统讲解 Cloudflare 的性能优化思路与实操配置，适合 WordPress、博客站、企业官网、内容站、工具站以及中小型独立网站参考。

一、Cloudflare 为什么能提升网站性能？

Cloudflare 的核心作用可以简单理解为：让用户优先访问离自己更近的 Cloudflare 节点，而不是每次都直接访问你的源站服务器。

当用户访问你的网站时，Cloudflare 会根据 DNS 解析和边缘节点调度，将请求转发到距离用户较近的节点。如果资源已经被缓存，Cloudflare 可以直接从边缘节点返回内容，避免请求回源站。这样可以带来几个明显优势：

1. 降低访问延迟
   用户无需跨地区访问你的服务器，静态资源可从附近节点加载。

2. 减少源站压力
   图片、CSS、JS、静态 HTML 等内容可以被 CDN 缓存，源站请求量明显下降。

3. 提升抗攻击能力
   Cloudflare 可以隐藏源站 IP，并过滤部分恶意流量。

4. 改善全球访问体验
   对海外用户、跨地区用户比较多的网站尤其有帮助。

5. 优化带宽成本
   静态资源由 CDN 分发后，源站带宽消耗减少。

不过需要注意，Cloudflare 并不是“开启就一定变快”。如果配置不合理，例如缓存规则错误、SSL 模式设置不当、JS 延迟策略冲突，反而可能导致网站变慢或异常。因此，站长需要理解各项功能的作用，并根据网站类型进行配置。

二、接入 Cloudflare 前的准备工作

在正式优化之前，建议先做好以下准备。

1. 确认网站当前性能情况

可以使用以下工具测试网站速度：

• PageSpeed Insights
• GTmetrix
• WebPageTest
• Chrome DevTools Network 面板
• Pingdom Tools

重点关注以下指标：

接入 Cloudflare 后，再用同样工具复测，方便对比优化效果。

2. 确认源站稳定

Cloudflare 是加速层，不是万能服务器。如果源站本身性能很差，例如 CPU 长期满载、数据库查询缓慢、PHP 执行时间过长，那么仅靠 Cloudflare 只能缓解部分静态资源压力，动态页面仍可能很慢。

建议源站至少做到：

• 开启 HTTPS；
• 使用较新版本 PHP、Nginx/Apache；
• 配置页面缓存或对象缓存；
• 数据库索引合理；
• 图片经过压缩；
• 网站程序和插件不过度臃肿。

3. 备份 DNS 记录

接入 Cloudflare 需要修改域名 DNS。操作前请记录原有 DNS 配置，包括：

• A 记录；
• CNAME 记录；
• MX 邮件记录；
• TXT 验证记录；
• 子域名解析；
• SPF、DKIM、DMARC 邮件相关记录。

尤其是企业邮箱用户，一定要确保 MX 和 TXT 记录迁移完整，否则可能影响邮件收发。

三、DNS 设置：性能优化的第一步

Cloudflare 的 DNS 解析速度本身较快，是很多站长接入 Cloudflare 的基础理由之一。

1. 开启代理状态

在 Cloudflare DNS 面板中，记录右侧有一个云朵图标：

• 橙色云朵：开启代理
  流量经过 Cloudflare，可使用 CDN、缓存、安全规则等功能。

• 灰色云朵：仅 DNS 解析
  只负责解析，不经过 Cloudflare，不享受 CDN 加速和安全防护。

一般建议：

如果把邮件、FTP、SSH 等服务错误开启代理，可能导致连接异常。

2. 合理设置 TTL

Cloudflare 开启代理后，TTL 通常由 Cloudflare 自动管理。如果是灰色云朵的 DNS-only 记录，可以根据需求设置 TTL。

• 频繁变更 IP：设置较短 TTL；
• 稳定业务：设置较长 TTL；
• 迁移服务器前：提前降低 TTL。

四、SSL/TLS 设置：避免 HTTPS 性能与安全问题

Cloudflare SSL 配置非常关键，错误设置可能导致循环重定向、证书错误或安全隐患。

1. 推荐使用 Full 或 Full Strict

Cloudflare 提供几种 SSL 模式：

对于正式网站，建议使用：

SSL/TLS → Overview → Full (strict)

前提是源站安装了有效证书。可以使用 Let’s Encrypt，也可以使用 Cloudflare Origin Certificate。

2. 开启 Always Use HTTPS

路径：

SSL/TLS → Edge Certificates → Always Use HTTPS

开启后，HTTP 请求会自动跳转到 HTTPS，有利于安全和 SEO 统一。

3. 开启 HTTP/2 和 HTTP/3

路径：

Network → HTTP/2
Network → HTTP/3

建议开启。HTTP/2 可以多路复用，减少连接开销；HTTP/3 基于 QUIC，在弱网环境下可能表现更好。

4. 开启 0-RTT 需谨慎

0-RTT 可以减少 TLS 握手延迟，但可能带来重放请求风险。对于普通内容站可以考虑开启；如果网站包含支付、登录、敏感操作，建议谨慎评估。

五、缓存设置：Cloudflare 性能优化核心

缓存是 Cloudflare 加速的关键。对于站长来说，最重要的是区分：

• 静态资源缓存：图片、CSS、JS、字体、视频等；
• 动态页面缓存：HTML 页面、接口、会员页面等。

1. 浏览器缓存 TTL

路径：

Caching → Configuration → Browser Cache TTL

建议设置为：

• 内容频繁更新的网站：4 小时或 1 天；
• 普通博客/企业站：1 天到 1 周；
• 静态资源版本化的网站：1 个月以上。

如果你的 CSS/JS 文件名带版本号，例如 style.css?ver=1.2.3 或 app.8f3a.js，可以设置更长的缓存时间。

2. Edge Cache TTL

Edge Cache TTL 是 Cloudflare 节点缓存资源的时间。对于静态资源，建议使用缓存规则设置较长时间。

例如：

条件：URI Path ends with .jpg 或 .png 或 .css 或 .js 或 .woff2
操作：Cache eligible for cache
Edge TTL：1 month
Browser TTL：1 week

这样可以显著减少源站请求。

3. Cache Everything 是否要开启？

Cloudflare 默认主要缓存静态资源，不一定缓存 HTML。很多站长为了极致速度，会启用“Cache Everything”，让 HTML 页面也被缓存。

适合启用的场景：

• 纯静态网站；
• 博客文章页；
• 新闻内容页；
• 企业官网；
• 不需要登录态展示差异的页面。

不适合启用的场景：

• 用户中心；
• 购物车；
• 结算页面；
• 后台管理；
• 个性化推荐页面；
• 含有动态用户信息的页面。

如果错误缓存了登录页面或会员页面，可能导致隐私泄露或页面显示异常。因此，建议使用规则精细控制。

4. WordPress 推荐缓存规则

对于 WordPress 站点，可参考以下规则：

规则一：缓存静态资源

条件：
URI Path contains /wp-content/
或 URI Path contains /wp-includes/

操作：
Cache eligible
Edge TTL：1 month
Browser TTL：1 week

规则二：不缓存后台和登录页

条件：
URI Path contains /wp-admin/
或 URI Path contains /wp-login.php

操作：
Bypass cache

规则三：不缓存预览和搜索结果

条件：
URI Query contains preview=true
或 URI Path contains /?s=

操作：
Bypass cache

规则四：文章页可考虑缓存 HTML

如果网站不是会员站，可对文章页开启 HTML 缓存：

条件：
URI Path does not contain /wp-admin/
且 URI Path does not contain /wp-login.php
且 Cookie does not contain wordpress_logged_in

操作：
Cache everything
Edge TTL：几小时到几天

对于 WordPress，建议搭配插件进行缓存清理，例如：

• Cloudflare 官方插件；
• WP Rocket；
• LiteSpeed Cache；
• W3 Total Cache；
• Super Page Cache for Cloudflare。

当文章更新时自动清理对应 URL 缓存，避免用户看到旧内容。

六、Speed 设置：压缩与资源优化

Cloudflare 的 Speed 功能可以进一步优化前端资源。

1. 开启 Brotli 压缩

路径：

Speed → Optimization → Brotli

建议开启。Brotli 通常比 Gzip 压缩率更高，能减少 HTML、CSS、JS 文件体积。

2. Auto Minify 谨慎开启

Cloudflare 支持自动压缩：

• JavaScript；
• CSS；
• HTML。

对于简单网站可以开启，但如果你已经使用构建工具、缓存插件或主题自带压缩功能，就不建议重复压缩。重复压缩可能带来 JS 错误或样式异常。

建议：

• CSS：可开启；
• HTML：可开启；
• JS：谨慎开启，开启后需测试交互功能。

3. Rocket Loader 谨慎使用

Rocket Loader 会异步加载 JavaScript，理论上可以提升页面渲染速度。但它也容易与主题、广告脚本、统计代码、评论系统、支付组件冲突。

建议：

• 普通博客可测试；
• 电商、会员系统、复杂前端项目不建议盲目开启；
• 开启后必须检查菜单、搜索、评论、登录、支付等功能是否正常。

4. Early Hints

Early Hints 可以让浏览器更早发现并加载关键资源。建议开启，尤其是页面资源较多的网站。

路径：

Speed → Optimization → Early Hints

七、图片优化：提升 LCP 的关键

图片通常是网页体积最大的部分，也是影响 LCP 的重要因素。

1. 开启 Polish

Polish 是 Cloudflare 的图片优化功能，部分套餐才支持。它可以自动压缩图片，并可提供 WebP 格式。

建议设置：

• Lossless：无损压缩，画质保持更好；
• Lossy：有损压缩，体积更小；
• WebP：建议开启。

内容站、博客、资讯站通常可以选择 Lossy + WebP，以获得更好性能。

2. 使用 Cloudflare Images 或 R2

如果你的网站图片很多，可以考虑：

• Cloudflare Images：图片托管、变体裁剪、自动优化；
• Cloudflare R2：对象存储，可配合 CDN 分发静态资源。

对于图片站、资源站、下载站，源站带宽压力很大时，R2 + Cloudflare CDN 是较好的方案。

3. 图片本地优化仍然重要

不要把所有优化都交给 CDN。上传前仍建议：

• 控制图片尺寸；
• 压缩 JPG/PNG；
• 使用 WebP/AVIF；
• 首屏大图不要过大；
• 图片设置 width 和 height；
• 对非首屏图片开启 lazy loading。

八、防止缓存穿透与源站过载

当大量请求绕过缓存直接打到源站时，源站容易过载。站长可通过以下方式降低风险。

1. 缓存静态资源

确保常见静态资源被缓存，例如：

.jpg .jpeg .png .gif .webp .svg .css .js .woff .woff2 .ttf .ico

2. 对恶意请求设置规则

可以在 WAF 或 Security Rules 中拦截异常请求，例如：

• 高频访问不存在路径；
• 扫描 WordPress 漏洞路径；
• 访问 .env、wp-config.php、phpmyadmin；
• 非法 User-Agent；
• 特定国家或地区异常流量。

示例规则：

URI Path contains ".env"
或 URI Path contains "wp-config"
或 URI Path contains "phpmyadmin"

操作：Block

3. Rate Limiting

如果网站经常被刷接口、刷搜索、刷登录，可以配置速率限制。

例如：

路径：/wp-login.php
规则：1 分钟超过 10 次请求
操作：Managed Challenge 或 Block

这样可以减少暴力破解和恶意请求。

九、页面规则与配置规则：站长常用方案

Cloudflare 旧版常用 Page Rules，新版更推荐 Cache Rules、Configuration Rules、Redirect Rules 等独立规则。下面给出常见站点配置思路。

1. 强制 www 或非 www

为了 SEO 统一，建议选择一个主域名形式。

例如统一到 https://www.example.com：

如果 hostname 等于 example.com
重定向到 https://www.example.com/$1
状态码：301

或者统一到非 www：

如果 hostname 等于 www.example.com
重定向到 https://example.com/$1
状态码：301

避免 www 和非 www 同时可访问导致权重分散。

2. 后台绕过缓存

条件：
URI Path contains /admin/
或 URI Path contains /wp-admin/
或 URI Path contains /user/

操作：
Bypass cache
Disable performance features

后台页面不要被缓存，也不要被 Rocket Loader 之类功能影响。

3. API 接口不缓存

条件：
URI Path starts with /api/

操作：
Bypass cache

如果是公开且数据变化不频繁的 API，可单独设置短缓存，但需要明确业务逻辑。

4. 静态资源长期缓存

条件：
URI Path ends with .css .js .jpg .png .webp .woff2

操作：
Edge TTL：1 month
Browser TTL：7 days 或 1 month

如果资源文件名带哈希，可设置更长时间，例如 6 个月或 1 年。

十、Cloudflare APO：WordPress 站长的加速利器

APO，全称 Automatic Platform Optimization，是 Cloudflare 针对 WordPress 的优化功能。它可以将 WordPress 页面缓存到 Cloudflare 边缘节点，显著降低 TTFB。

适合：

• WordPress 博客；
• 内容站；
• 企业站；
• 文章页访问量大的网站。

开启 APO 后，Cloudflare 会更智能地缓存 HTML 页面，并通过插件在文章更新时自动清理缓存。相比普通“Cache Everything”，APO 对 WordPress 更友好，配置成本更低。

不过需要注意：

• 登录用户页面仍要绕过缓存；
• WooCommerce 购物车和结算页要谨慎；
• 会员内容站需测试权限页面；
• 需要安装 Cloudflare WordPress 插件并绑定 API。

如果你是 WordPress 站长，而且网站以公开内容为主，APO 是非常值得考虑的功能。

十一、Argo Smart Routing 是否值得开启？

Argo Smart Routing 是 Cloudflare 的智能路由服务，可以根据网络状况选择更优路径回源，减少延迟和丢包。

适合：

• 全球用户较多；
• 源站和用户距离较远；
• 动态请求较多；
• 对稳定性要求较高的网站。

如果你的网站访问者主要在源站所在地区附近，且静态资源已经充分缓存，Argo 的收益可能不明显。但对于跨境访问、海外业务、SaaS 工具站、API 服务，Argo 可能带来更稳定的体验。

十二、源站配合优化：不要只依赖 Cloudflare

Cloudflare 可以提升边缘访问体验，但源站性能仍然是基础。建议从以下方面同步优化。

1. 开启源站缓存

WordPress 推荐：

• LiteSpeed Cache；
• WP Rocket；
• Redis Object Cache；
• W3 Total Cache。

如果是自建程序，可以使用：

• Nginx FastCGI Cache；
• Varnish；
• Redis；
• Memcached；
• 应用层页面缓存。

2. 优化数据库

定期清理：

• 垃圾评论；
• 文章修订版本；
• 过期 transient；
• 无用插件表；
• 低效索引。

对于访问量较大的网站，数据库性能会直接影响动态页面响应速度。

3. 减少插件和第三方脚本

很多网站慢，不是服务器差，而是页面加载了过多第三方资源，例如：

• 广告脚本；
• 在线客服；
• 统计代码；
• 社交插件；
• 字体服务；
• 外部评论系统。

Cloudflare 无法完全解决第三方脚本慢的问题。站长应尽量减少非必要脚本，或者延迟加载。

4. 使用合适的服务器地区

如果主要用户在中国大陆，源站却在欧美，动态请求延迟会比较高。Cloudflare 对静态资源帮助很大，但动态请求仍需回源。此时可以考虑：

• 选择更接近用户的服务器；
• 使用香港、新加坡、日本等区域；
• 对国内用户使用合规 CDN；
• 动态接口尽量减少回源次数。

十三、如何验证 Cloudflare 是否生效？

站长可以通过响应头判断缓存状态。

打开浏览器开发者工具，查看 Network 中的请求响应头：

cf-cache-status: HIT

常见状态含义：

如果静态资源长期显示 MISS 或 DYNAMIC，说明缓存规则可能没有配置好。

也可以使用命令行：

curl -I https://example.com/style.css

查看响应头中的 cf-cache-status、cache-control、age 等字段。

十四、常见问题与解决方案

1. 开启 Cloudflare 后网站无限重定向

常见原因是 SSL 模式设置为 Flexible，而源站也强制 HTTPS，导致循环跳转。

解决方法：

• 将 SSL 模式改为 Full 或 Full Strict；
• 源站安装有效证书；
• 检查 WordPress 地址是否为 HTTPS。

2. 修改内容后前台不更新

原因通常是缓存未清理。

解决方法：

• 手动 Purge Cache；
• 使用插件自动清理；
• 缩短 HTML Edge TTL；
• 对频繁更新页面绕过缓存。

3. 登录后台异常

可能是后台页面被缓存或 JS 优化冲突。

解决方法：

• 对 /wp-admin/、/wp-login.php 设置 Bypass Cache；
• 关闭 Rocket Loader；
• 禁用 JS Auto Minify 后测试。

4. 图片没有变成 WebP

可能原因：

• 未开启 Polish；
• 套餐不支持；
• 浏览器不支持；
• 图片响应头不符合优化条件；
• 源图格式或大小限制。

5. 网站速度没有明显提升

可能原因：

• 页面主要是动态请求；
• 源站 TTFB 很慢；
• 缓存没有命中；
• 第三方脚本太多；
• 用户与 Cloudflare 节点线路不佳；
• 首页 HTML 没有缓存。

建议先查看 cf-cache-status，再分析瀑布图。

十五、推荐配置清单

下面给出一套适合大多数内容型网站的 Cloudflare 配置参考。

基础设置

• DNS 主域名和 www 开启橙云；
• 邮件、FTP、SSH 不开启代理；
• SSL 设置为 Full Strict；
• 开启 Always Use HTTPS；
• 开启 HTTP/2、HTTP/3；
• 开启 Brotli；
• 开启 Early Hints。

缓存设置

• 静态资源 Edge TTL：1 个月；
• 浏览器缓存 TTL：1 天到 1 周；
• WordPress 后台、登录页绕过缓存；
• API、用户中心、购物车、结算页绕过缓存；
• 文章页可按需开启 HTML 缓存；
• WordPress 可考虑 APO。

安全与稳定

• 隐藏源站 IP；
• 拦截常见敏感路径；
• 登录页设置 Rate Limiting；
• 开启基础 WAF 托管规则；
• 定期查看 Security Events；
• 对异常国家或地区流量设置挑战验证。

前端优化

• Brotli 开启；
• CSS/HTML Minify 可开启；
• JS Minify 谨慎；
• Rocket Loader 谨慎；
• 图片压缩和 WebP 优化；
• 减少第三方脚本。

十六、总结

Cloudflare 对站长来说，是一个集 CDN、DNS、安全、防护和性能优化于一体的强大平台。想要真正发挥它的价值，关键不是“全部功能都打开”，而是根据网站类型进行合理配置。

对于普通博客、内容站和企业官网，最重要的是：

1. 正确配置 DNS 和 SSL；
2. 让静态资源充分缓存；
3. 对 HTML 页面谨慎开启缓存；
4. 后台、登录、用户相关页面必须绕过缓存；
5. 开启 Brotli、HTTP/2、HTTP/3 等基础优化；
6. 优化图片和第三方脚本；
7. 配合源站缓存和数据库优化；
8. 定期通过响应头和性能测试工具验证效果。

如果你是 WordPress 站长，可以优先考虑 Cloudflare APO 或搭配成熟缓存插件，实现更简单、更稳定的全站加速。对于访问量较大或全球用户较多的网站，还可以进一步评估 Argo、R2、Images、WAF 和 Rate Limiting 等进阶功能。

总之，Cloudflare 性能优化不是一次性操作，而是一个持续调试的过程。站长应根据访问日志、缓存命中率、页面速度指标和用户反馈不断调整配置。只有让 Cloudflare、源站服务器、网站程序和前端资源形成配合，网站才能真正做到访问更快、负载更低、体验更好。