...
logótipo de alojamento web

Reconhecer e corrigir loops de redireccionamento no WordPress - causas e soluções

Vou explicar de forma concisa e clara como pode criar um Loop de redireccionamento WordPress e analisá-los e resolvê-los de forma fiável. Mostrar-lhe-ei soluções imediatamente realizáveis para conflitos SSL, regras .htaccess incorrectas, URLs de sites incorrectos, caching/cookies, problemas de plugins e definições de servidor - incluindo testes e prevenção.

Pontos centrais

A lista seguinte resume os passos mais importantes antes de os explicar em pormenor.

  • Causa reduzir rapidamente: SSL, .htaccess, URLs, plugins, cache
  • Padrão-Verificar regras: .htaccess e wp-config.php
  • HTTPS definido corretamente: Certificado, Conteúdo Misto, HSTS
  • Plugins Desligar numa base de teste: através do painel de controlo ou FTP
  • Prevenção estabelecer: Cópias de segurança, documentação, monitorização

O que significa realmente um loop de redireccionamento?

A Loop de encaminhamento ocorre quando o URL A salta para o URL B e B salta de volta para A - ou quando vários saltos levam ao endereço inicial no final. O browser cancela então com ERR_TOO_MANY_REDIRECTS e bloqueia a chamada. Muitas vezes reconheço o ciclo pelo facto de o início de sessão carregar novamente o formulário de início de sessão após a introdução correta. Para os visitantes, isto parece uma ronda interminável e, para os motores de busca, um erro técnico. Isto custa confiança, impede os logins no backend e consome valiosos orçamentos de rastreio.

Principais causas de loops no WordPress

Os gatilhos mais frequentes são falso URLs do WordPress, regras .htaccess agressivas, duplo controlo de SSL ou redireccionamentos caóticos de plugins. Os cookies antigos e as caches difíceis do browser também desviam os pedidos. Após alterações de domínio ou conversões para HTTPS, os erros ocorrem com mais frequência porque o http e o https estão misturados. Em temas com os seus próprios redireccionamentos ou plug-ins de segurança, as regras podem bloquear-se mutuamente. Em casos raros, o malware define deliberadamente redireccionamentos para bloquear os administradores.

Testes rápidos no browser: Cookies e cache

Começo com um Cliente-Verificar, porque traz clareza em minutos. Elimino os cookies e toda a cache do domínio afetado. Uma janela privada ajuda a excluir sessões antigas. Se o início de sessão funcionar, isso deve-se a dados locais e não ao servidor. Se o erro continuar a ocorrer, vou ao nível do servidor e do WordPress.

Verifique o .htaccess e reponha as predefinições

Eu seguro o .htaccess e redefini-los para o padrão do WordPress como um teste. É assim que removo redireccionamentos contraditórios de experiências anteriores ou regras de SEO.

# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

Quando tudo estiver a funcionar, acrescentarei redireccionamentos adicionais, passo a passo. Para condições limpas, remeto para redireccionamentos htaccess com exemplos práticos. Importante: Nunca forçar http→https duas vezes - uma vez ao nível do servidor é suficiente.

Personalizar os URLs do WordPress nas definições e em wp-config.php

Desvios entre WP_HOME e WP_SITEURL desencadeiam frequentemente loops intermináveis, especialmente após transferências de domínio. Começo por verificar Definições > Geral. Se o backend não estiver acessível, defino brevemente os valores em wp-config.php:

define( 'WP_HOME', 'https://deinedomain.de' );
define( 'WP_SITEURL', 'https://deinedomain.de' );

Em caso de problemas de SSL da administração, também desbloqueio temporariamente o acesso:

define('FORCE_SSL_ADMIN', false);

Assim que entro no painel de controlo, defino os URLs corretos e volto a remover as constantes. Os endereços normalizados evitam ciclos repetidos.

Resolver conflitos HTTPS/SSL de forma limpa

