搜索机器人放行实战#

将 Cloudflare（边缘抗压与粗过滤）、阿里云 WAF 3.0（七层精细化拦截与误报治理）、阿里云云防火墙 CFW（四层边界访问控制与 IPS/威胁情报） 组合使用，可以在“抗压”“拦截”“低误伤”之间取得更好的平衡。整套体系能否跑稳，取决于三个前提：

真实客户端 IP 识别全链路一致（否则限频/黑白名单/溯源全部失真）。
放行策略“可信 + 可控”（机器人与上游代理放行要做范围约束与防伪造）。
源站只信任上游（阻断绕过 Cloudflare/WAF 的直连攻击）。

第一部分：整体架构与真实 IP 透传（最关键前提）#

1.1 架构概览与流量路径#

典型链路如下：

用户 → Cloudflare → 阿里云 ALB（公网入口） → 阿里云 WAF → ECS 源站

在该链路中，源站默认看到的连接源 IP 往往是上游代理（Cloudflare/ALB/WAF）的地址；若不做正确配置，会直接导致：

CC/限频按 IP 失效或误伤；
访问日志与审计溯源不准；
风控画像、地域策略、投放平台回访定位偏差。

架构概览图：

整体架构图

流量与 Header 变化路径图：

流量路径与 Header 变化图

完整全路径流量图（含安全组配置）：

完整全路径流量图

1.2 Cloudflare 侧：确认真实 IP Header 回源存在且未被改写#

Cloudflare 回源请求中最关键的真实 IP Header：

CF-Connecting-IP：真实客户端 IP（单值，语义清晰，优先使用）
X-Forwarded-For：通用链路 Header（多级代理时为列表）

注意：

不要在 Transform Rules / Workers 中删除或覆盖 CF-Connecting-IP
“信任 Header”的前提是：源站网络层只允许可信上游访问（见后文源站与云防火墙加固）

1.3 ALB 侧：确保 X-Forwarded-For 不被删除#

ALB 建议配置为：

不删除 XFF（绝对不要 Remove/Delete）
可以选择 Add/追加（常见做法），以便后端具备标准化兜底链路

1.4 阿里云 WAF 3.0：配置“从 Cloudflare Header 获取真实 IP”（细节版）#

当 Cloudflare 在 WAF 前时，WAF 必须配置“前面有七层代理”，并指定从可信 Header 读取客户端 IP，推荐：

前面有七层代理：是
获取客户端真实 IP 方式：使用“指定 Header 的第一个 IP”作为真实 IP（防止 XFF 伪造）
Header Field（按优先级顺序）：
1. CF-Connecting-IP
2. True-Client-IP（若链路存在）
3. X-Real-IP（若链路存在）
4. X-Forwarded-For（兜底）

要点：

Header 可配置多个，WAF 按顺序匹配读取；缺失则按内置逻辑回退
选“第一个 IP”是为了避免攻击者在 X-Forwarded-For 尾部拼接伪造链路绕过

1.5 源站（ECS/Nginx/应用）日志与真实 IP#

即使 WAF 已正确识别真实 IP，仍建议在源站日志保留关键字段，便于排障与回溯：

remote_addr（网络层看到的源地址）
CF-Connecting-IP
X-Forwarded-For
User-Agent

第二部分：Cloudflare 侧防护策略（抗压 + 低误伤）#

本部分目标：把大流量（CC/HTTP DDoS）与高噪声攻击（扫描、注入探测）尽量挡在 Cloudflare 边缘，同时把“误伤”控制在可接受范围内——尤其是正常用户、投流审核/落地页预览 Bot、搜索引擎爬虫，以及**业务长 URL（长 query string/参数多）**不应被频繁触发托管质询/挑战页。

你要抓住 3 个原则：

优先用“机器可验证信号”放行 Bot（Verified Bot Categories），其次才用 User-Agent 兜底；
WAF 以“Managed Challenge（托管质询）”为默认缓解动作，比 JS Challenge 更低误伤；
先“观察/日志”，再“挑战/拦截”：所有规则都要能在 Security Events / Security Analytics 里定位到命中原因，然后用 Exception / Skip 精准豁免。

