Errores de redirección

Acerca de esta categoría de errores

# Errores de redirección

Los errores de redirección ocurren cuando una solicitud se envía de una URL a otra, pero nunca llega a una página final, o cuando pasa por más redirecciones de las necesarias. Entre los síntomas habituales se incluyen ERR_TOO_MANY_REDIRECTS, cambios repetidos en la barra de direcciones, alternancia entre URLs HTTP y HTTPS, o una página que no se carga después de varias redirecciones.

Las redirecciones se utilizan normalmente para fines válidos: forzar HTTPS, seleccionar el hostname preferido, trasladar una URL antigua o dirigir una solicitud a una ruta nueva. El error suele aparecer cuando las decisiones de redirección entran en conflicto entre distintas capas o cuando el estado almacenado en caché hace que el navegador repita un resultado obsoleto.

Principales tipos de errores de redirección

Bucles de redirección

Un bucle de redirección ocurre cuando la secuencia termina volviendo a una URL que ya se había solicitado. Por ejemplo, una regla puede redirigir de HTTP a HTTPS, mientras otra considera que la solicitud HTTPS no es segura y la devuelve a HTTP. El navegador sigue el ciclo hasta que se detiene y muestra que hay demasiadas redirecciones.

Los bucles también pueden alternar entre hostnames, variantes con o sin barra final, rutas, o entre una URL de la aplicación y una URL del proxy. En WordPress, un bucle puede comenzar después de una migración a HTTPS cuando la WordPress Address, la Site Address, la configuración de forzar SSL, el tratamiento del proxy y la redirección del servidor no describen la misma URL pública. Consulta [Demasiadas redirecciones después de mover WordPress a HTTPS](/wordpress-too-many-redirects-https) para este caso concreto.

Cadenas de redirecciones largas

Una cadena de redirecciones contiene varias redirecciones consecutivas antes de que la solicitud llegue a su destino final. Una URL antigua podría redirigir primero a una ruta modificada, después al hostname preferido y, finalmente, a HTTPS. Las cadenas pueden quedar como resultado de varias migraciones o de reglas superpuestas.

Una cadena se diferencia de un bucle en que finalmente llega a una respuesta final. Sin embargo, puede ralentizar la navegación y dificultar la identificación de la regla responsable del destino final. La pregunta útil para el diagnóstico es si cada redirección intermedia sigue siendo necesaria.

Reglas de redirección en conflicto

El comportamiento de las redirecciones puede estar controlado por un reverse proxy o CDN, una plataforma de hosting, un servidor web, un sistema de gestión de contenidos, código de la aplicación o un plugin. Estas capas pueden no coincidir en lo siguiente:

• Si la solicitud original utilizó HTTP o HTTPS
• Qué hostname es el canónico
• Si una ruta debe incluir una barra final
• Si una ruta antigua debe reescribirse o redirigirse
• Qué URL debe considerarse la dirección final de la aplicación

Un proxy puede recibir HTTPS del visitante y reenviar al origen una conexión con un esquema diferente. Si la aplicación no está configurada para interpretar correctamente el esquema reenviado, puede emitir otra redirección a HTTPS aunque el visitante ya esté utilizando HTTPS.

Comportamiento relacionado con la caché o las cookies

Una prueba en navegación privada puede ayudar a separar el estado específico del navegador de un problema de configuración compartida. Las cookies, las respuestas almacenadas en caché o el estado de sesión de la aplicación pueden conservar un dominio, un flujo de inicio de sesión o una decisión de protocolo antiguos. Esto no demuestra que la configuración del servidor sea correcta; solo indica que el resultado puede depender del estado almacenado en el cliente.

Si la misma URL entra en un bucle en varios navegadores y dispositivos, prioriza las respuestas de redirección y la configuración compartida en lugar de borrar repetidamente los datos locales.

Cómo diagnosticar un error de redirección

