Cloudflare 最新漏洞修复教程｜适合站长

本文面向使用 Cloudflare 进行 DNS 解析、CDN 加速、WAF 防护、SSL/TLS 证书管理、Zero Trust 或 Workers 的站长。由于 Cloudflare 属于云端安全与网络服务平台，所谓“Cloudflare 漏洞”通常并不一定只发生在 Cloudflare 官方基础设施中，也可能出现在站点配置不当、源站暴露、错误的 SSL 模式、缓存规则疏漏、API Token 泄露、Workers 代码缺陷、DNS 解析设置错误等环节。

因此，本文将以“站长可执行的修复教程”为核心，帮助你快速完成风险排查、漏洞修复、配置加固和后续监控。

一、为什么站长需要关注 Cloudflare 相关漏洞？

很多站长认为网站接入 Cloudflare 后，就已经“自动安全”了。实际上，Cloudflare 确实能提供非常强大的安全能力，例如：

• 隐藏源站 IP；
• 提供 DDoS 防护；
• 使用 WAF 拦截常见攻击；
• 提供 Bot 管理能力；
• 支持 SSL/TLS 加密；
• 提供访问规则、速率限制、缓存规则；
• 可通过 Zero Trust 保护后台管理入口。

但 Cloudflare 并不是“万能盾牌”。如果配置不当，攻击者仍然可能绕过 Cloudflare 直接攻击源站，或者利用站点本身的漏洞进行入侵。

常见问题包括：

1. 源站真实 IP 暴露
2. SSL/TLS 模式设置错误
3. DNS 记录未开启代理
4. 后台地址未做访问控制
5. WAF 规则过于宽松
6. 缓存规则导致敏感数据泄露
7. API Token 权限过大或泄露
8. Workers / Pages 项目存在代码安全问题
9. Cloudflare 账户未开启双因素认证
10. 源站防火墙未限制 Cloudflare IP 段访问

很多网站被攻击，并不是 Cloudflare 被攻破，而是站长没有正确使用 Cloudflare。

二、修复前准备：先确认问题类型

在正式修复之前，建议先判断当前风险属于哪一类。

1. 官方安全漏洞

如果 Cloudflare 官方发布安全公告，说明某个产品或服务存在漏洞，你需要根据官方公告进行处理。

你应关注以下渠道：

• Cloudflare 官方博客；
• Cloudflare Status 页面；
• Cloudflare Dashboard 通知；
• Cloudflare 安全公告邮件；
• GitHub 上相关开源项目的安全公告；
• 服务器安全日志与 WAF 事件日志。

如果你看到类似以下内容，需要优先处理：

• 某版本组件存在安全漏洞；
• Workers、Pages、Turnstile、Access、Zero Trust 等功能存在安全更新；
• 需要轮换 API Token；
• 需要重新部署配置；
• 某些规则或功能需要升级。

2. 站点配置漏洞

这是站长最常遇到的问题。包括：

• DNS 记录未走 Cloudflare 代理；
• 服务器仍允许任意 IP 访问；
• SSL 使用 Flexible 模式；
• 后台登录页暴露；
• 没有启用 WAF；
• 没有限制恶意请求频率；
• 没有对上传目录、接口地址做防护。

3. 应用层漏洞

例如 WordPress、Typecho、Discuz、Laravel、ThinkPHP、Spring Boot、Node.js 项目自身存在漏洞。Cloudflare 可以缓解一部分攻击，但不能替代程序修复。

如果应用本身存在 SQL 注入、文件上传漏洞、RCE、弱口令等问题，仍然必须从源代码、框架、插件、服务器层面进行修复。

三、第一步：检查 Cloudflare 账户安全

很多安全事故的源头不是网站漏洞，而是账号被盗。

1. 开启双因素认证

登录 Cloudflare 后台：

My Profile → Authentication → Two-Factor Authentication

建议开启以下方式之一：

• Authenticator App；
• 硬件安全密钥；
• 企业账户可使用 SSO。

不建议只依赖邮箱验证码。邮箱一旦被盗，Cloudflare 账户也可能被接管。

2. 检查登录记录

进入账户安全页面，查看最近登录活动：

• 是否有陌生 IP；
• 是否有异常国家或地区；
• 是否在非工作时间登录；
• 是否有未知设备访问。

如果发现异常，应立即：

1. 修改 Cloudflare 密码；
2. 修改邮箱密码；
3. 退出所有会话；
4. 轮换 API Token；
5. 检查 DNS 记录是否被篡改。

3. 清理无用成员

如果你的 Cloudflare 账户是团队使用，应检查成员权限：

