Desactivar el proxy de Cloudflare en días de partido: una muy mala idea

Hay partido y tu web no carga en media España. Alguien te suelta: «apaga la nube naranja de Cloudflare y listo». Y como el consejo viene envuelto en un plugin o en un servicio que lo hace solo, suena casi razonable. No lo es. Desactivar el proxy de Cloudflare en días de partido es una de las peores cosas que puedes automatizar en tu infraestructura, y aquí te explicamos por qué, con las fuentes delante.

Y antes de entrar en materia, una advertencia de fondo: aquí no hablamos de parches. Ni la nube gris ni una VPN arreglan lo que está roto, que es mucho más grave y se llama #laligagate.

Resumen rápido

Con la nube gris, tu IP real queda pública en el DNS. Cloudflare lo advierte expresamente.
Pierdes protección DDoS, WAF, caché y reglas en el borde: todo el tráfico cae sobre tu servidor.
Tu certificado puede dejar de ser válido para el visitante, y un firewall «solo Cloudflare» te deja fuera de tu propia web.
Para automatizarlo entregas un token con permiso de edición sobre todo tu DNS.
Dependes de un semáforo que no es oficial y de terceros que pueden fallar o desaparecer.
Y si tu servidor está en un rango que también se bloquea, no sirve de nada.

Qué hacen estas iniciativas (y qué dicen de sí mismas)

El contexto lo conoces: durante los partidos, los operadores bloquean direcciones IP por orden judicial, y como una misma IP de Cloudflare sirve a miles de webs, caen también webs que nada tienen que ver con la piratería. OONI midió 7.441 IPs bloqueadas de 36 organizaciones y unos 554.500 dominios afectados en el primer semestre de 2026; Cloudflare concentra el 90,4 % de esos dominios. La «solución» que circula es cambiar el interruptor del proxy de tus registros DNS a «DNS only» mientras dure el bloqueo, para que los visitantes lleguen directamente a tu servidor y no a una IP compartida de Cloudflare. Dos ejemplos:

CF Football Bypass: un plugin gratuito de WordPress (código en GitHub, licencia GPLv2) que consulta el feed de hayahora.futbol y, si detecta bloqueos, pasa a «DNS only» los registros A, AAAA o CNAME que elijas durante un tiempo configurable (entre 60 y 600 minutos). Pide un token de Cloudflare con los permisos Zone:Read, DNS:Read y DNS:Edit. Existen variantes para PrestaShop y Craft CMS.
DesLigate: un servicio web en beta que, según su página, «comprueba la señal de bloqueo cada 2 minutos», apaga la nube naranja de los registros que le indiques y la reactiva al terminar, avisando por correo. Pide un token con la plantilla «Edit zone DNS».

No queremos atacar a nadie. Quienes han creado estas herramientas lo han hecho, creemos, de buena fe y con ganas de ayudar, y entendemos la rabia de ver tu tienda o tu blog caídos por culpa de un bloqueo ajeno. Nuestra crítica no es a las personas, sino a la decisión: creemos que, antes de tomar una decisión así, hay que informarse lo más posible y decidir con conocimiento, no por urgencia ni por inercia. Para eso escribimos esto. Una aclaración: no hemos auditado el código ni el servicio de ninguna de estas herramientas; describimos lo que sus propias páginas dicen a 8 de noviembre de 2026, y puede cambiar.

1. Dejas de estar detrás de Cloudflare: tu IP real queda a la vista

Según la documentación de Cloudflare, con el proxy activo el DNS devuelve IPs de Cloudflare; con «DNS only» devuelve la IP real de tu servidor y el tráfico HTTP/HTTPS va directo a él. Cloudflare advierte de que eso expone esa IP a cualquiera que consulte el registro, y de que puede exponer el servidor a actores malintencionados y a ataques DDoS. De hecho, recomienda «DNS only» solo para registros que no sirven tráfico web, como el correo o las verificaciones de dominio.

Las propias herramientas lo reconocen: DesLigate avisa de que, sin proxy, la web pierde caché, protección y la ocultación de la IP del servidor, y el plugin admite que, si el feed da un falso positivo, la IP quedará visible en el DNS. Mientras dura la nube gris, según Cloudflare, tu web pierde:

