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

Cloudflare 是全球最常用的 CDN、DNS、WAF 与边缘网络服务之一。对于站长来说，Cloudflare 的价值不仅是“隐藏源站 IP”或“防御攻击”，更重要的是通过合理配置，让网站在全球范围内获得更快的访问速度、更稳定的可用性以及更低的源站压力。

很多站长接入 Cloudflare 后，只是把域名 DNS 改过去，然后开启橙色云朵代理，认为这样就完成了优化。实际上，Cloudflare 的性能提升效果很大程度取决于配置是否合理。如果缓存策略、SSL、压缩、页面规则、Workers、图片优化等功能没有正确使用，网站可能提升有限，甚至出现缓存异常、登录失败、后台无法访问、静态资源加载慢等问题。

本文将从站长实战角度，系统讲解 Cloudflare 性能优化方法，适合 WordPress、Typecho、Discuz、Z-Blog、Laravel、静态博客、企业官网、跨境网站等站点参考。

一、Cloudflare 性能优化的核心思路

在开始具体配置前，站长需要先理解 Cloudflare 加速网站的基本原理。

用户访问网站时，正常流程是：

用户浏览器 → 源站服务器 → 返回网页内容

接入 Cloudflare 后，访问路径变为：

用户浏览器 → Cloudflare 边缘节点 → 源站服务器

如果资源已经缓存在 Cloudflare 边缘节点，访问路径可以进一步缩短为：

用户浏览器 → Cloudflare 边缘节点 → 直接返回缓存内容

因此，Cloudflare 优化的核心目标主要有三个：

1. 让更多静态资源命中缓存
   包括图片、CSS、JS、字体、视频封面等资源，减少源站请求。

2. 减少传输体积
   通过 Brotli、Gzip、图片压缩、代码压缩等方式降低页面体积。

3. 缩短连接与响应时间
   通过 HTTP/2、HTTP/3、TLS 优化、边缘缓存、智能路由等方式提升访问速度。

站长配置 Cloudflare 时，应该围绕这三个方向进行，而不是盲目开启所有功能。

二、接入 Cloudflare 前的准备工作

在正式优化之前，建议先检查源站基础环境。如果源站本身响应很慢，Cloudflare 可以缓解一部分压力，但不能完全替代服务器优化。

1. 确认源站运行正常

在接入 Cloudflare 前，建议先通过源站 IP 或临时域名访问网站，确认以下内容：

• 网站首页可以正常打开；
• 后台可以正常登录；
• 静态资源加载完整；
• HTTPS 证书有效；
• 数据库连接正常；
• 服务器没有明显高负载。

如果源站本身存在 500 错误、数据库慢查询、PHP 执行超时等问题，应优先处理源站问题。

2. 记录原 DNS 解析

接入 Cloudflare 会修改域名 NS 服务器，因此在修改前建议备份原 DNS 记录，包括：

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

尤其是企业邮箱用户，一定不要遗漏 MX 和 TXT 记录，否则可能导致邮件收发异常。

3. 确认证书模式

Cloudflare 的 SSL/TLS 模式非常重要，错误配置可能导致循环跳转或 HTTPS 异常。

推荐使用：

Full (strict)

也就是“完全（严格）”模式。

该模式要求源站也安装有效 SSL 证书。可以使用 Let’s Encrypt 免费证书，也可以使用 Cloudflare Origin Certificate 源站证书。

不建议长期使用：

Flexible

Flexible 模式是浏览器到 Cloudflare 使用 HTTPS，而 Cloudflare 到源站使用 HTTP。它容易导致后台跳转异常、WordPress 地址识别错误、Mixed Content 混合内容问题，不适合正式生产站点长期使用。

三、DNS 设置优化

Cloudflare 首先是 DNS 服务商。DNS 配置是否合理，会直接影响访问稳定性。

1. 开启橙色云朵代理

在 DNS 页面中，Cloudflare 的记录有两种状态：

• 橙色云朵：Proxied，经过 Cloudflare 代理；
• 灰色云朵：DNS only，仅 DNS 解析。

通常建议：