1. Registra la URL inicial y el síntoma exacto. Anota el esquema, el hostname, la ruta, la barra final, el mensaje del navegador y si la dirección cambia repetidamente.
2. Prueba una sesión nueva del navegador. Utiliza una ventana privada o borra las cookies y los datos almacenados en caché del sitio afectado. Cuando sea posible, compara el resultado con otro navegador o dispositivo.
3. Traza el historial de redirecciones. Las herramientas de desarrollo del navegador o una herramienta de inspección de cabeceras HTTP pueden mostrar cada respuesta y su destino Location. Identifica el estado devuelto en cada paso y busca una URL repetida, un esquema alterno, un hostname cambiante o una dirección intermedia innecesaria.
4. Clasifica el patrón. Una dirección repetida indica un bucle. Una secuencia que termina en una página indica una cadena. Un cambio entre HTTP y HTTPS apunta al tratamiento del protocolo; un cambio entre hostnames o rutas apunta a reglas de canonicalización o migración.
5. Comprueba la configuración de la URL pública. Confirma que la URL del sitio configurada en la aplicación coincide con el esquema y el hostname que deben utilizar los visitantes. En WordPress, compara la WordPress Address y la Site Address en lugar de cambiar solo uno de los valores.
6. Revisa las capas de redirección desde el exterior hacia el interior. Comprueba el CDN o reverse proxy, la configuración del hosting, las reglas del servidor web, la configuración de la aplicación y los plugins de redirección o SSL. Empieza por la capa que generó la respuesta Location inesperada.
7. Aísla cuidadosamente los cambios recientes. Si el problema comenzó después de activar HTTPS, cambiar un dominio, migrar un sitio, editar los permalinks o instalar un plugin, compara esos cambios con la secuencia de redirección. Desactiva o modifica una regla solo cuando tengas autorización y una forma de restaurar la configuración anterior.
8. Vuelve a probar las URL inicial y final. Utiliza una sesión nueva después de cada cambio controlado. Confirma que la URL inicial llega al destino previsto y que la URL final ya no se redirige innecesariamente.

Qué comprobar primero

El error comenzó después de activar HTTPS

Empieza por el tratamiento del protocolo. Comprueba dónde termina HTTPS, si la aplicación recibe la información esperada sobre una solicitud segura y si más de una capa está forzando HTTPS. Busca una regla que redirija una solicitud ya segura de vuelta a HTTP o que haga que la aplicación emita una segunda redirección a HTTPS.

El error comenzó después de cambiar el dominio o migrar

Compara los hostnames, el esquema, la ruta y el comportamiento de la barra final antiguos y nuevos. Revisa conjuntamente las redirecciones de migración y la configuración de las URL de la aplicación. Un hostname actualizado parcialmente o una redirección que todavía apunta al dominio antiguo pueden crear un bucle o una cadena larga.

Solo afecta a un navegador o usuario

Haz una prueba sin las cookies ni los datos almacenados en caché del sitio afectado. Si el problema desaparece, investiga el estado de sesión o de redirección almacenado antes de cambiar las reglas compartidas del servidor. Si persiste en varios navegadores y dispositivos, céntrate en las cabeceras de respuesta y en la configuración común del proxy, servidor o aplicación.

La cadena de redirecciones llega a la página, pero es inusualmente larga

Enumera todas las URL intermedias y determina qué regla introdujo cada una. Consolida las reglas de migración obsoletas cuando corresponda, conservando las redirecciones intencionadas y comprobando que las URL antiguas sigan llegando al destino final correcto.

Documentación de proveedores que conviene consultar

Para conocer los detalles específicos de la implementación, consulta la documentación del servidor web, el reverse proxy o CDN, la plataforma de hosting, el sistema de gestión de contenidos y el plugin de redirección o SSL involucrados en la solicitud. Busca en esa documentación información sobre la terminación de HTTPS, las cabeceras de protocolo reenviadas, las redirecciones al host canónico, la prioridad de las redirecciones y la invalidación de caché. La configuración correcta depende de qué capa recibe la solicitud original y de qué capa genera cada redirección.