Cloudflare 生产环境安全加固实战：从源站隐藏到 WAF、限流与应急防护

发布人：慈云数据-客服中心发布时间：2小时前阅读量：4

Cloudflare 安全加固方案｜生产环境实测

在生产环境中，Cloudflare 不只是一个“隐藏源站 IP、加速静态资源”的 CDN 工具，更是一套完整的边缘安全防护平台。合理配置 Cloudflare，可以显著降低源站暴露面，缓解常见的 Web 攻击、CC 攻击、恶意扫描、撞库请求、爬虫消耗以及异常流量带来的资源压力。

本文基于生产环境实测经验，围绕 DNS、SSL/TLS、WAF、防火墙规则、速率限制、Bot 防护、源站加固、缓存策略、日志监控与应急处置 等方面，整理一套相对完整的 Cloudflare 安全加固方案。适合中小型网站、API 服务、管理后台、SaaS 平台以及高并发业务在正式环境中参考落地。

一、为什么生产环境需要 Cloudflare 安全加固？

很多团队接入 Cloudflare 后，只完成了最基础的配置：

DNS 指向 Cloudflare；
开启橙色云代理；
SSL 设置为 Full 或 Full Strict；
简单开启缓存；
默认使用 Cloudflare 的安全策略。

这类配置虽然能够带来一定的隐藏源站和加速效果，但在真实生产环境中仍存在不少风险。

例如：

源站 IP 仍可能被扫描或历史 DNS 记录泄露
攻击者绕过 Cloudflare 直接访问源站
默认 WAF 规则不足以覆盖业务风险
登录接口、短信接口、API 接口容易被刷
管理后台暴露在公网，易被爆破
恶意爬虫消耗服务器资源
CC 攻击导致源站连接数、CPU、带宽异常
缓存配置不合理，反而放大回源压力
缺少日志分析，无法快速定位攻击来源

因此，Cloudflare 的生产级安全加固目标并不是“接入即可”，而是要做到：

只允许可信流量经过 Cloudflare 到达源站，尽可能在边缘层拦截异常请求，并对关键业务路径设置更严格的访问控制。

二、整体加固思路

Cloudflare 安全加固可以分为四层：

层级	加固目标	主要手段
DNS 与源站层	防止源站暴露和绕过	DNS 清理、源站防火墙、仅允许 Cloudflare IP
TLS 与传输层	防止中间人攻击和弱加密	Full Strict、Origin Certificate、HSTS
应用安全层	防御 Web 攻击和恶意请求	WAF、自定义规则、Bot Fight、Rate Limiting
监控与响应层	快速发现和处置异常	日志分析、安全事件审计、告警

核心原则是：

源站不直接对公网服务
Cloudflare 作为唯一入口
敏感路径单独加固
静态资源尽量边缘缓存
动态接口限制频率和来源
安全策略先观察后拦截
定期复盘日志和规则命中情况

三、DNS 安全配置

1. 清理历史 DNS 记录

接入 Cloudflare 前，很多域名可能曾经在其他 DNS 平台解析到真实源站 IP。如果这些历史记录被第三方数据库收录，攻击者仍可能找到源站。

建议检查：

历史 A 记录；
子域名解析；
测试环境域名；
临时解析记录；
邮件相关解析误指向；
老业务残留域名。

可通过以下方式排查：

SecurityTrails；
Shodan；
Censys；
FOFA；
ZoomEye；
DNSDB；
被动 DNS 查询工具。

如果发现源站 IP 曾被暴露，应在源站防火墙侧做进一步隔离，不能仅依赖 Cloudflare 隐藏。

2. 只代理必要记录

Cloudflare 中橙色云代表流量经过 Cloudflare 代理，灰色云代表仅 DNS 解析。

建议：

Web 服务使用橙色云；
API 服务使用橙色云；
后台管理域名如需公网访问，也应使用橙色云并额外加固；
SSH、数据库、Redis、内网服务不要直接暴露公网；
邮件服务相关记录通常保持灰色云；
FTP、SFTP 等不建议通过普通公网直接暴露。

