wordpress后台重定向循环最常因siteurl和home设为https而nginx以http转发导致，解决关键是让wordpress正确感知外部协议：在wp-config.php中定义wp_home和wp_siteurl为动态https地址，并确保nginx配置proxy_set_header x-forwarded-proto $scheme生效。
WordPress 后台 URL 设置必须匹配代理后的真实访问协议和域名
重定向循环最常发生在 WordPress 的 siteurl 和 home 地址被设为 https://example.com，而 Nginx 实际以 HTTP 转发请求给 PHP-FPM 或容器内 WordPress 时。WordPress 检测到当前是 HTTP 请求，就强制 302 跳转到 HTTPS 地址，Nginx 再次转发，形成死循环。
解决方法不是改 Nginx 去“模拟 HTTPS”，而是让 WordPress 正确感知外部协议：
- 在
wp-config.php开头（/* That's all, stop editing! */之前）加入这两行：define('WP_HOME', 'https://' . $_SERVER['HTTP_HOST']); define('WP_SITEURL', 'https://' . $_SERVER['HTTP_HOST']);这样能动态取浏览器实际访问的 Host 和协议 - 或者更稳妥：显式声明代理协议，加这行：
$_SERVER['HTTPS'] = 'on';
（仅当 Nginx 确实终止了 SSL） - 数据库中
wp_options表的siteurl和home字段建议留空或设为相对路径/，避免硬编码
proxy_set_header X-Forwarded-Proto $scheme 必须存在且生效
缺了这行，WordPress（尤其是启用了 server.forward-headers-strategy=framework 的 Spring Boot 类应用）会把所有请求当成 HTTP，哪怕你访问的是 https://。Nginx 默认不透传协议头，必须手动设置。
检查你的 location 块里是否包含：
proxy_set_header X-Forwarded-Proto $scheme;
常见错误包括：
- 写成了
X-Forwarded-Proto https—— 这会让所有请求都固定为 HTTPS，HTTP 入口会出问题 - 放在
server块顶层但没被location继承（Nginx 不自动继承，必须在 proxy_pass 所在作用域内） - CDN + Nginx 双层代理时，上层 CDN 已覆盖
X-Forwarded-Proto，Nginx 需配置underscores_in_headers on;并确认未被丢弃
proxy_redirect 要匹配后端返回的 Location 头格式
如果 WordPress 插件或主题生成了绝对跳转地址（如 Location: http://localhost:8080/wp-admin/），而 Nginx 没重写，浏览器就会直连内部地址，失败后可能触发二次跳转。
推荐用正则重写，适配各种后端来源：
proxy_redirect ~^http://[^/]+(/.*)$ $scheme://$host$1;
注意点：
- 不能写
proxy_redirect http:// https://—— 这会把所有http://开头的 Location 强制改成https://，若用户本就是 HTTP 访问，会跳错 - 如果后端已用相对路径跳转（如
Location: /wp-login.php），proxy_redirect off是安全的，无需重写 - 确保
$scheme在当前上下文有效（即该location块确实监听了 HTTPS 或明确设置了scheme）
Cookie Secure 属性与重定向环强相关
浏览器一旦收到 Set-Cookie: ... Secure，就只在 HTTPS 下发送该 Cookie。如果 WordPress 因 X-Forwarded-Proto 缺失误判为 HTTP，它可能仍设 Secure Cookie；但后续 HTTPS 请求因 Cookie 未送达导致无会话，又跳回登录页——而登录页再次因协议误判跳 HTTP，闭环形成。
验证方式：用 Chrome DevTools → Application → Cookies，看是否有 Secure 标记但当前是 HTTPS 访问。
临时绕过（仅调试）：
define('FORCE_SSL_ADMIN', false);
define('COOKIE_SECURE', false);
但根本解法仍是补全 X-Forwarded-Proto 和正确设置 WP_HOME/WP_SITEURL。这个环里最隐蔽的一环是：它不报错，只静默失效；清浏览器 Cookie 后第一次访问看似正常，第二次就崩——因为登录成功后服务端又写了新的 Secure Cookie，而环境没变。
