Muitos redirecionamentos após migrar o WordPress para HTTPS

O que este erro significa e como reconhecê-lo

• O site funcionava por HTTP antes da migração para HTTPS e depois começou a exibir “muitos redirecionamentos”.
• O navegador alterna repetidamente entre HTTP e HTTPS ou solicita várias vezes o mesmo endereço HTTPS.
• O site inteiro pode falhar, ou apenas /wp-admin, a página de login ou determinados caminhos podem entrar em loop.
• Abrir o endereço HTTP pode gerar um redirecionamento HTTPS esperado, seguido de redirecionamentos repetidos em vez de uma resposta normal.
• A navegação privativa ou outro dispositivo pode apresentar um comportamento diferente por causa de redirecionamentos, cookies ou dados do site armazenados em cache.

Causas principais, por probabilidade

1. As configurações de URL do WordPress ainda usam HTTP. Se Endereço do WordPress (URL) ou Endereço do site (URL) continuar usando HTTP enquanto outra camada exige HTTPS, o WordPress poderá redirecionar para um esquema que entra em conflito com a política do servidor.
2. A aplicação de HTTPS existe em várias camadas. Um plugin de segurança, uma lógica em wp-config.php, uma regra em .htaccess ou Nginx, uma configuração da hospedagem e uma regra do proxy podem se sobrepor ou fazer suposições diferentes sobre o esquema da solicitação.
3. Uma CDN ou um reverse proxy termina o TLS. O visitante se conecta por HTTPS, enquanto a conexão com a origem é HTTP. Se o protocolo original estiver ausente, incorreto ou não for confiável de forma segura, o WordPress poderá acreditar repetidamente que a solicitação não é segura.
4. Um plugin ou tema redireciona um caminho específico. Plugins de login, administração, URL canônica, segurança e membership podem afetar apenas /wp-login.php, /wp-admin ou páginas específicas.
5. Um redirecionamento antigo armazenado em cache ou um cookie do navegador mascara a correção. É menos provável que essa seja a causa original, mas isso pode fazer uma configuração corrigida parecer quebrada.
6. Referências HTTP antigas permanecem no conteúdo ou na configuração. Normalmente elas causam avisos de mixed content ou um redirecionamento adicional, não um loop de redirecionamento em todo o site; investigue-as depois que a cadeia principal estiver corrigida.

Como corrigir

1. Inspecione a cadeia de redirecionamento

Use uma janela de navegação privativa para uma verificação inicial. Se você tiver acesso ao shell, defina uma variável do shell com o endereço HTTPS real do site afetado e execute esta solicitação somente de leitura:

SITE_URL='the actual HTTPS site address'
curl -IL "$SITE_URL"

Registre cada código de status e cada cabeçalho Location:. A alternância entre HTTP e HTTPS geralmente indica um conflito na detecção do esquema ou nas regras de redirecionamento. A repetição do mesmo endereço HTTPS aponta mais para um redirecionamento canônico, de plugin, proxy ou cache. Não inclua credenciais, cookies ou cabeçalhos de autorização.

2. Verifique as duas configurações de URL do WordPress

Se o painel estiver disponível, abra Configurações → Geral e confirme se Endereço do WordPress (URL) e Endereço do site (URL) usam a mesma origem HTTPS pretendida, incluindo qualquer subdiretório necessário.

Se o loop bloquear o painel, um administrador autorizado com acesso via SFTP ou ao banco de dados poderá definir temporariamente os valores em wp-config.php:

define( 'WP_HOME', 'the actual canonical HTTPS address' );
define( 'WP_SITEURL', 'the actual canonical HTTPS address' );

Faça primeiro um backup do arquivo e execute uma alteração controlada. Enquanto estiverem definidos, essas constantes substituem os campos correspondentes do painel; portanto, remova-as ou gerencie-as deliberadamente após o teste.

3. Determine onde o TLS termina

Verifique se o navegador se conecta diretamente ao servidor web ou por meio de uma CDN, um load balancer ou um reverse proxy. Quando um proxy termina o TLS, a origem pode receber uma conexão HTTP mesmo que o visitante tenha usado HTTPS.

Peça ao administrador da hospedagem ou do proxy para confirmar que o protocolo original é encaminhado de forma consistente e que o WordPress está configurado para reconhecê-lo somente a partir do proxy confiável pretendido. Não confie cegamente em X-Forwarded-Proto enviado por clientes arbitrários; um cabeçalho encaminhado não validado pode criar problemas de segurança.

4. Reduza a aplicação de HTTPS a uma única camada deliberada

Liste todos os locais que podem redirecionar HTTP para HTTPS:

• Regras da CDN ou do load balancer
• Configurações de SSL no painel da hospedagem
• Configuração do Apache .htaccess ou do Nginx
• Plugins de segurança ou SSL
• Código personalizado em wp-config.php ou no tema

Mantenha a aplicação na camada adequada à arquitetura da hospedagem, normalmente na edge ou no servidor web, e desative redirecionamentos conflitantes no nível da aplicação. Faça backup da configuração e obtenha aprovação do administrador antes de alterar regras do servidor. Valide a configuração antes de qualquer reload ou restart aprovado; não reinicie um servidor web de produção como primeira etapa de diagnóstico.

5. Teste os caminhos de login e administração separadamente

Se a interface pública funcionar, mas /wp-admin ou o login entrar em loop, revise os plugins de segurança, login, URL canônica e cache alterados recentemente usando um procedimento de manutenção aprovado. Um conflito de plugin é mais provável quando apenas um caminho entra em loop. Se um plugin precisar ser desativado para o teste, registre a alteração, preserve os controles de acesso e reative-o ou substitua-o após o teste.

6. Limpe os caches e teste novamente

Depois de registrar o comportamento original e fazer uma correção controlada, limpe os dados do site no navegador e purge os caches de página ou objetos do WordPress, além dos caches da hospedagem e da CDN. Teste novamente o endereço HTTP, a página inicial HTTPS, a página de login e uma página interna representativa. Um 301 ou 302 armazenado em cache pode persistir depois que a configuração ativa for corrigida.

7. Atualize as referências HTTP restantes

Depois que a cadeia de redirecionamento estiver corrigida, faça backup do banco de dados antes de alterar URLs armazenadas. Use uma ferramenta confiável de migração do WordPress ou o recurso de pesquisa e substituição do WP-CLI, primeiro com uma simulação (dry run), e use uma ferramenta que lide com dados serializados do WordPress. Substitua somente a origem antiga do site pela origem HTTPS; não substitua amplamente todos os valores http://, pois URLs de terceiros e recursos externos intencionalmente usados podem não pertencer ao site.

Prevenção e como verificar a correção

• Registre a origem HTTPS canônica do site e atualize as duas configurações de URL do WordPress durante a migração.
• Escolha um local documentado para o redirecionamento HTTP-para-HTTPS e revise as outras camadas antes de ativar um plugin de force-SSL.
• Documente se uma CDN ou um reverse proxy termina o TLS e como a origem obtém o protocolo original.
• Teste a página inicial, uma página interna, o login e o painel após cada alteração na configuração HTTPS.
• Faça backup da configuração e do banco de dados antes de editar wp-config.php, regras de rewrite ou URLs armazenadas.
• Depois que os redirecionamentos funcionarem, execute uma migração direcionada de URLs para HTTPS e verifique referências de mixed content.

Perguntas frequentes