HTTP 302 Found: qué significa

Qué significa este error y cómo reconocerlo

• Un navegador, cliente de API, monitor de disponibilidad o comprobador HTTP informa de 302 Found.
• La respuesta incluye un encabezado Location o el cliente navega visiblemente a otra URL.
• Una solicitud parece funcionar en un navegador, pero falla en un cliente de API porque el cliente gestiona las redirecciones de forma diferente.
• Una solicitud POST u otra solicitud que no sea GET se redirige y la solicitud posterior no se comporta como se esperaba.
• Una ruta, host, método de solicitud, estado de autenticación o cliente se ve afectado, mientras que las demás URL funcionan con normalidad.
• DNS puede resolver y TLS puede ser válido porque la solicitud llegó a un endpoint que habla HTTP; esas comprobaciones son independientes de la respuesta de redirección.

Causas principales, ordenadas por probabilidad

1. Enrutamiento temporal intencionado: La aplicación o el servidor web envía a los usuarios de una URL a otra durante un cambio o flujo de trabajo temporal.
2. Gestión de autenticación o sesión: Una solicitud no autenticada se redirige a una ruta de inicio de sesión o relacionada con la sesión.
3. Lógica de la aplicación: Una ruta, selector de idioma, flujo de formularios, indicador de funcionalidad o regla basada en el estado de la solicitud devuelve una redirección para determinados usuarios o métodos.
4. Configuración del proxy inverso, la CDN o el WAF: Un intermediario aplica una redirección antes de que la solicitud llegue a la aplicación de origen.
5. Caché o configuración obsoleta: Una respuesta almacenada en caché o una regla de enrutamiento modificada recientemente sigue produciendo una redirección inesperada.
6. Desajuste del método o de la semántica de redirección: Un 302 puede no ser adecuado cuando la solicitud posterior debe conservar el método y el cuerpo de la solicitud; hay que comprobar el comportamiento del cliente antes de cambiar el código de estado.

El código de estado por sí solo no identifica qué componente generó la respuesta ni demuestra que todo el sitio web esté afectado.

Cómo solucionarlo

Para visitantes y usuarios de API

1. Vuelve a intentar la URL exacta una vez y confirma el esquema, el nombre de host, la ruta, la cadena de consulta y la ortografía.
2. Comprueba si el cliente sigue automáticamente las redirecciones. Si lo hace, compara la respuesta 302 original con la respuesta final en lugar de consultar únicamente la página final.
3. Si la ruta requiere autenticación, inicia sesión mediante el flujo normal del sitio y vuelve a intentarlo. No introduzcas credenciales en un destino desconocido.
4. Si afecta a una solicitud de API, registra el método, la URL de solicitud, el estado de la respuesta, el valor de Location y la respuesta final. No des por hecho que una redirección del navegador es un comportamiento válido de la API.
5. Evita actualizar repetidamente la página cuando el destino está fallando o el servicio está aplicando límites de solicitudes.
6. Si la redirección sigue siendo inesperada, envía al propietario del sitio la URL, el método, la marca de tiempo, el comportamiento del cliente y los detalles de la respuesta después de eliminar datos sensibles. No compartas contraseñas, cookies, encabezados de autorización ni secretos de API.

Para propietarios de sitios y desarrolladores

1. Reproduce la solicitud exacta. Registra el método HTTP, la URL completa, el host, el estado de autenticación, el agente de usuario, el estado, el encabezado Location y si el cliente siguió la redirección. La página final del navegador puede ocultar el 302 original.
2. Determina si la redirección es intencionada. Compara la ruta y el método con el enrutamiento, la autenticación, el idioma, el mantenimiento y los flujos de trabajo de la aplicación documentados.
3. Encuentra la capa que la genera. Comprueba los encabezados de respuesta y correlaciona la marca de tiempo de la solicitud con los registros de la aplicación, el servidor web, el proxy inverso, la CDN y el WAF. Prueba una ruta de origen por separado solo cuando tu infraestructura y autorización lo permitan.
4. Comprueba el destino de la redirección. Confirma que el valor de Location utiliza el esquema, host, ruta y parámetros de consulta previstos. Busca cadenas de redirecciones, bucles, un nombre de host no intencionado o un destino que devuelva un error.
5. Compara los métodos de solicitud. Prueba el método afectado por separado de GET. Si la solicitud debe conservar su método y cuerpo, revisa si el diseño de la aplicación y el comportamiento del cliente requieren un código de estado de redirección que conserve el método.
6. Revisa los cambios recientes. Compara los despliegues y los cambios en el enrutamiento, la autenticación, la gestión de sesiones, las reglas del proxy, el comportamiento de la CDN, las políticas del WAF y la caché.
7. Aplica la corrección segura más específica. Cambia únicamente la regla o el componente responsable, con la autorización adecuada y un plan de reversión. No desactives la autenticación ni los controles de seguridad solo para eliminar un 302.
8. Vuelve a probar la misma solicitud. Confirma el estado previsto, el destino, la gestión del método, los encabezados y la respuesta final. Después, prueba las rutas relacionadas, los estados autenticado y no autenticado y los métodos de API importantes.

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

• Monitoriza las tasas de redirección por ruta, método HTTP, host, estado de respuesta y despliegue para detectar los cambios inesperados de 302.
• Mantén bajo control de versiones la configuración del enrutamiento de la aplicación, la autenticación, el proxy, la CDN, el WAF y la caché.
• Después de cada lanzamiento, prueba tanto la respuesta original como el destino final de las páginas importantes y los endpoints de API.
• Incluye casos autenticados, no autenticados y de solicitudes que no sean GET cuando esas rutas los admitan.
• Documenta las redirecciones temporales intencionadas, sus destinos, los métodos afectados y su fecha prevista de eliminación o revisión.
• Conserva los registros del servidor y de la aplicación, con una sanitización adecuada, durante el tiempo suficiente para correlacionar los incidentes de redirección.
• Comprueba las cadenas de redirecciones y la propiedad de los destinos durante las revisiones de configuración para evitar bucles y cambios de host no intencionados.

Preguntas frecuentes