WordPress 登录后跳回登录页或一直转圈：先核 Cookie、站点 URL 与 HTTPS，再查 CDN 与安全插件

账号密码明明对了，点「登录」却又回到 wp-login.php，或者进度条转个不停、后台仪表盘永远进不去------前台首页往往还能打开，站点并没有整站挂掉。这和昨天写过的数据库连不上、表单 SMTP、HTTPS 整站重定向环、严重错误白屏、Woo 结账转圈、媒体库上传、WP-Cron、Shopify 主题旧版不是一类故障：PHP 与 MySQL 多半还活着，卡在 登录会话能否写进浏览器并在后续请求里带回来 （Cookie Domain / Secure / Path → siteurl/home 与访问域一致 → HTTPS 与反代头 → CDN/缓存是否误缓存后台 → 安全插件会话策略）。

更稳的顺序是：先用 无痕窗口 复现，并在 DevTools Application → Cookies 看登录响应有没有落下 wordpress_logged_in_* → 核 siteurl / home 与你实际敲的域名、协议是否一字不差 → 再查 FORCE_SSL_ADMIN、反代 X-Forwarded-Proto、COOKIE_DOMAIN / COOKIE_SECURE → 中段才动 CDN 对 wp-login.php / wp-admin / admin-ajax.php 的排除 → 最后才对照安全插件的会话锁定、双因素、IP 变更踢下线。别一上来就清全站缓存，也别在生产上直接卸掉全部安全插件。

先分清：Cookie 没落稳 vs 站点 URL 不一致 vs HTTPS/反代 vs CDN 缓存后台 vs 安全插件会话

「登录跳回 / 转圈」常见落在五条线上，别混着改：

• Cookie 没写上或写了带不回来 ：登录 302 响应里缺少 Set-Cookie，或 Cookie 的 Domain/Path/Secure/SameSite 与当前访问不匹配；浏览器 Application 面板里看不到 wordpress_logged_in_*，或 Domain 落在错误主机名上。
• siteurl / home 与访问域不一致 ：库里仍是旧域、裸域与 www 混用、http 与 https 混用。登录成功后核心按「权威 URL」跳，浏览器却在另一套域上，表现就是跳回登录或半截转圈。
• HTTPS / 反代头 / 强制 SSL ：前面 Nginx、负载均衡、CDN 做了 TLS 终结，源站仍以为自己是 http；或 FORCE_SSL_ADMIN、错误的 COOKIE_SECURE 导致 Secure Cookie 在「浏览器以为的 http」场景下被丢弃。
• CDN / 全页缓存误伤后台 ：边缘把 wp-login.php、/wp-admin/、甚至带登录 Cookie 的 HTML 缓存成「未登录壳」或错误 302；也可能把 Set-Cookie 剥掉、改写 Host。
• 安全插件 / 双因素 / 会话策略：登录次数限制、异地 IP 强制登出、Cookie 加盐改名、REST/admin-ajax 拦截，会让「看起来登录成功」立刻失效。要在副本或维护窗做单变量对比，而不是一口气全关。

先记下：无痕能否登录、Application 里 Cookie 名单与 Domain、siteurl/home 原文、CDN 是否对后台路径有规则。再决定是改 URL 还是改缓存排除。

第一步：无痕复现 + DevTools 看 Cookie 是否真正落下

用管理员账号，但先换 无痕 / 私密窗口（排除本机旧 Cookie、扩展、密码管理器捣乱）：

1. 打开 https://你的域名/wp-login.php（协议、是否带 www 与日常习惯保持一致），输入正确凭据登录一次。
2. 打开开发者工具 → Network ，勾选 Preserve log，再登录一次。点开登录那条 POST wp-login.php：
   • 状态应是 302 （或 303），Location 指向 /wp-admin/ 或仪表盘相关路径。
   • 响应头里应有多条 Set-Cookie ，名称通常含 wordpress_logged_in_、wordpress_sec_（具体后缀随站点变化）。
   • 若 200 留在登录页并提示错误 → 先当凭据/验证码/安全插件拦截，而不是 Cookie 问题。
   • 若 302 的 Location 又指回 wp-login.php → 高度怀疑 URL 不一致或 Cookie 立刻被判定无效（第二、三步）。