2.1 Cloudflare 最新版功能模块在哪里（控制台路径地图）#

以下路径以 Cloudflare 新版控制台为准（不同账号可能显示“Security rules page/安全规则”入口，但字段与逻辑一致）：

A. 安全设置总开关（Security Settings）#

位置：域名（Zone）→ Security → Settings（或页面顶部快捷入口 “Settings/Security Settings”）
作用：全局安全档位、紧急抗压开关等（更偏“粗颗粒”）

你主要会用到：

Security Level（安全级别）：决定对“可疑客户端”触发挑战的敏感度（越高越容易挑战）。
Under Attack mode（我正在遭受攻击/抗压模式）：L7 DDoS 最后手段，会给访问者加一层额外检查（会明显影响体验，且可能影响 API 流量，建议只在攻击期短期开启，并用 Configuration Rule 对 API 路径禁用）。
Browser Integrity Check（浏览器完整性检查）：基于特征过滤明显恶意请求（可能对少量非标准客户端有误伤风险，建议先观察事件再决定是否常开）。

B. WAF 主战场（Managed rules / Custom rules / Rate limiting）#

位置：域名（Zone）→ Security → WAF
核心页签：
1. Managed rules：Cloudflare 维护的规则集（主要拦 SQLi/XSS/RCE、常见漏洞利用、扫描特征等）
2. Custom rules：你自定义的规则（按表达式匹配，做 Block/Managed Challenge/Skip 等）
3. Rate limiting rules：按表达式匹配的限频（主要抗 CC、爆破、接口刷量）
4. Tools：User Agent Blocking 等工具（Cloudflare 官方建议优先用 Custom rules 替代单独的 UA 工具）

C. Bot 相关（Free / Business 关键差异）#

位置：域名（Zone）→ Security → Bots
Free：Bot Fight Mode（简单免费，无法精细调参）
Business：Super Bot Fight Mode（可对“确定是 Bot/疑似 Bot/Verified bots”分别选择 Allow/Challenge/Block，且可启用额外检测项）

D. 事件与溯源（误伤治理必用）#

位置：域名（Zone）→ Security → Events（Security Events）
Business 还建议重点看：Security Analytics（可做 Attack Score 维度分析、规则命中分布）

排障顺序永远是：先看 Security Events/Analytics 找到命中规则 → 再用 Exception/Skip 精准豁免，不要靠“整体关规则”解决误伤。

2.2 关键能力解释：每个“选型”的含义与推荐动作#

2.2.1 Managed rules（托底抗注入/扫描的主力）#

规则集分层（按计划可用能力不同）：

Cloudflare Free Managed Ruleset（Free/所有计划都有）：覆盖“高影响、广泛利用”的规则，默认在 Free 计划上已部署；特点是“更安全、低误报、运维成本低”。
Cloudflare Managed Ruleset（付费计划可用：Pro/Business/Enterprise）：覆盖更全面的 CVE/攻击向量，并持续更新；默认只开启部分规则以平衡误报，你可以按技术栈标签逐步增强。
Cloudflare OWASP Core Ruleset（付费计划可用：Pro/Business/Enterprise）：ModSecurity CRS 风格，覆盖很广，但更容易误报，Cloudflare 官方也提示“边际收益有限且更易误伤”，通常只建议在“高风险路径/后台/登录”按需开启，或用更保守参数。

推荐动作（低误伤优先）

先保证 Cloudflare Managed Ruleset（Business）处于启用，并保持默认的“部分规则开启”策略（默认就是为了降低误报）；
OWASP 只在你确认“误报可治理”的前提下再上，并从最低等级开始（PL1、较高阈值），且尽量限制在后台/登录等路径。

2.2.2 Rate limiting rules（抗 CC 的主力，强烈建议分路径）#

Rate limiting 是把 CC 压力“按请求特征”拆解成多个小桶来治：

