判断 CC 攻击，不能只看访问量突然升高：活动、内容传播或搜索引擎抓取也会带来正常峰值。关键是把请求来源、访问路径和服务器状态放在一起看。做好CC攻击识别与网站访问限速设置，可以先识别异常模式，再对高风险请求采取有范围的限制。
先看哪些信号
先比较异常时段与相近日期、相近时间的访问日志，观察每分钟请求数、热门路径、来源分布、响应状态码和响应耗时。若少数页面请求量陡增，同时应用进程、数据库连接或响应时间明显恶化，就需要进一步排查。
- 请求集中：大量请求反复访问搜索、筛选、商品详情等动态路径，或不断请求不同参数组合。
- 来源异常：单一来源短时间请求密集，或大量来源呈现相似的访问节奏。来源地址分散不代表一定是攻击。
- 访问行为单一：请求几乎只打某个接口、缺少正常页面浏览过程。浏览器标识等字段可以参考，但容易伪造，不能单独作为封禁依据。
- 服务端承压：响应耗时、超时和 5xx 错误增加。若请求数上升但服务器负载平稳，也应核实是否只是静态资源或缓存命中增加。
把这些信号与业务事件、发布安排及已知爬虫记录交叉核对，有助于区分流量高峰和恶意请求。单个指标不足以定性，CC攻击识别与网站访问限速设置应以连续观察到的模式为依据。
用 Nginx 做分层限速
Nginx 的 limit_req 可限制请求速率，适合控制高频访问；limit_conn 则限制并发连接。前者侧重请求到达速度，后者侧重同时占用的连接数，两者不能互相替代。以下示例按来源地址统计，只适用于 Nginx 配置了相应模块的情况。
- 在 http 配置段定义共享区：limit_req_zone $binary_remote_addr zone=perip:10m rate=5r/s;。这表示按来源地址统计，基准速率为每秒 5 个请求；实际容量和适用速率要结合服务器资源、业务请求模式调整。
- 在目标站点的 server 或特定 location 中加入：limit_req zone=perip burst=20 nodelay;。该设置允许一定突发量，超出可处理范围的请求会被拒绝；nodelay 会让突发请求立即处理，可能增加短时后端压力。
- 可在相应配置范围设置 limit_req_status 429;，让被限流请求返回 429 状态码，表示请求过多。不要对全站直接套用同一阈值，优先从耗资源的动态接口或容易被滥用的路径开始。
- 保存前运行 nginx -t 检查语法，通过后再执行 systemctl reload nginx 平滑加载。具体命令和服务管理方式可能因系统安装方式不同而变化。
- 观察限速命中数、正常请求的 429 比例、响应时间及后端负载。若正常用户频繁受限，先收紧适用路径或放宽阈值，再检查代理环境下来源地址是否识别正确。
阈值怎么定，怎样减少误伤
不要把每秒 5 次当作通用标准：一个页面可能同时加载多个资源，而高频调用接口也可能有明确业务需求。先用访问日志估算正常用户在短时间内的请求速率，再从低风险路径试行；对变化明显的接口单独设定策略，并逐步调整。针对登录、搜索等动态操作，可以结合账号、会话或业务规则判断，避免只按共享出口地址限流，误伤同一网络下的多个用户。
限速只能控制进入本站的部分请求，无法替代容量评估、日志监控和上游流量处置。对于来源分散、流量已占满网络入口的情况，应联系托管服务商或网络运营方排查。将识别、限流和效果复核串成流程，才是有效的CC攻击识别与网站访问限速设置。
常见问题
访问量上涨就一定是 CC 攻击吗？
不是。还要结合访问路径、来源特征、业务活动和服务器表现判断，单看请求量容易误判。
限流后用户看到 429，怎么处理？
先确认命中规则和受影响路径，再核对阈值是否适合正常访问模式。必要时放宽规则或缩小限流范围。
按来源地址限流会不会误伤？
会有这种可能。同一公司、校园或家庭网络中的用户可能共用出口地址，因此高频业务应考虑更细的路径或身份维度。