Os conflitos surgem quando SSL é aplicado no lado do servidor e um plugin também define os redireccionamentos. Primeiro testo se o certificado é válido e se os cabeçalhos HSTS ou proxy interferem com o reconhecimento. Em seguida, asseguro-me de que existe uma localização clara que impõe o https - de preferência ao nível do servidor. Elimino sistematicamente os erros de conteúdo misto e as cadeias de encaminhamento incorrectas. Para a mudança efectiva, estas instruções ajudam-me a Conversão de HTTPS no WordPress.

Limitação de plugins e temas como fonte de erros

Ligo-me desconfiado Plugins especialmente ferramentas de redireccionamento, SEO e segurança. Se não conseguir aceder ao backend, renomeio a pasta wp-content/plugins para plugins.old através de FTP. Em seguida, ativo cada plug-in individualmente no painel de controlo até o erro reaparecer. Mudar para um tema padrão como o Twenty Twenty-Four também mostra se o tema está a contribuir com regras. Isto permite-me encontrar rapidamente a causa e criar uma configuração sem conflitos.

Acabar com os loops de início de sessão: Cookies, Sessões, Segurança

Se o início de sessão falhar, apesar de estar correto Dados Verifico o domínio do cookie, o caminho e o sinalizador https. Limpo as caches a todos os níveis: Navegador, cache do WordPress, cache de objectos, CDN. Para os plug-ins de segurança, verifico as regras que redireccionam os URLs de administração ou restringem os logins. Defino temporariamente padrões claros para diagnóstico e depois reconstruo a segurança pouco a pouco. Objetivo: uma sessão estável sem redireccionamentos duplicados.

Definir corretamente o proxy inverso, a CDN e o cabeçalho do servidor

Atrás de um Proxy as aplicações confundem facilmente http e https se o cabeçalho Forwarded ou X-Forwarded-Proto estiver em falta ou chegar incorretamente. Verifico as configurações do Nginx/Apache, as definições do balanceador de carga e o encaminhamento da CDN. É importante que o WordPress reconheça corretamente o URL real do cliente. Para configurações com um proxy upstream, este guia ajuda-me a Configurar o proxy invertido. Isto evita regras contraditórias entre o servidor, a CDN e o plugin.

O malware como última fonte de suspeita

Se, apesar de todas as correcções, o ciclo ainda puder ser fechado não Analiso a instalação em busca de código malicioso. Comparo os ficheiros principais com os originais, verifico os administradores mais recentes e as tarefas cron. Exponho redireccionamentos em cabeçalhos, ficheiros de modelos ou através de JavaScript, procurando por window.location, meta refresh ou strings Base64 obscuras. Após a limpeza, redefino as palavras-passe e faço uma nova cópia de segurança. A segurança contra reinfecções poupa muito tempo mais tarde.

Profilaxia e monitorização na vida quotidiana

Evito os loops Alterações gerir centralmente os redireccionamentos e testá-los num ambiente de teste antes da implementação em tempo real. Crio cópias de segurança automaticamente e mantenho os plug-ins e os temas actualizados. Após as alterações de domínio, verifico os URLs do site, o SSL e as cadeias de redireccionamento. Um pequeno sistema de monitorização notifica-me de saltos no código de estado numa fase inicial. A tabela seguinte ajuda a efetuar diagnósticos rápidos durante o funcionamento.

Sintoma Causa possível Medida direta Ferramenta de teste
ERR_TOO_MANY_REDIRECTS Aplicação de duplo https Utilizar apenas uma localização para redireccionamentos Verificação do cabeçalho HTTP, Curl
Login salta para trás Conflito entre cookies e sessões Eliminar cookies, esvaziar a cache Janela privada, DevTools
A página inicial não carrega loop .htaccess Ativar o .htaccess padrão Registos do servidor, diff
Defeito apenas sob procuração Cabeçalho Proto incorreto Definir corretamente o X-Forwarded-Proto Proxy-Config, Header-Trace
De repente, da classificação Cadeias de redireccionamento Reduzir as correntes, 301 correto Rastejante, sapo gritador

Rastreie os redireccionamentos com precisão: Rastreio de cabeçalhos e curl

