Por qué WAP AI Assistant muestra una advertencia HTTPS en un sitio que ya usa HTTPS
Un candado válido en el navegador confirma la conexión entre el visitante y el borde, pero no demuestra por sí solo lo que WordPress recibe en el origen. Un proxy inverso, un balanceador de carga o el modo de cifrado de una CDN puede hacer que el navegador use HTTPS mientras la solicitud llega a WordPress mediante HTTP.
El mismo aviso también puede aparecer cuando la detección de HTTPS es correcta, pero las contraseñas de aplicación están desactivadas globalmente o para el usuario actual. Pruebe ambas condiciones por separado.
Causas probables
- El navegador usa HTTPS, pero WordPress no detecta como segura la solicitud recibida en el origen.
- Un plugin de seguridad, un plugin obligatorio o un filtro personalizado desactiva globalmente las Application Passwords.
- La versión instalada del plugin muestra un aviso HTTPS incorrecto u obsoleto.
- Home URL y Site URL de WordPress usan esquemas, hosts o rutas diferentes.
- Otro plugin modifica la detección de HTTPS, el acceso REST o la disponibilidad de Application Passwords.
Secuencia de diagnóstico
- Capture el mensaje exacto saneado, el estado HTTP y el cuerpo de respuesta sin incluir secretos.
- Registre las versiones de WordPress, plugin, cliente, conector y servidor antes de cambiar nada.
- Confirme que la URL exacta usada por el asistente carga con una conexión HTTPS válida.
- Confirme que WordPress considera la solicitud HTTPS, no solo el navegador.
- Compruebe si las Application Passwords están disponibles globalmente en el entorno activo.
- Compare Home URL, Site URL, host canónico público y dirección base REST.
- Compare la versión instalada con el registro oficial de cambios y las versiones correctivas.
Aplicar la corrección mínima
- Corrija el manejo del proxy de confianza y del origen para que WordPress reconozca la solicitud HTTPS original.
- Elimine o limite el filtro que desactiva Application Passwords solo después de confirmar la política de seguridad prevista.
- Alinee Home URL, Site URL, host público, esquema HTTPS y dirección base REST.
- Actualice a la versión del plugin que documenta o corrige el comportamiento observado.
- Escale con evidencia saneada y versionada cuando el comportamiento siga siendo específico del plugin.
Verificar el resultado
- El aviso desaparece solo en la condición corregida y no vuelve en páginas de administración no relacionadas.
- El índice REST responde desde la URL HTTPS canónica y expone los espacios de nombres esperados.
- La solicitud autenticada llega al endpoint canónico sin una redirección inesperada.
- La solicitud autenticada corresponde al usuario dedicado previsto.
Qué no hacer
- No conceda acceso de administrador solo para que una prueba de conexión funcione.
- No añada una solución permanente y no verificada del proxy antes de confirmar la ruta de confianza.
- 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 describa el aviso o credencial como malware, puerta trasera o compromiso sin evidencia.
Guías relacionadas
- WAP AI Assistant requiere HTTPS en WordPress: qué significa y cómo corregirlo
- WordPress no detecta HTTPS detrás de Cloudflare o de un proxy inverso
- Las Application Passwords de WordPress están desactivadas: causas y comprobaciones
- Una discrepancia entre Home URL y Site URL de WordPress rompe las conexiones de IA
- Contraseñas de aplicación de WordPress para conexiones de IA
Fuentes y verificación
Esta página se verificó a partir de las siguientes fuentes primarias. Última revisión de las fuentes: .
- WAP Client for WordPress Plugins · group.one / One.com
- Rank Math Free Changelog · Rank Math
- wp_is_application_passwords_available() · WordPress Developer Resources
- is_ssl() · WordPress Developer Resources
- home_url() · WordPress Developer Resources
- site_url() · WordPress Developer Resources