刚创建一个后台账号，第一次手工登录就提示账户被锁。直接解锁能暂时进去，但几分钟后又锁上，说明还有别的请求在持续提交错误密码。先找请求来源，再解锁。
先把锁定时间和访问日志对上
只查询这个管理员的失败次数、锁定到期时间和状态，不要把整张管理员表导出来。然后在 Nginx/Apache 日志里按后台登录路径、用户名相关请求时间和来源 IP 对照。Magento 不一定把用户名明文写入访问日志，可以结合 Session、IP、User-Agent 和请求频率判断。
常见来源包括浏览器密码管理器自动提交旧密码、可用性监控把登录页当表单探测、旧自动化脚本，以及另一位管理员还开着保存旧凭据的窗口。
如果来源 IP 是公司出口，继续按 User-Agent 和请求间隔区分具体客户端。固定每 30 秒一次更像监控，打开页面马上连续数次更像浏览器自动填充或脚本重试。必要时在受控时间短暂增加登录失败审计字段，但不要把密码、验证码或完整 Cookie 写进日志。
确认没有重试后再解锁这个用户
bin/magento admin:user:unlock username
bin/magento admin:user:create --help优先使用当前版本 CLI 解锁指定用户，不要批量清空所有管理员的 failures。完全无法进入后台时，可以按应急流程创建临时高强度账号，处理完成后立即禁用，并保留审计记录。
一台节点正常、一台节点总锁，就查时间和Session
负载均衡环境里，应用节点与数据库时间不一致会让锁定到期判断异常。检查 NTP、PHP 时间和数据库 UTC 时间。若后台 Session 分散在本地文件，登录请求切节点也可能表现异常，但它通常还会伴随掉线或 Form Key 问题。
解锁后分别测试密码、2FA 和退出重登。再故意输错一次，失败计数应该只增加一次；一次点击增加多次，就继续查代理重试或前端重复提交。把真正的自动重试源停掉，才算解决，不是把锁定阈值改得更大。
还要确认失败发生在哪一步。密码错误会增加登录失败计数，2FA 验证失败属于后续认证流程；如果界面统一显示“锁定”，日志里仍应能分开。把 2FA 问题误当密码爆破处理，解锁多少次都会再次失败。
