Corrigir loops de redirecionamento: HTTPS, www e proxies reversos
Encontre a regra em conflito e verifique todo o caminho até sua página.
Equipa técnica do check.uk.app · Revisto em 26 de setembro de 2026
Identifique a URL que se repete
Um loop retorna a uma URL anterior: /shop → /store → /shop. Uma cadeia longa ainda pode terminar com sucesso. Abra a cadeia de redirecionamentos no relatório do check.uk.app e compare os endereços e códigos de status. Um tempo limite excedido ou um limite de saltos, por si só, não comprova um loop.
Registre a resposta pública
Substitua example.com por uma URL pública sob seu controle. Este comando GET salva os cabeçalhos de cada salto e o corpo da resposta final. Ele para após dez redirecionamentos ou trinta segundos. No Windows PowerShell, use curl.exe. Nunca compartilhe resultados de diagnóstico que contenham tokens privados.
curl --silent --show-error --location --max-redirs 10 --max-time 30 --proto "=http,https" --proto-redir "=http,https" --dump-header headers.txt --output body.html https://example.com/Identifique a camada em conflito
Inspecione o CDN, o proxy, o servidor web e a aplicação. Uma camada pode adicionar www enquanto outra o remove. Um proxy que termina TLS pode encaminhar HTTP a uma aplicação que redireciona de volta à mesma URL HTTPS pública. Escolha o host e o esquema canônicos e compare os logs no horário da requisição.
Transmita o esquema por proxies confiáveis
No proxy Nginx que termina TLS, proxy_set_header X-Forwarded-Proto $scheme pode comunicar o esquema externo. A aplicação deve confiar apenas em proxies conhecidos. Em um salto HTTP de proxy interno, $scheme já não representa o esquema original; preserve-o apenas por uma cadeia explicitamente confiável. Nunca trate cabeçalhos de encaminhamento arbitrários fornecidos pelo cliente como fonte confiável.
Verifique e mantenha uma opção de reversão
Salve as regras originais. Altere uma camada, valide sua configuração e repita o GET para HTTP, HTTPS e ambas as variantes do nome de host, quando configuradas. Verifique o caminho e a string de consulta originais. O percurso deve terminar na página esperada sem alternar entre hosts nem passar de HTTPS para HTTP.
Verifique também o login e os formulários: os códigos de redirecionamento podem afetar o método da requisição. Compare uma nova sessão do navegador com curl, pois o cache do navegador e HSTS podem alterar o comportamento. Restaure a regra salva se a navegação falhar. Limpar cookies não resolve um conflito de redirecionamento no servidor.