Erros de redirecionamento

Sobre esta categoria de erros

# Erros de redirecionamento

Erros de redirecionamento acontecem quando uma solicitação é enviada de uma URL para outra, mas nunca chega a uma página final, ou quando passa por mais redirecionamentos do que o necessário. Os sintomas típicos incluem ERR_TOO_MANY_REDIRECTS, mudanças repetidas na barra de endereço, alternância entre URLs HTTP e HTTPS ou uma página que não consegue carregar após vários redirecionamentos.

Os redirecionamentos normalmente são usados para finalidades válidas: forçar o uso de HTTPS, selecionar um hostname preferencial, mover uma URL antiga ou encaminhar uma solicitação para um novo caminho. Um erro geralmente aparece quando as decisões de redirecionamento entram em conflito entre camadas ou quando um estado armazenado em cache faz o navegador repetir um resultado desatualizado.

Principais tipos de erros de redirecionamento

Loops de redirecionamento

Um loop de redirecionamento ocorre quando a sequência retorna, em algum momento, a uma URL que já foi solicitada. Por exemplo, uma regra pode redirecionar HTTP para HTTPS, enquanto outra considera a solicitação HTTPS insegura e a envia de volta para HTTP. O navegador segue o ciclo até interrompê-lo e informar que houve redirecionamentos demais.

Os loops também podem alternar entre hostnames, versões com ou sem barra no final, caminhos ou entre uma URL da aplicação e uma URL do proxy. No WordPress, um loop pode começar após uma migração para HTTPS quando o Endereço do WordPress, o Endereço do site, a configuração de forçar SSL, o tratamento do proxy e o redirecionamento do servidor não descrevem a mesma URL pública. Consulte [Too Many Redirects After Moving WordPress to HTTPS](/wordpress-too-many-redirects-https) para esse caso específico.

Cadeias longas de redirecionamento

Uma cadeia de redirecionamento contém vários redirecionamentos sucessivos antes que a solicitação chegue ao destino final. Uma URL antiga pode primeiro redirecionar para um caminho alterado, depois para um hostname preferencial e, por fim, para HTTPS. As cadeias podem permanecer após várias migrações ou devido à sobreposição de regras.

Uma cadeia é diferente de um loop porque, ao final, chega a uma resposta final. No entanto, ela pode deixar a navegação mais lenta e dificultar a identificação da regra responsável pelo destino final. A pergunta útil para o diagnóstico é se cada redirecionamento intermediário ainda é necessário.

Regras de redirecionamento conflitantes

O comportamento de redirecionamento pode ser controlado por um reverse proxy ou CDN, uma plataforma de hospedagem, um servidor web, um sistema de gerenciamento de conteúdo, um código da aplicação ou um plugin. Essas camadas podem divergir sobre:

• Se a solicitação original usou HTTP ou HTTPS
• Qual hostname é o canônico
• Se um caminho deve incluir uma barra no final
• Se um caminho antigo deve ser reescrito ou redirecionado
• Qual URL deve ser considerada o endereço final da aplicação

Um proxy pode receber HTTPS do visitante e encaminhar uma conexão com um esquema diferente para a origem. Se a aplicação não estiver configurada para interpretar corretamente o esquema encaminhado, ela poderá emitir outro redirecionamento para HTTPS, mesmo que o visitante já esteja usando HTTPS.

Comportamento relacionado a redirecionamento armazenado em cache ou cookies

Um teste em janela anônima pode ajudar a separar o estado específico do navegador de um problema na configuração compartilhada. Cookies, respostas armazenadas em cache ou o estado da sessão da aplicação podem preservar um domínio, fluxo de login ou decisão de protocolo antigo. Isso não comprova que a configuração do servidor esteja correta; apenas mostra que o resultado pode depender do estado armazenado no cliente.

Se a mesma URL entrar em loop em vários navegadores e dispositivos diferentes, priorize as respostas de redirecionamento e a configuração compartilhada em vez de limpar repetidamente os dados locais.

Como diagnosticar um erro de redirecionamento

