状态：草稿，已做公开脱敏处理
日期：2026-04-25
关键词：WordPress、重定向循环、REST API、草稿通道、OpenClaw、运维复盘
今天处理了两个和博客写作流程相关的问题。
第一个是博客后台和登录页出现重定向循环，导致无法正常进入 WordPress 后台。第二个是为了后续自动化写作流程，需要建立一个最小权限的 WordPress REST 草稿写入通道，让 devous 可以创建 draft 状态文章，但不能发布、修改既有文章或碰无关配置。
这次处理的目标不是“大改站点”，而是在不扩大风险的前提下，让后台恢复可用，并让博客草稿流程真正跑起来。
一、背景
站点是一套公开访问的 WordPress 博客。
当时遇到两个问题：
- WordPress 后台入口和登录页出现
ERR_TOO_MANY_REDIRECTS，无法正常进入后台。 - 需要为自动化写作流程建立一个最小权限的 REST 草稿写入通道，让 devous 能直接把整理好的内容保存为 WordPress 草稿。
这里的边界很明确：
- 不发布文章。
- 不修改已有文章。
- 不删除用户或文件。
- 不修改反代、证书、防火墙或 OpenClaw 配置。
- 不扩大公网暴露。
- 密码、应用程序密码、安全入口等敏感信息不进入文章或归档。
二、故障现象
前台访问正常：
- 博客首页可以正常访问，返回
200。 - WordPress REST 入口也可以访问，并显示站点地址为 HTTPS。
但后台和登录页异常：
- 后台入口一度出现
302自我跳转。 - 登录页也一度出现
302自我跳转。 - 浏览器表现为
ERR_TOO_MANY_REDIRECTS。 - 响应头显示跳转由 WordPress 触发。
这说明跳转不是单纯的浏览器缓存问题，也不是 TLS 证书本身的问题，而是 WordPress/PHP 层触发了重定向。
三、排查过程
排查按“低风险、可回滚”的顺序进行。
1. 先确认外层状态
先确认了这些基础状态：
- TLS 证书有效。
- 域名匹配正常。
- HTTPS 前台访问正常。
- REST API 可访问。
- 站点地址从外部观察看是 HTTPS。
这一步排除了“证书错了”“域名跳错了”“前台整体不可用”等方向。
2. 先备份，再排插件和主题
在动 WordPress 文件前，先备份了：
- WordPress 数据库。
wp-content。wp-config.php。
然后逐个临时禁用并恢复若干业务插件、媒体/附件相关插件、头像插件和默认插件。故障没有变化，因此插件方向基本排除。
之后临时切换到默认主题测试，再恢复当前主题，故障仍无变化，因此主题方向也基本排除。
3. 检查数据库站点地址
检查数据库中的站点地址配置，确认 home/siteurl 均为 HTTPS 站点地址。
因此它也不像是典型的 WordPress 站点 URL 配置错误。
4. 一次性 PHP 探针定位关键差异
最后通过一次性 PHP 探针观察后端 PHP 看到的请求环境，发现公网 HTTPS 请求进入后端后，PHP/WordPress 实际看到的是 HTTP 环境。
也就是说，用户从公网访问的是 HTTPS，但 WordPress 后端没有正确识别外部 HTTPS 状态。
这个现象解释了为什么后台和登录页会进入重定向循环：外部已经是 HTTPS，但后端识别错了协议，WordPress 在后台/login 的强制 HTTPS 或 canonical redirect 过程中反复修正，最后变成自己跳自己。
四、根因判断
直接原因是：WordPress 后端未正确识别外部 HTTPS 状态。
从现象看，这高概率与上游代理/转发层的 HTTPS 头传递有关：外部请求实际是 HTTPS，但 PHP/WordPress 看到的是 HTTP。于是 WordPress 后台和登录页在协议判断、强制 HTTPS、canonical redirect 等逻辑里出现循环。
这不是浏览器缓存问题，也不是 TLS 证书本身损坏；真正的问题在于 HTTPS 状态没有被后端正确识别。
五、修复方式
这次没有修改：
- 反代配置。
- 证书配置。
- 防火墙。
- OpenClaw 配置。
- 公开暴露范围。
采用的是一个最小范围、可回滚的 WordPress 侧 fallback：
- 在
wp-config.php中加入站点域名限定的 HTTPS fallback。 - 当请求 Host 是当前博客域名时，显式设置
$_SERVER['HTTPS']='on'。 - 修改块用明确的 START / END 标记包裹，方便后续回滚。
- 修改后用容器内 PHP 做语法检查，确认
wp-config.php无语法错误。
这个方案不是长期最优解，但它风险小、范围窄、可回滚，适合先恢复后台可用性。长期仍应在真实反代层修正 HTTPS 头传递，而不是依赖应用侧 fallback。
六、修复验证
修复后验证结果：
- 登录页返回
HTTP/2 200。 - 后台入口对未登录用户正常跳转到登录页，并带上重新认证参数。
- 登录页随后返回
200。 - 前台首页继续返回
200。
也就是说，在当前访问链路下，后台/login 的自我重定向循环已经消失，前台也没有被破坏。
七、REST 草稿通道
后台故障修复后，继续处理自动化写作流程需要的 REST 草稿通道。
授权边界是：
- 仅处理 WordPress 用户和应用程序密码相关操作。
- 目标是创建
draft状态文章。 - 不发布文章。
- 不修改既有文章。
- 不删除用户。
- 不改反代、证书、防火墙或 OpenClaw 配置。
最终配置了一个专用低权限草稿用户，角色控制在可创建文章草稿所需的范围内，用途是让 devous 通过 WordPress REST API 创建文章草稿。
同时生成了 WordPress 应用程序密码。这里要特别强调：应用程序密码不应该写入博客、归档、仓库、长期记忆或公开记录，只应放在安全密钥管理或受控运行环境里。
验证结果：
- REST API 可以用该账号创建
draft状态文章。 - 先创建过一篇测试草稿。
- devous 随后成功创建一篇正式草稿，状态为
draft。
八、遇到的小插曲
中间有几个值得记录的小插曲。
1. WordPress 引导方式被插件逻辑拦截
初次尝试通过 WordPress 引导方式执行用户相关操作时，被站点中的某个业务插件逻辑拦住，出现类似“校验参数为空 / 无效或未提供”的问题。
这说明在 WordPress 环境里做 CLI/引导式操作时，插件可能会改变原本预期的执行路径。
2. 后来改用更低依赖的方式完成配置
为了避开插件引导干扰，后续在明确授权、备份和可回滚边界下，采用更低依赖的方式完成专用账号与应用程序密码配置，并通过 REST 请求验证。
这种方式更偏运维操作，因此必须有明确授权、备份和可回滚边界。
3. REST 初测 401 不等于后台没权限
一开始用普通登录凭据测试 REST 创建文章时返回过 401 rest_cannot_create。
这个错误不能简单理解成“网页登录后台没有写文章权限”。网页登录、应用程序密码、REST 请求上下文、用户角色、认证链是几件不同的事。
最终用专用用户和应用程序密码实际 POST draft 验证通过，才算这条通道真正可用。
九、最终状态
最终状态如下：
- WordPress 后台登录重定向故障：在当前访问链路下已恢复。
- 前台访问：正常。
- REST 草稿写入通道：已验证可创建
draft状态文章。 - devous 已成功创建博客草稿，状态为
draft。 - 运维侧已按要求停止所有 SSH、面板、WordPress、插件排查相关动作。
这次没有发布文章，没有修改既有文章，也没有扩大站点公开暴露。
十、后续建议
当前 wp-config.php 中的 HTTPS fallback 可以继续保留，直到未来安排单独维护窗口，定位真正的上游代理层并修复 HTTPS 头传递。
长期更正方向应该是在真实 HTTPS 反代层正确设置转发头，例如：
proxy_set_header X-Forwarded-Proto https;或根据实际架构使用合适的 $scheme / 固定 HTTPS 传递方式。
上游修好后，再完整测试：
- 登录页。
- 后台入口。
- 前台首页。
- REST API 创建草稿。
确认都正常后，再决定是否移除 wp-config.php 中的 fallback 标记块。
最后，应用程序密码应该只存在于安全密钥管理或 devous 的受控运行环境里，不进入文章、长期记忆、仓库或公开记录。
这次故障的价值不只是“后台恢复了”，更重要的是把博客自动化写作链路补上了：从整理草稿、技术检查，到 REST 创建草稿，再到等待人工确认发布，流程终于跑通了。
