PAGUP Agent ControlAcceso a WordPress para asistentes de IA
Probar gratis

WordPress no detecta HTTPS detrás de Cloudflare o de un proxy inverso

El navegador usa HTTPS, pero WordPress no detecta como segura la solicitud recibida en el origen.

Confirme que la URL exacta usada por el asistente carga con una conexión HTTPS válida.

Causas probables

  • El navegador usa HTTPS, pero WordPress no detecta como segura la solicitud recibida en el origen.
  • El proxy no reenvía la información de esquema que WordPress necesita para reconocer HTTPS.
  • Home URL y Site URL de WordPress usan esquemas, hosts o rutas diferentes.
  • Una redirección cambia el esquema, host o ruta y también puede descartar encabezados de autenticación.
  • Otro plugin modifica la detección de HTTPS, el acceso REST o la disponibilidad de Application Passwords.

Secuencia de diagnóstico

  1. Confirme que la URL exacta usada por el asistente carga con una conexión HTTPS válida.
  2. Confirme que WordPress considera la solicitud HTTPS, no solo el navegador.
  3. Revise los encabezados del proxy de confianza que comunican a WordPress el esquema HTTPS original.
  4. Compare Home URL, Site URL, host canónico público y dirección base REST.
  5. Siga cada redirección y verifique que se conserven esquema, host, ruta y Authorization.
  6. Registre las versiones de WordPress, plugin, cliente, conector y servidor antes de cambiar nada.

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. Alinee Home URL, Site URL, host público, esquema HTTPS y dirección base REST.
  3. Elimine o corrija la redirección que modifica inesperadamente la solicitud autenticada.
  4. Ajuste solo la regla, ruta o método del falso positivo verificado, sin desactivar toda la protección.
  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.
  • La solicitud autenticada llega al endpoint canónico sin una redirección inesperada.
  • El índice REST responde desde la URL HTTPS canónica y expone los espacios de nombres esperados.
  • La solicitud autenticada corresponde al usuario dedicado previsto.

Qué no hacer

  • 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 edite el núcleo de WordPress o archivos de plugins de terceros como primer paso.
  • No conceda acceso de administrador solo para que una prueba de conexión funcione.
  • No incluya una Application Password, encabezado Authorization, token o cookie en prompts, tickets, registros o capturas.

Preguntas frecuentes

¿Debo forzar HTTPS con un fragmento de código permanente?

Solo después de comprender el contrato de alojamiento y proxy. Un fragmento genérico puede ocultar una mala configuración del origen o confiar en un encabezado reenviado no verificado.

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: .