如果你的网站使用 www.example.com 作为主站，建议将根域名 example.com 301 跳转到 www.example.com，或者反过来统一到根域名，避免重复收录和缓存混乱。

2. 避免暴露源站 IP

很多站长接入 Cloudflare 后，虽然主站开启了代理，但某些子域名仍然指向源站 IP，例如：

ftp.example.com
panel.example.com
mail.example.com
origin.example.com

如果这些记录暴露源站 IP，攻击者仍可能绕过 Cloudflare 直接攻击源站。

建议：

• 管理面板使用独立域名并限制访问 IP；
• 邮件服务器和网站服务器尽量分离；
• 源站防火墙只允许 Cloudflare IP 段访问 80/443；
• 不在公开 DNS 中保留明显的 origin、server、admin 子域名。

四、SSL/TLS 性能优化

HTTPS 已经是网站标配。Cloudflare 提供了很多 SSL/TLS 优化选项，合理开启可以提升安全性和连接速度。

1. 使用 Full Strict 模式

路径：

Cloudflare 后台 → SSL/TLS → Overview

选择：

Full (strict)

这样浏览器到 Cloudflare、Cloudflare 到源站都是 HTTPS，并且会验证源站证书有效性。

2. 开启 Always Use HTTPS

路径：

SSL/TLS → Edge Certificates → Always Use HTTPS

开启后，所有 HTTP 请求都会自动跳转到 HTTPS。

注意：如果你已经在源站 Nginx、Apache 或 WordPress 插件中做了 HTTPS 跳转，也可以保留，但要避免多重跳转。最佳状态是一次 301 跳转完成。

3. 开启 HTTP Strict Transport Security

HSTS 可以让浏览器强制使用 HTTPS 访问网站，提高安全性。但开启前要确认：

• 全站 HTTPS 正常；
• 所有子域名都支持 HTTPS；
• 不再需要通过 HTTP 访问；
• 没有混合内容问题。

如果不确定，不建议一开始就设置过长时间。可以先设置较短时间，例如 1 个月，确认无问题后再延长。

4. 开启 TLS 1.3

路径：

SSL/TLS → Edge Certificates → TLS 1.3

建议开启。TLS 1.3 相比 TLS 1.2 握手更快，安全性也更好。

5. 开启 0-RTT 时谨慎

0-RTT 可以减少重复连接的握手时间，但对于涉及支付、提交表单、敏感操作的网站，需要谨慎开启，因为它存在重放请求风险。

普通博客、内容站、静态网站一般可以开启；电商、金融、会员系统建议慎重评估。

五、缓存策略优化

缓存是 Cloudflare 性能优化中最重要的部分。很多站点速度提升不明显，主要原因就是缓存命中率低。

1. 理解 Cloudflare 默认缓存规则

默认情况下，Cloudflare 会缓存常见静态资源，例如：

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

但默认不会缓存 HTML 页面。也就是说，用户访问文章页、首页、分类页时，Cloudflare 通常还是会回源请求源站。

对于 WordPress 等动态网站，这是合理的，因为 HTML 页面可能因登录状态、评论、购物车等因素变化。

但对于纯内容站、静态博客或不涉及用户登录的页面，可以考虑缓存 HTML，从而显著提升速度。

2. 设置 Browser Cache TTL

路径：

Caching → Configuration → Browser Cache TTL

建议设置为：

1 month

对于经常更新静态资源文件名的网站，可以设置更长，例如 6 个月或 1 年。

如果你的网站 CSS/JS 更新后文件名不变，缓存时间过长可能导致用户看到旧样式。因此建议采用文件版本号，例如：

style.css?v=20240601
main.js?v=1.2.3

或者使用构建工具生成带 hash 的文件名：

main.a8f3c9.js
style.92ab1.css

这样就可以放心设置较长缓存时间。

3. 设置 Edge Cache TTL

Edge Cache TTL 指 Cloudflare 边缘节点缓存资源的时间。

对于静态资源，建议设置：

1 month 或更长

对于 HTML 页面，如果是静态博客，可以设置：

1 hour 至 1 day

