Test de velocidad en OpenWrt: causas, diagnóstico y mejoras

Un test de velocidad en OpenWrt que no coincide con lo que esperas no siempre indica un fallo del operador. En muchos casos, la diferencia aparece por la configuración del router, por el estado de la red local o por el tipo de prueba que se está usando. Entender el síntoma ayuda a separar un problema real de fibra o de Wi‑Fi de una limitación del propio equipo.

Qué se observa cuando el resultado no cuadra

Lo más habitual es ver una descarga o subida claramente por debajo de lo normal, picos de latencia durante la prueba o variaciones muy grandes entre mediciones consecutivas. También puede ocurrir que por cable el resultado sea correcto, pero por Wi‑Fi baje mucho, o que el router responda lento cuando se activan varias conexiones a la vez.

En OpenWrt, estos síntomas suelen aparecer cuando el tráfico pasa por reglas de control, cuando el hardware va justo de recursos o cuando la señal inalámbrica pierde calidad. Por eso conviene medir con método y no quedarse solo con un único resultado.

Causa 1: CPU del router saturada

Muchos routers con OpenWrt ofrecen buen control, pero no siempre tienen potencia suficiente para mover tráfico a alta velocidad con funciones activas como NAT, cifrado, SQM o inspección adicional. Cuando la CPU llega al límite, el test de velocidad suele mostrar una bajada brusca, sobre todo en subida y en conexiones con varias sesiones simultáneas.

Para comprobarlo, revisa el uso de CPU mientras ejecutas la prueba. Si uno o más núcleos se quedan al 100 % y la velocidad cae justo en ese momento, el cuello de botella probablemente está en el procesador del router.

Causa 2: Wi-Fi con interferencias o mala señal

Si el resultado cambia mucho entre habitaciones, bandas o momentos del día, el problema puede estar en el Wi‑Fi. La congestión del canal, los obstáculos físicos, la distancia al router o una banda mal elegida pueden reducir de forma notable la descarga real frente a la conexión por cable.

La forma más clara de identificarlo es comparar una prueba por Ethernet con otra por Wi‑Fi en el mismo dispositivo. Si por cable los valores son estables y por Wi‑Fi no, la red inalámbrica es la principal sospechosa.

Causa 3: SQM o QoS mal ajustados

En OpenWrt, SQM y QoS ayudan a controlar la latencia y evitar saturación, pero una configuración demasiado conservadora puede recortar más ancho de banda del necesario. Si el límite de descarga o subida está por debajo de la velocidad real de la línea, el test saldrá corto aunque la fibra funcione bien.

El indicio típico es una conexión con buena estabilidad, pero con cifras inferiores de forma constante. Si desactivas temporalmente estas funciones para probar, puedes ver si la limitación viene de la gestión del tráfico y no del operador.

Causa 4: Cable, puerto o negociación Ethernet

Un cable defectuoso, un puerto dañado o una negociación a 100 Mbps en lugar de 1 Gbps también puede reducir mucho el resultado. En estos casos, la velocidad máxima queda claramente limitada y el test suele estabilizarse en un valor muy inferior al esperado.

Revisa el estado del enlace en OpenWrt, cambia el cable y prueba otro puerto del switch o del router. Si el problema desaparece al sustituir el cableado, ya tienes localizado el origen.

Causa 5: Red del operador o saturación externa

A veces el problema no está en tu router, sino en la red del operador, en la hora del día o en la ruta hacia el servidor de prueba. Cuando hay congestión aguas arriba, el test puede mostrar menos velocidad, más latencia y, en algunos casos, cortes breves durante la carga.

Para distinguirlo, compara varios servidores, prueba en distintos horarios y haz la misma medición con el router conectado directamente al equipo cuando sea posible. Si el patrón se repite fuera de tu red local, conviene abrir incidencia con el operador.

Cómo diagnosticar la causa paso a paso

Empieza por una prueba por cable, con un solo dispositivo conectado y sin descargas en segundo plano. Después compara el resultado con Wi‑Fi, revisa el uso de CPU y comprueba si SQM o QoS están activos. Ese orden permite saber si el fallo nace en la red local o fuera de ella.

1. Haz una prueba por Ethernet para obtener una base fiable.
2. Repite el test por Wi‑Fi para comparar estabilidad y pérdidas.
3. Observa CPU, memoria y carga del router durante la medición.
4. Revisa cableado, puertos y velocidad de enlace negociada.
5. Prueba varios servidores y horarios para descartar saturación externa.

Qué ajustes suelen mejorar el resultado

Si el router va justo de potencia, desactiva funciones que no necesites y valora un equipo más capaz para conexiones de fibra rápidas. Si el problema está en Wi‑Fi, cambia de canal, usa la banda de 5 GHz cuando sea posible y acerca el dispositivo al punto de acceso.

Cuando el cuello de botella está en SQM o QoS, ajusta los límites a valores realistas y comprueba de nuevo el test. Si el cableado es antiguo o inestable, sustituirlo suele ser una mejora rápida y barata. Y si todo lo local está bien, la siguiente revisión debe ir al operador.

Cuándo merece la pena escalar al operador

Si por cable, con el router reiniciado y sin reglas especiales, la velocidad sigue muy por debajo de lo contratado y el patrón se repite en distintos momentos, ya no parece un problema de configuración. En ese caso, reúne capturas del test, hora de la medición y datos de latencia para que el soporte técnico pueda revisar la línea.

Cuanto más claro sea el diagnóstico, más fácil será separar una incidencia de red, un problema de fibra o una limitación del propio router.

Conclusión: un test de velocidad en OpenWrt sirve de poco si no se interpreta junto con la CPU, el Wi‑Fi, el cableado y la red del operador. La clave está en medir por pasos, comparar escenarios y ajustar solo lo que realmente limita la conexión.