Neutralidad de la red: lista de pruebas de bloqueo

Puede haber un fallo del servidor, un problema de DNS, una incidencia en la red local, una saturación temporal o una interferencia situada en algún punto intermedio de la conexión. La dificultad está precisamente ahí: distinguir una avería corriente de una alteración deliberada o sistemática del tráfico.

La neutralidad de la red implica que la conexión no debería tratar de forma arbitrariamente distinta unos contenidos, servicios o aplicaciones frente a otros. Para comprobar si existe un bloqueo de páginas web, una ralentización selectiva o algún sistema de inspección del tráfico, hacen falta pruebas comparables, repetibles y suficientemente cuidadosas. Un simple test de velocidad puede orientar, pero no basta para demostrar una vulneración.

Esta lista reúne las principales pruebas abiertas para investigar la neutralidad de la red, interpretar sus resultados y evitar conclusiones precipitadas. El objetivo no es convertir a cada persona en especialista en redes, sino facilitar una apropiación tecnológica razonable: saber qué observar, qué puede significar y cuándo conviene pedir acompañamiento.

Antes de empezar: qué puede y qué no puede demostrar una prueba

Cuando una persona dice que una web está bloqueada, normalmente parte de una experiencia sencilla: escribe una dirección y la página no aparece. Sin embargo, una conexión a internet tiene varias capas. El dispositivo necesita resolver el nombre de la web mediante DNS, establecer una conexión, recibir la respuesta del servidor y mostrar el contenido a través del navegador. Un fallo en cualquiera de esos pasos puede producir un resultado parecido.

Por eso conviene separar tres preguntas:

1. ¿El servicio está disponible?

Puede que la web esté caída para todo el mundo o que el problema afecte únicamente a una región.

2. ¿La red permite llegar hasta ese servicio?

Aquí se investigan posibles bloqueos mediante DNS, TCP o sistemas intermedios.

3. ¿La conexión trata ese tráfico de forma diferente?

Esta es la cuestión más difícil y requiere comparar aplicaciones, protocolos, horarios, operadores o tipos de contenido.

La neutralidad de la red no se audita mirando un único número. Se analiza el comportamiento de la conexión ante diferentes destinos y formas de tráfico. Una velocidad baja en una medición general puede indicar congestión, una tarifa limitada o una avería, pero no prueba que se esté ralentizando una aplicación concreta.

Una página que no carga es un indicio; una comparación repetida y bien documentada permite convertirlo en evidencia.

También hay que cuidar la seguridad de quien realiza la medición. Las herramientas de diagnóstico pueden generar solicitudes hacia webs, aplicaciones o servidores concretos. Las condiciones técnicas y legales no son iguales en todos los países ni para todos los operadores. Antes de iniciar una prueba, conviene leer qué hace la herramienta, qué datos recoge y cómo publica los resultados.

1. Preparar una medición que se pueda comparar

La primera parte de un buen test de neutralidad de la red no está en la aplicación, sino en la preparación. Si se cambia a la vez de dispositivo, conexión, navegador y ubicación, después será difícil saber qué ha influido en el resultado.

Anota, al menos, estos datos:

• El operador de internet y el tipo de conexión: móvil, fibra, cable, radioenlace o red comunitaria.
• La fecha y la hora de cada prueba.
• El dispositivo y el sistema operativo utilizados.
• Si la conexión se realiza mediante wifi o cable de red.
• La ubicación aproximada, sin publicar datos personales innecesarios.
• La dirección web o el servicio que se está comprobando.
• El resultado exacto de la herramienta, incluidos los mensajes de error.
• Si otras páginas y aplicaciones funcionan con normalidad en ese mismo momento.

La conexión wifi merece una atención especial. Una señal débil, la distancia al router o la saturación de la red doméstica pueden producir cortes y velocidades irregulares. Si es posible, repite la medición cerca del router y, para las comprobaciones más delicadas, utiliza un cable de red. En redes móviles, conviene registrar si el dispositivo está conectado a 4G, 5G o una tecnología anterior, porque el cambio de cobertura puede modificar mucho el rendimiento.

