Todos culparon a Cloudflare. Fue un corte de fibra en Zayo.
El lunes pasado, 22 de junio de 2026, buena parte de la web empezó a dar tiempos de espera agotados a la vez. Se informó de degradación en X, Zoom y algunos servicios de Google y Microsoft, y la causa fue un corte de fibra en el este de Norteamérica, en la red de Zayo, una de la media docena de redes troncales Tier 1 que no le compran tránsito a nadie. 1
No fue un error de software. No fue un ciberataque. Fue un cable cortado.
El reflejo, tanto en la prensa como en redes sociales, fue llamarlo una caída de Cloudflare. Cloudflare dijo lo contrario, y lo dijo sin matices: no estaba viendo una caída global propia, el problema estaba en las rutas de Zayo, y los sitios que dependen solo de Zayo podían quedar inalcanzables usaran Cloudflare o no. 1 Lo que se reportó fueron más errores, latencia elevada y tiempos de espera intermitentes, no un fallo global limpio. 1
El momento nos resultó incómodo. Esa misma mañana publicamos un texto sobre diversidad física de caminos, donde defendíamos que la conectividad redundante a menudo no lo es. La tarde defendió ese argumento mejor que el propio artículo.
La capa que nadie dibuja
Hay una versión de esta historia que va de Cloudflare, y es a la vez la popular y la equivocada. Cloudflare sostuvo que su red no tenía la culpa y que la interrupción nació una capa más abajo, en un operador troncal que está por debajo de muchas redes, la suya incluida.
La versión interesante va de por qué todo el mundo se equivocó.
Un solo corte de cable no debería poder degradar a la vez X, Zoom y partes de Google y Microsoft. Son plataformas enormes, diseñadas de forma independiente, con recursos de sobra y equipos grandes que han hecho planificación de resiliencia. Se degradaron juntas porque estaban expuestas a la misma dependencia, una que vive por debajo de la aplicación y por debajo del CDN, y que muchas organizaciones no tratan como punto único de fallo porque no es un servidor y no está en su diagrama.
Esa es la lección real del 22 de junio, y la atribución equivocada es la prueba. Cloudflare se ve. Lo eliges, lo configuras, tiene panel y página de estado, así que cuando algo se rompe es el primer nombre a mano. El tránsito es invisible. Casi nadie elige al operador de su operador, y casi nadie sabría nombrar la troncal por la que pasaron sus paquetes camino de un cliente.
Los proxies inversos, los CDN y el filtrado de DDoS son una capa concentrada, y el DNS es otra capa concentrada al lado. Debajo de todo eso hay un número bastante menor de redes troncales, y esa capa está aún más concentrada.
No independencia, solo no estar indefenso
Hay un límite a lo que la redundancia puede resolver. No puedes evitar que se corte una troncal, y no tienes relación contractual con el operador que falló. El objetivo no es eliminar dependencias. Es seguir teniendo opciones cuando una de ellas falla.
Mantén tu origen alcanzable. Si tu origen solo acepta tráfico de los rangos IP de tu CDN y no tiene otra entrada, no puedes salir del CDN. Conserva una ruta directa que funcione y esté probada, aunque normalmente no sirva a nadie.
Ten el DNS en otro sitio. Si tu DNS y tu proxy son el mismo proveedor, su mal día te quita a la vez el problema y la capacidad de esquivarlo. Es la separación de mayor valor que existe.
Conoce tus TTL antes del incidente. Un TTL de 24 horas significa que tu conmutación tarda un día, por rápido que te enteres.
Ten un plan B estático: una página sencilla en otro proveedor y en otro país que explique qué está pasando. Cuesta casi nada y es justo lo que quieren tus clientes durante una incidencia.
Y luego practícalo, porque un camino de conmutación que nunca se ha ejecutado es una hipótesis.
El papel que podemos jugar
Somos un proveedor europeo pequeño, no una troncal, y ahí es donde un proveedor independiente pequeño resulta de verdad útil. Somos el sitio donde vive tu plan B.
Un VPS de 5 €/mes en Tirana, Skopie, Ámsterdam o Dublín basta para alojar una página de estado estática, un servidor DNS secundario, una ruta directa al origen o un sistema en frío que no comparta plano de control, empresa ni continente con tu pila principal. KVM completo con acceso root, protección DDoS incluida, criptomonedas aceptadas, sin KYC, funcionando en minutos.
A quien quiera la capa de red bajo su propio control, AS210464 le ofrece sesiones BGP desde 5 €/mes, validación RPKI y un juego de comunidades con el que mover tus propios anuncios entre nuestras regiones, incluido el blackholing activado de forma remota cuando necesitas que el tráfico se descarte en nuestro borde y no en tu servidor.
Puedes mirar nuestros caminos tú mismo, sin cuenta, con el looking glass. Haz un traceroute desde las redes que te importan hasta cada una de nuestras sedes y fíjate en qué redes aparecen en el medio de todas ellas. Traceroute no te mostrará saltos MPLS, ni caminos de vuelta asimétricos, ni nada que un router se niegue a responder, así que tómalo como un primer vistazo y no como una auditoría. Aun así, conviene conocer al proveedor de tránsito que aparece en todos los caminos antes de que tenga un mal día.
La lección que nadie quiere
El relato sobre la resiliencia de internet siempre ha sido que los paquetes rodean el daño. Eso era cierto cuando el daño estaba en medio de una malla. Es bastante menos cierto cuando el daño está en una de las pocas troncales por las que hoy pasa casi todo.
La capa que falló el 22 de junio es la que no tiene panel, ni página de estado a la que suscribirse, ni línea en tu revisión de arquitectura. No es un argumento para el pánico. Es un argumento para saber de qué redes depende tu tráfico antes del siguiente corte, porque la respuesta se encuentra en diez minutos y durante una incidencia nadie la busca.
Fuentes
- Cloudflare Outage: Fibre Cut in Eastern North America Triggers Internet Disruptions, Latestly, 24 de junio de 2026