Manage Account → Members

删除不再参与项目的成员，避免离职人员继续拥有后台权限。

权限原则：

• 不要给所有人 Super Administrator；
• 运维只给 DNS 或安全相关权限；
• 开发只给 Workers / Pages 相关权限；
• 临时人员使用临时权限，完成后及时删除。

四、第二步：轮换 API Token 和 Global API Key

API Token 泄露是非常严重的风险。攻击者可能通过 API 修改 DNS、关闭 WAF、篡改解析记录，甚至接管网站流量。

1. 检查是否使用 Global API Key

Cloudflare 早期常用 Global API Key，但它权限过大，不建议继续使用。

建议做法：

• 停用不必要的 Global API Key；
• 改用细粒度 API Token；
• 给每个项目单独创建 Token；
• 不同用途使用不同 Token。

2. 轮换 API Token

进入：

My Profile → API Tokens

逐一检查：

• Token 名称是否清晰；
• 权限范围是否过大；
• 是否限制 Zone；
• 是否长期未使用；
• 是否给了 Edit 权限但只需要 Read 权限。

如果怀疑泄露，应立即：

1. 删除旧 Token；
2. 新建最小权限 Token；
3. 更新服务器、CI/CD、脚本中的环境变量；
4. 检查最近 API 调用记录；
5. 检查 DNS 和安全规则是否被修改。

3. 不要把 Token 写进代码仓库

错误示例：

CLOUDFLARE_API_TOKEN=xxxxxxxxxxxxxxxx

如果这个文件被提交到 GitHub、Gitee 或 GitLab，Token 就可能被搜索引擎或扫描器发现。

正确做法：

• 使用 .env 并加入 .gitignore；
• 在 CI/CD 平台使用 Secrets；
• 使用服务器环境变量；
• 定期扫描代码仓库中的敏感信息。

五、第三步：检查 DNS 解析与代理状态

Cloudflare 的防护能力建立在“流量经过 Cloudflare”的基础上。如果 DNS 记录是灰云状态，访问者会直接连接源站，Cloudflare 的 WAF、缓存、DDoS 防护都无法生效。

1. 检查 DNS 记录是否开启代理

进入：

Websites → 选择站点 → DNS → Records

重点检查：

• A 记录；
• AAAA 记录；
• CNAME 记录；
• www 记录；
• 主域名记录；
• API 子域名；
• 后台子域名；
• 静态资源子域名。

橙色云朵表示已代理，灰色云朵表示仅 DNS 解析。

一般网站建议：

注意：邮件服务相关记录不要乱开代理，否则可能导致邮件异常。

2. 检查是否存在 IPv6 泄露

很多站长只隐藏了 IPv4，却忘记了 IPv6。如果 DNS 中存在 AAAA 记录，并且没有走 Cloudflare 代理，攻击者仍然可以通过 IPv6 找到源站。

建议：

• 不需要 IPv6 时删除源站 AAAA 记录；
• 需要 IPv6 时确保经过 Cloudflare 代理；
• 在源站防火墙中同时限制 IPv4 和 IPv6。

六、第四步：隐藏并保护源站 IP

即使 DNS 已经走 Cloudflare，源站 IP 仍然可能通过历史解析记录、邮件头、第三方接口、证书透明日志、错误配置等方式泄露。

1. 服务器防火墙只允许 Cloudflare IP 访问

这是非常关键的一步。你需要在源站服务器防火墙中，只允许 Cloudflare 官方 IP 段访问网站端口。

Cloudflare 官方 IP 段可在官方页面查看：

https://www.cloudflare.com/ips/

常见需要限制的端口：

• 80
• 443
• 8080
• 8443

以 Linux ufw 为例，示意配置如下：

ufw default deny incoming
ufw allow ssh
ufw allow from 173.245.48.0/20 to any port 80
ufw allow from 173.245.48.0/20 to any port 443
ufw enable

实际配置时，需要加入 Cloudflare 所有 IPv4 和 IPv6 段，而不是只添加一条。

如果使用 iptables、nftables、宝塔面板、安全组、云服务器防火墙，也应实现同样效果。

2. 云服务器安全组同步设置

很多站长只在系统内设置防火墙，却忘记云厂商安全组。

你还需要检查：

• 阿里云安全组；
• 腾讯云安全组；
• 华为云安全组；
• AWS Security Group；
• Google Cloud Firewall；
• Azure NSG；
• 宝塔防火墙；
• 服务器商控制面板防火墙。

原则是：

公网 80/443 只允许 Cloudflare IP 段访问
SSH 只允许你的固定办公 IP 访问
数据库端口不要暴露公网
Redis、MongoDB、Elasticsearch 不允许公网访问

