El encabezado Authorization de WordPress falta o se elimina
El alojamiento, proxy inverso, redirección o WAF elimina el encabezado Authorization antes de que llegue a WordPress.
Verifique mediante evidencia saneada del servidor que el encabezado Authorization llega a WordPress.
Causas probables
- El alojamiento, proxy inverso, redirección o WAF elimina el encabezado Authorization antes de que llegue a WordPress.
- Un WAF o regla de seguridad bloquea la ruta REST, método, carga o patrón de autenticación.
- Una redirección cambia el esquema, host o ruta y también puede descartar encabezados de autenticación.
- El proxy no reenvía la información de esquema que WordPress necesita para reconocer HTTPS.
- El cliente llama al dominio, ruta base, endpoint REST o endpoint MCP equivocado.
Secuencia de diagnóstico
- Verifique mediante evidencia saneada del servidor que el encabezado Authorization llega a WordPress.
- Siga cada redirección y verifique que se conserven esquema, host, ruta y Authorization.
- Revise el evento exacto del WAF o plugin de seguridad, incluida la ruta, método e identificador de regla.
- Registre las versiones de WordPress, plugin, cliente, conector y servidor antes de cambiar nada.
- Use una comprobación mínima de identidad autenticada para confirmar qué usuario representa la solicitud.
- Confirme el esquema, host, ruta base y endpoint exactos configurados en el cliente.
Aplicar la corrección mínima
- Configure el servidor o proxy de confianza para pasar el encabezado Authorization a WordPress.
- Ajuste solo la regla, ruta o método del falso positivo verificado, sin desactivar toda la protección.
- Elimine o corrija la redirección que modifica inesperadamente la solicitud autenticada.
- Corrija endpoint, transporte, nombre de herramienta o referencia de credencial sin ampliar permisos.
- Escale con evidencia saneada y versionada cuando el comportamiento siga siendo específico del plugin.
Verificar el resultado
- La evidencia saneada confirma que el encabezado Authorization llega a WordPress.
- La solicitud autenticada corresponde al usuario dedicado previsto.
- La lectura limitada aprobada se completa con una respuesta reproducible.
- La solicitud autenticada llega al endpoint canónico sin una redirección inesperada.
Qué no hacer
- No desactive globalmente el WAF o plugin de seguridad para evitar una sola solicitud.
- No incluya una Application Password, encabezado Authorization, token o cookie en prompts, tickets, registros o capturas.
- No exponga públicamente registros de depuración o endpoints de diagnóstico.
- No añada una solución permanente y no verificada del proxy antes de confirmar la ruta de confianza.
- No conceda acceso de administrador solo para que una prueba de conexión funcione.
Guías relacionadas
- Una Application Password de WordPress devuelve 401 Unauthorized
- Un plugin de seguridad o un WAF bloquea la REST API de WordPress
- Bucle de redirección en una conexión IA de WordPress: HTTP, HTTPS y URL canónica
- Contraseñas de aplicación de WordPress para conexiones de IA
- Solución de problemas de acceso de Claude Code o Codex a WordPress
Fuentes y verificación
Esta página se verificó a partir de las siguientes fuentes primarias. Última revisión de las fuentes: .
- Application Passwords · WordPress Developer Resources
- wp_authenticate_application_password() · WordPress Developer Resources
- RFC 9110: HTTP Semantics · RFC Editor
- REST API Handbook · WordPress Developer Resources