HTTP 301 Moved Permanently: qué significa

Qué significa este error y cómo reconocerlo

• Un navegador, cliente de API, servicio de monitorización o comprobador HTTP informa de 301 Moved Permanently.
• Un navegador puede seguir automáticamente la redirección, mostrar una URL diferente o revelar un bucle de redirección si el destino vuelve a dirigir a la URL original.
• La respuesta puede incluir una cabecera Location que contiene el destino de la redirección.
• El comportamiento puede producirse solo para una URL, hostname, método HTTP, estado de autenticación, agente de usuario o ruta de red concretos.
• El DNS puede resolver correctamente y TLS puede completarse correctamente porque el endpoint devolvió una respuesta HTTP.
• Los clientes de API o las herramientas automatizadas pueden detenerse en el 301 en lugar de seguirlo, según su configuración de redirecciones.

Causas principales, ordenadas por probabilidad

1. Canonicalización intencionada de URL: El sitio redirige un hostname alternativo, una ruta, una variante con barra final u otra variante de URL a su dirección preferida.
2. Migración de protocolo o hostname: El tráfico HTTP puede redirigirse a HTTPS, o un hostname antiguo puede apuntar a un hostname de reemplazo.
3. Enrutamiento de la aplicación o del framework: La aplicación puede redirigir una ruta después de un cambio de ruta, un cambio en el estado de inicio de sesión o la reubicación de un recurso.
4. Reglas del servidor web, reverse proxy o CDN: La configuración de la infraestructura puede aplicar una redirección antes de que la solicitud llegue a la aplicación.
5. Comportamiento de redirección almacenado en caché: Un navegador, una caché intermedia o una CDN puede seguir sirviendo una redirección almacenada previamente mientras se propagan los cambios de configuración.
6. Comportamiento específico del método: Una regla de redirección puede ser adecuada para la navegación en un navegador, pero no para una solicitud de API o un método que deba conservar la semántica de su solicitud.
7. Reglas inesperadas o en conflicto: Varias capas pueden redirigir a destinos diferentes, creando una cadena o un bucle.

Cómo solucionarlo

Si estás visitando el sitio

1. Comprueba la dirección exacta, incluido el hostname, la ruta y el protocolo. Sigue la redirección solo si el destino es conocido y esperado.
2. Si el destino requiere una cuenta, inicia sesión mediante la interfaz normal del sitio y vuelve a intentarlo. No introduzcas credenciales en un dominio redirigido que no reconozcas.
3. Si un navegador llega a la página prevista, es posible que el 301 funcione según lo diseñado. Si entra en un bucle, llega al host equivocado o termina en una página inexistente, registra la URL original y el destino.
4. Para una API o un cliente automatizado, comprueba si sigue las redirecciones y si la URL redirigida es válida para el mismo método de solicitud y el mismo contexto de autenticación.
5. Comunica al propietario del sitio la URL original, el destino, la hora aproximada, el tipo de cliente y el estado observado. No compartas contraseñas, cookies ni secretos de API.

Si eres el propietario o mantienes el sitio

1. Reproduce la solicitud exacta. Registra el método HTTP, la URL completa, el host, el protocolo, el estado de autenticación cuando corresponda, el estado final y cada destino de redirección.
2. Inspecciona las cabeceras de respuesta, especialmente Location, las cabeceras relacionadas con la caché, las relacionadas con la autenticación y cualquier cabecera que identifique una capa de proxy o servidor.
3. Determina qué componente generó el 301: la aplicación, el servidor web, el reverse proxy, la CDN o el WAF. Comprueba los registros correspondientes usando la marca de tiempo de la solicitud y un identificador de solicitud, si está disponible.
4. Compara el comportamiento con el diseño de enrutamiento previsto. Confirma si la redirección debe gestionar un cambio de hostname, una política de HTTP a HTTPS, una ruta canónica, un recurso movido o un flujo de la aplicación.
5. Comprueba si hay cadenas, bucles o reglas de redirección en conflicto, así como un destino incorrecto. Revisa las implementaciones recientes y los cambios en el enrutamiento, la autenticación, la caché y la configuración del proxy o la CDN.
6. Aplica la corrección autorizada más limitada en la capa que generó la respuesta. Evita cambios amplios en permisos, seguridad o reglas de redirección cuando el problema afecta a una sola ruta o condición.
7. Vuelve a probar la misma URL y el mismo método desde un cliente adecuado. Después, prueba el destino, las rutas relacionadas importantes y los casos relevantes con y sin autenticación.
8. Si sospechas de una redirección almacenada en caché, sigue el proceso aprobado de invalidación de caché del sitio y considera su impacto operativo antes de realizar ese cambio.

Prevención y cómo verificar la solución

• Define y documenta las redirecciones intencionadas, incluidas las URL antiguas, los destinos, los métodos afectados y los responsables.
• Mantén las reglas del servidor web, la aplicación, el reverse proxy, la CDN y el WAF bajo control de versiones cuando sea posible.
• Prueba las URL canónicas, el comportamiento de HTTP a HTTPS, los cambios de hostname, los métodos de API importantes y las rutas autenticadas después de cada lanzamiento.
• Supervisa las tasas, cadenas y bucles de redirección por ruta y lanzamiento, en lugar de tratar cada 301 como una interrupción del servicio.
• Conserva los registros de solicitudes y de la infraestructura durante el tiempo suficiente para correlacionar redirecciones inesperadas.
• Revisa el comportamiento de la caché al cambiar las reglas de redirección para que las respuestas obsoletas no oculten el resultado de una corrección.

Preguntas frecuentes