3. 更换已泄露的源站 IP

如果源站 IP 已经长期暴露，并且经常被攻击，建议更换源站 IP。

更换后应做到：

1. 新 IP 不直接绑定公共 DNS；
2. 只在 Cloudflare DNS 中配置代理记录；
3. 源站防火墙只允许 Cloudflare IP；
4. 不在邮件服务中暴露新 IP；
5. 不在第三方监控中暴露新 IP；
6. 清理旧解析记录。

七、第五步：修复 SSL/TLS 配置错误

Cloudflare 提供多种 SSL/TLS 模式，其中最容易产生风险的是 Flexible。

1. 不建议使用 Flexible 模式

Flexible 模式下：

访客 → Cloudflare：HTTPS
Cloudflare → 源站：HTTP

这意味着 Cloudflare 到源站之间不是加密连接。如果源站与 Cloudflare 之间的链路被监听或篡改，就存在安全风险。

更严重的是，很多网站在 Flexible 模式下会出现：

• 后台登录异常；
• 无限重定向；
• Cookie 安全属性混乱；
• HTTPS 判断错误；
• 应用生成错误链接。

2. 推荐使用 Full 或 Full(strict)

推荐优先级：

Full (strict) > Full > Flexible

最佳实践是使用：

SSL/TLS → Overview → Full (strict)

然后在源站安装有效证书。

你可以使用：

• Let’s Encrypt 免费证书；
• Cloudflare Origin Certificate；
• 商业证书。

3. 启用 Always Use HTTPS

路径：

SSL/TLS → Edge Certificates → Always Use HTTPS

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

同时建议开启：

Automatic HTTPS Rewrites

用于减少混合内容问题。

4. 检查 HSTS

HSTS 可以强制浏览器使用 HTTPS，但配置错误可能导致网站无法访问。

如果你不熟悉 HSTS，不建议一开始就启用过长时间。

建议流程：

1. 先确认 HTTPS 完全正常；
2. 再启用短时间 HSTS；
3. 观察无异常后逐步增加时间；
4. 谨慎开启 includeSubDomains；
5. 谨慎提交 preload。

八、第六步：启用并优化 WAF 防护

Cloudflare WAF 是防护网站攻击的重要功能。站长应至少开启托管规则和基础自定义规则。

1. 开启 Managed Rules

进入：

Security → WAF → Managed Rules

建议开启：

• Cloudflare Managed Ruleset；
• OWASP Core Ruleset；
• 针对 WordPress 的规则；
• 针对常见 CMS 的规则。

如果你的网站是 WordPress，尤其建议启用 WordPress 相关防护规则。

2. 设置安全级别

路径：

Security → Settings → Security Level

常见建议：

• 正常站点：Medium；
• 被攻击期间：High；
• 严重攻击期间：I’m Under Attack。

I’m Under Attack 会对访客进行浏览器验证，不适合长期打开，可能影响用户体验和搜索引擎抓取。

3. 添加自定义 WAF 规则

以下是一些实用规则思路。

规则一：保护后台登录路径

如果你的后台是 WordPress：

URI Path contains "/wp-login.php"
或
URI Path contains "/wp-admin"

动作可以设置为：

• JS Challenge；
• Managed Challenge；
• Block；
• Allow 指定 IP。

更推荐只允许固定 IP 访问后台。

规则二：拦截异常国家访问

如果你的网站只面向中国大陆、港澳台或特定地区，可以针对非目标地区设置挑战或阻止。

注意不要误伤搜索引擎和海外用户。

规则三：拦截恶意 User-Agent

常见扫描器、漏洞探测工具会带有特征 User-Agent。可根据日志添加规则。

但不要只依赖 User-Agent，因为它很容易伪造。

规则四：限制敏感接口

例如：

/api/login
/api/register
/api/comment
/xmlrpc.php

这些接口容易遭遇暴力破解、撞库、垃圾注册和垃圾评论，应配合速率限制使用。

九、第七步：配置速率限制，防止暴力破解

如果攻击者不断请求登录接口，即使没有打穿漏洞，也会消耗服务器资源。

建议对以下路径设置 Rate Limiting：

• /wp-login.php
• /xmlrpc.php
• /admin
• /login
• /api/login
• /api/register
• /api/send-code
• /api/comment

示例策略：

同一 IP 1 分钟内访问 /login 超过 10 次 → Managed Challenge
同一 IP 1 分钟内访问 /api/send-code 超过 5 次 → Block 10 分钟
同一 IP 5 分钟内访问 /xmlrpc.php 超过 3 次 → Block

