WordPress REST API 返回 401 或 403，表面上都是“请求被拒绝”，但排查方向并不相同：401 通常表示服务端没有识别出有效身份，403 则更多表示身份已经识别，但当前用户或请求没有执行该操作的权限。先分清状态码出现在哪一层，再检查凭据、用户权限、代理请求头和安全策略，通常比直接关闭插件或修改服务器配置更有效。
一、先判断401和403分别代表什么
| 状态 | 常见含义 | 优先检查 |
|---|---|---|
| 401 Unauthorized | 未提供凭据、凭据无效，或 WordPress 没有识别出当前用户 | Authorization 请求头、Cookie 与 nonce、应用程序密码、代理转发 |
| 403 Forbidden | 已识别请求或用户，但权限检查、安全规则或来源限制拒绝访问 | 用户角色与 capability、安全插件、WAF/CDN、跨域及来源规则 |
不能只凭状态码下结论。CDN、WAF、Nginx、Apache、安全插件和 WordPress 本身都可能返回 401 或 403。第一步应查看响应正文和响应头，确认是谁拒绝了请求。
curl -i https://example.com/wp-json/wp/v2/users/me重点观察响应是否为 JSON，是否包含 WordPress REST API 常见的 code、message 和 data.status，以及是否出现 CDN、WAF、反向代理或主机安全产品的标识。如果返回的是完整 HTML 拦截页，而不是 WordPress 的 JSON 错误结构，问题往往发生在 WordPress 之前。
二、用公开接口确认REST API是否可用
先访问不需要登录的接口，区分“整个 REST API 不可用”和“只有受保护接口鉴权失败”：
curl -i https://example.com/wp-json/
curl -i https://example.com/wp-json/wp/v2/posts?per_page=1如果公开接口正常，而创建文章、读取当前用户或修改内容时才出现 401/403，说明路由和固定链接通常不是首要问题，应该转向鉴权与权限检查。
如果 /wp-json/ 也被拒绝或返回 404，再检查 WordPress 地址、固定链接规则、Nginx 或 Apache 的入口配置，以及插件、WAF 或主机面板是否禁止访问 /wp-json/。修改固定链接前先保存现有规则。生产站点不要为了测试长期禁用 REST API，因为区块编辑器、WooCommerce、移动端和部分第三方集成都可能依赖它。
三、检查使用的是哪一种鉴权方式
1. 后台页面内的Cookie和nonce
在已登录的 WordPress 后台中，REST API 请求通常依赖登录 Cookie，并通过 X-WP-Nonce 请求头发送 nonce。只有 Cookie 没有 nonce，或 nonce 已过期时，请求可能被当成未登录用户。
fetch('/wp-json/wp/v2/users/me', {
headers: {'X-WP-Nonce': window.wpApiSettings.nonce},
credentials: 'same-origin'
});检查浏览器开发者工具中的实际请求：请求是否带上登录 Cookie，是否存在 X-WP-Nonce，页面缓存是否保存了旧 nonce，域名、协议或端口变化后 Cookie 是否仍能发送，以及请求是否经过了会删除自定义请求头的代理。
nonce 不是长期 API 密钥，也不能替代 HTTPS。页面长期缓存、用户退出后重新登录或会话变化，都可能使旧 nonce 失效。
五、身份验证成功后，继续检查用户权限
如果 /users/me 能返回当前用户，但创建文章、上传媒体或修改设置仍返回 403，重点检查 WordPress 的角色与 capability。能读取公开文章不代表能创建文章；能编辑自己的文章，也不一定能编辑其他作者的文章、发布文章或管理插件。
按下面的顺序判断：
- 用同一凭据访问
/wp-json/wp/v2/users/me，确认识别到的用户是否正确； - 在后台核对该用户的角色；
- 查看目标 REST 路由的官方文档或插件说明，确认所需权限；
- 检查自定义接口的
permission_callback； - 临时换用具备明确权限的测试账号复现，但不要长期使用管理员账号作为自动化凭据。
自定义 REST 路由必须设置合理的权限回调。将权限回调直接设为始终允许，只适合真正公开且不涉及敏感数据的接口，不能作为解决 403 的通用办法。
六、排查安全插件、WAF和CDN规则
安全插件或边缘防护可能根据 URL、请求方法、User-Agent、来源 IP、请求频率或请求体内容拦截 REST API。常见表现包括：GET 正常但 POST、PUT 或 DELETE 返回 403；浏览器后台正常但外部脚本失败；同一请求从服务器本机成功、从公网失败；响应内容不是 WordPress JSON，而是安全产品的拦截页。
不要直接关闭全部安全功能。先查看安全插件、CDN 和 WAF 的事件日志，按时间、来源 IP、URI 和规则编号定位命中的规则。只对明确的 API 路径、来源和请求方法创建最小范围例外，重新测试后确认其他保护仍然有效，并记录恢复原规则的方法。
如果接口需要公网调用，可组合使用固定出口 IP、最小权限账号、独立应用程序密码和限速规则，而不是对整个 /wp-json/ 放行。
七、检查跨域请求，但不要把CORS和鉴权混为一谈
浏览器从另一个域名调用 WordPress API 时，还会受到同源策略影响。排查时分别确认：浏览器是否允许前端读取响应，Cookie 或 Authorization 是否实际发送，以及 WordPress 是否识别身份并允许该操作。
不要使用 Access-Control-Allow-Origin: * 同时允许携带用户凭据。应只允许确实需要访问接口的来源，并限制方法和请求头。非浏览器客户端不受浏览器 CORS 限制，因此可以用 curl 对照测试，判断问题是在浏览器还是服务器端。
八、推荐的最短排查顺序
- 用
curl -i保存状态码、响应头和响应正文； - 测试
/wp-json/和一个公开文章接口； - 测试
/wp-json/wp/v2/users/me，确认身份是否被识别； - 核对 Cookie + nonce 或应用程序密码的使用方式；
- 检查 Authorization、Cookie、X-WP-Nonce 是否穿过代理链；
- 核对用户角色、capability 和自定义路由权限回调；
- 查看安全插件、CDN、WAF 和服务器日志；
- 最后再调整规则，并用最小范围变更验证。
建议保留一份脱敏后的失败请求和成功请求，对比 URL、方法、请求头、响应头及来源网络。不要在排障记录中保留 Cookie、nonce、应用程序密码或完整 Authorization 值。
九、修复后如何验证
修复完成不能只看“状态码不再是 403”。还要验证匿名用户仍不能访问受保护数据，低权限账号不能执行管理员操作，目标账号只能执行业务所需操作，应用程序密码撤销后立即失效，CDN/WAF 的其他安全规则仍然工作，并确认日志没有记录明文凭据。
如果问题只在生产环境出现，应先在临时环境复现配置差异，再安排低峰期变更。涉及代理、WAF 或权限模型的调整，都应保留回滚方案。
总结
WordPress REST API 的 401 与 403 不能用同一种方法处理。401 优先检查身份凭据是否存在、是否有效，以及请求头是否完整到达 WordPress；403 则重点检查用户 capability、接口权限回调和安全策略。先用公开接口与 /users/me 把问题分层，再沿 CDN、代理、Web 服务器、PHP 和 WordPress 的链路逐层定位，可以避免盲目关闭插件或扩大接口权限。
参考资料
-
- WordPress Developer Resources：REST API Authentication
https://developer.wordpress.org/rest-api/using-the-rest-api/authentication/
-
- WordPress Developer Resources：Routes and Endpoints
https://developer.wordpress.org/rest-api/extending-the-rest-api/routes-and-endpoints/
-
- WordPress Developer Resources：Users REST API Reference
https://developer.wordpress.org/rest-api/reference/users/
-
- WordPress Documentation：Roles and Capabilities
https://wordpress.org/documentation/article/roles-and-capabilities/
-
- WordPress Developer Resources：Application Passwords Integration Guide
https://make.wordpress.org/core/2020/11/05/application-passwords-integration-guide/
资料核验日期：2026年9月7日