1. Registre a URL inicial e o sintoma exato. Anote o esquema, hostname, caminho, barra no final, mensagem do navegador e se o endereço muda repetidamente.
2. Teste uma nova sessão do navegador. Use uma janela anônima ou limpe os cookies e dados armazenados em cache do site afetado. Compare o resultado com outro navegador ou dispositivo, quando possível.
3. Rastreie o histórico de redirecionamentos. As ferramentas de desenvolvedor do navegador ou uma ferramenta de inspeção de cabeçalhos HTTP podem mostrar cada resposta e seu destino Location. Identifique o status retornado em cada etapa e procure uma URL repetida, um esquema alternado, um hostname diferente ou um endereço intermediário desnecessário.
4. Classifique o padrão. Um endereço repetido indica um loop. Uma sequência que termina em uma página indica uma cadeia. Uma alternância entre HTTP e HTTPS aponta para o tratamento do protocolo; uma alternância entre hostnames ou caminhos aponta para regras de canonicalização ou migração.
5. Verifique as configurações da URL pública. Confirme se a URL do site configurada na aplicação corresponde ao esquema e ao hostname que os visitantes devem usar. No WordPress, compare o Endereço do WordPress e o Endereço do site, em vez de alterar apenas um dos valores.
6. Revise as camadas de redirecionamento de fora para dentro. Verifique a CDN ou o reverse proxy, as configurações da hospedagem, as regras do servidor web, a configuração da aplicação e os plugins de redirecionamento ou SSL. Comece pela camada que gerou a resposta Location inesperada.
7. Isole cuidadosamente as alterações recentes. Se o problema começou depois de ativar HTTPS, alterar um domínio, migrar um site, editar links permanentes ou instalar um plugin, compare essas alterações com a sequência de redirecionamentos. Desative ou altere uma regra somente quando tiver autorização e uma forma de restaurar a configuração anterior.
8. Teste novamente as URLs original e final. Use uma nova sessão após cada alteração controlada. Confirme que a URL original chega ao destino pretendido e que a URL final não é mais redirecionada desnecessariamente.

O que verificar primeiro

O erro começou depois de ativar HTTPS

Comece pelo tratamento do protocolo. Verifique onde o HTTPS é encerrado, se a aplicação recebe as informações esperadas sobre uma solicitação segura e se mais de uma camada está forçando o uso de HTTPS. Procure uma regra que redirecione uma solicitação já segura de volta para HTTP ou faça a aplicação emitir um segundo redirecionamento para HTTPS.

O erro começou depois de uma alteração de domínio ou migração

Compare os hostnames, o esquema, o caminho e o comportamento da barra no final antigos e novos. Revise os redirecionamentos da migração e as configurações de URL da aplicação em conjunto. Um hostname atualizado apenas parcialmente ou um redirecionamento que ainda aponta para o domínio antigo pode criar um loop ou uma cadeia longa.

Apenas um navegador ou usuário é afetado

Teste sem os cookies e dados armazenados em cache do site afetado. Se o problema desaparecer, investigue o estado armazenado da sessão ou do redirecionamento antes de alterar as regras compartilhadas do servidor. Se persistir em vários navegadores e dispositivos, concentre-se nos cabeçalhos de resposta e na configuração comum do proxy, servidor ou aplicação.

A cadeia de redirecionamento chega à página, mas é excessivamente longa

Liste todas as URLs intermediárias e determine qual regra introduziu cada uma. Consolide as regras de migração desatualizadas quando apropriado, preservando os redirecionamentos intencionais e verificando se as URLs antigas ainda chegam ao destino final correto.

Documentação do fornecedor a consultar

Para obter detalhes específicos de implementação, consulte a documentação do servidor web, reverse proxy ou CDN, plataforma de hospedagem, sistema de gerenciamento de conteúdo e plugin de redirecionamento ou SSL envolvidos na solicitação. Pesquise nesses documentos informações sobre encerramento de HTTPS, cabeçalhos de protocolo encaminhados, redirecionamentos para o host canônico, precedência de redirecionamentos e invalidação de cache. A configuração correta depende da camada que recebe a solicitação original e da camada que gera cada redirecionamento.