WordPress 后台登录马上被踢回登录页：Cookie 域、HTTPS、盐值和页面缓存怎么查

上周帮一个迁完域的站查问题：后台账号密码都对，登录后闪一下仪表盘，马上又回到 wp-login.php。更别扭的是，有人能在 /wp-admin/ 里待着编辑文章，前台一刷新却又变成未登录，购物车、会员入口全丢。这类症状十有八九不是密码错了，而是 Cookie 没真正落稳，或者落稳了又被 HTTPS 配置、盐值、页面缓存其中一层冲掉。

我一般不急着重装、换主题。先把现象钉死，再按层往下抠，一次只动一层，方便回滚。

1. 先分清两种「登不进去」

别一上来改盐值。用无痕窗口登录一次，打开开发者工具 → Application（或「存储」）→ Cookies，看当前主机名下有没有 wordpress_logged_in_*、wordpress_sec_*，并记下 Domain、Path、Secure、HttpOnly：

完全没有 Cookie ------ 登录响应里根本没下发，或被浏览器拒收（域 / Path / Secure 对不上）。Network 里点开登录那条 POST，看响应头有没有 Set-Cookie。
Cookie 有，但一跳就没了 ------ 常见是页面缓存把「已登录 HTML」或带 Set-Cookie 的响应缓存给了匿名用户，下一个人拿到脏状态；也可能是盐值验签失败，下一请求直接作废。
后台能待着，前台像没登录 ------ 多半是 Cookie 的 Domain/Path 只覆盖了 /wp-admin/，或前台走了另一套主机名（www / 裸域 / CDN 源站不一致）。

把现象归到上面三类之一，后面就不会乱改。若连 Set-Cookie 都看不到，优先查下面第 2、3 节；若有 Cookie 却立刻失效，优先查第 4、5 节。

换域名、去掉 www、或者把站点从子目录挪到根目录之后，旧的 Cookie 参数经常还留在 wp-config.php 里。对照检查：

站点地址（后台「设置 → 常规」里的 WordPress 地址 / 站点地址，对应 siteurl / home）是不是你实际访问的那个主机名。不要一边用 https://www.example.com，一边用裸域登录------两边 Cookie 互相看不见。
若自定义过 Cookie，看是否有类似：

php 复制代码

define('COOKIE_DOMAIN', '.example.com'); // 注意前导点；跨子域才需要
define('COOKIEPATH', '/');
define('SITECOOKIEPATH', '/');
define('ADMIN_COOKIE_PATH', '/');

COOKIE_DOMAIN 写成了旧域名、写成了带端口的值、或者写成了和当前证书主机名不一致的值，浏览器会直接丢弃。不确定时，先注释掉这几行，清 Cookie 再登录一次，看能否恢复。
Path 如果还是 /blog/（当年装在子目录），根目录访问时 Cookie 不会带上；反过来，子目录站点若 Path 写成 /，也可能和同域其他应用抢 Cookie。

域名或迁移刚做完、登录态又反复丢的，常见对照点我整理在域名/迁移后登录态异常的排查要点，可以和本文对照着看。

3. HTTPS 和 FORCE_SSL_ADMIN 别打架

第二种高频原因是协议不一致：前台强制 HTTPS，后台却还在走 HTTP，或者反代终止 SSL 后，WordPress 以为自己还是 HTTP。表现往往是「登录成功 → 跳到后台 → 立刻被重定向回登录页」。

逐项看：

浏览器地址栏是不是全程 https://，中间有没有一次跳到 http:// 再跳回来（混用会导致 Secure Cookie 对不上，或登录 Cookie 只在其中一个协议下有效）。
wp-config.php 里如果写了 define('FORCE_SSL_ADMIN', true);，前面的 Nginx / 负载均衡必须把 X-Forwarded-Proto: https 正确传进来，否则后台会在「强制 HTTPS」和「自己以为是 HTTP」之间来回踢。
反代场景可在确认头已正确后，于 wp-config.php 靠前位置加一小段（这是本文唯一需要动的配置块示例）：

