REST API 开关由 wp_options 表中 option_name 为 rest_enabled 的字段控制，值为 '1' 启用、'0' 关闭；需手动 SQL 更新并清除对象缓存及 CDN 缓存，多站点需逐个子站表更新。
wp_options 表里哪个字段控制 REST API 开关
rest api 的启用状态由 rest_enabled 这个 option 控制，不是插件开关也不是常量。它在 wp_options 表中以 option_name 存在，值为 '1'（启用）或 '0'（关闭）。注意：wordpress 本身不提供后台界面修改它，也不响应 define('rest_enabled', false) 这类伪常量——那是常见误解。
直接 SQL 更新 rest_enabled 字段的实操步骤
进数据库执行 UPDATE 即可，但必须同时处理两个关键点：缓存失效 + 多站点兼容性。否则前端仍可能返回 API 路由或 200 响应。
- 用 phpMyAdmin 或命令行执行：
UPDATE wp_options SET option_value = '0' WHERE option_name = 'rest_enabled';
- 如果使用多站点（WP Multisite），需对每个站点的 options 表单独更新，例如
wp_2_options、wp_3_options—— 主站的wp_options不影响子站 - 更新后清空对象缓存（如 Redis / Memcached），否则 WP 可能从缓存读取旧值；文件缓存（如 APCu）也建议重启或清除
- 别漏掉
rest_route和rest_api_enabled—— 它们是过时字段或插件残留，只改rest_enabled就够了
为什么 wp-config.php 里 define('REST_API_ENABLED', false) 没用
这个常量根本不存在于 WordPress 核心代码中。搜索整个 WP 6.5 源码，找不到任何地方检查 REST_API_ENABLED。网上流传的写法属于混淆了早期插件逻辑或误读文档。真正生效的只有数据库字段 + 后续的钩子拦截。
- 想彻底封死 REST 请求？仅改数据库不够，还得配合
rest_authentication_errors钩子返回 WP_Error - 单纯设
rest_enabled = '0'后，/wp-json/路径会返回 404，但部分主题或插件可能绕过该判断发起内部请求 - 某些托管环境（如 WP Engine）会强制开启 REST API，数据库修改会被运行时覆盖，得结合其平台设置或 .htaccess 屏蔽
验证是否真的关闭成功的方法
别只看后台有没有“禁用插件”，要实际测请求响应和 HTTP 状态码。
- 浏览器访问
/wp-json/，应返回 404 页面（不是空白页或 JSON 错误） - curl -I https://yoursite.com/wp-json/ 应看到
HTTP/2 404，而不是200或301 - 检查响应头是否含
X-Robots-Tag: noindex—— 如果还有，说明 REST 仍在运行或被其他插件激活 - 禁用所有插件再测试，排除插件重写
rest_enabled值的可能性（有些安全插件会动态覆盖）
最麻烦的是缓存层和 CDN —— 即使数据库改了、WP 也返回 404，Cloudflare 或 Nginx 缓存可能还吐着旧的 200 响应。这时候得清 CDN 缓存，或者临时加 Cache-Control: no-cache 测试。