表达式（Expression）：你要限频的流量范围（路径、方法、国家、ASN、UA、是否已登录等）
阈值（Requests / Period）：每个桶每个时间窗允许多少请求
动作（Action）：
- Managed Challenge（推荐）：Cloudflare 自适应质询，通常比 JS Challenge 更低误伤
- JS Challenge：更强硬，但对部分浏览器/网络环境体验更差
- Block：直接拒绝（注意：不同计划对“Block 的节流行为”限制不同；保守起见限频建议优先用 Managed Challenge）

推荐动作（低误伤优先）

限频一定要“按路径拆”：/login、/api、落地页、静态资源，各自阈值不同；
对“Verified Bots（搜索引擎/预览）”要做排除（见 2.5），否则投流审核/搜索爬虫会被限频误伤。

2.2.3 Custom rules（你用来做“精准挑战/精准放行/精准跳过”的手术刀）#

Custom rules 的核心在于 Skip：

Skip 不是简单 Allow，而是“跳过哪些安全阶段/产品”。你可以让某类请求跳过：
- 所有 Managed rules
- 所有 Rate limiting rules
- 所有 Super Bot Fight Mode 规则（Business） 这样就能做到：只让 Verified/可信 Bot 在“必要范围”内免检，而不是全站裸奔。

2.3 Business 版推荐配置（抗压 + 低误伤的“默认档”）#

下面给你一套“默认就能用”的 Business 配置，并附上“攻击期加固档”。

2.3.1 WAF → Managed rules（建议顺序）#

路径：Security → WAF → Managed rules

Cloudflare Managed Ruleset：启用（必须）

推荐：保持默认（默认只启用子集以降低误报），然后再按业务技术栈标签逐步增强。
如果你在做渗透/压测验证，才临时把规则集整体拉满（更容易误报，生产不建议常态如此）。

Cloudflare OWASP Core Ruleset：可选（谨慎）

如果你“注入/扫描变种非常多”，且 Cloudflare Managed Ruleset + Attack Score 仍不够，再考虑。
推荐只用于高风险路径（例如后台、登录、管理 API），并使用保守参数：PL1 + 较高阈值，并准备好做误报例外（Exception）。

2.3.2 WAF Attack Score Lite（Business 版“攻击评分分类”）#

Business 计划对 WAF Attack Score 提供“分类字段”（Attack / Likely Attack / Likely Clean / Clean）。

路径：Security → WAF → Custom rules
建议新建 2 条规则（按顺序从严到松）：

规则 1（最强拦截，低误伤）：
条件：WAF Attack Score Class = Attack
动作：Block（或至少 Managed Challenge）
规则 2（中等摩擦）：
条件：WAF Attack Score Class = Likely Attack
动作：Managed Challenge

这样可以在不依赖具体特征签名的情况下，补上对“变种注入/绕过/新型探测”的覆盖，同时比“全站高安全级别”误伤更低。

2.3.3 Rate limiting（Business：建议 4 类限频）#

路径：Security → WAF → Rate limiting rules → Create rule

A) 登录/验证码/敏感动作（爆破防护）

范围：/login、/api/login、/api/auth/*（按你的实际路径）
方法：POST
建议：小阈值 + Managed Challenge（例如 10 次/10 秒/每 IP，具体按你业务调整）

B) API 读接口（抗刷/抗 CC）

范围：/api/*（但排除静态与健康检查）
方法：GET
建议：中阈值 + Managed Challenge（例如 120 次/10 秒/每 IP）

C) 落地页/详情页（投流场景最常被打）

范围：落地页路径（例如 /lp/、/detail）
方法：GET
建议：更高阈值（要允许正常人+投流预览），但对异常高频仍挑战

D) 扫描器特征路径（减少噪声回源）

范围：常见扫描路径（如 /wp-login.php、/.env、/phpmyadmin 等）
动作：Block（或 Managed Challenge）
说明：这类拦截通常误伤极低，能明显降低“噪声请求”对你源站与阿里云侧的压力。

关键：Rate limiting 规则里要把 Verified Bot Categories 做排除（下一节给你通用写法），否则广告平台审核/搜索爬虫非常容易被误伤为 CC。

2.3.4 Bots（Business：Super Bot Fight Mode 推荐）#

路径：Security → Bots → Configure Super Bot Fight Mode

2.4 Free 版推荐配置（在能力受限下尽量“抗压 + 低误伤”）#

Free 计划可用的关键点：

Cloudflare Free Managed Ruleset 已默认部署（高影响漏洞/广泛攻击托底）。
Custom rules 在 Free 也可用，但数量更少（例如 5 条）且不支持 Log、Regex，所以你要“少而精”。
Bot 防护只有 Bot Fight Mode（域名级别，无法精细调参）。

2.4.1 Bots → Bot Fight Mode（Free 必开）#

路径：Security → Bots → Bot Fight Mode → On
作用：针对已知简单 Bot/部分 headless 做计算型挑战，减少无意义刷量。

注意：

Bot Fight Mode 是“全域”生效，不适合做精细放行/细分策略；
Verified bots 默认会被排除在“被当成坏 Bot 处理”的范围之外（但你仍要在 WAF/限频规则里对 Verified Bot Category 做排除，避免别的规则误伤）。

2.4.2 WAF（Free：用 3~5 条 Custom rules 做关键拦截/放行）#

路径：Security → WAF → Custom rules

建议 Free 的 5 条规则这样分配（顺序很重要：先放行/跳过，再挑战/拦截）：

Verified Bot 放行/跳过（Skip）（减少误伤）
落地页长 URL 豁免特定规则（Skip）（专治“长链接被挑战”）
登录/敏感动作挑战（Managed Challenge）
API 抗刷挑战（Managed Challenge）
扫描器常见路径直接 Block（高收益低误伤）

2.4.3 Rate limiting（Free：少量关键限频）#

路径：Security → WAF → Rate limiting rules
优先只做：登录/敏感动作、API 抗刷、落地页抗压 3 类；动作尽量用 Managed Challenge。

2.5 正常 Bot 放行（Facebook / TikTok / Google / Telegram 等）——“不靠猜 UA”的最新版做法#

你提到“通过 User-Agent 信任 Bot”，但最新版 Cloudflare 更推荐你优先用 Verified Bot Categories（可验证） 来放行，因为它是 Cloudflare 识别后的信号，误判与被伪造的风险更低，并且所有计划都可用。

2.5.1 优先级 1：Verified Bot Categories（推荐）#

你在规则里用的字段： cf.verified_bot_category

常用类别（用于“放行/跳过”）：

Search Engine Crawler：Googlebot、Bingbot 等搜索引擎爬虫
Page Preview：Facebook/Telegram/Slack/Discord 等链接预览
Advertising & Marketing：例如 Google AdsBot 等广告相关抓取/审核类 Bot

实操建议：不要手打字符串，直接在 Cloudflare 规则编辑器里选择字段并从下拉项选择类别，避免空格/拼写差异。

Business/Free 通用：推荐做一条 Skip 规则

路径：Security → WAF → Custom rules → Create rule
条件（示例逻辑）：
- cf.verified_bot_category in {Search Engine Crawler, Page Preview, Advertising & Marketing}
- 且 http.request.method = GET
- 且 http.request.uri.path 在你的“落地页/公开页面/静态资源”范围内
动作：Skip（跳过）
- 勾选跳过：Managed rules、Rate limiting rules
- Business 额外可勾选：Super Bot Fight Mode rules（如果你希望 Verified bot 完全免受 SBFM 影响）

这样能最大化保证：搜索/投流预览/广告审核 Bot 不会被当成攻击流量导致托管质询。

2.5.2 优先级 2：User-Agent 兜底放行（仅用于“非 Verified”的平台机器人）#

如果某些平台审核 Bot 没出现在 Verified bots 列表里（或你看到它的 cf.verified_bot_category 为空），你再用 UA 兜底，但必须加 3 个限制，避免“UA 伪造导致全站裸奔”：

兜底放行规则写法（建议用 Skip，不建议纯 Allow）：

必须限制：
1. 只允许 GET
2. 只允许落地页与必要静态资源路径（例如 /lp/、/detail、/assets/）
3. 仍保留核心防护给写接口（POST/PUT/DELETE 一律不因 UA 放行）

你可以在 Custom rules 里写“UA 包含 facebookexternalhit / TelegramBot / TikTokSpider / AdsBot-Google 等”并配合上面的范围限制，然后动作选 Skip（跳过 Managed rules + Rate limiting）。

2.6 长 URL 被托管质询/挑战的治理（不靠“关 WAF”）#

长 URL（参数多、query 很长）常见被挑战原因有两类：

被 Managed rules / OWASP 的“请求异常/注入特征”误判；
被 Rate limiting 当成高频或被 Bot 策略误判。

2.6.1 先定位命中点（必做）#

进入：Security → Events（或 Security Analytics）
找到那条被挑战的请求，确认：
- 是哪个产品命中（Managed rules / Custom rules / Rate limiting / SBFM）
- 具体命中的规则名/规则 ID/规则集

2.6.2 再做精准豁免（两种方式二选一）#

A) 对 Managed rules 建 Exception（推荐，粒度更细）

路径：Security → WAF → Managed rules → Add exception
条件：只匹配“会出现长 URL 的那一类页面/参数模式”，并尽量只跳过“导致误判的那个规则/标签/规则集”。
好处：保留其它规则继续保护，不会扩大攻击面。

B) 用 Custom rule 的 Skip（最快捷）

路径：Security → WAF → Custom rules → Create rule
条件：只匹配你的长 URL 页面范围（例如 /lp/、/detail）
动作：Skip（仅跳过 Managed rules / Rate limiting 中你需要跳过的部分）
注意：Skip 规则一定要“范围小”，避免把后台/API 一并跳过。

2.7 攻击期“一键加固”预案（不影响 API 的做法）#

当你遭遇大规模 CC 时，建议按顺序升级（每一步都能回滚）：

先加 Rate limiting（按路径）：优先对热点路径加 Managed Challenge（低误伤）
再提高 Security Level（短期）：从 Medium → High
再启用 Under Attack mode（最后手段）：只在攻击峰值期开，并建议用 Configuration Rule 对 /api/* 禁用 Under Attack，避免 API 被挑战影响业务调用

2.8 你可以直接照抄的“通用规则骨架”（建议落地）#

下面是“策略骨架”，你把路径替换成你自己的即可：

Verified bots（Search/Preview/Ads）→ Skip（Managed rules + Rate limiting +（Business 可选）SBFM）
落地页长 URL → Skip（仅跳过导致误判的那部分）
登录/敏感动作（POST）→ Rate limiting + Managed Challenge
API（GET）→ Rate limiting + Managed Challenge
常见扫描路径 → Block

（本节配置要点对应 Cloudflare 官方最新文档：WAF（Managed rules / Custom rules / Rate limiting / Skip）、Verified Bot Categories、Bot Fight Mode / Super Bot Fight Mode、Security settings、Under Attack mode。）#

第三部分：阿里云 WAF 3.0 防护策略（精细拦截 + 误报治理）#

3.1 核心 Web 防护：注入 / XSS / 命令执行 / WebShell#

保持核心规则组开启作为主战场。误报治理建议优先用“白名单跳过部分模块”，不要一键关闭核心防护。

3.2 扫描防护（Scan Protection）：最容易误伤投流审核的模块之一#

投流平台审核/预览抓取常见行为：

短时间集中抓取
访问路径较深、参数复杂
重试较多

建议：

扫描防护保持开启
对明确可信且有业务价值的抓取（Meta/TikTok/Telegram/Ads）建立“可控放行”白名单：只跳过必要模块，并严格限制 URI 范围（落地页 + 静态资源）

3.3 白名单（Whitelist）：正确的放行姿势是“跳过指定模块”#

白名单用于让匹配请求绕过全部或指定模块。对机器人放行建议：

只跳过必要模块（例如扫描防护、部分访问控制或限频）
保留核心 Web 攻击防护
限制 URI 范围（只放行落地页、OG 元信息页、必要静态资源）

第四部分：投流/搜索机器人放行（Google/Bing/Meta/TikTok/Telegram 等）#

放行原则：

不要只靠 UA（可伪造）
放行必须限制范围（只放行落地页与资源，不放行后台与写接口）
可信优先（Verified Bots / DNS 反查验证）

4.1 常见 UA 放行规则清单#

adbot
AdsBot-Google
AdsBot-Google-Mobile
bingbot
Bytespider
facebookcatalog
facebookexternalhit
facebot
googlebot
linkedinbot
meta-externalads
meta-externalhit
slackbot
telegrambot
TikTokSpider
twitterbot
twitterbot/1.0

4.2 三段式放行模型（推荐）#

A. 强可信（优先）：可验证搜索机器人

Cloudflare：Verified Bots 豁免挑战/限频
源站/应用：需要强校验时，对 Google/Bing 做反向 DNS + 正向 DNS 校验

B. 中可信（可控放行）：投流审核 / Link Preview Fetcher

只放行落地页与必要资源
保留核心 Web 防护
扫描防护/部分限频可跳过或放宽

C. 低可信（谨慎）：AI/采集型爬虫

没有业务收益的抓取建议限速或阻断，避免带宽与资源被消耗

第五部分：源站加固（防绕过）#

5.1 源站只允许可信上游访问#

ECS 安全组：仅允许来自 WAF 回源 CIDR、必要的 ALB 私网网段/安全组、以及按需的 Cloudflare IP 段
删除不必要的公网放通（例如 0.0.0.0/0 直连源站）

第六部分：阿里云云防火墙 CFW 加白 Cloudflare 与 ALB，防止误拦截（精确到“在哪配、源是谁、目的是谁”）#

本节以“Cloudflare → ALB（公网入口）→（可选）WAF → ECS”为例，把“云防火墙 / ALB / ECS 安全组”三层分别要加白什么讲清楚。你可以只做其中一层，但生产上建议三层收口，减少单点配置误改带来的风险。

6.0 先判断：云防火墙是否会影响你的入口#

如果你没有在云防火墙配置任何“互联网边界访问控制策略”，云防火墙默认允许互联网流量进入资产（你仍可能被 IPS 拦截，见 6.4）。
一旦你启用“严格访问控制”（例如默认拒绝、只允许白名单），必须把 Cloudflare / 必要探活流量显式放行，否则会出现全站不可用或间歇性失败。

6.1 在云防火墙（Cloud Firewall）“互联网边界”加白：允许 Cloudflare → ALB 公网入口#

在哪里配（控制台路径）：
Cloud Firewall 控制台 → Protection Configuration → Access Control → Internet Border → Inbound（入向）
在入向页签里，选择 IPV4 或 IPV6，点击 Create Policy 创建策略。

策略要点（源是谁 / 目的是谁）：

Source（源）： Cloudflare 官方 IP ranges（IPv4 + IPv6）
Destination（目的）： 你的 ALB 公网入口（ALB 绑定的 EIP / 公网 IP）
Protocol/Port： TCP:80、TCP:443（或你的实际监听端口）
Action： Allow（允许）
Priority： 高于“拒绝所有”的兜底规则（即更高优先级）

推荐写法：两条允许 + 两条兜底拒绝

允许（IPv4）

Source: Cloudflare IPv4 IP ranges
Destination: ALB EIP（或公网 IP）
Port: 80/443
Action: Allow
Priority: 高

允许（IPv6）

Source: Cloudflare IPv6 IP ranges
Destination: ALB EIP（或公网 IP）
Port: 80/443
Action: Allow
Priority: 高

拒绝兜底（IPv4）

Source: 0.0.0.0/0
Destination: ALB EIP（或公网 IP）
Port: 80/443
Action: Deny
Priority: 低（必须低于允许规则）

拒绝兜底（IPv6）

Source: ::/0
Destination: ALB EIP（或公网 IP）
Port: 80/443
Action: Deny
Priority: 低（必须低于允许规则）

运维注意：Cloudflare IP ranges 会调整，务必以 Cloudflare 官方页面为准定期更新（建议用地址簿/地址组统一管理，然后策略引用地址簿）。

6.2 在 ALB 自身加白：只允许 Cloudflare 访问监听端口（第二道收口）#

仅在云防火墙放行还不够稳。更推荐在 ALB 自身也做一次“只允许 Cloudflare”的访问控制，避免云防火墙策略被误改后 ALB 直接暴露公网。

在哪里配（方式 1：ALB 安全组，最常见）：
ALB 控制台 → 找到实例 → 关联 Security Group（安全组） → 在该安全组的 Inbound（入方向） 里加规则。

源是谁 / 目的是谁：

Source（源）： Cloudflare IP ranges（IPv4 + IPv6 CIDR）
Destination（目的）： ALB（安全组绑定到 ALB 实例）
Protocol/Port： TCP:80、TCP:443（与监听端口一致）
Action： 允许（Allow 规则）

重要：ALB 安全组要实现“白名单”，通常需要“允许 + 拒绝”配合
ALB 文档说明：如果 ALB 实例加入安全组后仅有 Allow 规则、没有 Deny 规则，监听端口可能仍允许所有请求；要做到“只允许特定 IP”，需要同时配置 Deny 规则（或使用具备默认拒绝能力的安全组类型/默认规则）。实际以你所用安全组类型（基础/高级）与实例形态为准。

推荐规则组合：

Allow：Cloudflare IP ranges → ALB → TCP:80/443（高优先级）
Deny：0.0.0.0/0（以及 ::/0）→ ALB → TCP:80/443（低优先级）

额外注意：ALB 通常存在“托管/managed 安全组”规则用于 ALB 与后端通信。不要把 ALB 的本地地址（local IP）加到最高优先级 Deny 里，否则可能中断 ALB 与后端的通信。

在哪里配（方式 2：ACL）：
部分场景可用 ALB/SLB 的 ACL（访问控制列表）对白名单 CIDR 生效。原则与字段不变：源=Cloudflare IP ranges，目的=ALB 监听器，端口=80/443，白名单优先于拒绝。

6.3 在 ECS 源站加白：放行 WAF 回源 CIDR（必须做，否则大量 5xx/超时）#

只要你启用阿里云 WAF 作为代理回源，源站看到的请求源就会是 WAF 的 back-to-origin CIDR。如果源站安全组没放行，会导致：

WAF 无法回源，业务大量 5xx / 超时
源站误把 WAF 回源段当攻击 IP 段封禁

在哪里配（ECS 安全组）：
ECS 控制台 → Network & Security → Security Groups → 选中源站安全组 → Inbound → Add Rule。

源是谁 / 目的是谁：

Source（源）： WAF back-to-origin CIDR blocks（从 WAF 控制台获取，必须全量添加）
Destination（目的）： ECS 实例（安全组绑定到 ECS，目标端口是你的服务端口）
Protocol/Port： HTTP(80)、HTTPS(443) 或你的实际应用端口（例如 8080/8443）
Action： Allow
Priority： 最高（例如 Priority=1），并再加一条最低优先级 Deny 兜底（例如 Priority=100，源=0.0.0.0/0）把源站收口到“只允许 WAF 回源段”

若你的源站只在内网被访问（不暴露公网），云防火墙互联网边界可能看不到该内网流量，但 ECS 安全组一定会生效。

6.4 云防火墙 IPS 仍可能拦截“已允许”的流量：需要单独处理 IPS（避免误拦）#

云防火墙的 访问控制（Access Control） 与 IPS（入侵防御/虚拟补丁） 是两条不同的拦截链路：

访问控制 Allow 只表示“通过 ACL/访问策略”
IPS 仍可能在阻断模式下拦截同一条流量（例如被识别为扫描、漏洞利用特征）

在哪里配（IPS 白名单/Allowlist）：
Cloud Firewall 控制台 → Prevention / Intrusion Prevention（IPS 配置页）
在对应实例/边界的 Actions 列中，进入 Configure IPS Whitelist，分别配置 “Source IP Allowlist” 与 “Destination IP Allowlist”（以控制台实际字段为准）。

源是谁 / 目的是谁：

Source allowlist（源白名单）： 你信任的来源 IP（示例：Cloudflare 边缘节点 IP）
Destination allowlist（目的白名单）： 你信任的目的 IP（示例：ALB 公网入口 EIP 或 ECS EIP）

实操建议：Cloudflare IP 段数量较多，而部分 IPS 白名单能力可能存在条目数量上限。更通用的做法是：

攻击期先把 IPS 从 Block 调整为 Monitor/观察，确保业务稳定；

再按拦截日志逐步加精确例外（或仅对白名单入口资产启用 IPS 阻断）。

6.5 最终核验清单（上线前必做）#

云防火墙（Internet Border → Inbound）

Allow：Source=Cloudflare IP ranges → Destination=ALB EIP → TCP:80/443（高优先级）
Deny：Source=0.0.0.0/0（IPv6 用 ::/0）→ Destination=ALB EIP → TCP:80/443（低优先级）

ALB 自身（安全组或 ACL）

Allow：Source=Cloudflare IP ranges → Destination=ALB → TCP:80/443
Deny：Source=0.0.0.0/0（以及 ::/0）→ Destination=ALB → TCP:80/443
确认未误伤 ALB 与后端的本地通信地址（避免把 local IP 加入高优先级 Deny）

ECS 源站（安全组 Inbound）

Allow：Source=WAF back-to-origin CIDR → Destination=ECS → 服务端口（高优先级）
Deny：Source=0.0.0.0/0 → Destination=ECS → 服务端口（低优先级，按需）

云防火墙 IPS

若启用 Block：先确认未误拦关键入口；必要时改为 Monitor 并按日志逐步收紧

排障顺序

先看云防火墙拦截日志（Access Control / IPS）
再看 ALB 安全组/ACL 命中情况
再看 WAF 拦截日志
最后看源站 access log（Header/IP 是否一致）

参考链接（运维定位用）#

Cloud Firewall：Create inbound/outbound access control policies for the Internet firewall
https://www.alibabacloud.com/help/en/cloud-firewall/cloudfirewall/user-guide/create-inbound-and-outbound-access-control-policies-for-the-internet-firewall
Cloud Firewall：Configure access control policies（参数说明示例）
https://www.alibabacloud.com/help/en/cloud-firewall/cloudfirewall/use-cases/configure-access-control-policies
Cloud Firewall：IPS configuration（含 Configure IPS Whitelist）
https://www.alibabacloud.com/help/en/cloud-firewall/cloudfirewall/user-guide/prevention-configuration
ALB：Use security groups as blacklists or whitelists for ALB（白名单与规则优先级注意事项）
https://www.alibabacloud.com/help/en/slb/application-load-balancer/use-cases/use-alb-security-groups-to-implement-blacklist-and-whitelist-access-policies
WAF：Allow access from the back-to-origin CIDR blocks of WAF（源站放行 WAF 回源段）
https://www.alibabacloud.com/help/en/waf/web-application-firewall-2-0/user-guide/allow-access-from-the-back-to-origin-cidr-blocks-of-waf
WAF：Configure protection for an origin server（安全组 Allow + Deny 的推荐写法）
https://www.alibabacloud.com/help/en/waf/web-application-firewall-2-0/user-guide/configure-protection-for-an-origin-server
Cloudflare IP ranges（官方）
https://www.cloudflare.com/ips/
https://www.cloudflare.com/zh-cn/ips/