O erro "muitos redirecionamentos" significa que o site continua sendo redirecionado entre diferentes endereços de uma forma que nunca será concluída. Muitas vezes, isso é o resultado de redirecionamentos concorrentes, um tentando forçar HTTPS (SSL) e outro redirecionando de volta para HTTP (não SSL), ou entre as formas www e não www da URL.
Se você estiver usando um CMS como Wordpress, Magento, etc., que utiliza um base_url ou configuração de tipo de URL dentro do site, você pode acabar com a configuração no código ou banco de dados conflitante com um redirecionamento em um arquivo .htaccess. Esses redirecionamentos conflitantes vão virar e voltar e nunca serão concluídos.
Seu navegador protege você disso permitindo apenas um certo número de redirecionamentos (geralmente dez ou mais) antes de desistir e relatar a mensagem de erro "muitos redirecionamentos". Isso aparece de forma diferente entre o Chrome, Firefox e outros navegadores.
Firefox
A página não está redirecionando corretamente. Ocorreu um erro durante uma conexão com
Chrome
Esta página não está funcionando
Até mesmo o utilitário de teste curl desiste após 50 redirecionamentos por padrão.
Cachos: Máximo (X) redirecionamentos seguidos
curl -svILk https://www.example.com
....
* Maximum (50) redirects followed
O primeiro passo:cache e cookies
Como é mostrado nos erros do navegador acima, esses redirecionamentos em loop também podem ser causados por cookies no navegador que armazena em cache redirecionamentos antigos. O primeiro passo no teste seria limpar o cache e os cookies do navegador. Se você já limpou o cache e os cookies no navegador, é hora de passar para uma solução de problemas mais avançada.
Usando ferramentas de desenvolvedor para loops de redirecionamento
A próxima etapa para solucionar esses tipos de loops de redirecionamento é usar as Ferramentas do desenvolvedor no Firefox ou no Chrome. Essas ferramentas geralmente são abertas pressionando a tecla F12. Certifique-se de selecionar a Rede guia em qualquer um deles e, em seguida, recarregue a página com a qual você está tendo problemas.
Depois de recarregar a página, você deverá ver a série de redirecionamentos listados para você na nova janela. Observando os redirecionamentos, você pode ver se eles estão redirecionando entre algumas coisas diferentes ou redirecionando para a mesma coisa. De qualquer forma, você pode ver as etapas que levam ao erro, em vez de apenas o erro do navegador do usuário final.
Ferramentas do desenvolvedor no Firefox
Usando cURL para loops de redirecionamento
Como parte da escrita deste artigo, montamos um script Bash bastante simples que pode ser usado em qualquer sistema do tipo Unix com o curl comando. Usar o curl é bom, porque ele não armazena em cache as coisas da mesma maneira que os navegadores, portanto, às vezes, pode fornecer uma perspectiva diferente ao solucionar problemas.
Copie o seguinte em seu editor de texto preferido e salve-o como redirects.sh .
#!/bin/bash
echo
for domain in $@; do
echo --------------------
echo $domain
echo --------------------
curl -sILk $domain | egrep 'HTTP|Loc' | sed 's/Loc/ -> Loc/g'
echo
done
Em seguida, marque o redirects.sh arquivo como executável.
chmod +x redirects.sh
Você pode executar nosso script, como os exemplos abaixo, adicionando seu domínio após o nome do script. Ele pode até verificar vários domínios e verificará os redirecionamentos de cada URL, por sua vez, colocando um cabeçalho entre os domínios separados testados.
Exemplo de saída
./redirects.sh liquidweb.com
--------------------
liquidweb.com
--------------------
HTTP/1.1 301 Moved Permanently
-> Location: https://liquidweb.com/
HTTP/1.1 301 Moved Permanently
-> Location: https://www.liquidweb.com/
HTTP/1.1 200 OK
Exemplo de redirecionamento infinito de HTTP para HTTPS
./redirects.sh http://www.example.com
--------------------
http://www.example.com
--------------------
HTTP/1.1 301 Moved Permanently
-> Location: https://www.example.com/
HTTP/1.1 301 Moved Permanently
-> Location: http://www.example.com/
HTTP/1.1 301 Moved Permanently
-> Location: https://www.example.com/
HTTP/1.1 301 Moved Permanently
-> Location: http://www.example.com/
HTTP/1.1 301 Moved Permanently
....
-> Location: https://www.example.com/
HTTP/1.1 301 Moved Permanently
-> Location: http://www.example.com/
HTTP/1.1 301 Moved Permanently
-> Location: https://www.example.com/
HTTP/1.1 301 Moved Permanently
-> Location: http://www.example.com/
HTTP/1.1 301 Moved Permanently
-> Location: https://www.example.com/
Uma observação lateral sobre os tipos de redirecionamento
Olhando para o cacho Na saída acima, você pode ver que o código de resposta HTTP é 301. Os redirecionamentos 301 são redirecionamentos "permanentes", o que significa que algo foi movido permanentemente, e você ou seu navegador precisam procurá-lo no novo local agora e no futuro. Os redirecionamentos 302 são redirecionamentos "Temporários", o que significa que algo foi movido por enquanto, mas nem sempre pode estar no novo local.
Os redirecionamentos 301 são mais frequentemente escritos como entradas de redirecionamento ou reescrita em um arquivo .htaccess. Os redirecionamentos 302, no entanto, por design ou convenção, geralmente são gerados dentro do código de um site. Portanto, uma boa regra geral é que 301s estão em arquivos .htaccess e 302s estão no código do site. Isso pode nem sempre ser verdade, mas é bom ter em mente.
Redirecionamentos no arquivo .htaccess
O arquivo .htaccess é um arquivo de configuração usado para modificar o comportamento do servidor Apache por diretório em um site/servidor. Este é um arquivo de configuração em nível de usuário e apenas algumas configurações do Apache podem ser editadas aqui, embora os redirecionamentos sejam de uso comum.
Você pode ter vários arquivos .htaccess em cascata em uma série de diretórios. Se você tiver um .htaccess em um diretório pai e outro em um subdiretório, ambos afetarão o subdiretório. Nesses casos, é importante lembrar onde você tem e não tem arquivos .htaccess, para evitar conflitos entre arquivos .htaccess em diferentes níveis.
Abaixo estão uma série de exemplos de redirecionamento e ajudarão a identificar redirecionamentos em seu arquivo .htaccess. Essas não são as únicas maneiras de fazer esses tipos de redirecionamentos, mas elas devem mostrar como são os redirecionamentos mais comuns para que você possa reconhecê-los se estiverem em um arquivo .htaccess com o qual você está trabalhando.
Forçar HTTPS
O código .htaccess abaixo verifica primeiro se a solicitação chegou ao servidor usando HTTP ou HTTPS. Se a solicitação não usou HTTPS, a configuração informará ao navegador para redirecionar para a versão HTTPS do mesmo site e URL solicitados anteriormente.
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
Forçar HTTPS:quando atrás de um balanceador de carga ou proxy (CloudFlare/Incapsula/Sucuri/etc.)
Às vezes, você pode estar usando um proxy, como um balanceador de carga ou um firewall da Web, como CloudFlare, Incapsula ou Sucuri. Eles podem ser configurados para usar SSL no front-end, mas não usar SSL no back-end. Para permitir que isso funcione corretamente, você precisa verificar não apenas HTTPS na solicitação, mas também se o proxy transmitiu a solicitação HTTPS original ao servidor usando apenas HTTP. Esta regra a seguir verifica se a solicitação foi encaminhada de HTTPS e, em caso afirmativo, não tenta redirecionar uma hora adicional.
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{HTTP:X-Forwarded-Proto} =http
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
Forçar não www
Este redirecionamento apenas verifica se o nome do site foi solicitado com www no início do nome de domínio. Se o www estiver incluído, ele reescreverá a solicitação e informará ao navegador para redirecionar para a versão não www do nome de domínio.
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
Forçar www
Este último redirecionamento verifica se o nome do site não foi solicitado com www no início do nome de domínio. Se o www não estiver incluído, ele reescreverá a solicitação e informará ao navegador para redirecionar para a versão www do domínio.
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule (.*) http://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
WordPress
O CMS do WordPress usa um arquivo .htaccess para reescrever URLs para o index.php arquivo, mas define a URL do site como um valor no banco de dados. Se você ainda não sabe o nome do banco de dados que está sendo usado no site, pode procurá-lo na configuração principal do WordPress (wp-config.php ).
Você também pode abrir o arquivo em um editor de texto e procurar esses valores, mas a partir de uma conexão SSH, você pode usar o programa grep . Isso fornece mais do que apenas o nome do banco de dados, mas o nome do banco de dados é o mais importante para o que precisamos fazer a seguir.
grep DB wp-config.php
define('DB_NAME', 'wordpress_database');
define('DB_USER', 'wordpress_username');
define('DB_PASSWORD', 'Password');
define('DB_HOST', 'localhost');
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');
A tabela wp_options
Depois de saber o nome do banco de dados, você pode consultar a tabela de opções do banco de dados Wordpress para ver qual URL está definida no banco de dados. A tabela de opções pode ter qualquer prefixo no início do nome da tabela, mas geralmente é "wp_" por padrão, então o nome completo da tabela de opções geralmente é wp_options . As duas linhas importantes são a home e siteurl linhas na tabela de opções. Você pode encontrá-los usando phpMyAdmin , ou outro utilitário de gerenciamento de banco de dados, mas a partir da linha de comando, você também pode executar o seguinte mysql comando.
mysql -e 'show tables' wordpress_database | grep options
prefix_options
Verificando o URL configurado
Na linha de comando, você pode verificar quais são os valores atuais do home e siteurl linhas na tabela de opções. O comando deve enviar a você uma saída como no exemplo abaixo. A parte importante é que eles combinem entre si na maioria das circunstâncias e que sejam o que você espera. Se eles não são o que você espera, então você vai querer atualizá-los de acordo.
mysql -e 'select * from wp_options where option_name rlike "home|siteurl"' wordpress_database
+-----------+-------------+----------------------------------+----------+
| option_id | option_name | option_value | autoload |
+-----------+-------------+----------------------------------+----------+
| 36 | home | http://www.example.com | yes |
| 1 | siteurl | http://www.example.com | yes |
+-----------+-------------+----------------------------------+----------+
Atualizando o URL configurado
O comando a seguir atualizará as duas linhas do wp_options tabela de um determinado banco de dados para uma nova URL. Este comando deve atender a maioria das situações em que você precisa atualizar ou corrigir a URL configurada para um site Wordpress. Atualizando os base_urls configurado em um Wordpress Multisite está além do escopo deste artigo, mas envolveria a atualização de vários wp_option tabelas do tipo.
mysql -e 'update wp_options set option_value="https://www.example.com" where option_name rlike "home|siteurl"' wordpress_database
Magento
O nome do banco de dados Magento é configurado em um dos seguintes arquivos, local.xml ou env.php . Você também pode configurar um prefixo para os nomes das tabelas do banco de dados Magento, mas geralmente não é definido. Portanto, o nome esperado para a tabela de configuração principal do banco de dados é apenas core_config_data .
# Version 1.x
app/etc/local.xml
# Version 2.x
app/etc/env.php
A tabela core_config_data
Há muitos URLs em potencial que podem ser configurados, mas todos eles têm "base_url " como parte da linha no banco de dados. As URLs primárias configuradas serão as URLs seguras e inseguras, mas você também pode configurar URLs para imagens, arquivos de tema ou até mesmo configurar uma URL separada para a área de administração do site. Você pode encontrá-los novamente usando um utilitário de gerenciamento de banco de dados, mas na linha de comando, você pode executar algo como o seguinte.
mysql -e 'select * from core_config_data where path rlike "base_url"' magento_database
+-----------+---------+----------+-----------------------+----------------------------+
| config_id | scope | scope_id | path | value |
+-----------+---------+----------+-----------------------+----------------------------+
| 3 | default | 0 | web/unsecure/base_url | http://www.example.com |
| 4 | default | 0 | web/secure/base_url | http://www.example.com |
+-----------+---------+----------+-----------------------+----------------------------+
Para atualizar os base_urls no banco de dados Magento, você executaria algo como o comando abaixo. Atualizar os base_urls de um Magento Multisite também está além do escopo deste artigo, mas envolveria referenciar adicionalmente o scope_id específico valor para o determinado site ou loja configurado no banco de dados Magento.
mysql -e 'update core_config_data set value="https://www.example.com" where path rlike "web/.*/base_url"' magento_database
Resumindo tudo
Com as URLs configuradas no banco de dados, conforme mostrado acima, vale ressaltar que esses CMSs também fornecem seus próprios métodos de redirecionamento dentro do código do site. Se, por exemplo, você tiver um redirecionamento .htaccess que está redirecionando para uma URL que não se alinha com o que está no banco de dados, você pode acabar com o loop de redirecionamento infinito conforme descrito anteriormente. No entanto, agora você sabe como são alguns redirecionamentos .htaccess comuns e onde encontrar os URLs configurados em alguns bancos de dados de software CMS. Você também está bem equipado para testar, investigar e confirmar se essas coisas estão funcionando em conjunto ou uma contra a outra, e algumas etapas para resolvê-las.