刚接手账号安全，先别把登录失败简单等同于恶意请求：用户输错密码、脚本批量试密码，都可能产生失败记录。登录接口撞库防护的频率控制设计，关键是让自动化尝试变慢，同时避免攻击者借限速锁死真实用户。以下方案适用于常见的账号密码登录，阈值需要结合业务流量和验证能力调整。
先按三个维度计数，不要只看来源
撞库脚本可能更换网络出口，也可能集中尝试少数账号。只按来源限速，攻击者换出口就能绕过；只按账号限速，则可能针对同一来源的大量账号逐个尝试。建议至少分别统计账号、来源和设备信号，并结合接口整体负载判断。
- 账号维度：按规范化后的登录名计数。失败次数可以跨不同来源累计，降低轮换网络出口的效果。计数键应避免直接保存明文账号，可用带密钥的摘要生成标识。
- 来源维度：统计同一网络出口在短时间内对多个账号的失败请求。共享网络、企业出口和移动网络可能承载许多正常用户，适合触发验证码或提高校验强度，不宜轻易永久封禁。
- 设备维度：结合稳定的客户端标识、设备令牌等信号辅助判断。设备信息可能缺失或被更换，不应作为唯一拦截依据，也要谨慎处理隐私数据。
登录失败响应尽量保持一致，不应通过提示信息泄露账号是否存在。账号锁定可以阻止继续尝试，但长期、无条件锁定容易被利用来干扰用户登录；优先采用短暂延迟、验证码或额外验证等渐进措施。
按流量特点选择窗口和动作
滑动窗口适合识别短时突发
滑动窗口按最近一段时间内的请求计数，能较直观地限制连续失败。实现时应原子地完成计数与过期时间更新；多台应用服务器可以使用共享计数存储，例如 Redis。固定窗口实现简单，但请求集中在两个窗口交界处时，短时间内可能出现接近双倍的通过量。
令牌桶适合保留少量正常突发
令牌桶允许短暂突发，随后按设定速率恢复令牌，适合希望控制持续请求速度、又不想让正常用户偶尔重试就被拦截的场景。实践中可将它用于来源或接口整体限流，再用账号维度的失败计数触发递进措施。算法选型不是替代多维规则，而是决定每个维度怎样计时与放行。
可先用一组保守的观察值做灰度起点：同一账号在约5分钟内失败5至10次后增加等待或验证；同一来源在约1分钟内出现数十次失败时，先触发更强校验或限制突发请求。它们不是通用安全线：登录量、共享网络比例和验证码可用性不同，实际阈值应依据基线、误伤率和攻击信号调整。
上线时按步骤落地
- 盘点入口：列出密码登录、验证码校验、找回密码等相关接口，确认它们不会因走不同路径而绕过计数。
- 定义计数规则：区分成功与失败。通常只有密码验证失败才增加账号失败计数；成功后可清理或衰减该账号的短期失败状态，避免历史错误长期影响用户。
- 设置递进动作：先记录和告警，再增加短暂延迟或验证码，风险更高时才限制请求。对账号设置短时冷却时，应提供安全的恢复或验证路径。
- 保证分布式一致：计数更新应原子执行，并设置明确过期时间；存储故障时要预先决定降级策略，避免所有用户被意外拒绝，或限速完全失效。
- 灰度并复核：先观察失败率、验证通过率、登录成功率和限速命中量，再逐步扩大范围。测试正常用户连续输错、共享网络多人登录、自动化高速尝试及计数服务异常等情况。
把防护效果纳入持续监控
登录接口撞库防护的频率控制设计不能只看拦截请求数。还应关注被限速用户后续是否成功登录、验证码是否集中失败，以及账号失败是否从一个入口转向另一个入口。日志记录规则命中类型和时间即可，避免记录密码、验证码等敏感内容。发现误伤时，先检查账号规范化、共享出口和阈值，再调整动作；发现绕过时，则补齐遗漏入口或维度，而不是一味加严账号锁定。
常见问题
成功登录后要清零失败次数吗？
可清理短期账号失败计数，或按策略逐步衰减。若保留长期累计风险，应与短期限速计数分开管理。
验证码能替代频率限制吗？
不能。验证码可增加自动化成本，但可能被绕过或影响正常用户；应与多维计数和渐进限速配合。
达到阈值后应直接锁号吗？
通常不宜长期锁号。优先采用短时等待、额外验证和可恢复的冷却策略，避免他人通过反复试错阻止账号主人登录。
最终规则应由数据校准，而不是照搬固定数字。把账号、来源、设备与接口负载组合起来，逐步验证误伤和拦截效果，才是可运营的登录接口撞库防护的频率控制设计。
