PAGUP Agent ControlAcesso ao WordPress para assistentes de IA
Testar grátis

O WordPress não detecta HTTPS atrás da Cloudflare ou de um proxy reverso

O navegador usa HTTPS, mas o WordPress não reconhece a solicitação recebida na origem como segura.

Confirme que a URL exata usada pelo assistente abre com uma conexão HTTPS válida.

Causas prováveis

  • O navegador usa HTTPS, mas o WordPress não reconhece a solicitação recebida na origem como segura.
  • O proxy não encaminha a informação de esquema necessária para o WordPress reconhecer HTTPS.
  • Home URL e Site URL usam esquemas, hosts ou caminhos diferentes.
  • Um redirecionamento muda esquema, host ou caminho e pode remover cabeçalhos de autenticação.
  • Outro plugin altera a detecção de HTTPS, o acesso REST ou a disponibilidade das Application Passwords.

Sequência de diagnóstico

  1. Confirme que a URL exata usada pelo assistente abre com uma conexão HTTPS válida.
  2. Confirme que o próprio WordPress reconhece a solicitação como HTTPS, não apenas o navegador.
  3. Revise os cabeçalhos do proxy confiável que comunicam o esquema HTTPS original.
  4. Compare Home URL, Site URL, host canônico público e endereço base REST.
  5. Rastreie cada redirecionamento e verifique esquema, host, caminho e Authorization.
  6. Registre as versões de WordPress, plugin, cliente, conector e servidor antes de qualquer alteração.

Aplicar a menor correção necessária

  1. Corrija o tratamento do proxy confiável e da origem para o WordPress reconhecer a solicitação HTTPS original.
  2. Alinhe Home URL, Site URL, host público, esquema HTTPS e endereço base REST.
  3. Remova ou corrija o redirecionamento que altera inesperadamente a solicitação autenticada.
  4. Ajuste apenas a regra, rota ou método do falso positivo confirmado.
  5. Encaminhe evidências higienizadas e versionadas quando o comportamento continuar específico do plugin.

Verificar o resultado

  • O aviso desaparece somente na condição corrigida e não volta em páginas administrativas sem relação.
  • A solicitação autenticada chega ao endpoint canônico sem redirecionamento inesperado.
  • O índice REST responde pela URL HTTPS canônica e expõe os namespaces esperados.
  • A solicitação autenticada corresponde ao usuário dedicado pretendido.

O que não fazer

  • Não adicione uma solução permanente e não verificada de proxy antes de confirmar o caminho confiável.
  • Não desative globalmente WAF ou plugin de segurança para contornar uma solicitação.
  • Não edite o núcleo do WordPress ou arquivos de plugins terceiros como primeiro passo.
  • Não conceda acesso de administrador apenas para uma prova de conexão funcionar.
  • Não inclua Application Password, Authorization, token ou cookie em prompt, chamado, log ou captura.

Perguntas frequentes

Devo forçar HTTPS com um trecho permanente de código?

Somente depois de entender o contrato de hospedagem e proxy. Um trecho genérico pode esconder uma configuração incorreta na origem ou confiar em um cabeçalho encaminhado não verificado.

Guias relacionados

Fontes e verificação

Esta página foi verificada com base nas seguintes fontes primárias. Última revisão das fontes: .