Cloudflare me ha durado menos de una semana en PlaneaWeb. Lo activé para probarlo, como pruebo todo antes de recomendarlo a clientes. A los pocos días vi el patrón: durante los partidos de fútbol, mi web se caía con un ERR_CONNECTION_TIMED_OUT limpio, y un rato después volvía sola. Cuando até los cabos, lo desinstalé. Aquí cuento lo que vi, cómo lo diagnostiqué y qué he decidido.
- Por qué pruebo todo en mi web primero
- Qué quería probar con Cloudflare
- Lo que sí vi en los primeros días
- El problema que me hizo quitarlo
- Qué está pasando realmente
- Por qué lo quité sin pensarlo más
- Qué voy a recomendar a mis clientes
- Lo que me llevo del experimento
- Preguntas frecuentes sobre los bloqueos de IP en España
Por qué pruebo todo en mi web primero
Tengo una regla desde hace años: no experimento con las webs de mis clientes. Si quiero ver cómo se comporta un plugin, una configuración, un sistema de caché o una CDN, lo pruebo en planeaweb.com. Le doy un tiempo razonable, observo el comportamiento real, y solo entonces me planteo si tiene sentido llevarlo a un proyecto ajeno.
Esto me ha evitado más de un susto. Y también me ha permitido recomendar cosas con conocimiento concreto, no con lo que he leído en un foro o en un artículo patrocinado. Cloudflare era la siguiente pieza en esa lista.
Qué quería probar con Cloudflare
El motivo no fue el tráfico (PlaneaWeb no mueve tanto como para necesitar una CDN), sino algo más concreto: resolver a la vez dos cosas que llevaba rumiando.
Gestiono varias webs WordPress y WooCommerce, y los intentos de login por fuerza bruta son el pan de cada día. Para cubrir ese frente venía usando Wordfence en algunas webs. Repele ataques con eficacia, no tengo queja ahí. Lo que me hizo buscar otras opciones fue la sensación de que, según cómo se configure, puede añadir algo de carga al rendimiento. Nada dramático, pero suficiente para querer buscar otras opciones.
Leyendo sobre alternativas, me topé con Cloudflare. La promesa era atractiva: plan gratuito, buen rendimiento como CDN y, además, un WAF que repele los ataques típicos. Es decir, matar dos pájaros de un tiro, seguridad y velocidad, sin ralentizar WordPress desde dentro.
Sonaba bien sobre el papel. Fiel a mi costumbre, lo activé primero en planeaweb.com antes de plantearlo en ninguna web de cliente. Nube naranja, reglas básicas, a observar.
Lo que sí vi en los primeros días
Voy a ser justo. En el poco tiempo que lo tuve, hay cosas que me gustaron y merece la pena decirlas:
- Gestión de DNS rápida y cómoda. El panel es de los mejores que he usado. Propagación casi inmediata, interfaz clara.
- Analytics propios. Visión rápida de tráfico, países, ratio de caché, ataques bloqueados. No sustituye a Analytics, pero da una foto diferente.
- Bots bloqueados antes de llegar al hosting. En el panel ves actividad automática frenada en seco. Es el tipo de tráfico basura que todas las webs WordPress reciben a diario.
- Plan gratuito generoso. Lo que ofrece sin pagar está muy bien.
Si el artículo terminase aquí, sería un «Cloudflare me ha parecido bien, veremos a largo plazo». Pero no termina aquí.
El problema que me hizo quitarlo
A los pocos días noté algo raro. Abrí planeaweb.com por casualidad y me saltó un ERR_CONNECTION_TIMED_OUT. Ni página de error de Cloudflare, ni error 500, ni nada. Raro, pero asumí que era cosa puntual: recargué a los pocos minutos y la web cargaba bien.
Al día siguiente volvió a pasar lo mismo, ERR_CONNECTION_TIMED_OUT.
Ahí ya paré a pensar. Un fallo puntual lo dejas pasar, dos no. La web caía en franjas concretas y se recuperaba sola al cabo de un rato, sin que yo tocara nada.
Me puse con el diagnóstico en serio, porque cuando una web respira con dificultad hay que mirar más allá de lo evidente.
Paso 1: comprobar el panel de Cloudflare
En la gráfica de tráfico, la web estaba sirviendo con normalidad. Casi 700 visitantes únicos en 24 horas, picos recientes, todo dentro de lo esperable. Es decir, la web funcionaba para el resto del mundo. No funcionaba solo para mí.
Paso 2: probar desde otra red
Quité el WiFi en el móvil y abrí la web con datos. Mismo error. Dos redes distintas fallando a la vez ya era raro en serio.
Paso 3: diagnóstico de conexión
Abrí https://1.1.1.1/cdn-cgi/trace en el navegador. Carga perfecta, datacenter de Madrid respondiendo. Podía hablar con Cloudflare en general, así que el problema era específico de mi dominio, no de Cloudflare entero.
nslookup planeaweb.com devolvía IPs correctas del rango de Cloudflare (188.114.96.x). El DNS estaba limpio.
ping 188.114.97.5 devolvía 100% de pérdida.
tracert 188.114.97.5 mostraba los paquetes muriendo en el salto 4, dentro de la red de Movistar, antes siquiera de salir hacia Cloudflare.
Los paquetes no llegaban a Cloudflare. Se quedaban bloqueados dentro de mi operador.
Paso 4: confirmación cruzada
Probé con un móvil con línea de Jazztel. Mismo error. Tres operadoras distintas (Movistar fijo, Movistar móvil, Jazztel) fallando hacia la misma IP de Cloudflare, en la misma franja horaria, con recuperación que en mi caso llegaba al cabo de un par de horas. Aunque, como luego fui leyendo, no siempre es tan rápido.
No era mi red. No era mi equipo. No era mi hosting. No era Cloudflare. Era algo que bloqueaba esa IP dentro de la red de los operadores españoles.
Y el detalle de las franjas horarias me dio la pista definitiva.
Qué está pasando realmente
En diciembre de 2024, el Juzgado de lo Mercantil nº 6 de Barcelona dictó una sentencia que obliga a los cuatro grandes operadores españoles (Movistar, el grupo MasOrange que incluye Jazztel, Orange y Yoigo, Vodafone y DIGI) a bloquear, a petición de LaLiga, las direcciones IP que se usen para retransmisiones piratas de partidos.
El problema técnico es que Cloudflare, como cualquier CDN grande, asigna la misma IP a miles de webs. IPv4 es un recurso escaso, y compartir IP es la norma. Cuando LaLiga pide bloquear una IP porque ahí hay una retransmisión pirata, caen con ella todas las webs legítimas que comparten la misma dirección.
El bloqueo suele durar lo que dura el partido, pero no siempre. Lo habitual es que se active antes del encuentro, se mantenga durante la retransmisión y se levante al poco de terminar. La recuperación no depende de tu servidor ni de Cloudflare, sino de cuándo cada operador retire el bloqueo, y eso lo decide cada uno a su manera.
Miércoles Champions, jueves Europa League, fin de semana LaLiga. La IP concreta que cae cambia cada jornada. Para el dueño de una web es impredecible: no sabes si tu IP va a estar en la lista del sábado, ni si el bloqueo se va a levantar al pitido final o al despertarte el domingo.
Si quieres ver el alcance en tiempo real, en hayahora.futbol un grupo de ingenieros mantiene un sistema de sondas que monitoriza los bloqueos en los distintos operadores. La herramienta es impecable, y la frustración que se respira en sus textos me parece completamente legítima.
Por qué lo quité sin pensarlo más
En cuanto confirmé que el patrón era este, no hizo falta alargar la prueba. El razonamiento es simple.
Estaba probando Cloudflare para medir dos cosas: rendimiento y seguridad. No llegué a sacar conclusiones sólidas de ninguna de las dos, porque antes de poder hacerlo ya había topado con un tercer problema que pesa más que los otros juntos: disponibilidad intermitente por causas que no puedo controlar.
De nada sirve un rendimiento mejor si tu web se cae en horario de máxima audiencia. De nada sirve una barrera ante bots si el acceso legítimo de visitantes españoles está cortado por el operador. La ganancia potencial en los dos ejes que medía se anulaba de golpe por la pérdida en el eje que ni había considerado.
Fuera. DNS en el registrador, SSL del hosting con Let’s Encrypt, seguridad con plugin dentro del propio WordPress. Una capa menos, un punto de fallo menos, control total.
Qué voy a recomendar a mis clientes
No es un «Cloudflare es malo, no lo uses nunca». Es más matizado, y depende bastante del tipo de proyecto.
Web con tráfico mayoritariamente español y hosting decente
Aquí yo no pondría Cloudflare con proxy activo. El coste en disponibilidad durante el fútbol es real y no compensa el beneficio teórico. DNS en el registrador o en el hosting, SSL con Let’s Encrypt, un plugin de seguridad serio. Más simple, más fiable. Si tu audiencia está concentrada en un punto concreto, como cuando trabajas el SEO local para atraer clientes cercanos, una CDN global aporta poco y añade un vector de fallo innecesario.
Web con audiencia internacional
Cloudflare sigue teniendo sentido. El bloqueo de LaLiga afecta solo al tráfico desde operadores españoles: un visitante alemán, francés o latinoamericano ve la web sin problema. La CDN global aporta aquí, y el inconveniente queda circunscrito a un porcentaje pequeño del tráfico.
Web en hosting flojo
Antes que parchear el problema con Cloudflare, cambiaría el hosting. Una CDN disimulando un hosting lento funciona hasta que deja de funcionar, y cuando deja de funcionar no tienes margen. Invierte un poco de dinero al mes en un hosting bueno y te quitas dos problemas a la vez. La velocidad de carga tiene impacto directo en el posicionamiento, como ya vimos al analizar cómo algunos elementos pueden ralentizar una web sin que te des cuenta.
Web ya en Cloudflare
Hay quien te dirá que pases a modo «DNS only» (nube gris): mantienes Cloudflare pero el tráfico va directo a tu web, sin pasar por su sistema. Es una opción técnicamente válida, pero seamos honestos: si desactivas esa capa intermedia, estás renunciando a todo lo que hacía interesante a Cloudflare. Se acabó la aceleración de la carga, la protección frente a ataques y los filtros de seguridad. Te queda un panel para gestionar el dominio (que está bien, sí) y poco más.
Para un autónomo o una pyme española, mi recomendación es más sencilla: si vas a dejarlo así, quítalo del todo. Lleva la gestión del dominio a donde lo compraste o a tu hosting, simplifica y te ahorras una capa externa que ya no te aporta nada. Menos piezas, menos puntos de fallo, misma disponibilidad.
El modo DNS only solo compensa en casos concretos: si gestionas muchos dominios desde el mismo sitio o si quieres tener la opción de reactivar Cloudflare en un clic cuando cambie el panorama legal. Para el resto, es mantener viva una herramienta que ya no está haciendo su trabajo.
Lo que me llevo del experimento
La lección no es «Cloudflare malo». Es algo más concreto: Cloudflare hoy, en España, para webs con audiencia principalmente local, no me compensa. Es una valoración para un momento concreto. Dentro de seis meses puede cambiar, según cómo evolucione el pulso legal entre LaLiga y Cloudflare (que ha presentado ya un incidente de nulidad contra la sentencia) o según cambien las condiciones de servicio.
Y me queda el asunto pendiente con el que empezó todo esto: el equilibrio entre seguridad y velocidad en WordPress. Cloudflare ya no es, al menos hoy, la respuesta que yo buscaba. Seguiré observando cómo se comporta Wordfence en cada proyecto, probando configuraciones, y valorando otras opciones posibles. Cuando dé con algo que me convenza, lo contaré por aquí.
Por eso tengo banco de pruebas. Para que mis recomendaciones salgan de datos reales de un entorno controlado, no de la inercia de «siempre se ha hecho así» ni de artículos genéricos. Cuando la situación cambie, volveré a probar, y la recomendación seguramente cambiará con ella.
Preguntas frecuentes sobre los bloqueos de IP en España
Los síntomas son bastante claros: error ERR_CONNECTION_TIMED_OUT (timeout limpio, sin página de error) que aparece en franjas horarias coincidentes con partidos de fútbol (miércoles y jueves noche, sábado tarde, domingo) y que se resuelve solo al cabo de unas horas. Si en paralelo ves que tu web funciona bien desde otros países o desde VPN, es muy probable que sea esto. Herramientas como hayahora.futbol te permiten comprobar en tiempo real si tu IP está bloqueada.
Técnicamente sí: al desactivar el proxy, el tráfico deja de pasar por las IPs compartidas de Cloudflare y va directo a tu hosting, que no está en la lista de bloqueo. Pero ojo, si haces eso también pierdes la aceleración de la carga y la protección frente a ataques, que era lo que justificaba tener Cloudflare. Para la mayoría de webs españolas de pymes y autónomos, si llegas a ese punto lo más sensato es quitar Cloudflare del todo.
Los operadores están aplicando una orden judicial, así que técnicamente cumplen con lo que les exige la sentencia. Existen varias iniciativas legales y denuncias de asociaciones de consumidores sobre el alcance desproporcionado de estos bloqueos, pero a nivel individual la vía práctica es más bien adaptar tu configuración técnica para no depender de IPs compartidas en horario de partido.
Googlebot rastrea desde fuera de España, así que en principio no ve los bloqueos. Pero sí puede afectar indirectamente: si tus visitantes españoles encuentran la web caída de forma repetida, las señales de comportamiento (tasa de rebote, tiempo en página, retornos) pueden resentirse. Y si vendes productos o servicios en España, cada minuto de caída en horario de máxima audiencia tiene coste directo, independientemente del posicionamiento.
