Una carta remitida por la Liga Nacional de Fútbol Profesional (LaLiga) a un medio digital español solicita que este pida a su proveedor CDN (Cloudflare) “evitar de forma inmediata compartir desde la misma dirección IP páginas o recursos web” desde los que se facilitaría acceso ilícito a sus contenidos. La comunicación —fechada el 29 de septiembre de 2025— identifica la IP 188.114.96.5 (anycast de Cloudflare) y añade que LaLiga requerirá a los ISP el bloqueo de “aquellas direcciones IP donde se alojan páginas web que violan nuestros derechos”, citando la Sentencia de 18 de diciembre de 2024 del Juzgado de lo Mercantil nº 6 de Barcelona.
El sitio web receptor de la carta no está relacionado con emisiones ilegales; utiliza Cloudflare como CDN/proxy habitual, como miles de dominios comerciales. El caso reabre un debate técnico y jurídico: bloquear una IP compartida de una CDN puede afectar a multitud de servicios legítimos y, por diseño, no identifica un sitio concreto.
Qué pide la carta
- Notificación de “conocimiento efectivo”: se afirma que desde la IP indicada se habría facilitado acceso ilícito durante una jornada de Liga.
- Requerimiento: se insta al titular del sitio a evitar “compartir” esa IP con páginas presuntamente infractoras —algo que el cliente no controla en una red anycast—.
- Anuncio de medidas: LaLiga trasladará a operadores la solicitud de bloqueos por IP.
- Base citada: Sentencia 18/12/2024 (Mercantil 6, Barcelona) sobre medidas de bloqueo dinámico.


La misiva incorpora capturas como “prueba” y advierte de acciones judiciales por omisión.
El problema técnico: una IP anycast no identifica un dominio
En redes de distribución de contenidos, miles de dominios comparten las mismas direcciones IP (anycast). La selección del sitio se realiza en capa 7 (por SNI/Host y otras señales), no por IP.
- Bloquear una IP de CDN implica cortar el acceso a un número indeterminado de sitios no relacionados.
- Pedir al cliente que “deje de compartir la IP” es inviable: la asignación no depende del dominio individual.
- La situación recuerda a CGNAT: muchas conexiones comparten una sola IP pública; no hay correlación uno-a-uno.
La unidad proporcionada para un bloqueo selectivo no es la IP, sino el FQDN/host (y, si procede, la ruta), aplicado con ventanas temporales acotadas y mecanismos de reversión.
El marco jurídico: proporcionalidad y prevención del daño a terceros
Los juzgados mercantiles han autorizado bloqueos dinámicos de recursos durante ventanas de partido para combatir emisiones no autorizadas, pero las resoluciones insisten en la proporcionalidad y en evitar perjuicios a terceros ajenos. En esta línea, pronunciamientos consultables en el buscador del Poder Judicial subrayan la necesidad de precisión y control en la ejecución de los bloqueos.
Trasladar esa exigencia al plano técnico implica centrarse en dominios concretos, acotar tiempos de aplicación y disponer de canales operativos para retirar de inmediato los falsos positivos.
Lo que piden empresas y administradores: trazabilidad y canal NOC
Fuentes del sector consultadas señalan que, si se plantea un bloqueo que afecta a infraestructura compartida, debe acompañarse de:
- Inventario detallado: IPs, dominios (FQDN) y, cuando proceda, rutas y ventanas exactas.
- Metodología reproducible: herramientas y versiones, trazas con SNI/Host, marcas de tiempo (UTC), ASN y criterios de inclusión/exclusión —más allá de una captura de pantalla—.
- Criterios de reversión: cuándo y cómo se levanta la medida; SLA para resolver impactos colaterales.
- Canal NOC-to-NOC (24/7): contactos técnicos entre titulares, CDN e ISP para coordinar en minutos.
Recomendaciones operativas para limitar daños
Para titulares de derechos/ISP
- Priorizar bloqueo por FQDN/SNI (y path si es viable), no por IP compartida.
- Ventanas con inicio/fin y reversión automática post-partido.
- Pruebas firmadas y reproducibles (pcap/HAR con SNI/Host).
- Informe post-jornada con medidas aplicadas e incidencia en terceros.
Para sitios legítimos
- Monitorizar por operador en horas de jornada (RUM/synthetics) para detectar caídas selectivas.
- Documentar (NS/A/AAAA/SOA,
traceroute
,curl -v --resolve
con SNI) y escalar a CDN/ISP vía NOC. - Planes de contingencia (DNS Only/CDN alterna) si hay bloqueo cruzado.
- Comunicar a clientes/usuarios si el servicio se ve afectado.
Qué está en juego
La tutela de derechos exige eficacia, pero bloqueos por IP contra anycast de CDN son burdos e ineficaces frente a infractores que rotan dominios y proveedores, y además perjudican a actividades legítimas. El episodio conocido ya como “LaLigaGate” pone de nuevo el foco en cómo se ejecutan las órdenes: precisión técnica, proporcionalidad y coordinación para que la solución no sea peor que el problema.