la protección DDoS para el tráfico HTTP/HTTPS;
el WAF, la caché y las reglas de redirección;
la analítica HTTP/HTTPS de Cloudflare (solo queda la de DNS).

2. Reactivar el proxy no vuelve a esconder la IP

Reactivar la nube naranja cambia lo que responde el DNS a partir de ese momento; no borra lo que ya se vio. La guía de Cloudflare para proteger el servidor de origen lo dice sin rodeos: «Historical records are kept», es decir, los registros históricos se conservan y la IP anterior puede seguir accesible públicamente. Por eso Cloudflare recomienda cambiar las IPs de origen tras exponerlas.

Que hoy nadie use ese dato no lo hace inofensivo. Un histórico de DNS puede no explotarse hoy y sí mañana: es un peligro latente. Tu IP queda archivada en bases de datos de terceros y puede aprovecharse dentro de meses, cuando alguien tenga motivo, un mal día, una oleada de ataques o una vulnerabilidad nueva, sin que tú te enteres de que la tienen. Un dato que ya está en manos ajenas no se retira: solo puedes dejarlo obsoleto cambiando de IP.

Una herramienta que alterna la nube cada fin de semana abre una ventana de exposición en cada jornada. Un atacante no necesita que la ventana dure: le basta con verla una vez. Y con tu IP en la mano se salta el WAF y la protección DDoS aunque después vuelvas a la nube naranja, salvo que tu servidor rechace todo lo que no venga de Cloudflare. Cambiar la IP de origen es la solución real, y ninguna de estas herramientas lo hace por ti.

3. Tu propia seguridad te deja fuera (o desaparece)

Cloudflare recomienda blindar el origen aceptando solo las IPs de Cloudflare o usando Authenticated Origin Pulls. Si lo has hecho bien, con la nube gris tus visitantes llegan directos a un servidor que los rechaza: tu web cae. Si, para que el bypass funcione, relajas esas reglas, has quitado la cerradura de la puerta que ya estaba protegida. En ambos casos pierdes.

Hay un efecto más sutil: si tu servidor se fía de la cabecera CF-Connecting-IP para saber quién visita (logs, listas negras, límites por IP) sin restringirla a las IPs de Cloudflare, con acceso directo cualquiera puede falsearla.

4. HTTPS: certificados y modos SSL que dejan de encajar

Cloudflare emite sus certificados Universal SSL para los nombres que pasan por su proxy. Sin proxy, tu servidor tiene que presentar un certificado válido y de confianza pública por sí mismo. Y aquí aparecen los problemas:

Certificado Origin CA de Cloudflare: solo cifra el tramo entre Cloudflare y tu servidor. En su documentación, Cloudflare avisa de que, al desactivar el proxy, «Site visitors may see untrusted certificate errors» (los visitantes pueden ver errores de certificado no confiable). Detalles en la página de Origin CA.
Modo Flexible: Cloudflare habla con tu servidor sin cifrar (modos SSL/TLS). Si tu origen no tiene HTTPS, sin proxy tu web pasa a servirse en HTTP plano, y los navegadores que recuerden HSTS se negarán a cargarla.
Redirecciones y «Always Use HTTPS» en Cloudflare: dejan de aplicarse, así que la redirección a HTTPS tiene que hacerla tu propio servidor.

Ninguna de las páginas de las herramientas que hemos revisado trata el impacto en los certificados.

5. Tu servidor se come todo el tráfico, y el DNS no responde al instante

Sin CDN, tu servidor sirve cada imagen, cada script y cada petición de bots: ancho de banda, CPU y facturas del hosting. Además, con proxy el TTL es fijo (300 segundos); en «DNS only» manda el que tengas puesto, y los visitantes y resolutores guardarán tu IP real ese tiempo. Si pones un TTL alto, la vuelta a la normalidad tarda. Un detalle más: si un mismo nombre tiene varios registros A/AAAA, Cloudflare lo trata como proxied en cuanto uno lo esté, así que los cambios parciales pueden no hacer lo que esperas.

