输入正确的管理员账号密码，POST 返回 302，看起来已经进入 Dashboard，紧接着又回到登录页。没有“密码错误”提示时，应先把它当作 Session cookie 未被后续请求发送或服务端找不到，而不是重置管理员密码。

浏览器里看两次请求

检查登录响应的 Set-Cookie，再看 Dashboard 请求是否带回同名 cookie。重点比较 Domain、Path、Secure、SameSite、Expires。后台 URL 带自定义 frontName 时，错误的 Cookie Path 可能只覆盖前台根路径或旧后台路径。

若浏览器拒绝 Cookie，开发者工具通常会给出原因，例如 Secure cookie 经 HTTP 设置、Domain 不匹配或 SameSite 限制。

Base URL 与反向代理必须一致

外部访问 HTTPS、Magento 却认为是 HTTP，可能生成错误 cookie 和重定向。检查 secure/unsecure Base URL、offloader header、可信代理与 Host 转发。不要在生产直接把 Secure 关闭当长期修复，应让应用正确识别原始协议。

bin/magento config:show web/cookie/cookie_domain
bin/magento config:show web/cookie/cookie_path
bin/magento config:show web/secure/use_in_adminhtml

配置值为空不一定错误，Magento 可以使用默认范围；要与实际响应头结合判断。

多节点 Session 漂移

登录 POST 落到节点 A，Dashboard 落到节点 B；若使用本地文件 Session，B 找不到刚创建的数据。临时启用负载均衡粘性只能验证，长期应使用正确的共享 Session 存储并保证所有节点 crypt key 一致。

旧 Cookie 冲突

同一域名存在两个同名 cookie、不同 Path 时，浏览器可能同时发送，服务器选择结果不符合预期。用无痕窗口测试能发现，但真正修复要调整 Domain/Path 并让旧 cookie 过期，而不是要求所有管理员永久清浏览器。

修复后测试直接打开后台 URL、登录、刷新、跨后台页面、退出和重新登录，并在两个节点间切换。确认每次请求使用同一 Session，才不是一次偶然成功。

安全日志能排除账号层问题

查看管理员用户是否被锁定、失败次数和登录事件，但不要为了排查关闭二次验证或修改密码策略。若 POST 之后已经产生成功登录事件，随后请求立即变成匿名，证据更支持 Cookie/Session；若从未产生成功事件，才回到账号状态、验证码和认证插件。

只在一个浏览器失败时

检查该浏览器是否阻止第三方 Cookie、安装了改写请求的扩展，或保存着旧域名的 HSTS/代理规则。用新建干净浏览器配置做对照可以定位客户端因素，但站点仍应返回可理解的提示，不能让管理员在无提示循环中反复提交密码。