Antes de passar às configurações, desenho o cadeia exacta para. No DevTools (separador Rede) pode ver cada salto com o código de estado e o cabeçalho de localização. No shell é muitas vezes suficiente:

curl -IL https://deinedomain.de
# ou detalhado com visualização de cada redireccionamento
curl -IL --max-redirs 20 https://deinedomain.de

Procuro padrões como http→https→http (ida e volta) ou www↔não-www. Um 302 a seguir a um 301 também é suspeito. Se mesmo o primeiro pedido for redireccionado para /wp-login.php, a causa está normalmente no plugin/tema ou nos cookies; se acontecer globalmente, é frequentemente o .htaccess ou o servidor.

Utilização orientada dos registos do servidor e do WordPress

Os registos poupam horas. Activei o registo de depuração em wp-config.php sem o mostrar aos visitantes:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

Em seguida, verifico o ficheiro /wp-content/debug.log em busca de indicações (por exemplo, "Cannot modify header information" antes de um redireccionamento). Ao mesmo tempo, verifico os registos do servidor Web. Para o Apache: access.log e error.log, para o Nginx: access.log com o estado 301/302. Um olhar sobre o agente do utilizador ajuda a determinar se apenas os bots ou todos os utilizadores são afectados.

WP-CLI: recuperação rápida através da consola

Se o painel de controlo não estiver acessível, resolvo muitas coisas através de WP-CLI:

# Verificar e definir URLs
wp option get home
wp option get siteurl
wp option update home 'https://deinedomain.de'
wp option update siteurl 'https://deinedomain.de'

# "Guardar através de" permalinks uma vez
wp rewrite flush --hard

# Esvaziar as caches
wp cache flush
wp transient delete --all

# Desativar / testar plugins em massa
wp plugin deactivate --all
wp plugin activate classic-editor

Desta forma, posso voltar ao sistema sem riscos, encontrar os culpados e ativar apenas o que é realmente necessário.

www, barra e canonização sem ciclo

Os loops são frequentemente criados a partir de pequenas incoerênciaswww vs. não-www, barra em falta/adicional ou proto misto. Decido a favor de uma variante e defino apenas a Cadeia de regras. Exemplo de non-www→www no Apache (sem aplicação de duplo https):

RewriteEngine On
# Reencaminhar apenas se o anfitrião não for já www
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}/$1 [L,R=301]

Com o Nginx, defino um reencaminhamento claro do bloco do servidor e evito regras mistas em PHP/plugins. Importante: Primeiro a canonização (www/barreira), depois https - e apenas para a Posição.

Limpar atrás de proxy/CDN: Reconhecer HTTPS corretamente

Se o WordPress estiver atrás de um balanceador de carga ou CDN, o backend muitas vezes só recebe http, embora o cliente use https. O WordPress reconhece então o is_ssl() incorretamente e gera loops. Corrijo as variáveis do servidor no início do wp-config.php:

