请求量突然翻升、服务器负载升高、页面开始出现 502 或 504，这些现象既可能来自 CC 攻击，也可能来自活动开售、内容传播、搜索引擎集中抓取或客户端重试。仅凭 QPS、CPU 或某个 IP 的访问次数下结论，很容易把真实用户挡在门外。
区分两者的关键不是寻找一个万能阈值，而是观察请求是否符合业务行为。正常高并发通常能够在时间、入口、会话推进和业务结果之间形成解释；CC 流量则更容易出现重复、失衡、缺乏会话进展或资源成本异常。不过攻击流量可以模仿浏览器，真实用户也可能因为共享出口表现得像单一来源，所以每个信号都只能作为证据的一部分。
用六组证据建立判断矩阵
时间是否与业务事件一致
正常峰值常能与已知事件对应，例如内容发布、营销入口开放、消息推送、版本更新或外部链接传播。流量通常经过增长、峰值和回落，并在多个相关页面间扩散。异常请求可能毫无业务触发地出现，也可能长期保持机械节奏，但时间形态不能单独定性。预热不足的真实活动同样可能瞬间冲高，某些攻击也会故意制造自然波动。
排查时应把业务发布记录、监控告警、CDN 指标、Nginx 日志和后端慢查询对齐到同一时区。若团队各系统时区不同，应先完成时间换算，否则看似先发生的 CPU 异常，可能实际上晚于请求洪峰。
来源分布是否合理
查看客户端 IP、自治网络、地区和代理层来源，可以发现流量是否过度集中。但大量用户可能位于企业 NAT、校园网、移动运营商出口或 CDN 之后，单个 IP 并不等于单个用户。网站使用 CDN 或反向代理时，如果 Nginx 没有正确恢复可信代理传递的真实地址，日志中看到的可能只是节点 IP；贸然封禁会切断整批用户。
真实 IP 配置必须限定可信代理范围，不能无条件相信客户端自行提交的 X-Forwarded-For。调整前要保存 Nginx 配置，确认 CDN 官方公布的回源地址和请求头约定；修改后通过受控请求核对访问日志中的客户端地址；若出现地址伪造、日志异常或访问中断，应恢复备份并重新加载 Nginx。
会话是否在向业务目标推进
合法用户通常会形成页面、静态资源、接口和后续操作之间的序列。例如打开内容页后加载资源，登录成功后进入个人页，提交订单前访问商品与库存接口。CC 流量常反复集中在少数高成本 URL，Cookie 长期缺失或会话没有后续进展。然而 API 客户端、隐私保护浏览器和缓存命中用户可能没有典型页面链路，因此会话完整性需要按站点类型解释。
可以比较同一时间窗口内的入口页请求、静态资源请求、登录成功、表单提交和业务完成记录。如果请求暴涨而任何后续业务指标都没有相应变化，它会提高异常嫌疑，但不能把低转化本身当作攻击证据。真实热点内容也可能只有阅读，没有交易或注册。
请求成本是否异常失衡
两批流量即使请求数相同，对服务器的影响也可能完全不同。缓存命中的静态页面成本较低，触发数据库模糊搜索、复杂聚合、文件生成或外部调用的接口成本更高。若少数 URL 的占比快速升高，同时上游响应时间、PHP-FPM 队列、Java 线程池、Node.js 事件循环延迟或数据库连接等待恶化，应优先检查这些 URL 的调用链。
这里最容易犯的错误是把慢接口归咎于访问者。程序发布后出现索引缺失、缓存失效或无限重试，也会呈现请求增加与资源耗尽的组合。应检查同一版本在正常流量下的单请求成本，并确认客户端重试是否由服务端 5xx 或超时触发。很多雪崩并非外部攻击，而是故障让合法客户端不断重试。
请求细节是否具有机械重复
方法、URI、查询参数、User-Agent、Referer、Cookie、状态码和响应字节数可以揭示重复模式。大量请求若持续命中完全相同的动态入口、参数变化缺乏业务含义、响应始终很小或客户端忽略缓存，都值得进一步调查。但 User-Agent 很容易伪装，Referer 也不是可靠身份凭据，不能因为字符串陌生就直接拉黑。
相比某一个请求头，更可靠的是多字段组合。例如来源网络集中、会话不推进、固定访问高成本 URL、失败后立即重试，并且业务侧没有对应事件，这组证据比单纯的访问频率更有说服力。
处置后是否符合预期
安全的临时措施也能帮助验证判断。可先对单个高成本接口实施较宽松、可观察的限流，返回明确的 429 或业务可识别响应，并同时观察成功率、队列长度与投诉情况。如果后端压力明显下降且核心业务保持正常，说明该入口确实参与了资源耗尽；这仍不能自动证明所有被限制请求都是恶意的。
不要在没有基线时直接对全站启用严格限制，也不要把登录用户、匿名用户、API 调用方和搜索引擎放进同一计数桶。限流维度和响应方式要与业务协议匹配，尤其要避免客户端收到 5xx 后进行更激进的自动重试。
从 Nginx 日志提取可核验的事实
宝塔环境常见的 Nginx 安装目录是 /www/server/nginx，站点日志通常可在 /www/wwwlogs 附近查找，但实际路径应以当前站点配置中的 access_log 指令为准。Debian、Ubuntu 发行版安装的 Nginx 常使用 /var/log/nginx，CentOS 也常见该目录。不要因为路径常见就假定文件一定存在。
可先使用 /www/server/nginx/sbin/nginx -T 查看宝塔 Nginx 的完整生效配置；发行版 Nginx 则可使用 nginx -T。该命令的作用是输出并校验配置，从中确认日志路径、日志格式、代理设置和限流规则。风险在于输出可能包含域名、内部地址或证书路径，不应直接发布到公共渠道。验证方法是确认命令退出状态正常并找到目标 server 块；命令不修改配置，无需回滚。
获得日志路径后，可在授权范围内执行 tail -n 5000 /path/to/access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head，粗略查看日志首字段的来源分布。它只在日志首字段确实是客户端地址时有效。作用是快速建立候选来源列表，风险是大文件排序可能消耗 CPU 和内存，因此示例先用 tail 限定样本。验证时应核对 log_format，确保第一列含义正确；该命令不改动日志，无需回滚。
查看高频 URL 可使用 tail -n 5000 /path/to/access.log | awk '{print $7}' | sort | uniq -c | sort -nr | head，但第七列同样依赖常见日志格式。URL 可能带查询参数，直接聚合会把同一路径拆散，也可能在终端中暴露敏感参数。更稳妥的生产做法是使用已经脱敏的日志分析平台，或者按确认过的 log_format 编写解析程序。任何日志导出都应控制权限、保留周期和脱敏范围。
若要观察连接而不改动系统，可运行 ss -ant | awk 'NR>1 {print $1}' | sort | uniq -c 查看 TCP 状态分布。它的作用是判断是否存在大量 ESTAB、SYN-RECV 或 TIME-WAIT，但连接状态只能描述现象。风险主要是高连接数时命令本身产生短时开销；验证应通过多次采样与历史监控对照，无配置变更所以无需回滚。
限流配置必须带着回滚方案上线
无论使用原生 Nginx、CDN、网关还是宝塔 Nginx 防火墙进行 CC 攻击防护，都应先确定保护对象。动态搜索接口可以按客户端与接口限速，登录入口还要结合账号、设备和验证码策略，公开 API 则可能需要按访问凭证配额。单纯按 IP 限制，会误伤共享出口用户，也可能对分散来源的异常流量效果有限。
如果准备修改原生 Nginx 配置，应先复制目标配置文件并记录时间，执行 nginx -t；宝塔路径优先使用 /www/server/nginx/sbin/nginx -t。配置测试通过后再平滑重载。其作用是提前发现语法和引用错误，但测试通过不代表业务逻辑正确。重载风险包括阈值设置不当造成误限，以及配置作用域错误影响其他站点。验证要从外部完成正常浏览、登录、API 和健康检查，并监控 429、4xx、5xx、上游延迟及业务成功率。回滚时恢复变更前的配置，再次执行配置测试并平滑重载。
宝塔 Nginx 防火墙提供站点级 CC 防御等配置，但具体阈值不应脱离业务基线照抄。网站使用 CDN 时，还要按实际代理架构启用并核验真实 IP 相关设置。任何白名单都应尽量缩小到必要 IP、URL 或受认证接口，不能为了消除误报把整个站点长期放行。
可以定性，但要保留不确定性
一份可审计的判断应写成证据链，而不是一句遭到 CC 攻击。记录异常开始时间、受影响 URL、来源与会话分布、缓存命中变化、后端资源瓶颈、业务事件、临时措施及处置后的变化，同时列出尚未排除的程序故障、爬虫和客户端重试因素。
当时间线、来源异常、行为重复、高成本入口、业务无进展和处置反馈共同指向恶意消耗时，CC 攻击识别才具有较高可信度。证据不足时，更安全的表达是正在发生异常高并发，并继续采用可回滚、低误伤的措施。网络安全不仅要拦住异常请求，也要保护真正来访的用户。
延伸阅读