对于不需要公开访问的服务，应迁移至：

VPN；
Zero Trust Access；
内网专线；
堡垒机；
Tailscale / WireGuard；
Cloudflare Tunnel。

四、SSL/TLS 加固

1. 使用 Full Strict 模式

生产环境不建议使用：

Flexible；
Full。

推荐使用：

SSL/TLS encryption mode: Full (strict)

原因如下：

Flexible 只保证用户到 Cloudflare 加密，Cloudflare 到源站可能是 HTTP；
Full 虽然回源使用 HTTPS，但不严格校验证书；
Full Strict 会校验源站证书有效性，更适合生产环境。

2. 安装 Cloudflare Origin Certificate

Cloudflare 支持签发 Origin Certificate，用于 Cloudflare 到源站之间的 HTTPS 加密。

配置建议：

证书类型选择 RSA 或 ECC；
有效期可选择较长时间，但需要建立证书轮换计划；
绑定主域名和常用子域名；
源站 Web Server 配置该证书；
Cloudflare SSL 模式设置为 Full Strict。

Nginx 示例：

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    ssl_certificate     /etc/nginx/ssl/cloudflare-origin.pem;
    ssl_certificate_key /etc/nginx/ssl/cloudflare-origin.key;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    location / {
        proxy_pass http://backend;
    }
}

3. 开启 Always Use HTTPS

建议开启：

SSL/TLS → Edge Certificates → Always Use HTTPS

该功能可以自动将 HTTP 请求重定向到 HTTPS，减少明文访问风险。

如果业务中存在特殊 HTTP 回调接口，需要先确认兼容性，否则可能影响第三方回调。

4. 开启 HSTS

HSTS 可以强制浏览器在指定时间内只使用 HTTPS 访问站点。

建议配置：

Enable HSTS: On
Max Age: 6 months 或 12 months
Include subdomains: 谨慎开启
Preload: 谨慎开启

注意：

开启 Include subdomains 前，必须确认所有子域名均支持 HTTPS；
开启 Preload 后，回滚成本较高；
首次生产开启建议先设置较短 Max Age，例如 1 周或 1 个月，确认无问题后逐步提升。

五、源站防火墙加固

1. 仅允许 Cloudflare IP 回源

这是生产环境最关键的一步。

如果源站仍允许所有公网 IP 访问，那么攻击者只要找到真实 IP，就可以绕过 Cloudflare 的 WAF、限速和安全规则，直接攻击源站。

建议在源站防火墙、安全组或负载均衡层只允许 Cloudflare 官方 IP 段访问 80/443 端口。

Cloudflare IP 段官方地址：

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

Linux iptables 示例：

# 清空前请确认已有规则，避免误操作
iptables -A INPUT -p tcp -m multiport --dports 80,443 -s  -j ACCEPT
iptables -A INPUT -p tcp -m multiport --dports 80,443 -j DROP

UFW 示例：

ufw allow from  to any port 80 proto tcp
ufw allow from  to any port 443 proto tcp
ufw deny 80/tcp
ufw deny 443/tcp

生产环境建议通过脚本定期同步 Cloudflare IP 段，避免官方 IP 调整后导致回源异常。

2. 保护真实客户端 IP

Cloudflare 回源时，源站看到的直接连接 IP 是 Cloudflare 节点 IP，而非用户真实 IP。需要在源站恢复真实客户端 IP。

Nginx 配置示例：

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;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;

real_ip_header CF-Connecting-IP;

建议定期更新完整 IP 段。

如果使用应用框架，也需要确认框架层读取真实 IP 的逻辑，避免出现：

所有用户 IP 都显示为 Cloudflare；
限流系统失效；
登录风控失效；
日志分析不准确。

六、WAF 托管规则配置

Cloudflare WAF 是应用层防护的核心能力。

建议开启：

Cloudflare Managed Ruleset；
OWASP Core Ruleset；
Known Bots 识别；
Exposed Credentials Check；
WordPress / Drupal / Magento 等专项规则。