No hace falta hacer una docena de mediciones en pocos minutos. Es más útil repetir la misma prueba en distintos momentos y comparar con otro acceso a internet cuando sea posible. Por ejemplo, una página que falla tanto con la red móvil como con la conexión fija puede tener un problema propio. Si solo falla con un operador y funciona desde otra red, la hipótesis de una interferencia gana fuerza, aunque todavía no queda demostrada.

El papel de OONI Probe

OONI Probe es una herramienta de software libre impulsada por el Open Observatory of Network Interference. Permite investigar bloqueos de sitios web, aplicaciones de mensajería como WhatsApp, Telegram y Signal, y la posible presencia de sistemas intermedios que inspeccionan o alteran las comunicaciones.

La herramienta no ofrece una sentencia automática sobre la neutralidad de una conexión. Sus mediciones buscan señales técnicas compatibles con una interferencia. Después hay que leerlas en contexto y, cuando sea posible, contrastarlas con otras mediciones.

Antes de instalarla, revisa qué prueba vas a ejecutar y qué destino examina. No es lo mismo medir una página web que analizar una aplicación de mensajería o buscar indicios de manipulación de cabeceras. Cada prueba responde a una pregunta diferente.

El papel de Measurement Lab

Measurement Lab, conocido como M-Lab, ofrece infraestructuras y herramientas abiertas para medir la velocidad y el rendimiento de la red. Una de sus pruebas es NDT, orientada al diagnóstico de la conexión. Sus datos son públicos y se utilizan para investigación.

M-Lab resulta útil para observar el rendimiento general, pero una medición de velocidad no debe interpretarse como una prueba aislada de bloqueo o de estrangulamiento de tráfico. Sirve para establecer una línea de referencia: cuánto rinde la conexión en unas condiciones concretas y cómo cambia con el tiempo.

2. Comprobar bloqueos mediante DNS, TCP y HTTP

La prueba Web Connectivity de OONI examina si existe un bloqueo de sitios web y busca interferencias en varios niveles. Entre ellos están el DNS, las conexiones TCP y las respuestas HTTP. Entender esta diferencia ayuda a interpretar un resultado sin confundir un fallo de nombres con un bloqueo completo.

Bloqueo o manipulación del DNS

El DNS funciona como una guía que relaciona un nombre legible —por ejemplo, el de una página— con la dirección técnica del servidor al que debe conectarse el dispositivo. Si la consulta devuelve una dirección incorrecta, una respuesta vacía o un error, el navegador puede mostrar que la página no está disponible.

Un fallo de DNS puede tener varias explicaciones:

• El servidor de nombres del operador está temporalmente caído.
• La configuración del router o del dispositivo contiene un error.
• El dominio ha cambiado de dirección.
• El servidor que aloja la página no responde.
• Existe una respuesta alterada o filtrada en la red.

Para distinguirlas, las herramientas comparan la respuesta obtenida desde la conexión analizada con otras respuestas de referencia. Si el nombre se resuelve de manera diferente o incoherente, aparece una señal que merece investigación. Esa señal no siempre identifica quién ha intervenido ni demuestra por sí sola la intención del operador.

Un error frecuente consiste en cambiar manualmente el servidor DNS y considerar que el problema está resuelto de forma definitiva. A veces funciona porque el servidor anterior tenía una incidencia; en otros casos, solo se evita una capa concreta del problema. Además, modificar la configuración DNS no elimina necesariamente bloqueos aplicados en niveles posteriores de la conexión.

Bloqueo de la conexión TCP

Después de resolver el nombre, el dispositivo intenta establecer una conexión con el servidor. En términos sencillos, la conexión TCP es una de las vías que permiten iniciar la comunicación entre ambos extremos.

Si las solicitudes hacia una dirección concreta fallan de forma repetida mientras otros destinos funcionan, puede haber un bloqueo en esa fase. El resultado puede parecerse a una avería del servidor: la conexión no llega a completarse, expira o se cierra de forma inesperada.

