登录量突然上升时，先别把所有请求都当成攻击封掉。判断应用层CC攻击与正常登录高峰区分，关键不是看某个时刻请求多不多，而是看请求是否符合真实用户的操作过程，以及它给应用和数据库造成了什么影响。
应用层CC通常通过大量看似正常的应用请求，反复消耗登录接口、验证码服务或数据库资源；正常高峰则可能来自活动开始、服务恢复、通知发送后用户集中访问等情况。两者都可能让登录接口变慢，单看总流量或单个来源 IP，容易误判。
先比较行为，而非只数请求
把当前数据与近期同一时段的基线比较，优先检查登录接口的请求速率、成功与失败比例、响应状态码和延迟。基线最好按小时、星期和已知业务事件分别观察；新系统没有历史数据时，可先按分钟记录，逐步建立自己的参考范围，而不是套用通用阈值。
- 操作是否连贯：正常用户通常会加载页面、建立会话，再提交登录；大量请求若集中重复调用同一接口，几乎没有前置页面访问，也不符合常见操作顺序，应进一步核查。
- 失败是否异常：登录失败率短时间明显升高，且密码错误、账号不存在等结果集中出现，可能是自动化尝试；但用户输错密码、统一登录故障也会造成类似现象，须结合事件背景判断。
- 请求分布是否单一：大量来源请求内容、路径和节奏高度相似，或集中访问少数账号，风险较高。反过来，来自同一企业出口或运营商网络的许多真实用户可能共用 IP，不能因此直接封禁。
- 资源消耗落在哪：若登录接口延迟上升，并伴随应用线程、身份验证服务或数据库查询压力增加，说明请求确实触及关键资源。若请求增多而处理能力、成功率与延迟稳定，处置力度可以更温和。
用分层处置代替一刀切
确认应用层CC攻击与正常登录高峰区分时，不要依赖单一指标。建议按“观测、限速、验证、封禁”的顺序，逐步提高干预强度，并保留正常登录通道。
- 保存观测数据：按分钟查看接口请求量、成功率、失败原因、响应时间和来源分布；记录活动通知、服务变更等可能解释流量变化的事件。注意保护账号标识等敏感数据，分析时优先使用脱敏后的日志。
- 设定分层限速：先依据接口承载能力和正常使用基线，为单账号、会话或来源设置不同限制。共享出口场景下，应避免只按 IP 限流；限制触发后可返回明确的稍后重试提示，减少用户反复提交。
- 对可疑请求增加验证：对短时间重复失败、行为高度相似的请求，逐步启用验证码或其他风险验证。验证范围宜尽量精准；若所有用户一律增加验证，会给真实高峰带来额外阻碍。
- 满足条件再封禁：当某来源持续触发限制、行为证据一致且验证无法通过时，再对来源或相关账号采取短时限制。定期检查封禁效果和误伤情况，必要时撤销规则。
判断时要留意的误区
首先，失败率不是攻击结论。密码策略调整、登录服务异常或用户集中尝试旧密码，都可能让失败率升高。其次，验证码通过率只能作为辅助信号：自动化工具可能绕过某些验证，真实用户也可能因图片识别困难而失败。还要注意接口重试机制；客户端在超时后自动重试，可能把一次高峰放大成密集请求。
如果限流后响应延迟下降、失败请求减少，而正常登录成功率保持稳定，规则可能起到了缓解作用；若成功率也明显下降，应及时缩小规则范围并复核共享出口、账号分布和重试行为。具体阈值取决于接口设计、服务容量和用户使用习惯，不能直接照搬其他系统的数据。
常见问题
流量突然翻倍，能直接判断为攻击吗？
不能。还要看失败率、请求模式、服务端压力，以及是否有活动或通知等合理原因。
同一个 IP 请求很多，应该封吗？
不宜仅凭这一点封禁。家庭、办公网络和运营商出口都可能由多人共享，先结合账号、会话和请求行为判断。
验证码是否应该对所有登录者启用？
通常更适合作为分层措施。对风险较高的请求增加验证，既能提高拦截能力，也能减少对正常用户的影响。
稳妥的判断方式，是把行为证据、登录结果和资源影响放在一起看，再逐级采取措施。做好持续观测与小范围验证，才能更可靠地完成应用层CC攻击与正常登录高峰区分，避免把真实用户挡在门外。