1. 托管规则建议

生产环境建议先采用：

Action: Log / Simulate

观察一段时间后，再逐步改为：

Challenge / Block

原因是某些业务请求可能包含特殊参数，例如：

JSON 中包含 HTML；
URL 参数中包含 SQL 关键字；
搜索功能允许输入特殊字符；
富文本编辑器提交脚本片段；
API 请求体包含代码或模板内容。

如果一开始直接拦截，可能误伤正常业务。

2. OWASP 规则灵敏度

OWASP 规则可以防护常见攻击：

SQL 注入；
XSS；
RCE；
LFI/RFI；
协议异常；
请求走私；
命令注入。

建议策略：

环境	灵敏度	动作
测试环境	High	Log
生产初期	Medium	Log / Challenge
稳定生产	Medium 或 High	Challenge / Block
高风险接口	High	Block

对于误报路径，可单独添加例外规则，而不是关闭整套 WAF。

七、自定义防火墙规则

自定义规则是 Cloudflare 安全加固中最实用的部分。通过条件组合，可以针对不同业务路径设置精细化防护。

1. 拦截非必要国家或地区访问

如果业务只服务中国大陆、港澳台或特定地区，可以限制其他地区访问。

示例规则：

if country not in ["CN", "HK", "MO", "TW"] then Managed Challenge

对于后台管理接口，可更严格：

if uri path starts with "/admin" and country not in ["CN"] then Block

注意不要盲目按国家封禁，因为：

用户可能使用海外网络；
企业出口 IP 可能在境外；
搜索引擎爬虫可能来自全球；
第三方服务回调可能来自海外。

建议对公开页面采用 Challenge，对后台和敏感接口采用 Block。

2. 保护管理后台

如果后台路径为：

/admin
/wp-admin
/login
/dashboard

建议配置多层防护：

规则一：限制访问地区

uri path starts with "/admin" and ip.geoip.country not in ["CN"]

动作：

Block

规则二：限制访问 IP

如果后台只允许公司出口 IP 访问：

uri path starts with "/admin" and ip.src not in [公司公网IP]

动作：

Block

规则三：启用 Cloudflare Access

更推荐使用 Cloudflare Zero Trust Access，对后台增加身份认证层，例如：

Google Workspace；
GitHub；
Azure AD；
One-time PIN；
SAML；
OIDC。

这样即使后台登录页存在弱密码或 0day 风险，也多了一层边缘身份验证。

3. 拦截恶意 User-Agent

生产中常见恶意扫描 UA 包括：

sqlmap
nikto
acunetix
masscan
nmap
python-requests
Go-http-client
curl
wget
java
libwww-perl

示例规则：

http.user_agent contains "sqlmap"
or http.user_agent contains "nikto"
or http.user_agent contains "acunetix"

动作：

Block

但要注意，部分正常服务也可能使用 curl、python-requests 进行回调或监控，因此不要一刀切拦截所有命令行 UA。更合理的方式是结合路径判断，例如：

http.user_agent contains "python-requests"
and uri path not starts with "/api/callback"

4. 拦截异常请求方法

大多数 Web 业务只需要：

GET
POST
HEAD
OPTIONS

对于不使用的方法可以直接拦截：

http.request.method not in ["GET", "POST", "HEAD", "OPTIONS"]

动作：

Block

可拦截：

PUT；
DELETE；
TRACE；
CONNECT；
PATCH。

如果 API 服务确实使用 PUT、DELETE，需要按路径例外处理。

5. 阻断敏感文件访问

攻击者经常扫描：

/.env
/.git/config
/config.php
/backup.zip
/db.sql
/phpinfo.php
/.svn
/.DS_Store
/docker-compose.yml

可添加规则：

uri path contains ".env"
or uri path contains ".git"
or uri path contains "phpinfo"
or uri path contains "backup"
or uri path contains ".sql"

动作：

Block

同时，源站也应确保这些文件不存在于 Web 根目录，不能只依赖 Cloudflare。