La comparación debe ser cuidadosa. Un servidor puede rechazar conexiones por razones legítimas, limitar el número de solicitudes o estar protegido contra determinados rangos de direcciones. Por eso es conveniente observar:

• Si el fallo ocurre siempre o solo en determinados momentos.
• Si afecta a una única web o a varias del mismo proveedor.
• Si aparece únicamente con un operador.
• Si el dominio se abre desde otra red.
• Si la prueba identifica un patrón compatible con un bloqueo TCP.

Manipulación de respuestas HTTP

Aunque la conexión se establezca, la respuesta que recibe el dispositivo puede haber sido modificada. La herramienta puede buscar señales de manipulación en las cabeceras HTTP o en el contenido devuelto.

Las cabeceras contienen información técnica sobre la respuesta, el tipo de contenido, la caché y otros elementos de la comunicación. Una respuesta inesperada, un mensaje de bloqueo insertado por un sistema intermedio o una diferencia significativa respecto a la respuesta de referencia pueden indicar que la comunicación no está llegando intacta.

Aquí es importante no sacar conclusiones a partir de una sola anomalía. Las webs modernas utilizan redes de distribución de contenidos, sistemas de protección y redirecciones automáticas. Dos respuestas diferentes no implican necesariamente censura o discriminación del tráfico. La interpretación mejora cuando se repite la prueba y se combina con la información sobre DNS y TCP.

3. Detectar sistemas intermedios y posible inspección del tráfico

Entre el dispositivo y el servidor final pueden existir equipos intermedios, conocidos técnicamente como middleboxes. Algunos cumplen funciones normales de red: cortafuegos, sistemas de optimización, mecanismos de control de acceso o dispositivos de seguridad. Otros pueden inspeccionar el tráfico de manera más profunda y modificarlo, bloquearlo o clasificarlo.

La mera presencia de un equipo intermedio no significa que exista una vulneración de derechos digitales. Muchas redes necesitan estos sistemas para operar. La pregunta relevante es qué hacen, sobre qué tráfico actúan y con qué grado de transparencia.

OONI Probe incluye pruebas como HTTP Header Field Manipulation y HTTP Invalid Request Line, diseñadas para identificar señales compatibles con sistemas intermedios o con inspección profunda de paquetes. Estas pruebas envían solicitudes construidas de una manera concreta para comprobar si algún dispositivo de la red las altera, bloquea o responde antes de que lleguen al servidor.

Qué observar en estas pruebas

Una medición puede ser especialmente significativa cuando:

• La respuesta recibida parece proceder de un sistema distinto del servidor esperado.
• Una solicitud que debería ser rechazada por el servidor produce una respuesta intermedia con un patrón diferente.
• Las cabeceras aparecen modificadas de manera sistemática.
• El comportamiento se repite en distintos momentos y desde varias conexiones del mismo operador.
• El tráfico dirigido a ciertos servicios recibe un tratamiento diferente al de otros con características similares.

Aun así, la herramienta no siempre puede identificar con precisión la entidad responsable. Puede detectar una interferencia situada en la ruta, pero no necesariamente atribuirla al proveedor de acceso. También puede encontrar sistemas de seguridad desplegados por la propia web, por una empresa de alojamiento o por una red corporativa.

Evitar una lectura excesivamente técnica

En el trabajo de alfabetización digital, una dificultad habitual es presentar el resultado como si fuera evidente para cualquiera. No lo es. Una pantalla con términos técnicos puede generar preocupación sin ofrecer una explicación útil.

Una forma sencilla de comunicar el hallazgo es dividirlo en tres partes:

1. Qué se ha observado: por ejemplo, una respuesta diferente o una conexión que no se completa.

2. Qué hipótesis encaja con ese comportamiento: posible bloqueo DNS, TCP, HTTP o presencia de un sistema intermedio.

3. Qué falta por comprobar: repetición, comparación con otro operador, revisión del servidor o contraste con mediciones públicas.

Esta forma de documentar protege a la comunidad frente a dos errores opuestos: minimizar cualquier incidencia como una simple avería o afirmar un bloqueo deliberado sin suficientes elementos.

