Qué importa primero: La ruta REST existe, pero WordPress o una capa de autenticación no acepta las credenciales suministradas. El navegador cookies, REST nonces, contraseñas de aplicación y tokens al portador fallan por diferentes razones.
Qué indica realmente este síntoma
Un 401 es útil porque reduce el incidente a identidad y autorización. El código de respuesta, encabezado WWW-Authenticate y contexto de usuario muestran si la solicitud nunca se autentificó o autentificó sin la capacidad requerida.
Recopila pruebas antes de cambiar nada
- Llame al mismo punto final sin credenciales y con el método de credencial previsto.
- Graba el cuerpo de la respuesta y la cabecera de la WWW-Authenticate.
- Confirma que la cuenta de usuario está activa y tiene la capacidad requerida por la ruta.
- Comprueba si un proxy o una regla de seguridad elimina las cabeceras de autorización.
Causas más habituales
- Falta REST nonce: Las solicitudes de navegador autenticadas con cookies necesitan un wp_rest nonce actual.
- Encabezado de autorización rayado: Apache, Nginx, un proxy o CDN no pueden pasar credenciales básicas o portadoras a PHP.
- Contraseña de la aplicación revocada: La contraseña puede haber sido borrada, rotada o atada a un usuario diferente.
- Desajuste de capacidad: La autenticación tiene éxito, pero la devolución de permisos del endpoint niega al usuario.
Secuencia segura de diagnóstico y reparación
- Elija un método de autenticación y pruébelo fuera de la aplicación con una petición mínima.
- Pase el encabezado de Autorización a través de cada capa de proxy y servidor web.
- Generar una nueva contraseña de aplicación solo para el usuario requerido y la integración.
- Verifica la devolución de permisos del endpoint contra el rol previsto en lugar de conceder un amplio acceso al administrador.
Cómo distinguir entre las causas probables
No trates Falta REST nonce y Encabezado de autorización rayado como causas equivalentes. Las solicitudes de navegador autenticadas con cookies necesitan un wp_rest nonce actual. En cambio, apache, Nginx, un proxy o CDN no pueden pasar credenciales básicas o portadoras a PHP. Para distinguirlas, usa estas dos comprobaciones: Llame al mismo punto final sin credenciales y con el método de credencial previsto; y graba el cuerpo de la respuesta y la cabecera de la WWW-Authenticate. Con esos datos podrás decidir si conviene aplicar la primera acción controlada —Elija un método de autenticación y pruébelo fuera de la aplicación con una petición mínima— o si debes conservar el estado actual y ampliar la investigación.
En un sitio de WordPress en producción, repite la petición que falla mientras compruebas una página que funciona correctamente y el área de administración. Un fallo aislado en una ruta requiere un rollback más acotado que un problema que afecta a PHP, la base de datos o todas las peticiones. Documenta la fecha y hora exactas, la URL o transacción afectada, el último estado correcto conocido y cada cambio realizado durante el diagnóstico. Ese registro permite distinguir una reparación reproducible de una desaparición temporal del síntoma.
Qué no debes hacer
Nunca expongas una contraseña WordPress en URLs, logs o JavaScript. Usa contraseñas de aplicación o un token diseñado específicamente y rotalo después de probar.
Cómo verificar la reparación
- La integración autentica con la credencial no interactiva prevista.
- El mismo usuario solo puede acceder a las rutas y métodos que necesita.
- Los encabezados de autorización y los secretos no aparecen en público logs o fuente de página.
Que el síntoma visible desaparezca no es suficiente. Cierra la incidencia solo cuando la acción original que fallaba, el recorrido de negocio relacionado y los registros relevantes confirmen que el problema ha desaparecido.