se (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

Também defino os cabeçalhos X-Forwarded-Proto e Forwarded clean no proxy. Utilizo o HSTS com moderação: Se o HSTS estiver ativo, pode nenhum caminho http, caso contrário o browser bloqueia. Só utilizo o pré-carregamento quando todos os subdomínios estão a funcionar de forma estável em https.

Desativar as armadilhas de início de sessão e de cookies

Uma fonte comum é a definição incorrecta de cookies. Normalmente, defino nenhum COOKIE_DOMAIN. Se já tiver sido definido uma vez, altero-o como um teste:

define('COOKIE_DOMAIN', false);

Também verifico se o sinalizador de cookie de administração "Secure" está definido em https e se o caminho está definido para "/". No caso de problemas persistentes, elimino as sessões do lado do servidor (por exemplo, reinicio o php-fpm) e esvazio a cache de objectos/redis para que os nonces antigos deixem de ter efeito.

Caraterísticas especiais do mapeamento de vários sítios e domínios

Em Multisite-configurações, mapeamentos diferentes conduzem rapidamente a um ciclo: Modo subdomínio vs. modo diretório, protocolos diferentes ou um antigo plugin de mapeamento de domínios com os seus próprios redireccionamentos. Verifico as tabelas do blogue e do sítio, sincronizo protocolos e anfitriões e desativo brevemente os redireccionamentos automáticos para a mudança de idioma. Um login de "Super Admin" no blogue principal ajuda a ver os redireccionamentos da rede de forma centralizada. Importante: apenas uma instância decide sobre o domínio canónico.

WooCommerce, multilinguismo e "Ocultar início de sessão"

As lojas e os sítios multilingues dispõem de lógicas de redireccionamento adicionais: páginas SSL forçadas (checkout/conta), redireccionamento da língua para Accept-Language ou funções "Hide Login" nos plugins de segurança. Para o diagnóstico, desactivei o redireccionamento automático de idioma e autorizei temporariamente /wp-login.php sem desvio. No WooCommerce, defino "Apenas estas páginas em SSL" de forma limpa no lado do servidor ou completamente em todo o sistema para que não ocorram estados mistos.

Cache de objectos de coordenadas, cache de opcode e edge

Várias camadas de cache podem um ao outro amplify: código de operação PHP (OPcache), cache de objectos (Redis/Memcached), cache de páginas de plugins e CDN edge. Esvazio-as numa sequência ordenada para que nenhuma camada devolva redireccionamentos antigos. Após as alterações de regras, invalido completamente a cache de borda. Só então um teste faz sentido.

Armadilhas típicas do Nginx

Com o Nginx, os loops ocorrem quando os blocos de localização são reescritos duas vezes ou o /index.php vive internamente e externamente. Eu uso uma única configuração limpa: primeiro o encaminhamento do bloco do servidor (www/https), depois um try_files claro em /index.php. Evito consistentemente misturas de add_header refresh e 301/302.

Lista de controlo: encontrar a causa em 10 minutos

  • Eliminar cookies/cache localmente, testar no modo de navegação anónima
  • execute curl -IL e veja a cadeia
  • Redefinir .htaccess/Nginx para o caminho padrão
  • Sincronizar WP_HOME/WP_SITEURL (se necessário através de WP-CLI)
  • Apenas uma instância impõe https (servidor preferencial)
  • Desativar os plug-ins/tema, ativar passo a passo
  • Definir corretamente o cabeçalho do proxy, verificar is_ssl()
  • Cache de objeto/página/borda vazia
  • Verificar os registos: debug.log, access/error.log
  • Caraterísticas especiais: Multisite, Woo, Idiomas, Hide-Login

Padrões de erro para além dos loops clássicos

Nem todos os 301/302 são um verdadeiro loop - mas Desvio de rota custos também. Um 301 para 404 sinaliza aos motores de busca que "este recurso está aqui para sempre", mas entrega o vazio. Ou um 302 em vez de 301 impede a consolidação permanente dos sinais. Mantenho a cadeia num máximo de um ou dois níveis, defino 301 para casos permanentes, 302 para casos temporários e evito perdas de cadeias de caracteres de consulta passando corretamente sinalizadores ou argumentos QSA.

Implementações e documentação estáveis

Para evitar que os loops ocorram em primeiro lugar, documentei todas as regrasQuem encaminha o quê para onde - e porquê? Utilizo um ambiente de teste, faço as alterações de regras, registo cabeçalhos e horários e depois distribuo definições idênticas de servidor e plug-in na produção. Uma breve verificação pós-implementação (página inicial, login, checkout, idioma) evita falhas.

Conclusão em resumo

Estou a lançar um Loop de encaminhamento Sistemático: Verificar os cookies, repor o .htaccess para as predefinições, personalizar os URLs do WP, definir corretamente o SSL, isolar os plugins/tema e fornecer corretamente os cabeçalhos do servidor. Estes passos normalmente terminam o ciclo num curto espaço de tempo. Depois, protejo a instalação, documento os redireccionamentos e mantenho as actualizações em dia. Isto mantém o início de sessão acessível, os visitantes chegam às páginas corretas e os motores de busca fazem o rastreio sem perder tempo. Uma abordagem estruturada evita a repetição - e poupa os nervos.

Artigos actuais