如果网站更新不频繁，也可以设置更长，但需要配合手动清缓存或自动清缓存。

4. 使用 Cache Rules 替代 Page Rules

Cloudflare 过去常用 Page Rules 配置缓存，现在更推荐使用 Cache Rules。

示例：缓存静态资源

规则条件：

URI Path ends with .jpg
or URI Path ends with .png
or URI Path ends with .css
or URI Path ends with .js
or URI Path ends with .webp

设置：

Cache eligibility: Eligible for cache
Edge TTL: 1 month
Browser TTL: 1 month

示例：绕过后台缓存

如果是 WordPress，需要排除：

/wp-admin/*
/wp-login.php
/wp-json/*

并且对登录用户绕过缓存，避免后台页面被缓存。

5. WordPress HTML 缓存建议

对于 WordPress 站点，如果你希望缓存 HTML 页面，可以使用以下方案：

• Cloudflare APO；
• Super Page Cache for Cloudflare；
• WP Rocket + Cloudflare；
• LiteSpeed Cache + Cloudflare；
• 自定义 Cache Rules。

如果是普通博客，推荐使用 Cloudflare APO 或 Super Page Cache for Cloudflare，配置简单，缓存命中率高。

但务必排除：

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

对于 WooCommerce 商城，不能简单全站缓存 HTML，否则可能出现购物车错乱、订单页面缓存、用户信息泄露等严重问题。

六、压缩与协议优化

1. 开启 Brotli

路径：

Speed → Optimization → Content Optimization → Brotli

建议开启。

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

• HTML；
• CSS；
• JavaScript；
• SVG；
• JSON。

相比 Gzip，Brotli 通常能进一步减少文件体积，提高加载速度。

2. 开启 HTTP/2 与 HTTP/3

Cloudflare 默认支持 HTTP/2，建议确认已开启。

HTTP/3 基于 QUIC 协议，在网络抖动、高延迟环境下表现更好，尤其适合移动端用户和跨地区访问。

路径：

Speed → Optimization → Protocol Optimization

建议开启：

HTTP/2
HTTP/3

3. 开启 IPv6 Compatibility

路径：

Network → IPv6 Compatibility

建议开启。这样即使源站没有 IPv6，用户也可以通过 Cloudflare 的 IPv6 网络访问网站。

4. WebSockets 视情况开启

如果网站使用在线聊天、实时通知、协作工具、WebSocket API，需要开启 WebSockets。

普通博客、内容站即使开启也通常没有影响。

七、前端资源优化

Cloudflare 提供了一些前端优化功能，但站长需要根据网站情况谨慎使用。

1. Auto Minify

路径：

Speed → Optimization → Content Optimization → Auto Minify

可以选择压缩：

• JavaScript；
• CSS；
• HTML。

对于大部分网站，CSS 和 HTML 压缩比较安全。JavaScript 压缩可能与某些主题、插件冲突，尤其是已经经过打包压缩的网站。

建议：

• 静态网站：可全部开启；
• WordPress：先开启 CSS/HTML，观察无问题后再尝试 JS；
• 电商网站：谨慎开启 JS 压缩，避免影响购物车和支付流程。

2. Rocket Loader 谨慎开启

Rocket Loader 可以异步加载 JavaScript，提高首屏速度，但也容易导致兼容问题，例如：

• 轮播图失效；
• 评论插件异常；
• 广告代码不加载；
• 统计代码延迟；
• 后台脚本冲突。

如果你的网站 JavaScript 较少，可以不开启。如果开启后出现页面交互异常，应立即关闭。

3. Early Hints

Early Hints 可以让浏览器提前加载部分资源，减少等待时间。

建议开启。它通常比较安全，适合大多数网站。

4. Fonts 字体优化

如果网站使用 Google Fonts，国内或部分地区访问可能较慢。建议：

• 改用本地托管字体；
• 使用系统字体栈；
• 减少字体数量和字重；
• 对字体文件开启长期缓存；
• 使用 font-display: swap 避免文字长时间不可见。

示例 CSS：

body {
  font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Arial, sans-serif;
}

对于中文网站，使用系统字体通常是性能最好的选择。

八、图片优化

图片通常是网页体积最大的部分。Cloudflare 对图片优化有多种方案。

1. 使用 WebP 或 AVIF

如果你的网站图片较多，建议将图片转换为 WebP 或 AVIF 格式。相比 JPG/PNG，WebP 和 AVIF 通常体积更小。

Cloudflare 付费功能 Polish 可以自动优化图片并转换格式。但如果你使用免费计划，也可以通过以下方式实现：

• WordPress 插件生成 WebP；
• 使用对象存储图片处理；
• 使用本地脚本批量转换；
• 使用图床 CDN。

2. 开启 Lazy Load

图片懒加载可以让页面首屏只加载可视区域图片，降低首屏资源压力。

WordPress 新版本已默认支持图片懒加载，也可以通过主题或插件增强。

示例：

3. 控制图片尺寸

很多网站上传 3000px 宽的大图，但页面实际只显示 800px，这会造成严重浪费。

建议：

• 文章正文图片宽度控制在 800px 至 1200px；
• 缩略图单独生成；
• 首页列表使用小图；
• 避免用原图作为缩略图；
• 图片压缩后再上传。

4. 设置图片长期缓存

图片文件通常更新频率低，适合设置较长缓存时间，例如：

Browser TTL: 1 month 或 1 year
Edge TTL: 1 month 或 1 year

如果图片被替换但文件名不变，用户可能看到旧图。因此建议图片更新时改变文件名。

九、页面规则与重定向优化

1. 统一 www 与非 www

站点应该只保留一个主域名版本。例如：

https://example.com

或：

https://www.example.com

不要两个都作为正式入口。

可以使用 Cloudflare Redirect Rules 实现：

条件：

Hostname equals www.example.com

目标：

https://example.com/$1

或者反过来将根域名跳转到 www。

统一域名有利于：

• SEO 权重集中；
• 减少重复内容；
• 减少缓存分散；
• 简化 Cookie 和登录状态。

2. 避免多重跳转

常见错误跳转链：

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

优化后应该尽量变成：

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

可以使用浏览器开发者工具或在线检测工具查看跳转链。跳转越多，首屏等待时间越长。

3. 后台和动态接口绕过缓存

无论使用什么 CMS，都应避免缓存后台、登录页、提交接口。例如：

/admin/*
/user/*
/login
/api/*
/wp-admin/*
/wp-login.php

同时，对于 POST 请求、带身份 Cookie 的请求，通常也应该绕过缓存。

十、安全设置对性能的影响

Cloudflare 的安全功能也会影响性能体验。安全等级过高可能导致用户频繁遇到验证页面，降低访问体验。

1. Security Level 设置

普通网站建议设置为：

Medium

如果正在遭受攻击，可以临时调高为：

High 或 Under Attack

但不建议长期使用 Under Attack 模式，因为它会让用户访问前看到验证页面，影响 SEO 和用户体验。

2. WAF 规则合理配置

Cloudflare WAF 可以拦截恶意请求，但误杀可能导致正常用户无法访问。

建议站长针对以下路径加强保护：

/wp-login.php
/wp-admin/*
/admin/*
/login

例如：

• 限制后台只允许特定国家或 IP；
• 对登录接口添加速率限制；
• 对异常 User-Agent 拦截；
• 对明显扫描路径拦截。

这样既能提高安全性，也能减少恶意请求对源站造成的压力。

3. Bot Fight Mode 谨慎开启

Bot Fight Mode 可以拦截机器人流量，但也可能影响搜索引擎、监控服务、API 客户端。

如果网站依赖搜索引擎收录，开启后应观察：

• Googlebot 是否正常抓取；
• Bingbot 是否正常抓取；
• 百度蜘蛛是否受到影响；
• 站长平台抓取诊断是否正常。

十一、源站配合优化

Cloudflare 不是万能的。想获得最佳性能，源站也需要配合优化。

1. 源站开启 Gzip 或 Brotli

即使 Cloudflare 可以压缩传输内容，源站也应该开启 Gzip 或 Brotli，以便回源时减少传输体积。

Nginx Gzip 示例：

gzip on;
gzip_comp_level 5;
gzip_min_length 1024;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml image/svg+xml;

2. 设置正确的 Cache-Control

Cloudflare 会参考源站响应头。建议静态资源设置：

Cache-Control: public, max-age=31536000

HTML 页面可以设置：

Cache-Control: public, max-age=3600

动态接口则设置：

Cache-Control: no-cache, no-store, must-revalidate

合理的响应头可以让浏览器和 Cloudflare 更准确地缓存资源。

3. 限制源站只允许 Cloudflare IP

为了防止绕过 CDN 攻击源站，可以在服务器防火墙中只允许 Cloudflare IP 访问 80 和 443 端口。

做法包括：

• 使用 iptables；
• 使用 firewalld；
• 使用安全组；
• 使用 Nginx allow/deny；
• 使用宝塔防火墙或云厂商防火墙。

注意：Cloudflare IP 段会更新，需要定期同步。否则可能误拦截正常流量。

4. 保留真实访客 IP

接入 Cloudflare 后，源站看到的访问 IP 默认可能是 Cloudflare 节点 IP。需要配置真实 IP。

Nginx 可通过 CF-Connecting-IP 获取真实 IP，并配合 Cloudflare IP 段设置。

如果不配置真实 IP，会导致：

• 日志统计不准确；
• 后台显示访问者都是 Cloudflare IP；
• 安全插件误判；
• 限速规则失效。

十二、如何检测优化效果

优化完成后，不要只凭感觉判断速度，需要使用工具检测。

1. 查看缓存命中情况

浏览器开发者工具中查看响应头：

CF-Cache-Status: HIT

常见状态说明：

如果静态资源长期是 MISS 或 DYNAMIC，说明缓存规则可能有问题。

2. 使用测速工具

推荐使用：

• PageSpeed Insights；
• GTmetrix；
• WebPageTest；
• Chrome Lighthouse；
• Pingdom；
• 站长工具测速；
• curl 命令测试响应头。

curl 示例：

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

重点关注：

• TTFB；
• 首屏加载时间；
• 总请求数；
• 页面总大小；
• 缓存命中率；
• 是否有阻塞资源；
• 图片是否过大。

3. 观察源站负载

如果 Cloudflare 缓存配置有效，源站负载应该明显下降，表现为：

• CPU 使用率降低；
• 带宽占用下降；
• PHP 请求减少；
• 数据库压力降低；
• Nginx/Apache 日志请求量减少。

如果访问量很大但源站压力没有下降，说明大量请求仍然回源，需要继续优化缓存策略。

十三、推荐配置方案

下面给出一个适合普通中文内容站、博客、企业官网的 Cloudflare 基础优化方案。

免费版推荐配置

SSL/TLS：Full (strict)
Always Use HTTPS：开启
TLS 1.3：开启
HTTP/2：开启
HTTP/3：开启
Brotli：开启
Auto Minify：开启 CSS、HTML，JS 视情况
Rocket Loader：默认关闭
Browser Cache TTL：1 month
静态资源 Edge TTL：1 month
后台路径：绕过缓存
Security Level：Medium
IPv6 Compatibility：开启
Early Hints：开启

WordPress 站点推荐

使用 Full strict SSL
安装缓存插件
静态资源长期缓存
后台和登录页绕过缓存
评论、搜索、预览页谨慎缓存
WooCommerce 页面绕过缓存
开启 Brotli
关闭 Rocket Loader 或谨慎测试
配置真实访客 IP

静态博客推荐

如果你的网站是 Hugo、Hexo、Jekyll、Astro、VuePress 等静态站点，可以更激进地缓存：

HTML Edge Cache TTL：1 day 至 1 month
静态资源 Edge Cache TTL：1 year
Browser Cache TTL：1 month 至 1 year
开启 Auto Minify
开启 Brotli
开启 HTTP/3
更新内容后手动或自动 Purge Cache

静态站点非常适合 Cloudflare，优化后全球访问速度通常会有明显提升。

十四、常见问题排查

1. 网站出现 522 错误

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

• 源站服务器宕机；
• 防火墙拦截 Cloudflare IP；
• 源站 80/443 端口未开放；
• 服务器负载过高；
• 安全组配置错误。

解决方法：

• 检查源站是否能直接访问；
• 放行 Cloudflare IP；
• 查看 Nginx/Apache 状态；
• 查看服务器负载；
• 检查云服务器安全组。

2. 网站出现 521 错误

521 表示源站拒绝连接。通常是源站 Web 服务未运行，或防火墙拒绝 Cloudflare 连接。

可以检查：

systemctl status nginx
systemctl status apache2

并确认服务器监听了 80/443 端口。

3. HTTPS 循环跳转

常见原因是使用 Flexible SSL，同时源站或程序强制 HTTPS。

解决方法：

• 将 SSL 模式改为 Full 或 Full strict；
• 源站安装有效证书；
• 检查 WordPress 站点地址是否为 HTTPS；
• 避免重复跳转规则。

4. 登录后台异常

如果后台被缓存，可能出现无法登录、验证码错误、后台显示旧页面等问题。

解决方法：

• 对后台路径设置 Bypass Cache；
• 对登录 Cookie 设置绕过缓存；
• 清理 Cloudflare 缓存；
• 清理浏览器缓存；
• 检查缓存插件规则。

5. CSS/JS 更新后不生效

原因通常是浏览器或 Cloudflare 缓存了旧文件。

解决方法：

• 修改文件版本号；
• 清理 Cloudflare 缓存；
• 使用带 hash 的文件名；
• 开发期间降低缓存时间。

十五、进阶优化方向

如果你的网站访问量较大，或者面向海外用户，可以继续考虑以下进阶方案。

1. Cloudflare Workers

Workers 可以在边缘节点运行 JavaScript 逻辑，用于：

• 边缘重定向；
• A/B 测试；
• 修改响应头；
• 简单 API；
• 缓存 HTML；
• 鉴权；
• 防盗链；
• 地区分流。

对于有开发能力的站长，Workers 是非常强大的性能优化工具。

2. Cloudflare APO

APO 即 Automatic Platform Optimization，主要面向 WordPress。它可以将 WordPress 页面缓存到 Cloudflare 边缘节点，显著降低 TTFB。

适合：

• 博客；
• 内容站；
• 新闻站；
• 文档站；
• 企业官网。

不太适合复杂商城和高度动态会员站，除非做好排除规则。

3. Argo Smart Routing

Argo 是付费功能，可以通过 Cloudflare 智能网络选择更快路径回源。对于跨国访问、源站在海外、用户分布全球的网站，Argo 可能有明显效果。

但对于访问者和源站都在同一区域的网站，收益不一定明显。

4. R2 与对象存储

如果网站图片、附件、下载文件较多，可以考虑将静态资源迁移到对象存储，例如：

• Cloudflare R2；
• AWS S3；
• Backblaze B2；
• 阿里云 OSS；
• 腾讯云 COS。

再通过 Cloudflare CDN 分发，可以降低源站压力，提高静态资源加载速度。

结语

Cloudflare 的性能优化不是简单地“开启 CDN”就完成了，而是一个围绕缓存、压缩、协议、安全、源站配合的系统工程。对于大多数站长来说，最关键的优化点包括：使用 Full strict SSL、开启 Brotli 和 HTTP/3、正确设置静态资源缓存、绕过后台和动态接口、统一域名跳转、配置真实访客 IP，并通过响应头持续检查缓存命中率。

如果你的网站是普通博客、内容站或企业官网，合理配置后通常可以明显降低 TTFB、减少源站压力、提升全球访问速度。如果你的网站是电商、会员系统或 API 服务，则需要更加谨慎地处理 HTML 缓存和登录状态，避免因为过度缓存导致数据错乱。

总之，Cloudflare 是一套强大的边缘网络工具。站长真正需要做的，不是把所有功能都打开，而是根据网站类型选择合适的策略：静态内容尽量缓存，动态内容谨慎绕过，安全规则精准设置，源站环境持续优化。这样才能让 Cloudflare 发挥最大的性能价值。