被 CC 攻击时 Nginx 层能做的五件事

CC 攻击（模拟正常访问、耗尽应用资源的请求洪水）的特征很直白：总流量不一定大，但请求密集地砸向少数几个动态接口，CPU 和连接数先被拖垮。攻击进行时，Nginx 层按下面五步处置，多数轻量级 CC 能顶住。 ## 一、先看清楚谁在打 ``` awk '{print $1}' access.log | sort | uniq -c | sort -rn | head awk -F'"' '{print $6}' access.log | sort | uniq -c | sort -rn | head ``` 前一条统计来源 IP，后一条统计 User-Agent。攻击源要么 IP 集中，要么客户端标识高度一致。看清楚再动手，别把正常用户和搜索引擎爬虫一起封了。统计完再看一眼带宽和 CPU 曲线，找到攻击开始的时间点，日志分析的范围就有了边界。 ## 二、对动态接口限流 limit_req 模块按请求速率限制，http 块定义，location 里应用： ``` limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s; server { location /api/ { limit_req zone=one burst=20 nodelay; } } ``` 正常用户一秒钟打不出十个接口请求，超出的直接拒绝。rate 和 burst 按业务实际调，别一刀切误伤。限流策略在攻击期间一直保持，攻击停止后记得放宽，否则高峰期的正常用户会被误拦。 ## 三、拦下可疑客户端标识 日志里看到明显异常的 User-Agent，直接拒绝： ``` if ($http_user_agent ~* "python-requests|scanner") { return 403; } ``` 正则要按自家日志里的实际特征写，照抄网上的规则容易误杀。 ## 四、加一层访问验证 对登录、查询、提交这类接口加验证码或 JS 挑战，纯脚本发动的 CC 过不了这一关。简单实现：对可疑来源跳转到设置 Cookie 的中转页，后续请求无 Cookie 直接拦截。验证码层放在这些手段之后再用，它对真实用户有打扰，能靠限流和拦截挡住的，不必动用它。 ## 五、量级上来就上高防 前面四条都是缓解手段，攻击规模超出单机处理能力时，把入口切到高防节点才是正解。顺云的高防云服务器 S2、S4 标配 60G DDoS 防御，适合中小业务的前置防护；对资源独享有要求的，裸金属物理机 B4 扛得住更大的量。切换前确认源站做了回源限制，别给攻击者留直连的后门。 Nginx 层防护的目标不是拦得一个不剩，而是把攻击成本抬高到对方不划算。日志持续观察，策略跟着攻击手法调整。