WordPress 的应用程序密码在后台生成时，是被拆成六段、每段四个字符显示的，形如 ABCD EFGH IJKL MNOP QRST UVWX。去掉空格后它的长度仍然是 24 位，但肉眼很容易把它误读成两截——前面一截当作用户名，后面一截当作密码。实际上它是一整条凭据，只是一整条。
这次的教训是这个。
手头有一串六段式的口令，习惯性地拆成「用户名 + 密码」两半去试，于是把前四段当成了用户名。于是走 wp-login 报「未在本站点注册」，走 REST 报 rest_not_logged_in，两种报错都是”不认识你”，于是更加确信是密码给错了，或者更糟——认为是 nginx 没有转发 Authorization 头，准备去改服务器配置了。
其实没那么多弯弯绕。把六段拼成 24 位，当成一条完整的应用密码，配上真正的用户名，一次就通。REST 与 XML-RPC 两条路同时返回 200。
| 项目 | 说明 |
|---|---|
| 用户名 | <你的 user_login>，即 user_login，不是 slug |
| 凭据格式 | HTTP Basic Auth，用户名:应用密码 |
| 口令长度 | 24 位，6 组 × 4 字符 |
| 空格 | WordPress 内部会剥离，带不带都行 |
| 可用入口 | REST（/wp/v2/）与 XML-RPC（/xmlrpc.php） |
另外值得记一笔的是那几个报错各自的含义，它们并不等价：
rest_not_logged_in：WordPress 根本没收到凭据。注意这不等于「密码错了」——很多排查因此走偏。incorrect_password：凭据收到了，确实对不上。invalid_username：用户不存在，与密码无关。
读报错要先读错误码本身，而不是笼统地把 401 当作「凭据有问题」。一个 401 可能横跨三个完全不同的根因：头没传进来、用户名不存在、密码不对。分清楚这三者，比反复重新生成密码要省事得多。
还有一点：应用密码只在 REST 与 XML-RPC 请求里生效，wp-login 那个网页表单根本不认它。所以「拿应用密码去网页登录失败」这件事，是正常现象，不是密码失效的证据。
整件事最后落到一个很朴素的结论上：六段式的口令就是一条口令，不要再拆。