4. Evaluar el rendimiento del vídeo y buscar estrangulamiento

El estrangulamiento de tráfico consiste en reducir deliberadamente el rendimiento de un tipo de comunicación, aplicación o servicio. Puede afectar a la reproducción de vídeo, a las llamadas, a las descargas o a determinadas plataformas. Detectarlo es más complejo que medir la velocidad general, porque una conexión puede ofrecer un buen resultado en un test convencional y, sin embargo, rendir peor con una aplicación concreta.

Las pruebas de transmisión de vídeo, como DASH —siglas de un sistema de transmisión adaptativa mediante HTTP—, imitan la reproducción de un vídeo y observan cómo responde la red. Están disponibles en plataformas como OONI Probe y M-Lab.

La idea es acercarse a una situación de uso real. En lugar de preguntar únicamente cuántos datos puede descargar la conexión durante una prueba breve, se analiza cómo mantiene el flujo necesario para reproducir contenido audiovisual. Esto permite observar interrupciones, descensos de rendimiento y variaciones en el ancho de banda disponible.

Cómo hacer una comparación útil

Para investigar una posible ralentización selectiva, sigue una secuencia estable:

1. Mide el rendimiento general de la conexión.

Utiliza una prueba abierta como NDT de M-Lab para establecer una referencia. Registra la hora, el operador y las condiciones de la conexión.

2. Repite la medición en distintos momentos.

La congestión de una red puede concentrarse en ciertas horas. Una diferencia entre la mañana y la noche no prueba por sí sola una práctica discriminatoria, pero ayuda a localizar el patrón.

3. Compara el vídeo con otros usos de la red.

Si la navegación y las descargas funcionan con normalidad, pero la reproducción de vídeo se degrada de forma constante, hay una cuestión que investigar.

4. Comprueba más de un servicio.

Un problema de una plataforma concreta puede deberse a sus servidores, a su red de distribución o a una incidencia propia. Comparar varios servicios evita atribuir al operador un fallo ajeno.

5. Repite desde otra conexión.

Una red móvil, una conexión fija o una red comunitaria pueden ofrecer un punto de comparación. La diferencia no resuelve por sí sola la atribución, pero ayuda a separar un problema local de uno asociado a un operador.

6. Conserva los resultados completos.

La fecha, el tipo de red y las condiciones son tan importantes como el número final. Una medición sin contexto pierde buena parte de su valor.

La velocidad media describe la carretera; la neutralidad exige observar si algún vehículo recibe un trato distinto.

Qué no debe confundirse con estrangulamiento

Hay varias situaciones que pueden parecer una ralentización selectiva:

• La red de distribución de la plataforma está lejos o saturada.
• El vídeo cambia automáticamente a una calidad inferior por falta de capacidad.
• El dispositivo tiene poca memoria o un procesador limitado.
• El wifi sufre interferencias.
• La tarifa incluye restricciones explícitas de uso, siempre que estén claramente informadas y sean compatibles con la normativa aplicable.
• La congestión temporal afecta a todos los servicios, no solo a uno.

Por eso no es suficiente con que un vídeo se detenga o tarde en cargar. La hipótesis de estrangulamiento gana consistencia cuando el patrón es repetido, selectivo, medible y diferente respecto a tráficos comparables.

El antecedente de Glasnost

Glasnost fue una herramienta desarrollada por el Max Planck Institute for Software Systems para comparar flujos de tráfico de aplicaciones, como BitTorrent o vídeo, con tráfico de control. Su objetivo era detectar diferencias de tratamiento o posibles ralentizaciones deliberadas por parte de proveedores de internet.

Aunque no debe tomarse como una prueba universal para todas las redes actuales, su enfoque ayuda a entender una idea central: para identificar discriminación del tráfico hay que comparar comportamientos equivalentes, no observar únicamente el rendimiento de una aplicación aislada.

5. Relacionar la medición con los derechos digitales

