Tu web no está caída, está bloqueada: cómo comprobarlo en dos minutos

Tu web no está caída, está bloqueada: cómo comprobarlo en dos minutos

Hoy sábado hemos estado un buen rato dando vueltas a por qué tres webs que administramos no respondían. Los contenedores levantados, el servidor sirviendo, los dominios pagados hasta 2027 y las DNS correctas. Y desde España, nada: la petición se quedaba colgada hasta agotar el tiempo de espera.

Tu web no está caída, está bloqueada: cómo comprobarlo en dos minutos

La respuesta estaba en una diferencia de un dígito. Y como es una comprobación que puede hacer cualquiera en dos minutos, la dejamos escrita, porque en este país va a hacer falta durante otras dos temporadas.

La comprobación

Resuelve el dominio desde tu conexión española y mira qué dirección IP te devuelve:

nslookup tudominio.com

Ahora haz lo mismo desde una máquina fuera de España. Vale cualquier servidor que tengas por ahí, o cualquier resolutor DNS público al que preguntes desde fuera.

Lo que nos salió a nosotros:

  • Desde España: 188.114.96.5 y 188.114.97.5. Ninguna de las dos contesta. Ni por HTTPS, ni con un ping, ni nada.
  • Desde el servidor, fuera de España: 188.114.97.3. Responde 200 sin despeinarse.

Mismo dominio, mismo Cloudflare, misma configuración. La única diferencia es desde dónde preguntas y qué nodo de la red anycast te toca. Uno de ellos está bloqueado en el país y el otro no.

Si te sale ese patrón, tu web no está rota. Tu web está bloqueada.

Por qué pasa

Un juzgado de lo mercantil de Barcelona autorizó en diciembre de 2024 el bloqueo de direcciones IP utilizadas para retransmitir partidos sin derechos. La autorización es dinámica: la lista se actualiza cada semana y las operadoras —Movistar, MasOrange, Vodafone y DIGI— la aplican directamente.

El problema es de arquitectura, no de intenciones. En una red como la de Cloudflare, una dirección IP no identifica a una web: la comparten miles. Bloquear la dirección para tumbar a un emisor pirata tumba, a la vez, a todo lo demás que hay en esa dirección. Y entre «todo lo demás» está tu tienda, tu blog o la API que usa tu aplicación.

La autorización sigue vigente hasta el final de la temporada 2026/2027. Cloudflare ha recurrido al Constitucional y ha presentado queja ante el representante de comercio de Estados Unidos, pero eso va para largo.

Qué puedes hacer, ordenado de menos a más incómodo

Uno: comprobar antes de tocar nada. Es la parte más importante. Si tu web falla un sábado por la tarde, mira primero si hay partido y haz la comprobación de arriba. Nos hemos ahorrado horas de depuración con esto, y conocemos a más de uno que ha migrado de hosting por un problema que no era del hosting.

Dos: avisar a quien te lo va a preguntar. Si gestionas webs de clientes, esto merece un correo preventivo. La llamada de un sábado con la tienda caída y sin explicación quema mucha más confianza que un aviso previo diciendo que puede pasar, por qué pasa y que se arregla solo.

Tres: mirar el impacto real antes de mover nada. Aquí conviene el dato, no la impresión. Si tu tráfico es mayoritariamente español y tus ventas se concentran en fin de semana, esto te está costando dinero cada semana. Si tu tráfico llega de búsqueda internacional, o si tus horas fuertes son de lunes a viernes por la mañana, el daño puede ser perfectamente asumible.

Cuatro: quitar el proxy. Poner el registro en modo solo DNS hace que el dominio resuelva directamente a la IP de tu servidor, que no está en ninguna lista. Se acabó el bloqueo. A cambio pierdes la caché, la capa de protección y, sobre todo, expones la dirección real de tu origen, con lo que eso implica si compartes servidor con otros proyectos que preferías no relacionar.

Cinco: cambiar de proveedor de CDN o poner el origen detrás de otro servicio. Es la solución más limpia y la más cara en trabajo. Y no es garantía eterna: la lista la hace otro, y puede crecer.

Lo que nosotros hemos hecho

Nada, en el servidor. Porque no estaba roto.

Para poder seguir trabajando durante el corte, los guiones que publican en esas webs ahora fuerzan la resolución al origen, que es una línea de curl:

curl --resolve tudominio.com:443:IP_DE_TU_ORIGEN https://tudominio.com/wp-json/...

El certificado valida igual, porque el nombre que se pide por SNI sigue siendo el del dominio. Solo se salta el paso de preguntar al DNS por una dirección que en este país está bloqueada.

Y para lo demás, paciencia: cuando acaba la ventana del partido, vuelve solo. Que es lo más incómodo de todo esto, porque un fallo que se arregla solo es un fallo que nadie documenta y que vuelves a investigar desde cero dentro de un mes.

Comentarios

Aún no hay comentarios. ¿Por qué no comienzas el debate?

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *