海外网站遭遇 CC 攻击怎么办？

直接回答： CC / 七层洪水由看起来完全合法的请求组成，所以加大带宽永远解决不了它，能解决它的是「区分」。先用四个信号确认它是不是七层洪水：URI 高度集中、请求链断裂（不取静态资源、没有 referrer 递进）、JA4 与会话指纹复用、按端点看的尾延迟异常。然后按顺序缓解：先 HTTP DDoS 规则，再针对攻击模式调敏感度，接着对承压端点收敛限流规则，然后用 Managed / Interactive 挑战（API 用 Turnstile），最后才是临时自定义规则。

为什么七层攻击是另一回事

流量型攻击靠容量取胜：入口带宽比攻击者能填满的还多就行。而 HTTP 洪水——很多中文团队称之为 CC 攻击——靠的是区分，因为每一个单独的请求都是合规的。它建立正常的 TCP 连接、说正确的 HTTP、请求你网站本来就提供的页面。没有畸形包可过滤，也没有字节阈值可吸收。

这个区别决定了后面所有事情。给七层洪水加带宽毫无作用。有用的是对每个请求回答一个问题：这是不是真实用户，这个请求值不值得响应？ 下面讲的是如何按正确顺序构建这个答案。

四个信号：怎么判断这是七层洪水

信号	看什么	为什么重要
与业务曲线背离	请求量上涨，但订单、注册、会话数没动	最便宜也最可靠的检测器——真实增长一定同时体现在业务指标上
集中度	流量集中在少数 ASN、国家、路径或 UA 上	真实受众是分散的，洪水是集中的
昂贵端点	调用集中在搜索、导出、登录、报表生成上	攻击者专挑高成本路径，因为那里少量请求就能造成大伤害
行为不匹配	没有页面间的跳转递进、不请求静态资源、没有 referrer	真实会话会取静态资源并跳转，脚本不会

第四个最具诊断价值，也最少被埋点。一个反复请求 /api/search 却从不请求 CSS 文件的会话，不是用户。

真正奏效的缓解顺序

1. 先止血，再撤掉应急手段。 Under Attack Mode 在文档里被定义为最后手段之一，会插入约五秒插页并影响你的统计。用它换几分钟时间，然后回退——一直开着等于把攻击变成一次自残式宕机。

2. 把缓存挡在源站前面。 对大多数站点，这是收益最高的一项改动：打向可边缘响应页面的洪水，根本到不了你的基础设施。Cache Rules 支持按路径、查询串、请求头或 Cookie 匹配，直接从缓存响应而不回源。

3. 让自动层做粗粒度的工作。 HTTP DDoS 托管规则集在所有套餐都运行。低套餐只有一个 override，且不能自定义表达式；默认敏感度在 1,000 errors/s 触发，Pro/Business/Enterprise 还要求错误率达到正常水平约 5 倍才缓解。敏感度（High/Medium/Low/Essentially Off）属于这个规则集——可以调，但要清楚它天生是粗粒度工具。

4. 为你看到的模式写针对性规则。 上一步四个信号的价值，在这里变成策略：匹配集中的 ASN、被滥用的路径、缺失的 referrer。WAF 自定义规则条数为 5 / 20 / 100 / 1,000，正则表达式需 Business 及以上。

5. 在量仍然伤人的地方加限流。 限流规则：Free 1 条、Pro 2 条、Business 5 条、Enterprise 100 条（视合同）。统计周期从 Free 的固定 10 秒到 Enterprise 可配置的最长 65,535 秒；缓解超时从 10 秒到一天。计数维度比条数更重要：Free 与 Pro 仅 IP，Business 起更丰富，Enterprise 加装 Advanced Rate Limiting 后有 query/host/header/cookie/ASN/country/path/JA3-JA4。

6. 在应用层保护昂贵路径。 Turnstile 免费，但服务端校验是强制的，token 有效期 300 秒且一次性使用。把它与队列、降级一起用在搜索、导出、报表端点上，这样即使洪水成功，服务也是降级而不是中断。

分层缓解

Cloudflare 能力 vs 应用层职责

事项	Cloudflare 提供的	你的应用必须做的
粗粒度自动检测	HTTP DDoS 托管规则集，全套餐	决定敏感度；接受低套餐只有一个 override 的现实
针对性阻断	WAF 自定义规则（条数受套餐限制，正则需 Business+）	用真实事件信号维护规则集，而不是靠猜
速率控制	限流规则；按数据中心计数，缓解有几秒延迟	在昂贵端点上实现权威配额
缓存吸收	按路径、查询串、请求头、Cookie 匹配的 Cache Rules	让响应可缓存：正确的响应头，共享路径里不要塞用户级 HTML
真人校验	Turnstile——免费；服务端校验强制；token 300 秒一次性	把它接进登录、搜索、导出流程
优雅降级	—	昂贵操作的队列、超时与降级模式

边界与不适用情况

• 限流无法表达精确配额。文档明确它不是为了让精确数量的请求通过而设计，计数器按数据中心累计，缓解有几秒延迟。如果你需要按账号或按 API Key 的硬上限，计数必须放在应用层。
• 缓存只对可缓存内容有效。打在个性化、按用户生成的 HTML 上的洪水，边缘吸收不了。如果每个响应都独一无二，第 1 层不可用，只能在 3–6 层补偿。
• 挑战对真实用户是有代价的。Managed 与 Interactive Challenge 都会增加摩擦，用在合作伙伴或爬虫也在用的路径上是有成本的。范围应限定在真正被打的部分。
• 自动规则集抓不住低速慢打。低于约 1,000 errors/s 且没有错误率飙升时，默认阈值不会被触发。慢速攻击要靠你自己的规则和限流，而不是托管层。
• 不要把应急控制常开。Under Attack Mode 会暂停访问并扭曲统计；它是有责任人和回退步骤的应急开关，不是配置项。

FAQ

CC 攻击和 DDoS 是一回事吗？ 它是 DDoS 的一类，而且是最不符合刻板印象的一类：量不大、请求合法、靠分类而非容量来缓解。很多团队买了容量，然后惊讶地发现不大的请求速率照样把站点打挂。

升级套餐能解决吗？ 部分能。更多限流规则、更好的计数维度、更多 WAF 规则与正则支持确实有用。但如果昂贵端点在应用层既没缓存也没限速，升级套餐只是把崩溃点往后挪，而不是消除它。

预算很少时从哪开始？ Free 有 1 条仅按 IP 计数、周期固定 10 秒的限流规则，5 条 WAF 自定义规则，以及自动的 HTTP DDoS 规则集。把这点预算花在「缓存被打的路径」和「一条选得好的限流」上，而不是试图让免费档表现得像 Enterprise。

怎么判断攻击结束了？ 反向看同样四个信号：请求量回到业务曲线，异常 ASN 或路径上的集中度消失，静态资源请求回来了。到那时再关应急开关，而不是等告警不响了才关。

相关阅读

• 出海企业如何选择 DDoS 防护服务？
• 网站遭受 DDoS 攻击时，CDN 能否解决问题？
• 企业级 WAF 应该如何选择？
• 应用安全解决方案