Cloudflare 安全加固方案｜一键部署

在网站安全防护体系中，Cloudflare 是非常常见的一层“前置安全网关”。它不仅可以提供 CDN 加速、DNS 托管、DDoS 防护，还能通过 WAF、防火墙规则、Bot 管理、速率限制、访问控制、SSL/TLS 加密等能力，帮助网站抵御大量自动化攻击与常见 Web 风险。

但很多站点在接入 Cloudflare 后，只完成了基础解析与代理开启，并没有进一步做安全策略加固。结果是：虽然域名已经走了 Cloudflare，但源站 IP 暴露、后台路径裸奔、缓存策略混乱、TLS 配置不严谨、恶意扫描仍可直达应用层，安全收益并没有完全发挥出来。

本文将围绕 Cloudflare 安全加固方案 展开，提供一套适用于企业官网、博客、电商站点、API 服务、SaaS 平台等场景的安全配置思路，并给出“一键部署”的落地方案。文章内容偏实战，适合运维、安全工程师、开发者以及站点负责人参考。

一、方案目标

本方案的核心目标不是“开启某一个功能”，而是构建一套完整的边缘安全防护体系。

主要目标包括：

1. 隐藏源站真实 IP

   • 避免攻击者绕过 Cloudflare 直接攻击源站。
   • 降低 DDoS、CC 攻击、端口扫描对源站的影响。

2. 强化 HTTPS 与传输安全

   • 使用 Full Strict 模式。
   • 开启 HSTS、TLS 1.2/1.3。
   • 禁用不安全协议与弱加密连接。

3. 启用 Web 应用防火墙

   • 防护 SQL 注入、XSS、文件包含、命令执行等常见攻击。
   • 使用 Cloudflare 托管规则集快速加固。

4. 限制敏感路径访问

   • 对后台、管理接口、登录接口增加访问限制。
   • 可结合 IP 白名单、国家/地区限制、验证码挑战、Zero Trust 访问策略。

5. 拦截恶意扫描与自动化请求

   • 针对恶意 User-Agent、异常请求频率、可疑路径进行拦截。
   • 使用 Bot Fight Mode、Rate Limiting 等功能。

6. 优化缓存与安全响应头

   • 提升访问性能。
   • 增加浏览器侧安全防护能力。

7. 实现配置标准化与自动化部署

   • 通过脚本或 Terraform 快速部署。
   • 降低人工配置错误。
   • 便于多站点统一管理。

二、适用场景

该方案适用于以下场景：

• 企业官网、品牌站、营销落地页；
• WordPress、Typecho、Halo、Hexo 等博客系统；
• 电商网站、会员系统、内容管理系统；
• API 网关、SaaS 平台入口；
• 需要隐藏源站 IP 的业务；
• 经常遭遇扫描、撞库、CC 攻击的网站；
• 希望快速建立 Cloudflare 安全基线的团队。

需要注意的是，Cloudflare 是边缘安全层，并不能完全替代源站安全建设。应用自身仍然需要做好身份认证、权限控制、输入校验、日志审计、漏洞修复和主机加固。

三、总体架构设计

推荐架构如下：

用户 / 攻击流量
        |
        v
Cloudflare DNS + CDN + WAF + Bot 防护
        |
        v
仅允许 Cloudflare IP 访问的源站服务器
        |
        v
Nginx / Apache / 应用服务 / 数据库

在这个架构中，所有公网流量首先进入 Cloudflare。Cloudflare 负责完成 DNS 解析、TLS 终止、WAF 过滤、缓存处理、访问控制和速率限制。只有经过 Cloudflare 放行的请求，才会转发到源站。

源站侧则需要配合完成一项非常关键的配置：

只允许 Cloudflare 官方 IP 段访问源站 Web 端口。

如果源站仍然允许任意公网 IP 直接访问 80/443 端口，那么攻击者一旦发现源站真实 IP，就可以绕过 Cloudflare，导致边缘防护失效。

四、Cloudflare 基础安全配置

1. DNS 记录开启代理

在 Cloudflare DNS 面板中，将需要保护的记录开启橙色云朵代理。

例如：

开启代理后，用户访问域名时看到的是 Cloudflare 边缘节点 IP，而不是源站真实 IP。

但需要注意：

• 邮件相关记录，如 MX、SPF、DKIM、DMARC 通常不要开启代理；
• FTP、SSH、数据库端口不应通过普通 Cloudflare CDN 代理；
• 如果子域名指向源站 IP 且未开启代理，也可能泄露源站地址。