La neutralidad de la red no es solo una cuestión de velocidad. Está relacionada con la capacidad de las personas para acceder a información, comunicarse, participar en la vida pública y utilizar servicios digitales sin una discriminación opaca por parte de la red.

El debate también se vincula con la privacidad. Una red que clasifica el tráfico puede necesitar observar determinados rasgos de las comunicaciones. Cuanto más profunda sea esa inspección, mayor es la necesidad de transparencia, garantías y límites claros. La seguridad de la información y la protección de datos personales forman parte del mismo tejido social: no basta con conectar a una comunidad si sus comunicaciones se examinan o se condicionan sin explicaciones comprensibles.

En la Unión Europea, el Reglamento 2015/2120 consagra el acceso abierto a internet y la neutralidad de la red. Prohíbe el bloqueo o estrangulamiento del tráfico, salvo excepciones previstas legalmente o situaciones concretas de congestión temporal. El marco normativo no se traslada automáticamente a Nicaragua ni sustituye las normas nacionales, pero ofrece un referente importante para entender cómo se formula jurídicamente el principio de internet abierta.

La libertad de expresión y de información también tiene una dimensión digital. En España, el artículo 20 de la Constitución se relaciona con estos derechos, aunque su aplicación a casos concretos requiere atender al contexto jurídico correspondiente. En Nicaragua, cualquier persona o colectivo que documente interferencias debe buscar asesoramiento local antes de presentar acusaciones o publicar datos que puedan poner a alguien en riesgo.

Cómo documentar una posible incidencia

Cuando las mediciones apuntan a un patrón anómalo, prepara un registro ordenado:

• Describe el servicio afectado sin afirmar todavía quién es responsable.
• Guarda la fecha, la hora y el operador.
• Indica si el problema se reproduce en más de un dispositivo.
• Anota si otras páginas y aplicaciones funcionan.
• Conserva los resultados de OONI Probe o M-Lab.
• Compara, cuando sea posible, con otra red.
• Evita publicar direcciones IP, nombres, números de teléfono u otros datos personales que no sean necesarios.
• Explica el grado de certeza: indicio, patrón repetido o resultado pendiente de confirmación.

Este último punto es esencial. La comunicación responsable no pierde fuerza por reconocer la incertidumbre. Al contrario: diferencia una observación técnica de una acusación y facilita que otras personas puedan revisar el procedimiento.

Una lista práctica para no perderse durante la comprobación

Si necesitas ordenar el proceso, puedes utilizar esta secuencia:

1. Define el problema con precisión.

No es lo mismo una web que no abre, un vídeo que se detiene, una aplicación que no conecta o una descarga que funciona más despacio.

2. Descarta los fallos de la red local.

Revisa el wifi, prueba otro dispositivo y repite la conexión si es posible.

3. Registra las condiciones.

Operador, tipo de red, hora, ubicación aproximada y servicio afectado.

4. Realiza una medición general.

Utiliza M-Lab para observar el rendimiento de la conexión, sin presentarlo como prueba suficiente de bloqueo.

5. Analiza la conectividad web.

Emplea Web Connectivity de OONI para buscar interferencias en DNS, TCP y HTTP.

6. Comprueba si hay señales de sistemas intermedios.

Las pruebas de manipulación de cabeceras y solicitudes pueden aportar información adicional sobre la ruta.

7. Mide el vídeo si el problema afecta al streaming.

Las pruebas DASH permiten acercarse al comportamiento de una reproducción real.

8. Repite y compara.

Cambia el momento de la medición o utiliza otra conexión, pero modifica una variable cada vez.

9. Interpreta con prudencia.

Un resultado anómalo es una señal para seguir investigando, no una explicación automática.

10. Protege a las personas y a la comunidad.

No publiques datos sensibles y valora los riesgos técnicos y legales antes de ejecutar o difundir los resultados.

Errores habituales al hacer un test de neutralidad de la red

El primer error es llamar neutralidad a cualquier prueba de velocidad. La medición del ancho de banda sirve para conocer el estado general de la conexión, pero no compara necesariamente servicios, protocolos ni formas de tráfico.