八、速率限制策略

速率限制是防御 CC、爆破、撞库、接口刷量的重要手段。

重点保护对象：

登录接口；
注册接口；
短信验证码接口；
邮箱验证码接口；
搜索接口；
下单接口；
支付回调接口；
API Token 获取接口；
文件上传接口。

1. 登录接口限速

示例策略：

路径：/login
规则：同一 IP 1 分钟超过 10 次
动作：Managed Challenge 或 Block

如果是后台登录：

同一 IP 1 分钟超过 5 次 → Block 10 分钟

更成熟的做法是结合账号维度进行应用层限流，例如：

同一账号 5 分钟内失败超过 5 次；
同一 IP 1 分钟尝试多个账号；
同一设备指纹频繁请求。

Cloudflare 负责边缘层限速，业务系统负责账号级风控。

2. 短信接口限速

短信验证码接口成本较高，必须重点保护。

建议：

/api/sms/send
同一 IP 1 分钟超过 3 次 → Challenge
同一 IP 10 分钟超过 10 次 → Block

同时业务侧应限制：

同一手机号每日发送次数；
同一手机号每小时发送次数；
同一设备每日发送次数；
同一 IP 对多个手机号发送次数；
图形验证码或行为验证码；
黑名单手机号段识别。

3. 搜索接口限速

搜索接口如果没有缓存，容易消耗数据库资源。

建议：

/search
同一 IP 30 秒超过 20 次 → Challenge

如搜索接口支持复杂条件查询，还应限制：

查询关键词长度；
分页深度；
排序字段；
模糊查询范围；
单次返回数量。

九、Bot 防护配置

Cloudflare 提供多种 Bot 防护能力，不同套餐功能不同。

常见选项包括：

Bot Fight Mode；
Super Bot Fight Mode；
Bot Management；
JavaScript Challenge；
Managed Challenge；
Turnstile。

1. 开启 Bot Fight Mode

对于普通网站，可以开启 Bot Fight Mode，用于对抗常见自动化请求。

但要注意：

部分 API 客户端可能受影响；
第三方回调可能失败；
移动端 App 请求可能被误判；
服务端脚本访问可能被挑战。

因此，API 域名建议独立出来，例如：

www.example.com
api.example.com
admin.example.com

分别配置不同安全策略。

2. 使用 Turnstile 替代传统验证码

Cloudflare Turnstile 是一种用户体验更好的验证码方案。

适合部署在：

登录页；
注册页；
找回密码；
短信验证码发送；
评论提交；
表单提交；
低信誉请求二次校验。

相比传统图片验证码，Turnstile 对用户更友好，也能降低自动化滥用。

十、缓存安全与性能加固

缓存配置不仅影响性能，也影响安全。

1. 静态资源缓存

建议缓存：

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

配置建议：

Cache Level: Standard
Browser Cache TTL: 1 month
Edge Cache TTL: 1 month

对于带版本号的静态资源，可设置更长缓存：

/app.20250101.js
/main.a8f9c2.css

可缓存 6 个月甚至 1 年。

2. 动态接口不要盲目缓存

以下路径一般不建议缓存：

