WordPress 登录后跳回登录页或提示「Cookie 被阻止」：先核站点 URL 与 HTTPS 一致，再查安全插件与 CDN

登录后台输对账号密码后立刻跳回登录页，或浏览器提示「Cookie 被阻止 / Cookies are blocked」、会话像没写上------这和今天槽位里写过的表单「提交成功但收不到邮件」、「建立数据库连接时出错」、「全站 HTTPS 后仍显示不安全 / 混合内容」、「定时发布不生效 / WP-Cron / Action Scheduler 堆积」、「更新插件后白屏 / 致命错误」，以及 502/503、媒体上传失败、固定链接 404、Woo 支付回调不是一类故障。站点多半是 会话 Cookie 没落稳，或站点 URL / HTTPS 与 Cookie 域不一致 ：home/siteurl 带错协议或域名、COOKIE_DOMAIN / Secure 标志、安全插件拦登录 Cookie、CDN/全页缓存把登录页或会话 Cookie 缓存/改写了。

更稳的顺序是：先分清是 整站跳回 / 仅后台跳回 / 仅某浏览器 / 仅经 CDN 域名 → 核对 WordPress 地址与 HTTPS 强制一致 → 查 Cookie 域、路径与 Secure → 再动安全插件与 CDN 缓存键 / Cookie 透传。别一上来就清全站缓存、乱改 COOKIE_DOMAIN，也别在没对照「直连源站 vs 走 CDN」之前就怪浏览器。

先分清：跳回登录页 vs Cookie 被阻止 vs 多域名串会话

「登录后跳回 / Cookie 被阻止」常见落在五条线上，别和 SMTP、数据库连接、HTTPS 混合内容（锁被划掉）、Cron、插件 Fatal 白屏混着改：

• 账号密码正确，提交后仍停在 wp-login.php ：多半是 Set-Cookie 没被浏览器接受，或下一跳请求没带上 wordpress_logged_in_* / wordpress_sec_*。
• 短暂进了后台又被踢回登录页：会话写上了但马上丢------常见于 Cookie 域写错（带了不该带的点前缀）、Secure 与当前协议不一致、或中间层剥掉了 Cookie。
• 浏览器明确提示 Cookie 被阻止 / 第三方 Cookie ：站点用了跨域嵌入登录、或 SameSite / 分区 Cookie 策略撞上了；也可能是扩展/隐私模式拦截。
• 仅经 CDN / 自定义域名失败，源站 IP 或临时 hosts 直连正常：问题在边缘缓存键、Cookie 白名单、或 HTTPS 回源与前台域名不一致。
• www 与裸域、或 http 与 https 各有一份「像登录又没登录」 ：home 与 siteurl 不一致，或 301/302 在协议/主机名之间来回跳，Cookie 写在 A 域却在 B 域读。

先记下：当前访问用的完整 URL（协议+主机+是否带 www）、后台「设置 → 常规」里两个地址、是否挂 CDN、最近是否强制 HTTPS / 换过域名、用的浏览器与是否无痕。再决定先改 URL 还是先绕过 CDN。

第一步：站点 URL 与 HTTPS 必须一致（home / siteurl / 强制跳转）

登录 Cookie 的域与 Secure 标志高度依赖「浏览器地址栏里的那一串」和 WordPress 自己认为的站点地址：

1. 对照三处是否 同一协议 + 同一主机名 ：

   • 浏览器地址栏（你实际打开后台的 URL）
   • 后台「设置 → 常规」的 WordPress 地址（siteurl）与站点地址（home）
   • 数据库 wp_options 里 siteurl、home（面板进不去时用 phpMyAdmin / wp option get）

2. 典型坏组合：地址栏是 https://www.example.com，库里却是 http://example.com；或一个带 www、一个不带。结果是登录跳转跨主机/跨协议，Cookie 写在一侧、读在另一侧。

3. 若必须改库：只改这两项到「你打算长期用的规范 URL」，改完立刻用 同一规范 URL 打开 /wp-login.php，不要混用旧书签。

4. wp-config.php 里若写了：

   define('WP_HOME', 'https://www.example.com');
   define('WP_SITEURL', 'https://www.example.com');

   以这里为准，并与 CDN / 证书上的主机名对齐；改完清对象缓存（若有 Redis/Memcached 持久化了旧 option）。

