WordPress REST API 认证排查：6 条 curl 命令快速定位问题

WordPress 的 REST API 报认证失败时，最多人做的一件事是：重新生成一次应用程序密码。如果没好，再生成一次。其实用几条 curl 命令就能把问题定位得八九不离十——本文的所有命令都可以直接复制到服务器终端（或任何装了 curl 的电脑）上运行。

准备工作：把下面命令里的「你的域名」「你的用户名」「xxxx xxxx xxxx xxxx xxxx xxxx」（应用程序密码，6 组 4 位）换成你自己的。

命令 1：站点活着吗？

curl -sS -o /dev/null -w 'HTTP:%{http_code}\n' https://你的域名/wp-json/

结果解读：

HTTP:200 → 站点和 REST API 都活着，继续往下查
HTTP:403/404 → REST API 被禁用了（可能被安全插件或服务器规则关闭）
连接失败 → 先查网络、DNS、SSL 证书

命令 2：测试应用程序密码认证（核心命令）

curl -sS -w '\nHTTP:%{http_code}\n' \
  -u '你的用户名:xxxx xxxx xxxx xxxx xxxx xxxx' \
  https://你的域名/wp-json/wp/v2/users/me

结果解读：

HTTP:200 + 一段 JSON（包含你的用户信息）→ 认证正常，问题在调用方工具的配置上
HTTP:401 + rest_not_logged_in 或类似 → 密码或用户名真的不对
HTTP:500 + 「为用户名 xxx 指定的密码不正确」这类登录框文案 → ⚠️ 重点来了，见下文

关于 500 + 登录框文案：这是最容易被误判的情况。它看起来在说”密码错了”，实际上真正的含义是：你的站点认证链路被某个插件接管了，应用程序密码被当成登录密码去校验。重新生成一万次密码也没用。

一个佐证细节：应用程序密码带不带空格都合法，如果两种写法报同样的错，基本可以排除”复制粘贴出错”。

命令 3：交叉验证——用 XML-RPC 测同一对凭据

curl -sS -X POST -H 'Content-Type: text/xml' --data '<?xml version="1.0"?>
<methodCall><methodName>wp.getUsersBlogs</methodName>
<params>
<param><value><string>你的用户名</string></value></param>
<param><value><string>xxxx xxxx xxxx xxxx xxxx xxxx</string></value></param>
</params></methodCall>' https://你的域名/xmlrpc.php

结果解读：

返回包含你的站点名称、isAdmin 字段 → 凭据完全有效。REST 报错就是站点自身问题（大概率插件冲突），不用再折腾密码了
返回「用户名或密码不正确」→ 凭据真的有问题，去 wp-admin/profile.php 重新生成应用程序密码

这条命令是判断”密码有没有冤情”的最快方法，强烈建议在重新生成密码之前先跑一次。

命令 4：对照组——故意用错误密码

curl -sS -w '\nHTTP:%{http_code}\n' \
  -u '你的用户名:totallywrong' \
  https://你的域名/wp-json/wp/v2/users/me

结果解读：

返回 401 → 站点认证行为标准
返回 500 + 和正确密码一模一样的登录框报错 → 实锤：这个站对所有 Basic 认证请求都会触发同一段报错逻辑，跟密码对错无关。问题在认证链路被接管

正确密码和错误密码报错完全一样，是”认证被接管”最典型的指纹。

命令 5：测试受保护接口（发文能力）

curl -sS -w '\nHTTP:%{http_code}\n' \
  -u '你的用户名:xxxx xxxx xxxx xxxx xxxx xxxx' \
  -X POST -H 'Content-Type: application/json' \
  --data '{"title":"API测试-草稿","content":"测试内容","status":"draft"}' \
  https://你的域名/wp-json/wp/v2/posts

结果解读：

返回 201 + 文章 JSON → 发文能力正常，第三方工具可以放心接入（测完记得删掉这篇草稿）
返回 401/403 → 用户权限不足，检查该用户的角色是否有 publish_posts 权限

命令 6：确认插件凶手（进阶）

如果前面判断出是站点认证链路被接管，用二分法抓凶手：

后台把所有插件停用 → 跑命令 2 → 恢复 200/401 标准行为？
逐个重新启用插件，每启用一个就跑一次命令 2
哪个插件启用后 500 复现，哪个就是元凶

嫌慢可以折半：先启用一半，测一次；好的话启用另一半，坏的话在坏的一半里继续折半。10 个插件 4 轮就能锁定。

常见结果速查表

现象	诊断	处理方向
命令 1 非 200	REST API 被禁用或站点故障	检查安全插件/服务器规则
命令 2 返回 401	密码/用户名错误	重新生成应用程序密码
命令 2 返回 500+登录框文案	认证链路被插件接管	命令 4 确认 → 命令 6 抓凶手
命令 3 成功 + 命令 2 失败	凭据有效，站点问题	插件冲突，参考本系列文章
命令 2 成功但工具仍报错	调用方配置问题	检查工具里站点地址是否带 /wp-json/