php 复制代码

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

改完清浏览器 Cookie，再登录验证。别同时改盐值和协议，否则分不清是哪一层修好的。若站点在 CDN 后，还要确认源站回源协议和「始终 HTTPS」规则没有互相打架。

4. 盐值（AUTH_KEY 等）：换域或从备份恢复后必查

WordPress 用 AUTH_KEY、SECURE_AUTH_KEY、LOGGED_IN_KEY、NONCE_KEY 以及对应的 *_SALT 给登录 Cookie 签名。迁移时如果：

从别的环境拷了 wp-config.php，盐值和当前库里的用户会话对不上；
或者有人「安全起见」重新生成了盐值，但没让所有人重新登录；
备份恢复时库是新的、wp-config.php 却是旧盐值（或反过来）；

表现就是：刚登录成功，下一请求验签失败，立刻踢回登录页。有时只影响部分角色或只影响前台会员 Cookie，更像「玄学」。

处理很直接：确认八个常量完整且唯一，不要留 put your unique phrase here 这种占位；改完之后所有人必须重新登录（旧 Cookie 全部作废）。不要在生产高峰随意轮换盐值，除非你明确要踢掉全站会话。轮换前先通知编辑同事，并确认没有长期「记住我」依赖。

第三种「后台能进、前台乱」或「登录后马上又像没登录」，经常是缓存插件 / Nginx fastcgi_cache / CDN 干的：

登录成功响应里带了 Set-Cookie，若被全页缓存，后来的匿名访客会拿到别人的登录头，或者拿到「半登录」的脏页面。
已登录用户看到的仪表盘、顶栏、「你好，某某」被当成公开 HTML 缓存，匿名用户一刷新又变回游客版------看起来像 Cookie 坏了。
部分缓存插件默认排除了 /wp-admin/，却没排除带 wordpress_logged_in_ Cookie 的前台请求，于是后台正常、前台会员状态乱跳。

排查时：

缓存规则里排除带 wordpress_logged_in_、wordpress_sec_、comment_author_ 等 Cookie 的请求；
对 /wp-login.php、/wp-admin/、admin-ajax.php、/wp-json/ 一律不缓存；
临时关掉页面缓存插件（或给自己加 bypass Cookie）再登录一次，若立刻正常，就回到缓存规则上改，而不是继续改盐值；
CDN 控制台看该 URL 是否命中缓存、响应里是否误带了 Set-Cookie。

6. 修完怎么验收

我习惯用这张小清单收工，少一项都不算稳：

无痕窗口登录成功后，Cookies 面板能看到 wordpress_logged_in_*，Domain/Path 与当前主机名、站点根路径一致，Secure 标志与 HTTPS 一致。
刷新 /wp-admin/ 不会被踢回登录页；再开一个前台标签，顶栏或会员状态与后台一致。
退出登录后，上述 Cookie 清除；再登录仍正常（排除「碰巧还留着旧 Cookie」）。
换一台设备或手机流量再测一次，排除本机残留与公司代理干扰。
若开了页面缓存 / CDN，用未登录身份访问首页，响应头不应出现别人的 Set-Cookie，页面也不应出现「已登录」痕迹。
隔几分钟再刷新一次（等缓存轮转），确认不是「刚清缓存那一下碰巧好了」。

登录态看起来玄学，其实大多是域、协议、盐值、缓存四层叠在一起。按上面顺序一层层确认，通常比反复重装、换主题快得多。如果你想按自己站点的域名、HTTPS 和缓存现状过一遍问题清单，可以看这份按站点现状出问题清单的免费诊断。

WordPress 后台登录马上被踢回登录页：Cookie 域、HTTPS、盐值和页面缓存怎么查

1. 先分清两种「登不进去」

2. Cookie 域和 Path：迁移后最容易漏

3. HTTPS 和 FORCE_SSL_ADMIN 别打架

4. 盐值（AUTH_KEY 等）：换域或从备份恢复后必查

5. 页面缓存：别把 Set-Cookie 和已登录 HTML 缓存出去

6. 修完怎么验收