2. SSL/TLS 模式设置为 Full Strict

进入：

SSL/TLS → Overview

建议选择：

Full (strict)

该模式要求 Cloudflare 到源站之间也使用有效证书加密通信。相比 Flexible 模式，Full Strict 更安全，可以避免边缘到源站之间明文传输或证书校验不严格的问题。

源站证书可以使用：

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

不建议使用：

Flexible

因为 Flexible 只保证用户到 Cloudflare 之间是 HTTPS，而 Cloudflare 到源站可能仍是 HTTP。这种配置容易产生重定向循环，也不符合生产安全要求。

3. 最低 TLS 版本设置为 TLS 1.2

进入：

SSL/TLS → Edge Certificates

建议配置：

• Minimum TLS Version：TLS 1.2；
• TLS 1.3：开启；
• Automatic HTTPS Rewrites：开启；
• Always Use HTTPS：开启。

这样可以阻止老旧客户端使用 TLS 1.0/1.1 访问，降低中间人攻击和弱协议风险。

4. 开启 HSTS

HSTS 可以强制浏览器在后续访问中只使用 HTTPS。

推荐配置：

SSL/TLS → Edge Certificates → HTTP Strict Transport Security

建议参数：

• Enable HSTS：开启；
• Max Age：6 个月或 12 个月；
• Include subdomains：谨慎开启；
• Preload：确认所有子域名均支持 HTTPS 后再开启。

如果站点存在历史 HTTP 子域名，或者某些子域名不支持 HTTPS，不建议贸然开启 Include subdomains 和 Preload，否则可能导致部分业务无法访问。

五、WAF 防护规则配置

Cloudflare WAF 是安全加固的核心能力之一。

1. 启用托管规则集

进入：

Security → WAF → Managed rules

建议启用：

• Cloudflare Managed Ruleset；
• OWASP Core Ruleset；
• Cloudflare Specials；
• CMS 相关规则集，例如 WordPress 规则。

对于普通站点，托管规则集可以覆盖大量通用 Web 攻击，包括：

• SQL 注入；
• XSS 跨站脚本；
• RCE 远程命令执行；
• LFI/RFI 文件包含；
• 常见扫描器探测；
• CMS 漏洞利用；
• 异常协议与畸形请求。

初次启用时建议将部分高敏感规则设置为：

Log 或 Challenge

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

Block

这样可以降低误拦截风险。

2. 自定义防火墙规则

除了托管规则集，还需要根据业务特征增加自定义规则。

拦截常见恶意路径

很多扫描器会自动探测敏感文件或后台路径，例如：

/.env
/.git/config
/wp-config.php
/backup.zip
/phpinfo.php
/adminer.php

可创建规则：

(http.request.uri.path contains ".env") or
(http.request.uri.path contains ".git") or
(http.request.uri.path contains "wp-config.php") or
(http.request.uri.path contains "phpinfo.php") or
(http.request.uri.path contains "adminer.php")

动作：

Block

保护后台登录路径

以 WordPress 为例，后台路径通常是：

/wp-login.php
/wp-admin

可以配置：

(http.request.uri.path contains "/wp-login.php") or
(http.request.uri.path contains "/wp-admin")

动作建议根据业务选择：

• 仅允许固定 IP；
• Managed Challenge；
• Turnstile 验证；
• 使用 Cloudflare Access；
• 限制国家/地区访问。

如果后台只允许公司出口 IP 访问，可使用规则：

(http.request.uri.path contains "/wp-admin" and not ip.src in {1.2.3.4 5.6.7.8})

动作：

Block

限制高风险国家或地区访问

如果业务只面向特定国家或地区，可以限制非目标地区访问。例如只允许中国大陆、新加坡和美国访问：

not ip.geoip.country in {"CN" "SG" "US"}

动作：

Managed Challenge

不建议无脑 Block 所有非目标地区，因为搜索引擎、监控系统、第三方回调服务可能来自其他国家。更稳妥的方式是 Challenge 或对敏感路径进行限制。

六、速率限制与 CC 防护

CC 攻击的特点是请求看似正常，但频率异常，目标通常是登录页、搜索页、接口、动态页面等。

1. 登录接口限速

例如登录接口路径：

/login
/api/login
/wp-login.php

可以设置：

如果同一 IP 在 1 分钟内请求超过 10 次，则 Challenge 或 Block 10 分钟

推荐策略：

2. API 接口限速

对于 API 服务，建议按接口类型设置不同限速：

