站长实测:用 Cloudflare 搞定加速、防护与源站优化
Cloudflare 实战案例分享|适合站长
对于很多个人站长、中小企业网站运营者来说,网站上线之后最常遇到的几个问题通常是:访问速度不稳定、海外用户打开慢、被恶意扫描或攻击、服务器带宽被刷爆、HTTPS 配置麻烦、图片和静态资源加载慢、搜索引擎抓取压力大等。
Cloudflare 作为全球知名的 CDN、DNS、WAF 与网络安全服务平台,几乎可以覆盖站长日常运维中的大部分基础需求。它既适合个人博客,也适合内容站、工具站、资源站、跨境电商站、SaaS 官网和企业门户站。更重要的是,Cloudflare 提供了相当可用的免费套餐,对于预算有限的站长来说非常友好。
本文将以“实战案例”的方式,分享站长如何使用 Cloudflare 提升网站访问速度、安全性和稳定性,并结合常见问题给出可落地的配置建议。
一、为什么站长需要 Cloudflare?
很多站长最初接触 Cloudflare,通常是因为以下几个需求:
- 想给网站套一层 CDN
- 想隐藏源站 IP
- 想免费配置 HTTPS
- 想防止恶意爬虫和 CC 攻击
- 想让海外用户访问更快
- 想减少服务器带宽消耗
- 想用更稳定、更快的 DNS 解析
- 想做页面规则、缓存规则和跳转规则
Cloudflare 的优势在于,它不是单纯的 CDN,而是一个完整的边缘网络服务平台。站长只需要把域名 DNS 接入 Cloudflare,就可以逐步启用 CDN 缓存、安全防护、访问规则、Bot 管理、页面规则、Zero Trust、Workers、R2 对象存储等功能。
对于不想复杂折腾服务器的站长来说,Cloudflare 可以说是一个“低成本提升网站基础设施能力”的工具。
二、实战案例背景:一个个人内容站的优化过程
这里以一个典型的内容站为例。
假设我们有一个中文内容网站,主要面向国内和海外华人用户,网站程序使用 WordPress,服务器部署在新加坡,配置为 2 核 2G,月流量有限。上线一段时间后,站长遇到了以下问题:
- 国内部分地区访问速度不稳定;
- 海外访问还可以,但高峰期页面加载明显变慢;
- 每天有大量恶意扫描请求,例如访问
/wp-admin、/xmlrpc.php、/wp-login.php; - 图片较多,服务器带宽消耗明显;
- 搜索引擎蜘蛛抓取较频繁,导致 CPU 偶尔飙高;
- 网站偶尔出现异常请求,疑似被 CC 攻击;
- SSL 证书需要定期维护,比较麻烦。
这个案例非常常见,很多个人博客、资源站、教程站、测评站都会遇到类似情况。下面我们就按照实际操作流程,看看如何用 Cloudflare 逐步优化。
三、第一步:将域名 DNS 接入 Cloudflare
接入 Cloudflare 的核心步骤是修改域名的 NS 服务器。
一般流程如下:
- 注册或登录 Cloudflare 账号;
- 点击 “Add a site” 添加网站域名;
- 选择套餐,个人站通常选择 Free 即可;
- Cloudflare 自动扫描当前 DNS 记录;
- 检查 A 记录、CNAME、MX、TXT 等记录是否正确;
- 根据 Cloudflare 提示,去域名注册商后台修改 NS;
- 等待 DNS 生效。
例如原来域名注册商提供的 NS 可能是:
ns1.example-dns.com
ns2.example-dns.com
接入 Cloudflare 后,需要改为类似:
maria.ns.cloudflare.com
tom.ns.cloudflare.com
修改完成后,等待几分钟到数小时不等,Cloudflare 后台会显示域名已激活。
注意事项
接入 Cloudflare 时,站长一定要仔细检查 DNS 记录,尤其是以下几类:
| 记录类型 | 用途 | 是否建议代理 |
|---|---|---|
| A 记录 | 指向源站 IP | 网站主域名建议开启代理 |
| CNAME | 指向其他域名 | 视情况开启 |
| MX | 邮箱服务 | 不要开启代理 |
| TXT | 验证、SPF、DKIM | 不涉及代理 |
| FTP | FTP 连接 | 通常不要开启代理 |
| API 子域名 | 接口服务 | 根据业务决定 |
Cloudflare 中橙色云朵表示开启代理,灰色云朵表示仅 DNS 解析。
对于网站访问域名,例如:
example.com
www.example.com
建议开启橙色云朵代理。这样流量会经过 Cloudflare,才能使用 CDN、安全防护和缓存能力。
对于邮箱相关记录,例如:
mail.example.com
通常不要开启代理,否则可能影响邮件收发。
四、第二步:配置 SSL/TLS,解决 HTTPS 问题
接入 Cloudflare 后,很多站长最关心的是 HTTPS 怎么配置。
Cloudflare 的 SSL/TLS 模式主要有以下几种:
| 模式 | 说明 | 推荐程度 |
|---|---|---|
| Off | 不启用 HTTPS | 不推荐 |
| Flexible | 用户到 Cloudflare 是 HTTPS,Cloudflare 到源站是 HTTP | 不推荐长期使用 |
| Full | 用户到 Cloudflare 是 HTTPS,Cloudflare 到源站也是 HTTPS,但不严格校验证书 | 可用 |
| Full Strict | 全链路 HTTPS,并严格校验证书 | 强烈推荐 |
很多新手站长会选择 Flexible,但这很容易导致 WordPress 出现跳转循环、后台异常、Mixed Content 等问题。更推荐的方式是使用 Full Strict。
推荐配置方案
- 在源站服务器配置有效 SSL 证书;
- 可以使用 Let’s Encrypt 免费证书;
- 也可以使用 Cloudflare Origin Certificate;
- Cloudflare 后台 SSL/TLS 模式选择 Full Strict;
- 开启 Always Use HTTPS;
- 开启 Automatic HTTPS Rewrites。
Cloudflare Origin Certificate 的优点是证书有效期很长,适合源站只对 Cloudflare 提供 HTTPS 连接的场景。但需要注意,这种证书只被 Cloudflare 信任,普通浏览器直接访问源站 IP 时不会信任。
WordPress 站点注意
如果 WordPress 后台出现 HTTPS 跳转异常,可以检查:
- 网站地址是否设置为
https://; - Nginx 或 Apache 是否正确识别反向代理头;
- 是否需要添加
CF-Visitor或X-Forwarded-Proto判断; - 是否安装了多余的 SSL 插件造成冲突。
对于 WordPress,建议在 Nginx 中确保传递以下头部:
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
如果使用 Cloudflare 后源站日志中全部显示 Cloudflare IP,还需要配置真实 IP 回源识别。
五、第三步:开启 CDN 缓存,减轻服务器压力
Cloudflare 最核心的能力之一就是缓存静态资源。默认情况下,Cloudflare 会缓存常见静态资源,例如:
- 图片:jpg、png、gif、webp、svg;
- CSS 文件;
- JavaScript 文件;
- 字体文件;
- 部分媒体资源。
对于内容站来说,图片和静态资源通常占据了大部分带宽。如果静态资源能从 Cloudflare 边缘节点返回,就可以明显降低源站压力。
推荐缓存设置
在 Cloudflare 后台可以配置:
- Browser Cache TTL:建议设置为 4 小时到 1 天;
- Cache Level:Standard;
- Always Online:可开启;
- Brotli:建议开启;
- Early Hints:可开启;
- HTTP/2:开启;
- HTTP/3:开启。
如果网站静态资源更新不频繁,可以适当增加缓存时间。例如:
图片、字体文件:缓存 7 天到 30 天
CSS、JS 文件:缓存 1 天到 7 天
HTML 页面:根据业务决定
是否缓存 HTML?
这是很多站长纠结的问题。
默认情况下,Cloudflare 不会缓存 HTML 页面。对于普通 WordPress 博客,如果启用“Cache Everything”缓存整页,确实可以大幅提升速度,但也可能带来问题,例如:
- 登录用户看到缓存页面;
- 评论提交后页面不刷新;
- 后台页面被缓存;
- 电商购物车异常;
- 个性化内容显示错误。
因此,是否缓存 HTML 要看网站类型。
对于纯内容站、静态博客、文档站,可以考虑缓存 HTML。
对于会员站、电商站、论坛站,不建议全站缓存 HTML,除非做了细致的绕过规则。
内容站页面缓存规则示例
可以设置缓存规则:
如果 URL 包含 example.com/*
并且不包含 /wp-admin/*
并且不包含 /wp-login.php
并且 Cookie 不包含 wordpress_logged_in
则 Cache Everything
同时设置:
Edge Cache TTL:1 小时或 4 小时
Browser Cache TTL:不强制或较短
这样访客访问文章页时,Cloudflare 可以直接返回缓存页面,源站压力会明显下降。
六、第四步:隐藏源站 IP,降低被攻击风险
很多站长接入 Cloudflare 的目的之一,是隐藏服务器真实 IP。
如果攻击者不知道源站 IP,就只能攻击 Cloudflare 前端,而 Cloudflare 拥有较强的抗攻击能力。对于普通站点来说,这已经可以阻挡大量低成本攻击。
如何避免源站 IP 暴露?
以下几点非常重要:
- 网站主域名开启 Cloudflare 代理;
- 不要在 DNS 记录中暴露源站 IP;
- 邮箱服务尽量不要和网站源站共用 IP;
- 不要使用容易暴露 IP 的子域名,例如
origin.example.com; - 检查历史 DNS 解析记录;
- 源站防火墙只允许 Cloudflare IP 访问 80/443;
- 避免程序主动泄露服务器 IP;
- 避免通过邮件头、报错信息暴露 IP。
最关键的一步是:源站防火墙只允许 Cloudflare IP 访问网站端口。
如果攻击者已经知道了源站 IP,即使你接入 Cloudflare,他仍然可以绕过 Cloudflare 直接攻击源站。因此建议在服务器上配置防火墙,只放行 Cloudflare 的 IP 段。
Nginx 配合防火墙示例思路
可以通过系统防火墙、云服务器安全组、iptables、ufw 等方式限制访问。
例如:
ufw allow from to any port 443
ufw allow from to any port 80
ufw deny 80
ufw deny 443
实际配置时,需要从 Cloudflare 官方文档获取最新 IP 段,不建议复制过期列表。
七、第五步:使用 WAF 规则拦截恶意请求
Cloudflare 的 WAF 是站长非常值得使用的功能。即使是免费套餐,也可以配置基础安全规则,拦截常见恶意请求。
对于 WordPress 站点,最常见的攻击路径包括:
/wp-login.php
/wp-admin/
/xmlrpc.php
/wp-content/plugins/
/wp-content/themes/
其中 /xmlrpc.php 经常被用于暴力破解和恶意请求。如果网站不需要 XML-RPC 功能,建议直接拦截。
示例规则一:拦截 XML-RPC
规则条件:
URI Path equals /xmlrpc.php
动作:
Block
这样可以减少大量无意义请求。
示例规则二:保护 WordPress 登录页
如果你的网站后台只有自己访问,可以设置规则:
URI Path equals /wp-login.php
并且 国家/地区 不等于你的常用访问地区
动作:
Managed Challenge
或者更严格一点:
URI Path equals /wp-login.php
并且 IP 不在你的白名单
动作:
Block
这样可以明显减少后台暴力破解。
示例规则三:拦截异常 User-Agent
很多低质量爬虫会使用明显异常的 User-Agent,例如为空、伪造工具名、扫描器标识等。
可以针对以下请求进行挑战或阻断:
User-Agent 为空
User-Agent 包含 python-requests
User-Agent 包含 curl
User-Agent 包含 sqlmap
User-Agent 包含 masscan
User-Agent 包含 zgrab
动作可以选择:
Managed Challenge
不建议一开始全部 Block,因为有些正常服务也可能使用 curl 或程序化请求。更稳妥的做法是先观察日志,再逐步收紧。
八、第六步:应对 CC 攻击和异常流量
对于个人站长来说,最头疼的不是大型 DDoS,而是低成本 CC 攻击。攻击者可能使用大量代理 IP 反复请求动态页面,造成源站 CPU 和数据库压力飙升。
Cloudflare 可以通过以下方式缓解:
- 开启 Under Attack Mode;
- 设置 Rate Limiting;
- 使用 WAF Challenge;
- 缓存可缓存页面;
- 限制敏感路径访问;
- 根据国家、ASN、IP 段进行拦截;
- 使用 Bot Fight Mode;
- 分析 Security Events 日志。
Under Attack Mode 适合什么时候用?
当网站突然遭遇异常访问,源站开始变慢,后台日志出现大量请求时,可以临时开启:
Under Attack Mode
开启后,访客访问网站时会看到 Cloudflare 的浏览器验证页面。这个模式不适合长期使用,因为会影响用户体验,但在紧急情况下非常有效。
Rate Limiting 使用思路
如果发现某些路径被频繁请求,例如:
/search
/api
/wp-login.php
/comment
可以设置请求频率限制。
例如:
同一 IP 在 10 秒内请求 /wp-login.php 超过 5 次
则 Managed Challenge 或 Block
对于搜索页,也可以设置:
同一 IP 在 60 秒内请求 /search 超过 30 次
则 Challenge
这样可以防止恶意请求拖垮数据库。
九、第七步:优化图片和静态资源加载
图片是很多内容站最大的性能瓶颈。Cloudflare 在图片优化方面提供了多种能力,不过部分功能需要付费,例如 Polish、Mirage、Images 等。
即使不使用付费功能,站长也可以通过以下方式优化:
- 使用 WebP 图片;
- 开启 Brotli 压缩;
- 设置合理的缓存 TTL;
- 图片文件名版本化;
- 使用懒加载;
- 减少第三方脚本;
- 合并或延迟加载非关键 JS;
- 避免首屏加载过多大图。
如果你的网站使用 WordPress,可以搭配缓存插件,例如:
- WP Rocket;
- LiteSpeed Cache;
- W3 Total Cache;
- Autoptimize;
- Perfmatters。
但需要注意,插件不要叠加过多。很多站点速度变慢,不是因为没有优化,而是因为优化插件之间互相冲突。
推荐组合
对于 WordPress 内容站,一个比较稳妥的组合是:
Cloudflare CDN + LiteSpeed Cache 或 WP Rocket + WebP 图片 + 懒加载 + 合理缓存规则
如果服务器使用 LiteSpeed Web Server,那么 LiteSpeed Cache 插件效果很好。
如果使用 Nginx,也可以选择 WP Rocket 或其他缓存插件。
十、第八步:使用 Page Rules 或 Rules 做跳转与缓存
Cloudflare 早期常用 Page Rules,现在新的 Rules 功能更灵活。站长可以用它完成很多实用操作。
常见需求一:HTTP 跳转 HTTPS
虽然可以开启 Always Use HTTPS,但也可以通过规则实现:
http://example.com/*
转向
https://example.com/$1
常见需求二:裸域跳转 www
如果你希望统一使用 www.example.com,可以配置:
example.com/*
301 跳转到
https://www.example.com/$1
反过来也可以将 www 跳转到裸域。
常见需求三:后台不缓存
对于 WordPress 后台,必须绕过缓存:
*example.com/wp-admin/*
Cache Level: Bypass
登录页也建议绕过:
*example.com/wp-login.php*
Cache Level: Bypass
常见需求四:静态资源长缓存
例如:
*example.com/wp-content/uploads/*
Cache TTL: 30 days
这样可以减少图片资源回源。
十一、第九步:利用 Cloudflare Analytics 分析网站问题
Cloudflare 的分析数据对站长非常有价值。它不仅能看访问量,还能看到很多服务器日志中不容易直观看到的信息。
常用分析维度包括:
- 请求数量;
- 缓存命中率;
- 带宽节省;
- 威胁请求数量;
- 来源国家和地区;
- HTTP 状态码;
- Bot 请求;
- WAF 命中记录;
- DNS 查询情况;
- 性能指标。
重点关注缓存命中率
对于内容站来说,缓存命中率是一个重要指标。
如果 Cache Hit Ratio 很低,可能说明:
- 网站大部分请求是动态页面;
- 静态资源 URL 带有随机参数;
- 缓存规则没有配置好;
- 请求携带 Cookie 导致不缓存;
- 资源过期时间太短;
- HTML 没有启用边缘缓存。
一般来说,如果是图片较多的内容站,缓存命中率应该逐步提升。如果长期低于 20%,说明 Cloudflare 的 CDN 优势没有发挥出来。
关注 4xx 和 5xx 状态码
如果 403 很多,说明 WAF 或访问规则较严格,也可能有大量攻击请求。
如果 404 很多,可能是恶意扫描,也可能是站内死链。
如果 520、521、522 较多,通常说明 Cloudflare 与源站之间连接异常。
常见含义如下:
| 状态码 | 常见原因 |
|---|---|
| 520 | 源站返回异常 |
| 521 | 源站拒绝连接 |
| 522 | Cloudflare 连接源站超时 |
| 523 | 无法连接源站 |
| 524 | 源站响应超时 |
| 525 | SSL 握手失败 |
| 526 | SSL 证书验证失败 |
如果出现这些错误,不要只盯着 Cloudflare,也要检查源站服务器、Nginx、PHP-FPM、数据库、SSL 证书和防火墙。
十二、第十步:源站真实 IP 获取与日志分析
接入 Cloudflare 后,源站看到的访问 IP 通常是 Cloudflare 节点 IP,而不是访客真实 IP。如果不处理,日志分析和安全策略都会受到影响。
Nginx 获取真实 IP
可以使用 Nginx 的 real_ip 模块,配置 Cloudflare 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 列表。
配置后,Nginx 日志中就可以记录访客真实 IP,便于分析异常访问。
为什么这一步重要?
因为如果不恢复真实 IP,所有访客都像是来自 Cloudflare。这样会导致:
- Fail2ban 判断失效;
- 访问统计不准确;
- 登录安全策略异常;
- 后台 IP 白名单无法正确工作;
- 程序限流逻辑失效;
- 日志排查困难。
对于有一定运维能力的站长,这一步强烈建议配置。
十三、常见问题与解决方案
1. 接入 Cloudflare 后网站打不开怎么办?
优先检查:
- DNS 记录是否正确;
- A 记录是否指向源站 IP;
- 是否开启了橙色云朵;
- 源站是否允许 Cloudflare IP 访问;
- SSL/TLS 模式是否正确;
- Nginx/Apache 是否正常;
- 源站防火墙是否误拦截。
如果出现 521,通常是源站拒绝连接。
如果出现 522,通常是源站响应超时。
如果出现 526,多半是 Full Strict 下源站证书无效。
2. WordPress 后台无法登录怎么办?
可能原因:
- 登录页被 WAF 误拦截;
- 缓存了登录页面;
- SSL 模式配置错误;
- 安全插件与 Cloudflare 冲突;
- 真实 IP 获取异常;
- Cookie 被缓存规则影响。
解决方案是:
- 对
/wp-admin/*和/wp-login.php设置 Bypass Cache; - 检查 WAF 日志;
- 暂时关闭可疑安全规则;
- 确保 WordPress 地址是 HTTPS;
- 不要对后台页面启用 Cache Everything。
3. 开启 Cloudflare 后国内访问一定更快吗?
不一定。
Cloudflare 免费版在全球范围内表现不错,但国内访问速度受到网络环境、运营商线路、节点调度等因素影响。对于主要面向中国大陆用户的网站,如果追求极致速度,可能需要国内 CDN 或备案支持。
但对于以下网站,Cloudflare 仍然很有价值:
- 海外服务器网站;
- 面向全球用户的网站;
- 个人博客;
- 外贸站;
- 技术文档站;
- 跨境电商站;
- 不方便备案的网站;
- 需要安全防护的网站。
4. Cloudflare 会影响 SEO 吗?
正确配置下,Cloudflare 通常不会影响 SEO,反而可能提升网站稳定性和速度,对 SEO 有帮助。
需要注意:
- 不要误拦截搜索引擎蜘蛛;
- 不要频繁出现 5xx 错误;
- 不要错误缓存过期页面;
- 不要让 HTTPS 跳转混乱;
- 不要启用过于严格的挑战模式影响爬虫;
- 保持站点地图和 robots.txt 可访问。
如果配置 WAF,一定要观察是否误伤 Googlebot、Bingbot、百度蜘蛛等搜索引擎爬虫。
十四、适合站长的 Cloudflare 推荐配置清单
下面给出一个相对通用的配置清单,适合大多数个人站长和中小网站参考。
DNS
- 网站主域名开启代理;
- 邮箱记录不要代理;
- 删除无用子域名;
- 避免暴露源站 IP;
- 定期检查 DNS 记录。
SSL/TLS
- 使用 Full Strict;
- 源站配置有效证书;
- 开启 Always Use HTTPS;
- 开启 Automatic HTTPS Rewrites;
- 避免使用 Flexible 作为长期方案。
缓存
- 开启 Brotli;
- 静态资源设置较长缓存;
- 后台、登录页、接口页绕过缓存;
- 内容站可谨慎启用 HTML 缓存;
- 定期观察缓存命中率。
安全
- 开启 WAF 基础规则;
- 拦截
/xmlrpc.php; - 保护登录页;
- 对异常 User-Agent 做挑战;
- 遭遇攻击时临时开启 Under Attack Mode;
- 源站只允许 Cloudflare IP 访问。
性能
- 开启 HTTP/2 和 HTTP/3;
- 减少第三方脚本;
- 图片使用 WebP;
- 启用懒加载;
- 配合本地缓存插件;
- 优化数据库和源站性能。
监控
- 定期查看 Analytics;
- 关注 5xx 错误;
- 关注 WAF 命中记录;
- 关注缓存命中率;
- 关注异常国家和 ASN 流量;
- 保留源站日志,方便排查问题。
十五、实战效果总结
以上案例经过 Cloudflare 优化后,通常可以获得以下效果:
-
静态资源加载更快
图片、CSS、JS 等资源由 Cloudflare 边缘节点缓存返回,减少源站带宽消耗。 -
源站压力明显下降
通过缓存和 WAF 拦截,大量无效请求不再进入服务器。 -
安全性提升
恶意扫描、暴力破解、异常爬虫和部分 CC 攻击可以在边缘层被拦截。 -
HTTPS 管理更方便
使用 Full Strict 后,全链路加密更安全,也减少证书配置混乱。 -
源站 IP 更难暴露
配合防火墙策略后,攻击者更难绕过 Cloudflare 直连源站。 -
故障排查更清晰
通过 Cloudflare Analytics 和 Security Events,可以更快判断异常流量来源。
当然,Cloudflare 不是万能的。它不能替代良好的服务器配置、程序优化、数据库优化和安全开发习惯。如果源站本身代码效率很低、数据库查询混乱、插件过多,即使接入 Cloudflare,也只能缓解问题,不能彻底解决。
十六、写给站长的建议
对于站长来说,Cloudflare 最值得学习的地方不是“套个 CDN”这么简单,而是建立一套完整的网站边缘防护与性能优化思路。
建议你按照以下顺序逐步配置:
- 先接入 DNS;
- 再配置 SSL/TLS;
- 然后开启基础缓存;
- 接着配置 WAF 防护;
- 再处理真实 IP;
- 最后根据数据优化规则。
不要一开始就启用大量复杂规则,也不要盲目照搬别人的配置。每个网站的程序、用户来源、访问路径、缓存需求都不一样。最稳妥的方式是:先观察,再配置;先温和挑战,再严格拦截;先保证可用,再追求极致优化。
如果你是个人博客站长,Cloudflare 免费版已经足够完成基础加速、安全防护和 HTTPS 管理。
如果你是外贸站、跨境业务站或高流量内容站,可以进一步考虑 Pro、Business 套餐,使用更强的 WAF、图片优化、优先节点和高级规则。
总的来说,Cloudflare 是站长工具箱中非常值得长期使用的一项基础设施服务。合理配置后,它不仅能让网站更快、更稳,也能让站长从大量无效攻击、证书维护和带宽压力中解放出来,把更多精力放在内容、产品和用户体验上。