如果你的网站有短信验证码接口，务必加限制，否则可能被刷短信费用。

十、第八步：检查缓存规则，避免敏感信息泄露

Cloudflare 缓存配置错误可能导致严重问题。例如把用户中心、订单页面、后台页面缓存给其他用户。

1. 不应缓存的页面

以下页面通常不应缓存：

• 登录页面；
• 用户中心；
• 订单页面；
• 支付页面；
• 后台管理页面；
• API 私密接口；
• 带有用户身份 Cookie 的页面；
• 动态个性化页面。

2. 推荐缓存规则

可以缓存：

• CSS；
• JS；
• 图片；
• 字体；
• 静态 HTML；
• 公共接口返回；
• 不含用户隐私的数据。

3. WordPress 站点注意事项

WordPress 站点如果使用 Cache Everything，必须排除：

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

如果使用 WooCommerce，更要谨慎缓存购物车和结算页面。

十一、第九步：保护后台管理入口

后台入口是最常被攻击的位置。不要只依赖用户名和密码。

1. 使用 Cloudflare Access

Cloudflare Zero Trust Access 可以在访问后台前增加一层身份验证。

适合保护：

• WordPress 后台；
• 宝塔面板；
• phpMyAdmin；
• Grafana；
• Jenkins；
• 内部管理系统；
• 运维面板。

配置思路：

Zero Trust → Access → Applications → Add an application

选择 Self-hosted，然后填写后台域名，例如：

admin.example.com

再设置允许访问的邮箱、团队成员或身份提供商。

2. 后台使用独立子域名

例如：

admin.example.com

然后对该子域名配置更严格规则：

• 仅允许固定 IP；
• 开启 Access；
• 禁止搜索引擎索引；
• 开启 Managed Challenge；
• 不对外公开链接。

3. 禁止默认后台路径

如果程序支持，建议修改默认后台路径。例如：

• WordPress 可限制 /wp-login.php；
• Laravel 后台不要直接暴露 /admin；
• 宝塔面板不要使用默认端口；
• phpMyAdmin 不要放在默认路径。

十二、第十步：检查 Workers、Pages 与边缘代码

如果你使用 Cloudflare Workers 或 Pages，也需要进行安全检查。

1. 检查环境变量

确认没有把密钥写死在代码中，例如：

• 数据库密码；
• API Key；
• JWT Secret；
• 支付密钥；
• Webhook Secret；
• Cloudflare Token。

应使用 Cloudflare 的环境变量或 Secrets 功能保存。

2. 检查 CORS 配置

错误示例：

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

这类配置可能导致跨域安全风险。

如果接口涉及用户身份、Cookie、Token，应明确允许可信域名，而不是使用通配符。

3. 检查请求转发逻辑

很多 Workers 用于反向代理，如果没有限制目标地址，可能被滥用为开放代理。

应避免：

• 用户传入任意 URL 后 Workers 帮其请求；
• 未校验 Host；
• 未校验路径；
• 未限制方法；
• 未过滤敏感 Header。

十三、第十一步：源站程序与服务器同步修复

Cloudflare 是边缘防护层，不能替代源站修复。

你还需要：

1. 更新 CMS、插件和主题

如果使用 WordPress：

• 更新 WordPress 核心；
• 更新插件；
• 更新主题；
• 删除不用的插件；
• 删除盗版主题和破解插件。

盗版插件往往带后门，是站点被黑的高发原因。

2. 更新服务器组件

包括：

• Nginx；
• Apache；
• PHP；
• MySQL / MariaDB；
• Redis；
• OpenSSL；
• OpenSSH；
• Node.js；
• Python；
• Java；
• 应用框架。

3. 检查文件权限

常见建议：

目录权限：755
文件权限：644
敏感配置文件：600

不要给网站目录随意设置 777 权限。

4. 关闭不必要端口

使用命令查看监听端口：

ss -tulnp

确认是否有不应暴露的服务，例如：

• MySQL 3306；
• Redis 6379；
• MongoDB 27017；
• Elasticsearch 9200；
• Docker API；
• Jenkins；
• phpMyAdmin。

十四、第十二步：查看日志确认是否仍被攻击

修复后不要立刻认为安全了，需要观察日志。

1. 查看 Cloudflare 安全事件

路径：

Security → Events

重点关注：

• 被拦截请求数量；
• 攻击来源国家；
• 命中的 WAF 规则；
• 请求路径；
• User-Agent；
• IP 信誉；
• 是否存在大量 403、429、5xx。

2. 查看源站日志

Nginx 日志通常在：