• 登录、注册、验证码接口：严格限速；
• 查询类接口：中等限速；
• 支付回调、第三方 Webhook：建议使用签名校验与白名单；
• 公开 API：按用户 Token 或 IP 维度限速。

Cloudflare 的 Rate Limiting 可以在边缘层提前阻断恶意请求，减少源站压力。

七、Bot 与自动化流量防护

1. 开启 Bot Fight Mode

进入：

Security → Bots

免费版可开启：

Bot Fight Mode

该功能可以对部分低质量机器人、自动化脚本和恶意爬虫进行挑战或阻断。

对于业务站点，尤其是内容站、电商站、登录系统，Bot 防护非常重要。大量撞库、刷接口、爬取数据、垃圾注册行为，本质上都属于自动化流量问题。

2. 使用浏览器完整性检查

进入：

Security → Settings

建议开启：

Browser Integrity Check

它可以检测请求头异常、浏览器特征异常的访问，并进行拦截或挑战。

八、缓存与安全性能优化

安全和性能并不是互相矛盾的。合理使用 Cloudflare 缓存，可以显著降低源站压力，间接提升抗攻击能力。

1. 静态资源缓存

建议对以下文件开启较长缓存：

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

缓存时间可设置为：

7 天至 30 天

对于带版本号的静态资源，例如：

/app.8f3a2.js
/style.v2024.css

可以设置更长缓存时间。

2. 动态页面谨慎缓存

登录页、用户中心、购物车、订单页、后台页面不应缓存，否则可能造成数据错乱或隐私泄露。

典型不缓存路径：

/login
/admin
/user
/account
/cart
/checkout
/api

建议为这些路径创建 Cache Rule：

Bypass Cache

九、安全响应头加固

除了 Cloudflare 自身防护，还可以通过 Transform Rules 或源站配置增加安全响应头。

推荐响应头包括：

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation=(), microphone=(), camera=()
Content-Security-Policy: default-src 'self'; frame-ancestors 'self';

其中 CSP 配置需要根据站点实际资源来源谨慎调整。若站点使用了第三方统计、广告、字体、支付、客服系统，过于严格的 CSP 可能导致页面功能异常。

十、源站安全加固

Cloudflare 配置完成后，源站仍然必须做加固。

1. 只允许 Cloudflare IP 访问

以 Linux + Nginx 为例，可以使用防火墙限制 80/443 端口只允许 Cloudflare IP 段访问。

Cloudflare 官方 IP 地址列表：

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

示例脚本：

#!/bin/bash

set -e

CF_IPV4_URL="https://www.cloudflare.com/ips-v4"
CF_IPV6_URL="https://www.cloudflare.com/ips-v6"

echo "[1/4] 清理旧规则..."
iptables -D INPUT -p tcp --dport 80 -j DROP 2>/dev/null || true
iptables -D INPUT -p tcp --dport 443 -j DROP 2>/dev/null || true

echo "[2/4] 放行 Cloudflare IPv4..."
for ip in $(curl -s $CF_IPV4_URL); do
  iptables -C INPUT -p tcp -s "$ip" --dport 80 -j ACCEPT 2>/dev/null || \
  iptables -A INPUT -p tcp -s "$ip" --dport 80 -j ACCEPT

  iptables -C INPUT -p tcp -s "$ip" --dport 443 -j ACCEPT 2>/dev/null || \
  iptables -A INPUT -p tcp -s "$ip" --dport 443 -j ACCEPT
done

echo "[3/4] 放行 Cloudflare IPv6..."
for ip in $(curl -s $CF_IPV6_URL); do
  ip6tables -C INPUT -p tcp -s "$ip" --dport 80 -j ACCEPT 2>/dev/null || \
  ip6tables -A INPUT -p tcp -s "$ip" --dport 80 -j ACCEPT

  ip6tables -C INPUT -p tcp -s "$ip" --dport 443 -j ACCEPT 2>/dev/null || \
  ip6tables -A INPUT -p tcp -s "$ip" --dport 443 -j ACCEPT
done

echo "[4/4] 拒绝非 Cloudflare 访问 Web 端口..."
iptables -C INPUT -p tcp --dport 80 -j DROP 2>/dev/null || iptables -A INPUT -p tcp --dport 80 -j DROP
iptables -C INPUT -p tcp --dport 443 -j DROP 2>/dev/null || iptables -A INPUT -p tcp --dport 443 -j DROP

echo "完成：源站 Web 端口已限制为仅允许 Cloudflare IP 访问。"

执行前请确认：

