CC 攻击（应用层请求洪泛）的本质是：攻击者用“看起来像正常访问”的大量 HTTP/HTTPS 请求，把你的并发连接、动态接口计算资源、回源带宽与数据库/缓存拖到极限，最终让正常用户变慢甚至不可用。要用蓝易云CDN把 CC 防护做“能落地、可运营”，建议按下面这套闭环来做 🛡️

1）先做“防绕过”：源站封口是分水岭

很多 CC 之所以扛不住，不是边缘没策略，而是攻击者绕过 CDN 直打源站。务实做法：

• 源站仅允许“CDN 回源出口”访问（白名单），其他入口一律拒绝
• 后台管理、API 内网口与数据库完全不暴露公网
• 关键路径（登录/支付/下单）单独域名或路径策略隔离

结论：没有源站封口，CDN 防护价值会被大幅削弱。

2）边缘侧“控成本”：分接口限频 + 行为校验

CC 的核心对抗思路是让异常请求“变贵、变慢、变少”，并尽量不误伤真实用户。

建议策略（按优先级）

• 分 URI 限频：对 /api/、/login、/search、/comment 这类动态接口设置更低阈值；静态资源放宽
• 分维度限流：不要只按 IP（共享出口会误伤），要结合 UA、Cookie、Referer、路径、参数特征做组合判断
• 挑战/校验：对可疑请求启用 JS/Cookie 校验或交互验证，让脚本与代理池成本上升 🤺
• 灰度生效：先“观察/记录”再“拦截”，把误杀控制在可接受范围

运营要点：把“误杀率”和“拦截率”一起看，CC 防护不是越严越好，而是“稳住核心链路”。

3）源站兜底“保可用”：限并发 + 降级熔断

当边缘仍有漏网流量，源站必须有“最后一道闸门”，否则会被慢慢磨穿。

• 限制单 IP 并发，防连接堆积
• 限制接口请求速率，防 QPS 撞爆
• 非核心功能降级（如推荐、排行榜、非必要查询），优先保登录/下单等主链路 🔥

可直接用的兜底配置示例（Nginx/OpenResty）

用途：源站作为“兜底闸门”，即使有流量绕过或回源异常，也能把损害限制在边界内。

# 1) 定义限速区域：按客户端IP统计，每秒10个请求
limit_req_zone $binary_remote_addr zone=api_rate:10m rate=10r/s;

# 2) 定义并发连接限制：按客户端IP统计，限制并发连接
limit_conn_zone $binary_remote_addr zone=addr:10m;

server {
  location /api/ {
    # 3) 对 /api/ 启用限速：允许短时突发20个，超过就拒绝
    limit_req zone=api_rate burst=20 nodelay;

    # 4) 限制单IP并发连接最多50
    limit_conn addr 50;

    proxy_pass http://backend;
  }
}

逐行解释（确保你能拿去给运维/研发直接对齐）

• limit_req_zone $binary_remote_addr zone=api_rate:10m rate=10r/s;
  • 以“客户端 IP”为统计键（$binary_remote_addr 性能更好），建立名为 api_rate 的共享内存区（10MB）
  • rate=10r/s 表示：每个 IP 每秒最多 10 个请求（适合动态接口兜底）
• limit_conn_zone $binary_remote_addr zone=addr:10m;
  • 建立并发连接统计区，后续用来限制单 IP 同时建立的连接数量
• limit_req zone=api_rate burst=20 nodelay;
  • 引用 api_rate 限速区
  • burst=20 允许短时间突发（例如用户连续点击/弱网重试）
  • nodelay 表示不排队，超阈值直接拒绝，更适合抗压场景
• limit_conn addr 50;
  • 单 IP 并发连接上限 50，防止连接洪泛拖垮工作进程/连接池
• proxy_pass http://backend;
  • 通过限流与并发控制后，再转发到后端服务，保证后端资源优先留给“更像真人”的请求

最后的“老板版”落地口径 ✅

用蓝易云CDN做 CC 防护，核心就是三件事：
1）源站封口（防绕过，决定成败）
2）边缘限频 + 行为校验（把异常流量挡在边缘）
3）源站兜底限流与降级（最坏情况下也保核心链路）

这套做完，你的防护就从“靠运气”升级成“可运营的系统能力”。💪