Y revisa el correo: los registros MX y TXT son siempre «DNS only», y Cloudflare recomienda no alojar el correo en el mismo servidor que la web, precisamente porque puede delatar su IP.

6. El token: entregas la llave de tu DNS para mover un interruptor

Las dos herramientas necesitan permiso de edición del DNS de tu zona. En la documentación de tokens de Cloudflare, «Edit» equivale a crear, leer, actualizar y eliminar. Con ese token se pueden modificar o borrar cualquier registro: apuntar el dominio a otro servidor, cambiar los MX para interceptar correo, tocar el SPF o añadir subdominios. La documentación que hemos revisado no ofrece un permiso más fino que «solo el interruptor del proxy».

Plugin de WordPress: guarda las credenciales en la base de datos de WordPress (su página no dice si van cifradas), y el token del cron externo viaja en la URL, por lo que puede acabar en logs. Un fallo en WordPress o en cualquier otro plugin, o un administrador comprometido, puede convertirse en un secuestro del DNS de todo el dominio.
DesLigate: le das el token a un tercero. Su página no identifica a la entidad responsable y los términos de servicio indican como contacto una dirección de Gmail. Se presta «tal cual», sin SLA ni garantía de detección o de reactivación del proxy, puede suspender cuentas o cesar sin previo aviso, y depende de proveedores externos (entre ellos hayahora.futbol y football-data.org). Dicen que el token se guarda cifrado y se puede revocar; nosotros no podemos comprobarlo.

Cloudflare recomienda, si hay que usar tokens: alcance mínimo, filtrado por IP y caducidad.

7. Un semáforo que no es oficial

La señal que dispara el cambio es hayahora.futbol, que mide los bloqueos desde conexiones domésticas. Ellos mismos avisan de que sus datos son observaciones propias, pueden contener errores u omisiones, y no garantizan ni disponibilidad continua ni formatos estables. Dicho de otro modo: la decisión de exponer o no tu servidor se delega en una medición de voluntarios. El plugin lo sabe y advierte de que un falso positivo dejaría tu IP al aire; intenta mitigarlo con un mínimo de operadores afectados, un umbral de antigüedad y un enfriamiento. DesLigate, por su parte, no explica en su página cómo mide el bloqueo.

Y si el feed falla, el plugin mantiene el estado actual: el peor caso es quedarse en gris más tiempo del previsto. Imagina además, como ejercicio, que alguien manipula esa fuente: no decimos que ocurra, decimos que tu seguridad no debería depender de ello.

8. Y puede que ni siquiera funcione

Los bloqueos son por IP. Con la nube gris, tus visitantes van a la IP de tu servidor: si esa IP está en un rango que también se bloquea, cambias un bloqueo por otro. OONI observó IPs bloqueadas de Amazon, Akamai, Microsoft, Alibaba Cloud, Meta y Cloudflare, entre otras; Bandaancha cita también BunnyCDN, Vercel y GitHub, y Magic Pages añade Squarespace y recuerda que la lista cambia cada jornada. El propio artículo que presenta el plugin admite que no puede «desbloquear» un origen que ya figure en la lista.

Qué hacer en lugar de apagar la nube naranja

Nuestra propuesta es sencilla: informarse, preguntar y moverse antes que automatizar un parche.