• SSH 端口未被误封；
• 已经保留服务器控制台登录方式；
• Cloudflare 代理已正常开启；
• 源站证书配置正确。

2. 获取真实客户端 IP

由于请求经过 Cloudflare，源站看到的默认来源 IP 可能是 Cloudflare 节点 IP。需要在 Nginx 中恢复真实客户端 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;
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;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 131.0.72.0/22;

real_ip_header CF-Connecting-IP;

建议定期同步 Cloudflare IP 段，避免地址更新后导致访问异常。

十一、一键部署思路

所谓“一键部署”，并不是简单执行一个命令就完成所有安全建设，而是把重复性配置标准化、自动化。

推荐采用以下方式：

1. Cloudflare API 自动创建安全规则

   • 配置 WAF 自定义规则；
   • 配置 Zone Settings；
   • 配置 Cache Rules；
   • 配置 Rate Limiting；
   • 配置 DNS 代理状态。

2. 源站脚本自动加固

   • 同步 Cloudflare IP；
   • 配置 iptables/nftables；
   • 写入 Nginx real_ip 配置；
   • 检查证书与 HTTPS 状态。

3. 配置模板化

   • 不同站点只需修改域名、Zone ID、Token、后台路径、白名单 IP；
   • 统一安全基线；
   • 支持回滚。

十二、一键部署脚本示例

下面提供一个基础版部署脚本，用于快速完成源站侧安全加固。Cloudflare 面板规则仍建议结合实际业务配置，或通过 API/Terraform 进一步自动化。

使用前请务必在测试环境验证，避免误封生产业务。

#!/bin/bash

set -e

CF_IPV4_URL="https://www.cloudflare.com/ips-v4"
CF_IPV6_URL="https://www.cloudflare.com/ips-v6"
NGINX_CF_REALIP="/etc/nginx/conf.d/cloudflare-real-ip.conf"

echo "========== Cloudflare 源站安全一键加固 =========="

if [ "$(id -u)" != "0" ]; then
  echo "请使用 root 权限运行该脚本"
  exit 1
fi

echo "[1/6] 检查依赖..."
command -v curl >/dev/null 2>&1 || {
  echo "未找到 curl，请先安装 curl"
  exit 1
}

echo "[2/6] 获取 Cloudflare IP 段..."
CF_IPV4=$(curl -s "$CF_IPV4_URL")
CF_IPV6=$(curl -s "$CF_IPV6_URL")

if [ -z "$CF_IPV4" ]; then
  echo "获取 Cloudflare IPv4 失败"
  exit 1
fi

echo "[3/6] 写入 Nginx Real IP 配置..."
cat > "$NGINX_CF_REALIP" <> "$NGINX_CF_REALIP"
done

for ip in $CF_IPV6; do
  echo "set_real_ip_from $ip;" >> "$NGINX_CF_REALIP"
done

cat >> "$NGINX_CF_REALIP" </dev/null || \
  iptables -A INPUT -p tcp -s "$ip" --dport 80 -j ACCEPT

  iptables -C INPUT -p tcp -s "$ip" --dport 443 -j ACCEPT 2>/dev/null || \
  iptables -A INPUT -p tcp -s "$ip" --dport 443 -j ACCEPT
done

if command -v ip6tables >/dev/null 2>&1; then
  for ip in $CF_IPV6; do
    ip6tables -C INPUT -p tcp -s "$ip" --dport 80 -j ACCEPT 2>/dev/null || \
    ip6tables -A INPUT -p tcp -s "$ip" --dport 80 -j ACCEPT

    ip6tables -C INPUT -p tcp -s "$ip" --dport 443 -j ACCEPT 2>/dev/null || \
    ip6tables -A INPUT -p tcp -s "$ip" --dport 443 -j ACCEPT
  done
fi

iptables -C INPUT -p tcp --dport 80 -j DROP 2>/dev/null || \
iptables -A INPUT -p tcp --dport 80 -j DROP

iptables -C INPUT -p tcp --dport 443 -j DROP 2>/dev/null || \
iptables -A INPUT -p tcp --dport 443 -j DROP

echo "[5/6] 检查 Nginx 配置..."
if command -v nginx >/dev/null 2>&1; then
  nginx -t
  systemctl reload nginx || service nginx reload
else
  echo "未检测到 nginx，跳过重载"
fi

echo "[6/6] 完成"
echo "建议下一步："
echo "1. 在 Cloudflare 开启 Full Strict SSL"
echo "2. 启用 WAF Managed Rules"
echo "3. 为后台路径配置 Challenge 或 IP 白名单"
echo "4. 为登录/API 接口配置 Rate Limiting"
echo "5. 定期更新 Cloudflare IP 段"