5. 主机或插件做的「强制 HTTPS」要与上述一致：避免 http→https 与 www↔裸域 两道 301 链 叠在登录跳转上，中间丢 Referer/Cookie 的情况并不少见。

6. 多站点注意：网络级 DOMAIN_CURRENT_SITE、子站映射与主站 URL 不一致时，也会表现为「能打开登录页、登进去又掉」。

预期：规范 URL 唯一；从该书签进入登录，跳转目标主机名与协议不再漂移。URL 未对齐时先别深挖 CDN。

第二步：Cookie 域、路径、Secure / HttpOnly，以及 wp-config 覆盖项

URL 对齐后仍跳回，再看 Cookie 本身怎么被写出：

1. 开发者工具 → Application / 存储 → Cookies：登录提交后是否出现 wordpress_test_cookie、wordpress_logged_in_*、wordpress_sec_*（名称随站点而变）。没有 Set-Cookie：问题在响应被中间层改写或插件拦截；有 Cookie 但下一跳 Request 没带上：域/路径/Secure/SameSite 不匹配。

2. 勿轻易乱加：

   define('COOKIE_DOMAIN', '.example.com');

   域名写错、或与当前主机不一致时，浏览器会直接拒收。只有明确需要「子域共享登录」且主机规划清楚时才设；多数单站点 不设 更稳。

3. ADMIN_COOKIE_PATH、COOKIEPATH、SITECOOKIEPATH 被主题/旧教程改过时，对照官方默认：路径通常落在 /。路径过窄会导致后台子路径读不到 Cookie。

4. 全站 HTTPS 后：Cookie 应带 Secure。若仍有页面从 http 入口进来，Secure Cookie 不会在 http 请求里带上，表现就是「偶发掉登录」。先把入口统一到 https，再查混合内容（那是另一篇的锁图标问题，这里只关心会话是否丢）。

5. 服务器时间严重偏斜时，Expires/Max-Age 可能让 Cookie 立刻过期；对照 NTP / 主机面板时间。

6. 反向代理后若 WordPress 以为自己是 http：检查 $_SERVER['HTTPS'] / X-Forwarded-Proto 是否被正确传入，必要时在 wp-config 早期根据代理头设置 HTTPS 检测（按主机文档，避免复制来路不明的片段）。

预期 ：登录响应里能看到会话 Cookie；后续 /wp-admin/ 请求 Cookie 头带齐；域与路径与规范 URL 一致。

第三步：安全插件、防火墙与「登录保护」误伤

安全类插件最容易在「防暴力破解 / 会话控制 / 防火墙」里误伤正常登录：

1. 临时 停用 安全插件（或其「登录保护 / Cookie / 防火墙」子模块），再试一次纯净登录。能登进去再逐项打开，定位是哪一条规则。
2. 常见误伤点：限制登录 Cookie 生命周期过短、强制二次验证但回调域名不一致、WAF 规则把 wordpress_logged_in_* 或登录 POST 当攻击拦截、国家/IP 规则把你当前出口挡住。
3. 主机面板 WAF / 模版防火墙：看同一时间戳是否有拦截日志；排障窗口可对 /wp-login.php 与 /wp-admin/ 做临时放行（记得到期关回）。
4. 验证码 / 人机验证插件：挑战页跨域或缓存了挑战页，也会表现为「提交后回登录页」。先排除缓存，再查验证码站点密钥与当前域名是否匹配。
5. 改完安全规则后：清浏览器该站 Cookie，再用无痕窗口测，避免旧会话与新规则缠在一起。

预期：安全层旁路后能稳定进后台；再收敛到「哪一条规则」而不是永久关闭全部防护。

第四步：CDN、全页缓存键与 Cookie 透传（含源站对照）

仅 CDN 域名失败、或「清缓存就好一会儿又坏」时，优先做源站对照：