El segundo es repetir una prueba sin cambiar las condiciones y tratar cada resultado como una confirmación independiente. Diez mediciones realizadas en el mismo minuto, desde el mismo dispositivo y con el mismo problema local no equivalen a diez evidencias distintas.

El tercero consiste en atribuir de inmediato la incidencia al proveedor. Una interferencia puede estar en otro punto de la ruta, en la red del servicio o en un sistema de seguridad. La atribución requiere más información que la detección.

El cuarto es ignorar la hora. Las redes compartidas pueden saturarse cuando muchas personas se conectan al mismo tiempo. Si un servicio funciona por la mañana y se degrada por la noche, conviene medir también otras aplicaciones durante esas franjas.

El quinto es publicar capturas sin contexto. Una imagen con un mensaje de error no permite saber qué red se utilizó, cuándo se hizo la prueba ni si el fallo afectaba a más personas. Un registro breve y ordenado suele ser mucho más útil.

El sexto es pensar que una herramienta abierta elimina todos los riesgos. OONI Probe y M-Lab facilitan investigaciones independientes, pero cada comunidad necesita valorar su propio contexto. La alfabetización digital también incluye saber cuándo detenerse, pedir acompañamiento y no exponer innecesariamente a quien realiza la medición.

Una práctica de transparencia para comunidades y organizaciones

En una escuela, una biblioteca, una red comunitaria o una organización de derechos digitales, estas mediciones pueden convertirse en una práctica colectiva. No hace falta comenzar con un programa complejo. Es suficiente con definir una lista pequeña de servicios, acordar una frecuencia razonable y registrar siempre las mismas condiciones.

El valor aparece cuando los datos se pueden leer a lo largo del tiempo. Una medición aislada responde a lo que ocurrió en un momento concreto. Una serie ordenada puede mostrar cambios, patrones horarios o diferencias persistentes entre operadores. También puede revelar que el problema no era un bloqueo, sino una infraestructura local insuficiente que necesita otra respuesta.

En ese trabajo conviene repartir las tareas. Una persona puede realizar la prueba, otra anotar las condiciones y otra revisar si los resultados están siendo interpretados con cuidado. El acompañamiento evita que el conocimiento técnico quede concentrado en unas pocas manos y fortalece los saberes locales sobre conectividad.

La documentación comunitaria debe respetar tres principios:

• Repetibilidad: otra persona debe poder entender cómo se hizo la medición.
• Proporcionalidad: se recopilan los datos necesarios, no todo lo que técnicamente sería posible reunir.
• Cuidado: se protege la identidad, la seguridad y la tranquilidad de quienes participan.

La neutralidad de la red se defiende mejor cuando las personas pueden comprender lo que ocurre con su conexión. No se trata de llenar a la comunidad de términos técnicos, sino de darle herramientas para formular preguntas precisas: qué servicio falla, en qué momento, desde qué red y con qué diferencia respecto a otros tráficos.

Conclusión: medir antes de afirmar, explicar antes de alarmar

Las pruebas de bloqueo y estrangulamiento permiten observar la red con más detalle que un simple test de velocidad. OONI Probe ayuda a investigar bloqueos de páginas y aplicaciones, interferencias DNS, TCP o HTTP y posibles sistemas intermedios. M-Lab ofrece mediciones abiertas del rendimiento general y pruebas de transmisión de vídeo que ayudan a estudiar la experiencia de uso.

Ninguna herramienta sustituye al contexto. Una señal técnica necesita repetición, comparación y una interpretación prudente. También necesita una mirada humana: detrás de cada conexión hay una persona que intenta estudiar, trabajar, comunicarse, informarse o participar en su comunidad.

La neutralidad de la red no debería ser un concepto reservado a especialistas. Con un procedimiento ordenado, un registro cuidadoso y acompañamiento cuando haga falta, las comunidades pueden conocer mejor su infraestructura y reclamar transparencia con argumentos sólidos. Medir no resuelve por sí solo una interferencia, pero permite dejar atrás la sospecha difusa y construir una conversación pública basada en evidencias.