/api/*
/login
/register
/user/*
/order/*
/payment/*
/admin/*

尤其包含用户身份、订单、支付、个人信息的接口，必须确保：

不被边缘缓存；
不被浏览器长期缓存；
响应头正确设置。

建议响应头：

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

3. 防止缓存投毒

缓存投毒通常利用 Host、Header、Query 参数差异，让边缘缓存错误内容。

建议：

只缓存明确的静态资源；
动态页面谨慎 Cache Everything；
规范 Host 头；
忽略无意义 Query 参数；
对登录态页面禁止缓存；
使用 Cache Rules 精细控制；
对异常 Header 请求进行拦截。

十一、API 安全加固

API 是生产环境中最容易被滥用的入口。

1. API 域名单独配置

建议拆分：

www.example.com      页面访问
api.example.com      API 服务
admin.example.com    后台管理
static.example.com   静态资源

这样可以按域名配置不同策略：

域名	策略
www	WAF + Bot Challenge + 缓存
api	严格限速 + Token 校验 + 禁止缓存
admin	Access 身份认证 + IP 白名单
static	强缓存 + 低安全挑战

2. 强制 API 鉴权

Cloudflare 可以挡掉一部分异常请求，但不能替代业务鉴权。

API 必须具备：

Token；
签名；
时间戳；
Nonce；
重放防护；
权限校验；
参数校验；
服务端限流。

对于开放 API，可增加：

mTLS；
API Shield；
Schema Validation；
JWT Validation；
客户端证书认证。

3. 限制 Content-Type

如果 API 只接受 JSON，可以拦截异常 Content-Type：

uri path starts with "/api/"
and http.request.method eq "POST"
and http.request.headers["content-type"][0] not contains "application/json"

动作：

Block

实际配置时要考虑：

multipart 上传；
form 表单；
webhook 回调；
老客户端兼容。

十二、Cloudflare Tunnel 与 Zero Trust

如果希望进一步降低源站暴露风险，可以使用 Cloudflare Tunnel。

1. Cloudflare Tunnel 优点

使用 Tunnel 后，源站无需开放公网 80/443 端口，而是由源站主动向 Cloudflare 建立出站连接。

优势：

源站无公网入口；
降低被扫描概率；
不需要暴露真实 IP；
适合后台、内网服务、测试环境；
可结合 Access 做身份认证。

适合保护：

管理后台；
Grafana；
Kibana；
Jenkins；
GitLab；
内部文档；
测试 API；
运维面板。

2. Zero Trust Access 保护后台

对于后台系统，推荐配置：

admin.example.com → Cloudflare Access → 指定邮箱/组织账号登录

策略示例：

仅允许公司邮箱；
仅允许管理员组；
必须启用 MFA；
登录会话 8 小时过期；
高风险国家禁止访问；
未认证用户无法看到后台登录页。

这样可以有效降低后台弱口令、扫描器探测和撞库风险。

十三、DDoS 与 CC 防护实测策略

生产环境中最常见的不是超大规模 DDoS，而是中小规模 CC 攻击，例如：

高频访问首页；
高频请求动态接口；
大量随机路径；
高频搜索；
高频登录；
使用代理池绕过单 IP 限制；
模拟正常 UA。

1. Under Attack Mode

当出现明显攻击时，可以临时开启：

Security → Under Attack Mode

它会对访问者执行更严格的浏览器验证。

优点：

快速降低攻击压力；
对普通网站效果明显；
配置简单。

缺点：

用户体验下降；
API 请求可能失败；
移动端 App 可能异常；
不适合长期启用。

建议作为应急手段，而不是长期策略。

2. Managed Challenge 优于直接 Block

在不确定请求是否恶意时，推荐使用：

Managed Challenge

它比直接 Block 更温和，可以减少误杀真实用户。

适合场景：

可疑国家访问；
可疑 UA；
高频访问；
无 Cookie 请求；
新访问者异常行为；
非搜索引擎爬虫。

对于明确恶意行为，例如扫描 .env、SQLMap、路径穿越，可直接 Block。

3. 随机路径攻击处理

攻击者常请求随机路径造成回源压力，例如：

/a8d92k
/test123
/wp-login.php
/admin.php
/不存在路径

如果源站对 404 也执行复杂逻辑，会造成压力。

建议：

源站优化 404 返回；
Cloudflare 对明显不存在路径做挑战；
对高频 404 IP 限速；
缓存静态 404 页面；
拦截常见扫描路径。

十四、日志与监控

没有日志，就无法判断规则是否有效。

建议关注 Cloudflare 中的：

Security Events；
Firewall Events；
WAF 命中情况；
Rate Limiting 命中；
Bot Score；
Top Countries；
Top IPs；
Top Paths；
Cache Hit Ratio；
Origin Error；
5xx 错误；
带宽与请求量趋势。

1. 生产监控指标

建议监控：

指标	异常含义
请求量突增	可能 CC 或爬虫
403 突增	防火墙规则命中
429 突增	限速策略触发
5xx 突增	源站异常或回源失败
Cache Hit Ratio 降低	缓存失效或动态请求增加
某路径请求异常	接口被刷
某国家流量突增	代理池或攻击来源变化

2. 日志回传

如果使用企业级或支持 Logpush 的套餐，可以将日志推送到：

S3；
R2；
BigQuery；
Elasticsearch；
Splunk；
Datadog；
SIEM 平台。

日志字段建议包含：

Ray ID；
Client IP；
Country；
User-Agent；
Host；
URI；
Method；
Status Code；
WAF Action；
Bot Score；
Cache Status；
Origin Response Time。

通过日志可以做更深入分析，例如：

攻击来源 IP 聚类；
UA 指纹分析；
高频路径识别；
用户误伤排查；
规则效果复盘。

十五、生产环境推荐规则模板

以下是一套适合大多数业务的基础模板，实际需按业务调整。

1. 管理后台保护

if hostname eq "admin.example.com"
and ip.src not in [公司出口IP]
then Block

或：

admin.example.com 接入 Cloudflare Access

2. 敏感文件拦截

if uri path contains ".env"
or uri path contains ".git"
or uri path contains "phpinfo"
or uri path contains "backup"
or uri path contains ".sql"
then Block

3. 恶意扫描 UA 拦截

if http.user_agent contains "sqlmap"
or http.user_agent contains "nikto"
or http.user_agent contains "acunetix"
or http.user_agent contains "masscan"
then Block

4. 登录接口限速

/login
同一 IP 1 分钟超过 10 次
动作：Managed Challenge

5. 短信接口限速

/api/sms/send
同一 IP 1 分钟超过 3 次
动作：Managed Challenge

6. 非常见请求方法拦截

if http.request.method not in ["GET", "POST", "HEAD", "OPTIONS"]
then Block

7. API 禁止缓存

hostname eq "api.example.com"
Cache: Bypass

8. 静态资源强缓存

uri path ends with ".js"
or uri path ends with ".css"
or uri path ends with ".png"
or uri path ends with ".jpg"
or uri path ends with ".webp"
then Cache Eligible
Edge TTL: 30 days
Browser TTL: 30 days

十六、上线顺序建议

生产环境加固不能一次性全部强拦截，否则容易误伤业务。推荐按以下顺序实施：

备份当前 DNS 和 Cloudflare 配置
确认源站 HTTPS 正常
切换 SSL 为 Full Strict
开启 Always Use HTTPS
配置源站仅允许 Cloudflare IP
开启 WAF 托管规则，先 Log
观察 3~7 天安全事件
对明确恶意规则改为 Block
对登录、短信、搜索接口配置限速
后台接入 Access 或 IP 白名单
优化缓存规则
接入日志分析和告警
定期复盘规则命中与误报情况

十七、常见问题与避坑

1. 为什么开启 Cloudflare 后源站还是被打？

常见原因：

源站 IP 已泄露；
源站防火墙未限制 Cloudflare IP；
某些子域名直连源站；
历史解析记录被收录；
邮件头或应用错误泄露 IP；
服务器还有其他端口暴露。

解决方法：

更换源站 IP；
只允许 Cloudflare IP 访问 80/443；
关闭不必要端口；
排查所有子域名；
使用 Tunnel 隐藏源站；
应用层不要返回源站 IP 信息。

2. 为什么用户真实 IP 变成了 Cloudflare IP？

因为源站未正确配置真实 IP 还原。

需要配置：

real_ip_header CF-Connecting-IP

并添加 Cloudflare IP 段为可信代理。

3. 为什么接口请求被 Challenge？

可能原因：

Bot Fight Mode 误判；
WAF 规则命中；
自定义规则过宽；
API 与 Web 使用同一安全策略；
User-Agent 或 Header 不完整。

建议 API 单独域名配置，并对可信回调路径设置例外。

4. 为什么缓存没有生效？