1. 绕过 CDN （临时 hosts 指到源站 IP，或用面板「开发模式 / 旁路」）访问同一规范 URL 的 /wp-login.php。源站正常、经 CDN 失败 → 问题在边缘，不在 WordPress 核心。
2. 全页缓存 不得 缓存已登录 HTML，也尽量别缓存 wp-login.php / wp-admin。缓存键若忽略 Cookie，会把「未登录壳页」或错误登录页发给下一访客/下一请求。
3. Cookie 白名单：确保边缘把 wordpress_logged_in_*、wordpress_sec_*、wordpress_test_cookie（及你栈里真实前缀）转发到源站 ，且不要在边缘改写/剥掉 Set-Cookie。
4. 缓存键建议包含「是否存在登录 Cookie」或对带登录 Cookie 的请求直接 bypass；不要只按 URL 缓存后台相关路径。
5. 多 CDN / 回源 Host 头错误：回源 Host 与证书、与 siteurl 不一致时，源站可能按错误主机生成重定向，Cookie 域跟着错。
6. 把「边缘旁路、Cookie 透传、登录相关路径不缓存、缓存键含会话特征」写成固定核对项；涉及边缘会话与缓存键的系统说明，可对照 CDN / Cookie 会话与缓存键排查 把「源站对照 → 白名单 → 键设计 → 回源 Host」串成一条线，避免只在面板里反复点「清全部缓存」。
7. 对象缓存 / 持久化 option 里若仍是旧 siteurl，CDN 旁路后也要 wp cache flush 或重启 Redis 后再测。

预期：源站与经 CDN 两条路径都能完成「登录 → 停在后台仪表盘」；带登录 Cookie 的请求不再命中匿名全页缓存。

第五步：浏览器、多域名与验证清单

1. 无痕窗口 + 禁用扩展再测一次；排除广告拦截 / 隐私扩展误杀 Cookie。
2. 同一规范 URL 下：Chrome / Safari / 移动端各测一轮；仅 Safari ITP 出问题再查跨站嵌入与 SameSite。
3. 书签、邮件里的旧 http:// 或非 www 链接全部改到规范 URL，避免从错误入口「半登录」。
4. 子域（如 shop. / blog.）若不应共享登录：不要设宽泛 COOKIE_DOMAIN；若必须共享：证书、CDN、两端 siteurl 规划先于改常量。
5. 验证步骤建议固定：
   • 清该站 Cookie → 打开规范 /wp-login.php
   • 登录成功后地址栏仍在规范主机，且能打开「仪表盘」「插件」「设置」
   • 刷新、新开后台标签仍保持登录
   • 退出后再登录一次（确认不是「碰巧残留 Cookie」）
   • 经 CDN 与绕过 CDN 各一遍
6. 常见坑：只改了「设置 → 常规」UI 没改库（或反过来）；CDN 清了文件缓存但没关「忽略 Cookie 的 HTML 缓存」；安全插件与 CDN WAF 双重拦截；COOKIE_DOMAIN 带了前导点却证书/主机不在父域下。
7. 验收只看技术结果（会话可写可读、URL 唯一、CDN 不吞 Cookie），不把「再装一个登录修复插件然后忘掉」当成收尾。

技术验收清单

• home / siteurl / 地址栏 / 证书主机名四者一致（协议+主机）
• 登录响应含会话 Cookie；后续 /wp-admin/ 请求带上同名 Cookie
• 未随意设置错误的 COOKIE_DOMAIN；路径为合理的 /
• 安全插件 / WAF 旁路后可登录，再收敛规则并留变更记录
• CDN：登录相关路径不缓存；登录 Cookie 透传；缓存键区分登录态
• 源站对照与经 CDN 对照均通过；对象缓存中无陈旧 siteurl
• 无痕与至少一款其他浏览器复验；旧 http/非规范书签已替换

小结

登录后跳回登录页或提示 Cookie 被阻止时，按 分场景 → URL/HTTPS 一致 → Cookie 域与 Secure → 安全插件/防火墙 → CDN 缓存键与 Cookie 透传 → 浏览器与多域名验收 推进，每次只动一层并保留「源站对照」结果。把它和 SMTP 投递、数据库连接、HTTPS 混合内容（锁图标）、WP-Cron / 定时发布、插件更新白屏区分开，能少走很多「盲目清全站缓存 / 乱写 COOKIE_DOMAIN / 未对齐 www 与协议就怪浏览器」的弯路。DEVDIY 实务里把「规范 URL、源站是否可登、CDN 是否吞 Cookie」三列记一笔，下次换证、切 CDN 或并域名时能直接对备忘，而不是从零猜。