3. 切到 Application（或存储）→ Cookies → 当前源 ：
   • 有无 wordpress_logged_in_*？Domain 是 .example.com 还是只绑了 www / 裸域 / 甚至 CDN 主机名？
   • Secure 是否勾选？你当前地址栏是否确为 https://？Secure Cookie 不会在纯 http 下发送。
   • Path 是否被收窄到异常路径，导致进 /wp-admin/ 时带不上？
4. 对比：无痕能进、常规窗口不能 → 清本机该域 Cookie 或关掉可疑扩展后再测；两边都不能 → 服务端/CDN/URL 问题，进入第二步。
5. 预期现象：登录成功后，无痕下能稳定打开「仪表盘」，刷新仍保持登录；Application 里登录相关 Cookie 的 Domain 与你地址栏主机名匹配。

这一步结束时应能口头说清：「Set-Cookie 有没有出来；Domain/Secure 对不对；无痕能不能进后台。」说不清就不要先改 wp-config。

第二步：siteurl / home、COOKIE_DOMAIN 与 HTTPS 反代

Cookie 链路看起来「写了又丢」或 302 指回登录时，核权威 URL 与 Cookie 作用域：

1. 若偶发还能进后台：到 设置 → 常规 ，看「WordPress 地址（URL）」与「站点地址（URL）」是否与你浏览器地址栏的协议+域名完全一致 （含 www、是否 https、有无子路径）。不一致先在维护窗改成一致，改前备份。
2. 进不了后台时，用 WP-CLI 或只读查库（生产先快照）：

# 只读查看（把示例域换成自己的）
wp option get siteurl
wp option get home

或在数据库 wp_options（注意表前缀）里查 option_name 为 siteurl、home 的值。两者应指向你真正用来登录的那个 https 域。

3. wp-config.php 里若曾手写：

define( 'WP_HOME', 'https://www.example.com' );
define( 'WP_SITEURL', 'https://www.example.com' );
define( 'COOKIE_DOMAIN', '.example.com' );
define( 'COOKIE_SECURE', true );
define( 'FORCE_SSL_ADMIN', true );

核对：COOKIE_DOMAIN 不要写成带端口、带路径、或与当前域无关的值；子域多站点才需要宽松的前导点域名。COOKIE_SECURE / FORCE_SSL_ADMIN 为 true 时，整条访问链必须是 https，且反代要正确传递协议。

4. 反代 / 负载均衡 TLS 终结 ：源站 Apache/Nginx 若仍看到 http，WordPress 可能生成 http 的重定向或错误地处理 Secure Cookie。在反代层把 X-Forwarded-Proto（或等价头）设对，并让 WordPress/服务器信任该头（具体指令因栈而异）。排障对比：临时用 hosts 直连源站 https，绕过 CDN/反代------直连能登录、经边缘不能，就定界在边缘或头传递，而不是用户表坏了。
5. 改 URL 类选项属于高风险：改完用无痕复测登录与前台链接；保留改前值以便回滚。不要同时改域名、清全站缓存、关安全插件三件事搅在一起。

站点 URL 与 HTTPS 对齐后仍只能「登录闪一下又回来」，继续查边缘是否在改写后台响应。

第三步：CDN / 全页缓存是否误伤 wp-login 与 wp-admin

许多「登录死循环」最终落在缓存层：边缘把未登录的登录页或错误 302 缓存给了已提交凭据的浏览器，或对带 Cookie 的请求仍返回公共缓存。

1. 在 CDN / 缓存插件规则里确认：排除 （或 Bypass）至少：
   • /wp-login.php
   • /wp-admin/（整段路径）
   • /wp-admin/admin-ajax.php、/wp-json/（若后台依赖）
   • 请求头含 WordPress 登录 Cookie 的 HTML 页（按厂商「按 Cookie 绕过」能力配置）