/var/log/nginx/access.log
/var/log/nginx/error.log

Apache 日志通常在：

/var/log/apache2/access.log
/var/log/apache2/error.log

你需要确认：

• 是否还有非 Cloudflare IP 直接访问；
• 是否有大量异常 POST 请求；
• 是否有扫描器访问敏感路径；
• 是否出现异常 500 错误；
• 是否有可疑文件上传。

3. 检查网站文件是否被篡改

可重点检查：

• 最近修改的 PHP 文件；
• 上传目录中的脚本文件；
• .htaccess；
• index.php；
• wp-config.php；
• 主题目录；
• 插件目录；
• 定时任务；
• 计划任务；
• 新增管理员账号。

十五、站长快速修复清单

如果你没有时间逐项阅读，可以先按下面清单执行：

• [ ] Cloudflare 账户开启双因素认证；
• [ ] 删除无用成员；
• [ ] 轮换 API Token；
• [ ] 检查 DNS 是否橙云代理；
• [ ] 删除不必要的 AAAA 记录；
• [ ] 源站防火墙只允许 Cloudflare IP；
• [ ] 更换已泄露源站 IP；
• [ ] SSL/TLS 改为 Full(strict)；
• [ ] 开启 Always Use HTTPS；
• [ ] 启用 WAF Managed Rules；
• [ ] 给后台路径添加挑战或 IP 白名单；
• [ ] 给登录、注册、验证码接口加速率限制；
• [ ] 排除后台、用户中心、订单页缓存；
• [ ] 使用 Cloudflare Access 保护后台；
• [ ] 更新 CMS、插件、主题和服务器组件；
• [ ] 检查源站日志和 Cloudflare 安全事件；
• [ ] 备份网站和数据库；
• [ ] 建立定期安全巡检机制。

十六、常见问题解答

1. 接入 Cloudflare 后还需要服务器防火墙吗？

需要。Cloudflare 只能保护经过它的流量。如果攻击者知道源站 IP，就可以绕过 Cloudflare。所以服务器防火墙必须限制只允许 Cloudflare IP 段访问网站端口。

2. Cloudflare 的橙云一定要打开吗？

对网站 HTTP/HTTPS 流量来说，一般建议打开。橙云开启后，流量才会经过 Cloudflare，WAF、缓存、DDoS 防护等功能才会生效。

但邮件、FTP、SSH、数据库等服务不能随意开启橙云，应根据业务单独处理。

3. WAF 开启后网站异常怎么办？

可以先查看 Security Events，找到误拦截规则。不要直接关闭整个 WAF，而是针对具体规则调整：

• 改为 Log；
• 添加 Skip 规则；
• 放行可信 IP；
• 缩小匹配范围；
• 调整安全级别。

4. 源站 IP 已经泄露怎么办？

建议更换源站 IP，并立即配置防火墙，只允许 Cloudflare IP 段访问。旧 IP 如果仍被攻击，可以保留一段时间观察，但不要继续作为正式源站使用。

5. 使用 Cloudflare 后还需要 HTTPS 证书吗？

需要。推荐源站也配置 HTTPS，并在 Cloudflare 中使用 Full(strict) 模式。不要长期使用 Flexible 模式。

十七、总结

Cloudflare 是非常强大的网络安全与性能优化平台，但安全效果取决于站长是否正确配置。对于大多数站点来说，真正危险的往往不是 Cloudflare 官方服务本身，而是以下问题：

• 源站 IP 暴露；
• DNS 未代理；
• API Token 泄露；
• SSL 模式错误；
• WAF 未启用；
• 后台入口裸奔；
• 缓存规则错误；
• CMS 和插件长期不更新；
• 服务器端口暴露；
• 缺少日志监控。

站长在修复 Cloudflare 相关漏洞时，应遵循一个核心原则：

让所有 Web 流量必须经过 Cloudflare，并在 Cloudflare 和源站两端同时建立防护。

具体来说，就是：

1. Cloudflare 账户要安全；
2. DNS 解析要正确；
3. 源站 IP 要隐藏；
4. 防火墙要限制来源；
5. SSL/TLS 要使用 Full(strict)；
6. WAF 和速率限制要启用；
7. 后台入口要加访问控制；
8. 缓存规则不能缓存敏感页面；
9. 源站程序和服务器要持续更新；
10. 日志和告警要长期监控。

完成以上步骤后，你的网站安全性会明显提升，即使面对扫描、暴力破解、漏洞探测和中小规模攻击，也能具备更好的防护能力。对于站长而言，Cloudflare 不只是一个 CDN，更应该被当作网站安全体系的一部分来管理。