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

  1. Capture el mensaje exacto saneado, el estado HTTP y el cuerpo de respuesta sin incluir secretos.
  2. Registre las versiones de WordPress, plugin, cliente, conector y servidor antes de cambiar nada.
  3. Confirme que la URL exacta usada por el asistente carga con una conexión HTTPS válida.
  4. Confirme que WordPress considera la solicitud HTTPS, no solo el navegador.
  5. Compruebe si las Application Passwords están disponibles globalmente en el entorno activo.
  6. Compare Home URL, Site URL, host canónico público y dirección base REST.
  7. Compare la versión instalada con el registro oficial de cambios y las versiones correctivas.

Aplicar la corrección mínima

  1. Corrija el manejo del proxy de confianza y del origen para que WordPress reconozca la solicitud HTTPS original.
  2. Elimine o limite el filtro que desactiva Application Passwords solo después de confirmar la política de seguridad prevista.
  3. Alinee Home URL, Site URL, host público, esquema HTTPS y dirección base REST.
  4. Actualice a la versión del plugin que documenta o corrige el comportamiento observado.
  5. 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

Fuentes y verificación

Esta página se verificó a partir de las siguientes fuentes primarias. Última revisión de las fuentes: .