同一条限流规则，很难同时适配普通用户登录、管理员入口和机器账号。设计登录接口撞库防护的频率控制设计时，先按账号价值、登录方式和可接受的误拦截程度拆分业务，再决定限制维度与响应动作。
先选限流维度，再确定触发动作
只按单一来源地址限速，攻击者换来源后可能继续尝试；只按账号限速，又可能被恶意请求反复触发，阻止账号主人登录。较稳妥的做法是组合判断，并将失败次数、成功登录和验证码结果分别记录。
- 账号维度：识别对同一用户名或账号标识的连续失败，适合抑制针对单个账号的猜测；账号标识应规范化，避免大小写或格式差异绕过计数。
- 来源维度：观察同一网络来源在短时间内对多个账号发起的失败请求。共享网络、企业出口和移动网络可能带来误判，不宜仅凭来源直接长期封禁。
- 设备与会话维度：结合可信设备标记、会话状态等信号判断风险，但不能把浏览器指纹当作稳定身份，也要考虑清除数据或更换设备的情况。
- 全局维度：监控登录服务的整体请求量，保护验证服务和后端资源。全局阈值应结合正常峰值、容量和弹性扩容能力设定。
固定时间窗口实现简单，适合规则清晰的短时计数；滑动窗口能减少窗口边界突增；令牌桶允许一定突发流量，适合需要兼顾正常瞬时高峰的接口。算法没有脱离业务的通用最优解。
五类业务的细分参考
1. 面向公众的账号密码登录
适用于注册用户较多、密码登录仍常见的服务。可同时设置账号失败计数和来源异常检测：例如在数分钟内连续失败数次后要求验证码，继续失败再施加短时等待。具体次数和时长应根据正常输错率、攻击监控和申诉成本调整；避免一次失败就锁号。
2. 管理员与高权限入口
后台账号失陷的影响较大，宜采用更严格的阈值，并结合多因素认证、强密码策略和异常登录告警。普通登录与高权限操作可使用不同规则：登录阶段限制失败尝试，敏感操作再要求重新验证。对管理员直接长时间锁定仍可能造成业务中断，应保留受控的恢复流程。
3. 企业统一身份认证入口
企业单点登录可能跳转至身份提供方，限流应明确由哪一端负责密码验证。应用自身仍需限制登录发起、回调校验和异常重试，避免故障时客户端自动循环请求。共享办公网络用户较多，来源规则宜观察聚合行为，不应简单按单一出口封禁整个企业。
4. 短信或邮件验证码登录
这类业务不仅要限制验证码校验，还要限制验证码发送。可按账号、接收号码、来源及业务总量设置不同配额，并对重复发送设置递增等待；验证码应有有效期，成功使用后失效。短信发送通常还涉及费用和渠道容量，阈值需结合服务预算、送达延迟与正常重发需求评估。
5. API、服务账号与设备登录
机器账号的请求频率可能远高于人工操作，不宜直接套用交互式用户规则。优先使用独立凭证、明确的配额和调用方身份；达到限制时返回可识别的限流响应，并提供建议重试时间。若设备登录通过配对码或一次性凭证完成，也应限制凭证猜测和重复兑换。
落地时按这四步配置
- 盘点登录入口，区分密码、验证码、单点登录及机器凭证，并标记高权限账号。
- 为每个入口记录账号、来源、设备和全局请求的成功与失败数据，先观察正常流量，再设初始阈值。
- 按风险分级响应：轻度异常增加等待或验证码，持续异常短时限制，并记录触发原因；不要把所有异常都处理成永久封禁。
- 用正常输错、集中登录高峰、来源轮换和验证码重发等测试场景验证规则，监测误拦截、认证成功率及资源消耗，按结果调整。
频率限制不能替代密码安全、凭证保护和异常告警。可靠的登录接口撞库防护的频率控制设计，应让攻击尝试逐步变贵，同时让真实用户仍有恢复与申诉路径。
常见问题
失败几次后应触发限制？
没有适用于所有业务的固定次数。可从较短观察窗口内的少量连续失败开始试运行，再依据误拦截和攻击信号调整。
是否应该直接锁定账号？
通常不建议仅凭失败次数长期锁号。短时等待、验证码或额外验证更不容易被用于恶意阻断用户登录。
登录成功后要清空失败计数吗？
可清除该账号的连续失败状态，或让计数随时间衰减；同时保留必要的安全审计记录，便于发现短期内反复试探的模式。
验证码能否代替限流？
不能。验证码可增加自动化尝试成本，但发送、校验接口仍需限速，并要考虑无障碍访问和验证码渠道故障。
