El error "demasiadas redirecciones" significa que el sitio web sigue siendo redirigido entre diferentes direcciones de una manera que nunca se completará. A menudo, esto es el resultado de redireccionamientos competitivos, uno que intenta forzar HTTPS (SSL) y otro que redirige de nuevo a HTTP (no SSL), o entre las formas www y no www de la URL.
Si está utilizando un CMS como Wordpress, Magento, etc., que utiliza una base_url o la configuración del tipo de URL dentro del sitio, puede terminar con la configuración en el código o la base de datos en conflicto con una redirección en un archivo .htaccess. Estos redireccionamientos en conflicto cambiarán de un lado a otro y nunca se completarán.
Su navegador lo protege de esto al permitir solo una cierta cantidad de redireccionamientos (a menudo diez o más) antes de que se dé por vencido e informe el mensaje de error "demasiados redireccionamientos". Esto se muestra de manera diferente entre Chrome, Firefox y otros navegadores.
Firefox
La página no se redirige correctamente. Ocurrió un error durante una conexión a
Cromo
Esta página no funciona
Incluso la utilidad de prueba curl se rinde después de 50 redireccionamientos por defecto.
Rizado: Máximo de (X) redireccionamientos seguidos
curl -svILk https://www.example.com
....
* Maximum (50) redirects followedEl primer paso:caché y cookies
Como se muestra en los errores del navegador anteriores, estos redireccionamientos en bucle también pueden ser causados por cookies en el navegador que almacena en caché redireccionamientos antiguos. El primer paso en la prueba sería borrar su caché y cookies en su navegador. Si ya borraste el caché y las cookies en el navegador, entonces es hora de pasar a una solución de problemas más avanzada.
Uso de herramientas de desarrollo para bucles de redirección
El siguiente paso para solucionar este tipo de bucles de redirección es usar las Herramientas para desarrolladores en Firefox o Chrome. Estas herramientas se abren comúnmente presionando la tecla F12. Asegúrese de seleccionar la Red pestaña en cualquiera de estos y luego vuelva a cargar la página con la que tiene problemas.
Después de volver a cargar la página, debería ver la serie de redireccionamientos enumerados en la nueva ventana. Mirando las redirecciones, puede ver si están redirigiendo entre algunas cosas diferentes o redirigiendo a la misma cosa. De cualquier manera, puede ver los pasos que conducen al error, en lugar de solo el error del navegador del usuario final.
Herramientas para desarrolladores en Firefox
Uso de cURL para bucles de redirección
Como parte de la escritura de este artículo, creamos un script Bash bastante simple que se puede usar en cualquier sistema similar a Unix con el curl dominio. Usar curl es bueno, porque no almacena las cosas en caché de la misma manera que lo hacen los navegadores, por lo que a veces puede brindarle una perspectiva diferente al solucionar problemas.
Copie lo siguiente en su editor de texto preferido y guárdelo 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
doneLuego marque el redirects.sh archivo como ejecutable.
chmod +x redirects.shPuede ejecutar nuestro script, como los ejemplos a continuación, agregando su dominio después del nombre del script. Incluso puede verificar múltiples dominios y verificará las redirecciones de cada URL, a su vez, colocando un encabezado entre los dominios separados probados.
Ejemplo de salida
./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 OKEjemplo de una redirección infinita de HTTP a 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/Una nota al margen sobre los tipos de redireccionamiento
Mirando el rizo En el resultado anterior, puede ver que el código de respuesta HTTP es 301. Las redirecciones 301 son redirecciones "permanentes", lo que significa que algo se ha movido permanentemente y usted o su navegador deben buscarlo en la nueva ubicación ahora y en el futuro. Los redireccionamientos 302 son redireccionamientos "temporales", lo que significa que algo se ha movido por ahora, pero es posible que no siempre esté en la nueva ubicación.
Las redirecciones 301 a menudo se escriben como entradas de redireccionamiento o reescritura en un archivo .htaccess. Sin embargo, los redireccionamientos 302, ya sea por diseño o convención, a menudo se generan dentro del código de un sitio web. Así que una buena regla general es que los 301 están en archivos .htaccess y los 302 están en el código del sitio. Puede que esto no siempre sea cierto, pero es bueno tenerlo en cuenta.
Redirecciones en el archivo .htaccess
El archivo .htaccess es un archivo de configuración que se utiliza para modificar el comportamiento del servidor Apache por directorio en un sitio web/servidor. Este es un archivo de configuración a nivel de usuario, y solo algunas configuraciones de Apache se pueden editar aquí, aunque las redirecciones son de uso común.
Puede tener varios archivos .htaccess en cascada sobre una serie de directorios. Si tiene un .htaccess en un directorio principal y otro en un subdirectorio, ambos afectarán al subdirectorio. En estos casos, es importante recordar dónde tiene y dónde no tiene archivos .htaccess, para evitar conflictos entre archivos .htaccess en diferentes niveles.
A continuación hay una serie de ejemplos de redireccionamientos que ayudarán a identificar los redireccionamientos en su archivo .htaccess. Estas no son las únicas formas de hacer este tipo de redireccionamientos, pero deberían mostrarle cómo son los redireccionamientos más comunes para que pueda reconocerlos si están en un archivo .htaccess con el que está trabajando.
Forzar HTTPS
El código .htaccess a continuación primero verifica si la solicitud llegó al servidor usando HTTP o HTTPS. Si la solicitud no usó HTTPS, la configuración le indicará al navegador que redirija a la versión HTTPS del mismo sitio web y URL que se solicitó antes.
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]Forzar HTTPS:cuando está detrás de un balanceador de carga o proxy (CloudFlare/Incapsula/Sucuri/etc.)
A veces, puede estar usando un proxy, como un balanceador de carga o un firewall web, como CloudFlare, Incapsula o Sucuri. Estos se pueden configurar para usar SSL en el front-end, pero no usar SSL en el back-end. Para permitir que esto funcione correctamente, debe verificar no solo HTTPS en la solicitud, sino también si el proxy pasó la solicitud HTTPS original al servidor usando solo HTTP. La siguiente regla verifica si la solicitud se reenvió desde HTTPS y, de ser así, no intenta redirigir una vez más.
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{HTTP:X-Forwarded-Proto} =http
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]Forzar no www
Esta redirección solo verifica si el nombre del sitio web se solicitó con www al comienzo del nombre de dominio. Si se incluye www, vuelve a escribir la solicitud y le dice al navegador que redirija a la versión que no es www del nombre de dominio.
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]Fuerza www
Esta última redirección verifica si el nombre del sitio web no se solicitó con www al comienzo del nombre de dominio. Si no se incluye www, vuelve a escribir la solicitud y le dice al navegador que redirija a la versión www del dominio.
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule (.*) http://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]WordPress
El CMS de WordPress usa un archivo .htaccess para reescribir las URL en index.php archivo, pero define la URL del sitio web como un valor en la base de datos. Si aún no conoce el nombre de la base de datos que se está utilizando en el sitio, puede buscarlo en la configuración principal de WordPress (wp-config.php ).
También puede abrir el archivo en un editor de texto y buscar estos valores, pero desde una conexión SSH, puede usar el programa grep . Esto le brinda más que solo el nombre de la base de datos, pero el nombre de la base de datos es lo más importante para lo que debemos hacer a continuación.
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', '');La tabla wp_options
Una vez que sepa el nombre de la base de datos, puede mirar la tabla de opciones de la base de datos de Wordpress para ver qué URL está configurada en la base de datos. La tabla de opciones puede tener cualquier prefijo al comienzo del nombre de la tabla, pero a menudo es "wp_" de forma predeterminada, por lo que el nombre completo de la tabla de opciones suele ser wp_options . Las dos líneas que son importantes son la casa y url del sitio líneas en la tabla de opciones. Puede encontrarlos usando phpMyAdmin , u otra utilidad de administración de base de datos, pero desde la línea de comando, también puede ejecutar el siguiente mysql comando.
mysql -e 'show tables' wordpress_database | grep options
prefix_optionsComprobación de la URL configurada
Desde la línea de comandos, puede comprobar cuáles son los valores actuales de la casa y url del sitio líneas en la tabla de opciones. El comando debería enviarlo y generar una salida como el ejemplo a continuación. La parte importante es que estos coincidan entre sí en la mayoría de las circunstancias y que sean lo que espera. Si no son lo que espera, querrá actualizarlos en consecuencia.
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 |
+-----------+-------------+----------------------------------+----------+Actualización de la URL configurada
El siguiente comando actualizará las dos filas de wp_options tabla para una base de datos dada a una nueva URL. Este comando debería adaptarse a la mayoría de las situaciones en las que necesita actualizar o corregir la URL configurada para un sitio de Wordpress. Actualización de base_urls configurado en un Wordpress Multisite está más allá del alcance de este artículo, pero implicaría actualizar múltiples wp_option tipo tablas.
mysql -e 'update wp_options set option_value="https://www.example.com" where option_name rlike "home|siteurl"' wordpress_databaseMagento
El nombre de la base de datos de Magento se configura en uno de los siguientes archivos, local.xml o env.php . También puede configurar un prefijo para los nombres de las tablas de la base de datos de Magento, pero generalmente no se establece. Entonces, el nombre esperado para la tabla de configuración principal de la base de datos es simplemente core_config_data .
# Version 1.x
app/etc/local.xml
# Version 2.x
app/etc/env.phpLa tabla core_config_data
Hay muchas direcciones URL potenciales que se pueden configurar, pero todas tienen "base_url " como parte de la línea en la base de datos. Las URL principales configuradas serán las URL seguras e inseguras, pero también puede configurar URL para imágenes, archivos de temas o incluso configurar una URL separada para el área de administración del sitio. Puede volver a encontrarlos usando una utilidad de administración de base de datos, pero desde la línea de comando, puede ejecutar algo como lo siguiente.
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 actualizar las base_urls en la base de datos de Magento, ejecutaría algo como el siguiente comando. La actualización de base_urls de Magento Multisite también está más allá del alcance de este artículo, pero implicaría una referencia adicional al scope_id específico. valor para el sitio web o tienda dado configurado en la base de datos de Magento.
mysql -e 'update core_config_data set value="https://www.example.com" where path rlike "web/.*/base_url"' magento_databaseResumir todo
Con las URL configuradas en la base de datos, como se muestra arriba, vale la pena señalar que estos CMS también brindan sus propios métodos de redirección dentro del código del sitio. Si, por ejemplo, tiene un redireccionamiento .htaccess que redirige a una URL que no se alinea con lo que está en la base de datos, puede terminar con el ciclo de redireccionamiento infinito como se describió anteriormente. Sin embargo, ahora sabe cómo se ven algunos redireccionamientos .htaccess comunes y dónde encontrar las URL configuradas en alguna base de datos de software CMS. También está bien equipado para probar, investigar y confirmar si estas cosas funcionan en concierto o funcionan unas contra otras, y algunos pasos para resolverlas.