ERR_TOO_MANY_REDIRECTS tras una CDN: los dos ajustes que hacen bucle juntos.
Una CDN que llega al origen por HTTP plano y un origen que fuerza la redirección de HTTP a HTTPS son correctos cada uno por su cuenta y hacen bucle juntos. Cómo reconocer la pareja, reproducirla con una sola petición y cerrar los dos extremos.
En este artículo 4 secciones
- La pareja que hay que buscar cuando un sitio detrás de una CDN devuelve ERR_TOO_MANY_REDIRECTS: un modo SSL de la CDN que llega al origen por HTTP plano, y un origen que fuerza la redirección de HTTP a HTTPS sin comprobar lo que el proxy ya hizo.
- Dos fallos, cada uno inofensivo por separado. Muchos orígenes sirven HTTP detrás de una CDN que termina el TLS, y muchos orígenes fuerzan HTTPS. Solo los dos juntos hacen bucle.
- El bucle puede no dejar ninguna entrada en el access log, porque la capa que responde la redirección puede no registrar las peticiones rutinarias. El silencio parece ausencia de tráfico y dirige la búsqueda hacia el lado equivocado.
- Reprodúzcalo con una sola petición contra el origen, por el camino que siguen los visitantes, y después corrija los dos extremos, para que el bucle no pueda formarse sea cual sea la forma de servir el sitio.
Activar el proxy de la CDN delante de un origen que fuerza HTTPS basta para que empiece el bucle. Los dos ajustes son razonables, y ninguno rompe nada por sí solo. Cambiar un ajuste y probar desde un camino que evita la CDN parece una solución mientras todos los visitantes reales siguen en bucle.
El mecanismo: dos extremos, un bucle
El modo SSL de la CDN estaba en "Flexible": el navegador habla HTTPS con la CDN, pero la CDN habla HTTP plano con el origen. Un ajuste defendible por sí mismo. Muchos orígenes sirven HTTP detrás de una CDN que termina el TLS.
El edge del origen, mientras tanto, redirigía a la fuerza cada petición HTTP a HTTPS, sin saber que había un proxy: emitía la redirección sin comprobar la cabecera que dice que esa petición ya era HTTPS en la puerta de entrada. Así que la CDN llega por HTTP, el origen responde «vaya a HTTPS», la siguiente petición del navegador llega a la CDN como HTTPS, la CDN vuelve a llegar al origen por HTTP, y el origen redirige otra vez. Infinito, por construcción. Flexible por sí solo está bien. La redirección forzada por sí sola está bien. Solo los dos juntos hacen bucle.
El bug que no registró nada
Si la capa que responde la redirección no registra las peticiones rutinarias, el bucle no deja nada en el access log. El silencio parece que no llegó tráfico alguno, y la investigación va a todas partes menos al sitio correcto. La regla: cuando un bug no deja logs, deje de perseguir el silencio y reproduzca el mecanismo.
Reproduzca el mecanismo
$ curl -I -H 'X-Forwarded-Proto: https' http://origin.example/
HTTP/1.1 301 Moved Permanently
Location: https://origin.example/
# told the origin the request was already HTTPS. it redirects anyway.Una petición reproduce el bucle, por el camino que siguen los visitantes. Una prueba desde cualquier otro camino pasa y no demuestra nada.
Corrija los dos extremos
| EL EXTREMO | LA SOLUCIÓN |
|---|---|
| El lado de la CDN | El modo SSL pasó a "Full (Strict)": la CDN habla HTTPS real y verificado con el origen. |
| CUALQUIERA DE LAS DOS ROMPE EL BUCLE. LAS DOS LO HACEN IMPOSIBLE.El lado del origen | La redirección se hizo consciente del proxy: comprueba la cabecera del protocolo reenviado y nunca rebota una petición que ya era HTTPS en la puerta de entrada. |
Corregir un extremo de una incompatibilidad de dos extremos deja una configuración «cargada» esperando al siguiente cambio. Cierre los dos extremos y no queda ninguna combinación que gire en círculo: pause la CDN, cambie de CDN, cambie el origen, y el bucle no tiene dónde volver a formarse.
“Ninguno de los dos extremos estaba roto. Los dos juntos sí.”
Respuestas directas
¿Cómo corrijo ERR_TOO_MANY_REDIRECTS detrás de una CDN?+
Compruebe la pareja, no un solo ajuste. Si la CDN llega a su origen por HTTP plano (un modo SSL tipo "Flexible") y su origen fuerza la redirección de HTTP a HTTPS, hacen bucle. Pase la CDN a HTTPS completo y estricto hacia el origen, y haga que la redirección del origen sea consciente del proxy.
¿Por qué mi bucle de redirecciones no muestra nada en los access logs?+
La capa que hace bucle puede no registrar las peticiones rutinarias, así que el bucle es invisible. No persiga el silencio. Reproduzca el mecanismo con una petición contra el origen y lea lo que hace.
¿Qué hace X-Forwarded-Proto?+
Un proxy la establece para decirle al origen qué protocolo usó realmente el visitante. Un origen que redirige HTTP a HTTPS debe comprobarla; de lo contrario rebota peticiones que ya eran HTTPS en el proxy, y así es como empiezan los bucles.
¿Es malo el modo SSL Flexible?+
Es un compromiso con un filo cortante: el tráfico entre la CDN y el origen va sin cifrar, y combinado con una redirección forzada en el origen hace bucle. El modo completo y estricto, con un certificado real en el origen, elimina los dos problemas.
¿Por qué funcionó cuando lo probé yo?+
Una prueba que no pasa por la CDN sigue un camino distinto al de sus visitantes. Reproduzca por el camino exacto que falla, cabeceras incluidas. En esa diferencia se esconde esta clase de bugs.
¿Pelea con un bug que no registra nada?
El silencio también es un síntoma. Reproducimos el fallo, leemos las fuentes primarias y corregimos los dos extremos.
Hable con un ingenieroHa llegado al final.
Ponga la lectura a trabajar
¿Qué está ejecutando?
Cuéntenos la carga de trabajo, el tráfico y los requisitos de recuperación. Empiece por el configurador de servidores o repase los detalles con un ingeniero.
Escrito por los ingenieros que construyen y operan la infraestructura que describe.Hable con un ingeniero