十三、Cloudflare API 自动化配置示例

如果需要真正意义上的“一键部署”，可以通过 Cloudflare API 自动配置部分安全选项。

示例：开启 Always Use HTTPS。

curl -X PATCH "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/settings/always_use_https" \
  -H "Authorization: Bearer ${CF_API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{"value":"on"}'

示例：设置最低 TLS 版本为 1.2。

curl -X PATCH "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/settings/min_tls_version" \
  -H "Authorization: Bearer ${CF_API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{"value":"1.2"}'

示例：开启 TLS 1.3。

curl -X PATCH "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/settings/tls_1_3" \
  -H "Authorization: Bearer ${CF_API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{"value":"on"}'

使用 API Token 时，建议遵循最小权限原则，仅授予对应 Zone 的必要权限，不要直接使用全局 API Key。

十四、推荐安全基线清单

下面是一份可直接用于检查的 Cloudflare 安全基线。

十五、常见问题与排查

1. 开启 Full Strict 后网站打不开

常见原因：

• 源站没有安装有效证书；
• 证书域名不匹配；
• 源站 HTTPS 端口未开放；
• Nginx/Apache 虚拟主机配置错误；
• 使用了过期证书。

解决方案：

• 为源站安装 Let’s Encrypt 证书；
• 或使用 Cloudflare Origin Certificate；
• 确保证书覆盖当前域名；
• 检查源站 443 端口是否正常监听。

2. 配置防火墙后无法访问网站

可能原因：

• DNS 记录没有开启代理；
• Cloudflare IP 段未完整放行；
• iptables 规则顺序错误；
• IPv6 配置不完整；
• 源站服务监听地址异常。

排查方式：

iptables -L -n --line-numbers
nginx -t
curl -I https://你的域名

必要时通过云厂商控制台登录服务器，临时清理防火墙规则。

3. 后台登录被误拦截

可能原因：

• WAF 规则过于严格；
• 登录插件请求被识别为异常；
• CSP 或缓存规则影响后台功能；
• Rate Limiting 阈值过低。

解决方案：

• 为后台路径设置单独规则；
• 对公司固定 IP 放行；
• 将部分规则从 Block 调整为 Challenge；
• 查看 Cloudflare Security Events 日志定位具体规则。

十六、上线建议

生产环境上线 Cloudflare 安全加固时，建议按阶段推进：

第一阶段：基础接入

• DNS 迁移；
• 开启代理；
• 配置 Full Strict；
• 确认 HTTPS 正常；
• 检查源站证书。

第二阶段：边缘安全

• 开启 WAF 托管规则；
• 开启 Bot 防护；
• 配置后台保护；
• 配置登录接口限速。

第三阶段：源站封锁

• 确认所有业务流量均经过 Cloudflare；
• 放行 Cloudflare IP；
• 阻断非 Cloudflare 对 80/443 的访问；
• 配置真实 IP 识别。

第四阶段：监控与优化

• 观察 Security Events；
• 调整误拦截规则；
• 分析访问日志；
• 优化缓存策略；
• 编写自动化部署与回滚脚本。

十七、总结

Cloudflare 的价值不仅在于 CDN 加速，更在于它可以作为网站的第一道安全边界。一个合格的 Cloudflare 安全加固方案，至少应该包括以下几个关键点：

1. 核心业务域名开启代理；
2. SSL/TLS 使用 Full Strict；
3. 开启 WAF 托管规则与 OWASP 规则；
4. 对后台、登录、API 等敏感路径单独加固；
5. 使用 Rate Limiting 防护暴力破解与 CC 攻击；
6. 启用 Bot 防护与浏览器完整性检查；
7. 源站只允许 Cloudflare IP 访问；
8. 正确恢复真实客户端 IP；
9. 合理配置缓存与安全响应头；
10. 通过脚本、API 或 Terraform 实现自动化部署。

所谓“一键部署”，真正的意义是将安全经验沉淀为标准化配置，把容易遗漏、容易出错的操作自动化。这样不仅可以提升部署效率，也能让多站点、多环境保持一致的安全基线。

对于个人站点来说，这套方案可以显著减少恶意扫描、暴力破解和小规模 CC 攻击带来的影响；对于企业业务来说，它则是构建边缘安全体系的重要起点。Cloudflare 不是万能的，但如果配置得当，它可以极大提升网站的安全性、稳定性和可用性。