Technical Context
El problema no es una "caída de Cloudflare" ni un ataque DDoS clásico. Hablamos de un bloqueo dinámico de direcciones IP legalmente sancionado por los ISP españoles a petición de La Liga para combatir las retransmisiones piratas. Dado que Cloudflare utiliza masivamente IPs compartidas (shared IP, muchos dominios en una sola dirección), bloquear un sitio "malo" por IP afecta inevitablemente a los "buenos".
Fechas clave en la cronología:
- 18 de diciembre de 2024: El Juzgado de lo Mercantil nº 6 de Barcelona autoriza el mecanismo de bloqueo basado en las solicitudes de La Liga.
- 9 de febrero de 2025: Se registran las primeras oleadas de bloqueos de IPs de Cloudflare en ISPs españoles durante los partidos.
- 26 de marzo de 2025: Se rechazan las apelaciones (incluidas las de Cloudflare y RootedCON); la práctica es confirmada por el tribunal.
Cómo se ve técnicamente para un usuario en España: en ciertos proveedores (Movistar, Vodafone, Orange y Digi son los más mencionados en discusiones públicas), se cortan las rutas a rangos de IP específicos durante los partidos de La Liga. Esto no es filtrado de dominios ni "bloqueo por URL", por lo que sus dominios pueden ser completamente correctos, el SSL válido y el DNS responder, pero la conexión TCP/QUIC al nodo edge de Cloudflare no se establece.
Detalles que afectan a la arquitectura:
- Los bloqueos son temporales y repetitivos: generalmente duran lo que el partido, pero las ventanas pueden ampliarse dependiendo del procedimiento de "verificación" de las fuentes.
- Disparador: la presencia de una transmisión ilegal en una IP/subred que también sirve a proyectos de terceros.
- Por defecto, la mayoría de los clientes de Cloudflare no tienen un "interruptor simple" a una IP aislada: las IPs dedicadas o esquemas personalizados son posibles, pero no están disponibles en todas partes, no siempre son económicamente justificables y no garantizan inmunidad ante un bloqueo excesivo (overblocking) agresivo.
- Proveedores como Vercel informaron públicamente que al principio también se vieron afectados, pero luego establecieron un canal de comunicación con La Liga para evitar bloqueos masivos mediante una reacción más selectiva.
Importante: esto no es una "excentricidad española". Es un precedente de un modelo regulatorio donde un titular de derechos logra medidas técnicas masivas a nivel de ISP. Si su negocio depende de una sola plataforma CDN/edge, un país puede "desaparecer" sin una sola alerta de su proveedor de nube.
Business & Automation Impact
El efecto más desagradable es que puede estar gastando presupuesto en publicidad, generación de leads y SEO, mientras que en las horas pico (que coinciden con partidos y fines de semana) parte de la audiencia físicamente no ve el sitio. Y esto no parecerá un incidente estándar: las métricas de monitoreo de otros países están en verde, la página de estado del proveedor está en verde, pero en España — “ERR_CONNECTION_TIMED_OUT”.
Quién gana y quién pierde:
- Pierden las empresas con una arquitectura edge monolítica: una CDN, un conjunto de IPs, un contorno de entrega para estáticos/SSR/API.
- Pierden los productos donde las "ventanas de partidos" coinciden con el dinero: comercio electrónico los fines de semana, servicios de entrega, reservas, suscripciones B2C, portales de soporte.
- Ganan los equipos que han planificado la geo-resiliencia: ruta de entrega alternativa, cambio de proveedor, diferentes pools de IP, DNS multinivel/traffic steering.
Conclusión práctica para la arquitectura: La CDN deja de ser una "capa transparente". Se convierte en un riesgo regulatorio y operativo. Por lo tanto, en proyectos modernos, considero no solo el SLA y la latencia, sino también escenarios de cortes impulsados por políticas (policy-driven outages), cuando una desconexión no es causada por la técnica, sino por la política, los tribunales o la aplicación de la ley.
Qué deben hacer las empresas ahora mismo (brevemente, sin magia):
- Medir la disponibilidad desde España con comprobaciones sintéticas separadas desde múltiples ISP/ASN y guardar el historial. Esto no es "para presumir", sino para distinguir el bloqueo de la degradación.
- Plan B a nivel de edge: Una segunda CDN/proveedor para rutas críticas (landing, checkout, auth, webhooks) o al menos para estáticos. No siempre es necesario "duplicarlo todo", pero la ruta crítica debe sobrevivir.
- Separar superficies: API, panel de administración, sitio público, assets, almacenamiento (ej. object storage), para que el bloqueo de un punto no derribe todo el producto.
- Protocolo de comunicación: Quién en la empresa decide cambiar, qué tan rápido, qué métricas son el disparador y cómo se notifica a marketing y soporte.
Un tema aparte es la automatización con IA de los procesos de respuesta. Cuando la indisponibilidad geográfica ocurre a ráfagas y "según el horario de los partidos", el triaje manual se convierte rápidamente en caos. En proyectos de nivel de producción, automatizamos: recolección de señales (RUM + sintéticos), correlación por regiones/ASN, ejecución de runbooks, creación de incidentes y, a veces, cambio automático de enrutamiento. Esto ya no es "observabilidad por la observabilidad", sino parte del modelo operativo.
Y sí, tales cambios casi siempre requieren una arquitectura de IA en la intersección de infraestructura y procesos: de lo contrario, obtienes un "zoológico de alertas" en lugar de un sistema de toma de decisiones gestionado.
Expert Opinion Vadym Nahornyi
Pensamiento impopular: el riesgo principal aquí no son ni siquiera los bloqueos de Cloudflare, sino el hábito empresarial de considerar Internet como un entorno neutral. Tan pronto como el bloqueo se convierte en una herramienta legal de lucha competitiva/jurídica, "simplemente elegir al mejor proveedor" deja de ser una estrategia.
En Nahornyi AI Lab, veo regularmente el mismo error: las empresas invierten en la implementación de inteligencia artificial (scoring, personalización, asistentes de ventas), pero dejan la entrega del producto al usuario en un "botón único de CDN". Como resultado, la IA mejora la conversión en un 3–7%, mientras que un riesgo de infraestructura puede anular los ingresos de un país durante horas, exactamente en los momentos en que el marketing está impulsando el tráfico.
Hablando de la práctica, el patrón más funcional no es "mudarse urgentemente a Vercel/cualquier otro lugar", sino diseñar portabilidad en el edge:
- configuración como código (reglas CDN/WAF en el repositorio),
- separación de dominios por criticidad,
- mecanismo de conmutación listo (DNS steering/Anycast/funciones del proveedor),
- telemetría que entiende "país/ASN/proveedor",
- y automatización usando IA para el triaje y la ejecución de acciones correctas, no solo para generar informes.
Pronóstico para 6–18 meses: casos similares aumentarán y serán más amplios que los deportes. A los titulares de derechos y reguladores les encantan las herramientas que "funcionan rápido", incluso si causan daños colaterales. Significa que ganarán aquellos que construyan antifragilidad a nivel de arquitectura y procesos, en lugar de esperar apelaciones y declaraciones públicas de los proveedores.
Si vendes en España (o estás construyendo un producto con audiencia europea) y quieres verificar la resistencia de tu esquema edge y plan de conmutación, discutámoslo sustancialmente. Escribe a Nahornyi AI Lab; yo, Vadym Nahornyi, realizaré la consulta personalmente y desglosaremos los riesgos por escenarios y costo de corrección.