Informarte antes de decidir: lee la documentación de Cloudflare sobre el estado del proxy, los certificados y la protección del origen (las enlazamos abajo), pregunta a quien administra tu servidor y pruébalo todo en un entorno de pruebas. Una decisión con conocimiento casi nunca acaba en «apago la nube y rezo».
Preguntar a Cloudflare qué piensa hacer: escribe a su soporte o a su equipo comercial y pregunta qué opciones ofrecen a los clientes afectados por estos bloqueos y si piensan hacer algo más. Ya han criticado públicamente los bloqueos (comunicado a Xataka) y, según Genbeta, presentaron en febrero de 2025 un incidente de nulidad contra la sentencia que los ampara. Es razonable exigirles que se muevan, y que lo hagan por sus clientes.
Valorar un plan de pago: pasar a una cuenta Pro o superior puede tener sentido por otras razones (más herramientas de seguridad, mejor soporte), pero no des por hecho que arregle los bloqueos. Según Magic Pages, tener IPs propias exige traer tu propio rango (BYOIP) en Enterprise, y la lista de IPs bloqueadas cambia cada jornada. Pregunta antes de pagar.
Aceptar que es una indisponibilidad con horario, y comunicarlo. Según OONI, los bloqueos empiezan poco antes de los partidos y se levantan poco después. Un aviso o una página de estado cuesta menos que un incidente de seguridad.
Medir y documentar: OONI Probe, hayahora.futbol y capturas con fecha y hora.
Denunciar y moverse, pero donde toca: LaLiga ha habilitado un buzón de correo para los clientes de Cloudflare afectados por sus propios bloqueos. Sí, un buzón: quien te corta el grifo te ofrece una hoja de reclamaciones. Eso no es una solución, es una broma. Reclama ante quien puede darte la razón: Magic Pages enlaza una plantilla de RootedCON para denunciar ante la AEPD, y aquí tienes nuestro modelo de texto para demandar a los operadores. Y hazlo con ruido: #laligagate.
Si tu negocio depende de estar disponible en España esos días, plantea con calma una arquitectura con IPs dedicadas o un proveedor distinto, y pruébala: nadie puede garantizarte que la lista no te alcance. Un interruptor automático de última hora no es arquitectura.

Si aun así vas a hacerlo: reducción de daños

Esto no convierte la idea en buena; solo reduce el estropicio.

Cambia solo los registros web imprescindibles (raíz y www). Nunca paneles, APIs ni correo.
Instala en el origen un certificado de una CA pública (por ejemplo, Let's Encrypt) y haz la redirección a HTTPS en tu servidor. Nada de Origin CA ni de modo Flexible.
Protege el origen por tu cuenta: parches al día, WAF o limitación de peticiones, fail2ban y solo los puertos 80 y 443 abiertos.
No confíes en CF-Connecting-IP salvo si la petición viene de las IPs de Cloudflare.
Usa un token mínimo: solo tu zona, con filtrado por IP y caducidad, y revócalo si dejas de usarlo.
Pon un TTL bajo, ensaya la vuelta atrás y programa una alerta si un registro lleva demasiado tiempo en gris.
Asume que tu IP ya está fichada: planifica cambiarla después.
Prefiere código que puedas leer y ejecutar tú a un servicio de terceros que guarde tu token.

Conclusión: esto no va de parches, va de derechos

La nube gris no es un parche: es una decisión de arquitectura de seguridad, y tomarla automáticamente cada fin de semana, a partir de una señal no oficial y con un token que puede reescribir tu DNS, es mucho riesgo para un alivio que ni siquiera está garantizado.

Pero ni siquiera esa es la cuestión de fondo, y por eso existe #laligagate. Ni apagar la nube naranja, ni cambiar de IP o de proveedor, ni una VPN: todos son rodeos a algo mucho más grave. Bloquear direcciones IP compartidas durante los partidos se lleva por delante a medio internet y, con él, nuestros derechos fundamentales en la red y la neutralidad de la red: que un tercero decida qué se ve y qué no, y que lo pague quien no tiene nada que ver. Cada web que se adapta, cada usuario que se compra una VPN y cada administrador que automatiza su propio debilitamiento ayuda a normalizar lo que no debería ser normal.

Insistimos: no es un ataque a nadie ni va con mala intención. Es una petición de prudencia: informarse a fondo, preguntar a Cloudflare, valorar las opciones y moverse antes de dejar en manos de un automatismo la seguridad de tu web.

#laligagate: esto no va sobre sus pérdidas, va sobre tus derechos.

Para más contexto, tienes nuestro informe de seguimiento de la crisis de bloqueos, el resumen en vídeo de Spain blocks half the internet, la historia de un tercero afectado y el debate sobre si bloquear o no bloquear.

Fuentes consultadas

Páginas consultadas el 8 de noviembre de 2026. Si eres autor de alguna de las herramientas y detectas una imprecisión, avísanos por X (@laligagate) y la corregimos.