上一篇 下一篇 分享链接 返回 返回顶部

站长实测:用 Cloudflare 搞定加速、防护与源站优化

发布人:慈云数据-客服中心 发布时间:14小时前 阅读量:5

Cloudflare 实战案例分享|适合站长

对于很多个人站长、中小企业网站运营者来说,网站上线之后最常遇到的几个问题通常是:访问速度不稳定、海外用户打开慢、被恶意扫描或攻击、服务器带宽被刷爆、HTTPS 配置麻烦、图片和静态资源加载慢、搜索引擎抓取压力大等。

Cloudflare 作为全球知名的 CDN、DNS、WAF 与网络安全服务平台,几乎可以覆盖站长日常运维中的大部分基础需求。它既适合个人博客,也适合内容站、工具站、资源站、跨境电商站、SaaS 官网和企业门户站。更重要的是,Cloudflare 提供了相当可用的免费套餐,对于预算有限的站长来说非常友好。

本文将以“实战案例”的方式,分享站长如何使用 Cloudflare 提升网站访问速度、安全性和稳定性,并结合常见问题给出可落地的配置建议。


一、为什么站长需要 Cloudflare?

很多站长最初接触 Cloudflare,通常是因为以下几个需求:

  1. 想给网站套一层 CDN
  2. 想隐藏源站 IP
  3. 想免费配置 HTTPS
  4. 想防止恶意爬虫和 CC 攻击
  5. 想让海外用户访问更快
  6. 想减少服务器带宽消耗
  7. 想用更稳定、更快的 DNS 解析
  8. 想做页面规则、缓存规则和跳转规则

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 服务器。

一般流程如下:

  1. 注册或登录 Cloudflare 账号;
  2. 点击 “Add a site” 添加网站域名;
  3. 选择套餐,个人站通常选择 Free 即可;
  4. Cloudflare 自动扫描当前 DNS 记录;
  5. 检查 A 记录、CNAME、MX、TXT 等记录是否正确;
  6. 根据 Cloudflare 提示,去域名注册商后台修改 NS;
  7. 等待 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

推荐配置方案

  1. 在源站服务器配置有效 SSL 证书;
  2. 可以使用 Let’s Encrypt 免费证书;
  3. 也可以使用 Cloudflare Origin Certificate;
  4. Cloudflare 后台 SSL/TLS 模式选择 Full Strict;
  5. 开启 Always Use HTTPS;
  6. 开启 Automatic HTTPS Rewrites。

Cloudflare Origin Certificate 的优点是证书有效期很长,适合源站只对 Cloudflare 提供 HTTPS 连接的场景。但需要注意,这种证书只被 Cloudflare 信任,普通浏览器直接访问源站 IP 时不会信任。

WordPress 站点注意

如果 WordPress 后台出现 HTTPS 跳转异常,可以检查:

  • 网站地址是否设置为 https://
  • Nginx 或 Apache 是否正确识别反向代理头;
  • 是否需要添加 CF-VisitorX-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 暴露?

以下几点非常重要:

  1. 网站主域名开启 Cloudflare 代理;
  2. 不要在 DNS 记录中暴露源站 IP;
  3. 邮箱服务尽量不要和网站源站共用 IP;
  4. 不要使用容易暴露 IP 的子域名,例如 origin.example.com
  5. 检查历史 DNS 解析记录;
  6. 源站防火墙只允许 Cloudflare IP 访问 80/443;
  7. 避免程序主动泄露服务器 IP;
  8. 避免通过邮件头、报错信息暴露 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 可以通过以下方式缓解:

  1. 开启 Under Attack Mode;
  2. 设置 Rate Limiting;
  3. 使用 WAF Challenge;
  4. 缓存可缓存页面;
  5. 限制敏感路径访问;
  6. 根据国家、ASN、IP 段进行拦截;
  7. 使用 Bot Fight Mode;
  8. 分析 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 等。

即使不使用付费功能,站长也可以通过以下方式优化:

  1. 使用 WebP 图片;
  2. 开启 Brotli 压缩;
  3. 设置合理的缓存 TTL;
  4. 图片文件名版本化;
  5. 使用懒加载;
  6. 减少第三方脚本;
  7. 合并或延迟加载非关键 JS;
  8. 避免首屏加载过多大图。

如果你的网站使用 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 很低,可能说明:

  1. 网站大部分请求是动态页面;
  2. 静态资源 URL 带有随机参数;
  3. 缓存规则没有配置好;
  4. 请求携带 Cookie 导致不缓存;
  5. 资源过期时间太短;
  6. 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 优化后,通常可以获得以下效果:

  1. 静态资源加载更快
    图片、CSS、JS 等资源由 Cloudflare 边缘节点缓存返回,减少源站带宽消耗。

  2. 源站压力明显下降
    通过缓存和 WAF 拦截,大量无效请求不再进入服务器。

  3. 安全性提升
    恶意扫描、暴力破解、异常爬虫和部分 CC 攻击可以在边缘层被拦截。

  4. HTTPS 管理更方便
    使用 Full Strict 后,全链路加密更安全,也减少证书配置混乱。

  5. 源站 IP 更难暴露
    配合防火墙策略后,攻击者更难绕过 Cloudflare 直连源站。

  6. 故障排查更清晰
    通过 Cloudflare Analytics 和 Security Events,可以更快判断异常流量来源。

当然,Cloudflare 不是万能的。它不能替代良好的服务器配置、程序优化、数据库优化和安全开发习惯。如果源站本身代码效率很低、数据库查询混乱、插件过多,即使接入 Cloudflare,也只能缓解问题,不能彻底解决。


十六、写给站长的建议

对于站长来说,Cloudflare 最值得学习的地方不是“套个 CDN”这么简单,而是建立一套完整的网站边缘防护与性能优化思路。

建议你按照以下顺序逐步配置:

  1. 先接入 DNS;
  2. 再配置 SSL/TLS;
  3. 然后开启基础缓存;
  4. 接着配置 WAF 防护;
  5. 再处理真实 IP;
  6. 最后根据数据优化规则。

不要一开始就启用大量复杂规则,也不要盲目照搬别人的配置。每个网站的程序、用户来源、访问路径、缓存需求都不一样。最稳妥的方式是:先观察,再配置;先温和挑战,再严格拦截;先保证可用,再追求极致优化。

如果你是个人博客站长,Cloudflare 免费版已经足够完成基础加速、安全防护和 HTTPS 管理。
如果你是外贸站、跨境业务站或高流量内容站,可以进一步考虑 Pro、Business 套餐,使用更强的 WAF、图片优化、优先节点和高级规则。

总的来说,Cloudflare 是站长工具箱中非常值得长期使用的一项基础设施服务。合理配置后,它不仅能让网站更快、更稳,也能让站长从大量无效攻击、证书维护和带宽压力中解放出来,把更多精力放在内容、产品和用户体验上。

目录结构
全文