2. 对上述路径做一次 定向 Purge，再用无痕登录。避免一上来 Purge Everything 掩盖「到底哪条规则在误缓存」。
3. Network 里看登录后的文档请求：响应头若出现异常的 Age、X-Cache: HIT、或与源站不一致的 Server/Via，且正文仍是登录壳 → 边缘 HIT 了不该缓存的响应。
4. 若 CDN 提供「源站 Host / 回源 Host」改写，确认回源 Host 与证书、与 siteurl 一致，避免 Set-Cookie 落在 CDN 域名上。
5. 缓存插件（页面缓存、移动端缓存、单独「登录用户缓存」开关）同样按路径与「已登录用户不缓存」核对；改一条、测一次。

把「后台路径排除、按登录 Cookie 绕过、回源 Host」放在同一条链路上看，比单独清浏览器有用。CDN 与缓存分层的排查顺序可对照 CDN 与缓存分层排查，先定界是边缘 HIT 还是源站会话问题，再改规则。

第四步：安全插件、双因素与会话锁定

前三步都干净，仍跳回登录时，再动安全类插件------且一次只动一个变量：

1. 看安全插件日志：是否有「登录成功后立即强制登出」「Cookie 校验失败」「IP 变更」「国家限制」「REST 被拦」。
2. 维护窗对单个可疑模块做对比：会话锁定、强制重新登录、自定义 Cookie 名、禁用 XML-RPC 时误伤的后台通道等。能进后台后先复测核心业务，再决定是否保留该策略的宽松版。
3. 双因素 / 邮件魔法链 / SSO：第二步验证码页若被缓存或被 CDN 剥 Cookie，也会表现为「转圈后回登录」。对验证回调 URL 同样做缓存排除。
4. 服务器时钟严重漂移会导致会话票过期异常；抽查 NTP / 容器时区是否与 WordPress 时区离谱偏离。
5. 不要为了进后台在生产上长期关闭整站 WAF 或全部安全插件；对比结束立刻恢复，并把放行路径写进变更说明。

验证与回滚

建议验收动作（同一维护窗口）：

1. 无痕：正确凭据可进入仪表盘；刷新、点「文章 / 插件」菜单仍保持登录。
2. Application：wordpress_logged_in_* 存在，Domain/Secure/Path 与 https 访问域一致；Network 里登录 POST 带 Set-Cookie。
3. siteurl / home（或 WP_SITEURL / WP_HOME）与地址栏一致；反代协议头抽测无误。
4. CDN / 缓存：wp-login.php 与 /wp-admin/ 为 Bypass/排除；登录后文档响应不再是错误的缓存 HIT。
5. 安全插件：仅保留已验证过的策略；临时关闭项已恢复并记录。
6. 回滚：siteurl/home 改前值；wp-config Cookie/SSL 常量注释还原；CDN 排除规则可单条撤销；缓存 Purge 记录时间。勿用「删用户再重建」当首选回滚。

排障窗口尽量短；稳定后把权威域名、CDN 后台排除清单、安全插件会话相关开关写进运维备忘，避免下次有人只改 CDN 半截。

验收清单（技术）

• 无痕可稳定登录后台；常规窗口异常时已排除本机旧 Cookie / 扩展干扰
• Network：登录 POST 的 302 + Set-Cookie 已核对；Application 中 Cookie Domain/Secure/Path 正确
• siteurl / home（及 wp-config 覆盖项）与访问协议+域名一致；改前值已备份
• HTTPS / 反代 X-Forwarded-Proto（或等价）与 FORCE_SSL_ADMIN / COOKIE_SECURE 不互相打架
• CDN / 缓存已排除 wp-login.php、/wp-admin/ 等；Purge 后无痕复测通过
• 安全插件 / 双因素仅做单变量对比并已收紧；回滚说明已写，未长期裸奔关防护