Rendimiento de la conexión · Motor OpenSpeedTest

Prueba de velocidad de Internet para descarga, subida, ping y fluctuación

Realiza una prueba privada de velocidad de conexión a través del navegador con el servidor perimetral de IP CONFIG. Úsala para comparar la velocidad de Internet por Wi-Fi, banda ancha por cable o 5G en condiciones similares; no como garantía del servicio de un proveedor de acceso a Internet.

Medición autohospedada

Comprobar la velocidad de mi conexión a Internet

No hay nada instalado y los resultados de las pruebas no se guardan. El motor transfiere datos aleatorios temporales entre este navegador e IP CONFIG.

Interpretar un resultado de velocidad como un intervalo

Una prueba de velocidad de Internet refleja solo un breve instante. Las interferencias en la red Wi-Fi, el tráfico de otros dispositivos del hogar, la configuración de energía de los dispositivos, la distancia al servidor y la actividad del navegador pueden influir en el resultado. Realiza tres pruebas, descarta los valores atípicos evidentes y compara condiciones similares. Una conexión por cable ayuda a diferenciar los problemas inalámbricos locales de los relacionados con la línea de banda ancha.

Por qué los resultados de 5G pueden cambiar rápidamente

La velocidad de Internet 5G puede variar en función de la señal de radio, los materiales de los interiores, la carga de la torre, la banda de espectro y si el dispositivo alterna entre 5G y LTE. Realiza la prueba desde la misma posición, anota las condiciones de la señal y compara los resultados en diferentes momentos antes de llegar a la conclusión de que el servicio ha cambiado.

La latencia y el ancho de banda resuelven problemas distintos

El ancho de banda de descarga es importante para archivos grandes y vídeos. El ancho de banda de subida es importante para las copias de seguridad, las videollamadas y la publicación de contenidos. El ping es el retraso de ida y vuelta que se percibe en las aplicaciones interactivas, mientras que el jitter describe la variación entre esas muestras de retraso. Una cifra elevada de Mbps no puede compensar una latencia inestable.

Lo que esta prueba demuestra —y lo que no—

Esta prueba mide la ruta hasta IP CONFIG, incluyendo el navegador, la red local, el proveedor de servicios de Internet (ISP) y el borde del servidor de alojamiento. No mide todos los destinos de Internet, ni garantiza la velocidad del plan, ni diagnostica la pérdida de paquetes, ni sustituye a una prueba controlada realizada por un técnico del ISP. Compara con otro destino cuando investigues el enrutamiento o el peering.

Guía detallada

Cómo utilizar la estimación de la velocidad de conexión del navegador

A useful network tool needs more than a result table. It should explain what was measured, which provider supplied the evidence, what can change the answer and where the answer stops being reliable. This guide turns the informe de velocidad into a repeatable troubleshooting process instead of a screenshot without context.

Para qué está diseñada esta herramienta

The primary purpose is to Medir el ping, el jitter y el rendimiento de la transferencia con múltiples solicitudes entre este navegador y el servidor perimetral o de origen de IP CONFIG actual. IP CONFIG keeps the scope narrow because network data becomes misleading when an interface suggests more certainty than the protocol provides. The result is therefore presented as technical evidence observed at a specific moment, not as a permanent identity or guarantee.

The most useful evidence includes Muestras de ida y vuelta de OpenSpeedTest, además de transferencias paralelas limitadas de descarga y subida sin registro de resultados guardados. Read those fields together. One value rarely tells the whole story: a timestamp without a source is hard to reproduce, a provider name without the queried value is hard to investigate, and a status without its limitation can lead to an unnecessary production change.

Prepara una comprobación clara y repetible

Empieza con el valor exacto que quieras comprobar. Elimina los signos de puntuación copiados y confirma si la tarea se refiere a un dominio raíz, un nombre de host, una dirección IP o la conexión actual al sitio web. Si el resultado respalda el caso de un cliente, anota la hora local, el navegador, el tipo de red y los cambios recientes en la configuración antes de realizar otra comprobación.

Una comprobación repetible permite controlar las variables. Evita modificar la configuración del DNS, cambiar de salida de VPN, alternar entre Wi-Fi y datos móviles o iniciar una descarga de gran tamaño a mitad de la comparación. Cuando sea necesario realizar un cambio, trátalo como una segunda prueba y etiquétalo claramente. Esta sencilla medida es más valiosa que recopilar numerosas capturas de pantalla sin etiquetar que luego no se puedan comparar.

Comprender los proveedores, el almacenamiento en caché y los puntos de observación

Las herramientas de redes públicas dependen de los proveedores de nivel superior y del lugar desde el que se observa una solicitud. Un resolutor puede tener una respuesta almacenada en caché, una base de datos de geolocalización puede contar con una actualización reciente de las asignaciones, un registro puede ocultar determinados campos y un servicio meteorológico puede indicar el punto del modelo más cercano en lugar de la calle del visitante. Es de esperar que existan diferencias entre los proveedores, y estas deben seguir siendo visibles.

El almacenamiento en caché mejora la velocidad y protege los límites de los proveedores, pero también implica que un resultado puede reflejar brevemente un estado anterior. IP CONFIG utiliza cachés breves del lado del servidor para la conexión y la ampliación de datos meteorológicos, respeta la información de TTL del DNS en la visualización y no fusiona respuestas independientes del DNS. Actualizar una página repetidamente no puede obligar a un registro, un resolutor o una base de datos de asignaciones de nivel superior a publicar un nuevo valor.

Sigue una secuencia profesional de resolución de problemas

Realiza pruebas en Ethernet y Wi-Fi, cierra las transferencias que puedan interferir, repite las pruebas a horas fijas, compara las medianas en lugar de un único valor máximo y guarda la información sobre el dispositivo y la red. Empiece por la observación de menor riesgo y avance hacia un cambio de configuración. En primer lugar, reproduzca el problema; a continuación, compárelo con una fuente independiente; y, por último, identifique al responsable oficial de los datos. Solo el proveedor de DNS, el registrador, el proveedor de alojamiento, el proveedor de servicios de Internet (ISP) o el administrador de la aplicación responsables deben modificar la configuración correspondiente en el entorno de producción.

Registra tanto las comprobaciones que se hayan realizado con éxito como las que hayan fallado. Una respuesta vacía, un tiempo de espera agotado o un estado de «proveedor no disponible» pueden ser significativos cuando se relacionan con una hora y una consulta concretas. No son significativos cuando se desconoce la entrada original. Si un resultado afecta a la seguridad, la facturación, las acciones legales o el control de acceso, confírmalo a través de la consola autenticada del proveedor y con un revisor cualificado antes de actuar.

Motivos habituales por los que dos resultados no coinciden

Las diferencias pueden deberse a la antigüedad de la caché, el enrutamiento geográfico, el anycast, los horarios de actualización de las bases de datos, la política del registro, las interrupciones del proveedor, las ubicaciones de salida de la VPN, el NAT de nivel de operador, las extensiones del navegador, las pasarelas empresariales y los simples errores tipográficos. Las direcciones IPv4 e IPv6 también pueden seguir rutas diferentes. Un usuario puede acceder correctamente a un servicio a través de un protocolo, mientras que el otro sigue estando mal configurado.

No resuelvas las discrepancias eligiendo la respuesta que parezca más conveniente. Compara las marcas de tiempo y las fuentes, vuelve a realizar la comprobación una vez transcurrido el TTL o el periodo de caché correspondiente y consulta al sistema de referencia cuando sea posible. Las discrepancias persistentes deben documentarse con el caso reproducible más pequeño y enviarse a la parte que controla dichos datos.

Privacidad y uso responsable

La información de red puede llegar a ser confidencial cuando se combina con cuentas, marcas de tiempo precisas o registros internos. Utiliza esta herramienta únicamente para direcciones y dominios que estés autorizado a investigar. Evita publicar registros completos, enlaces a currículos privados, respuestas de API que contengan identificadores de clientes o capturas de pantalla que revelen tokens administrativos. Comparte solo las pruebas mínimas necesarias para resolver el problema.

No se trata de un laboratorio multirregional, ni de un certificado de nivel de servicio de un proveedor de servicios de Internet (ISP), ni de una prueba de la capacidad máxima de una conexión doméstica o de oficina. IP CONFIG utiliza deliberadamente un lenguaje prudente, con términos como «aproximado», «observado» e «inconcluso». Estas palabras no son meras florituras, sino que describen los límites reales de los protocolos y los proveedores. Las decisiones relativas a una persona, al empleo, al fraude, al acceso a una cuenta o a la aplicación de la ley requieren autoridad legal y pruebas que vayan más allá de un resultado de diagnóstico público.

Cómo documentar un caso de asistencia técnica

Una nota de caso completa debe incluir el valor consultado, la página utilizada, la marca de tiempo UTC, el proveedor o el resolutor, el estado devuelto, los campos relevantes del registro o de la asignación, el resultado esperado y el último cambio de configuración conocido. Elimina los datos confidenciales, las cookies, los encabezados de autorización y los datos personales innecesarios. Asigna una referencia interna para que las pruebas de seguimiento puedan compararse sin necesidad de reenviar un registro privado completo.

Describe el impacto en términos comprensibles para el usuario: qué sitio web, flujo de correo electrónico, aplicación o ruta de red ha fallado; quiénes se han visto afectados; si ha habido diferencias entre IPv4 e IPv6; y si existe alguna solución provisional. Esto permite al operador priorizar el problema. Adjunta los datos sin procesar del proveedor únicamente cuando el destinatario esté autorizado y se haya comprobado que los datos no contengan información personal ni credenciales.

Cuándo dejar de realizar pruebas y escalar el problema

Notifica el incidente cuando la configuración oficial y la observación pública sigan sin coincidir más allá del intervalo de caché previsto, cuando varias redes independientes reproduzcan el mismo fallo, cuando falle la validación de DNSSEC, cuando el estado de un registrador impida una operación necesaria o cuando el problema pueda exponer datos privados. Deja de llamar repetidamente a las API de pago cuando ya se haya confirmado un error de cuota o de credenciales.

Incluye las pruebas reproducibles y las medidas que ya se hayan tomado. No modifiques varios parámetros no relacionados entre sí a la vez. Una reversión controlada suele ser más segura que añadir más cambios a una situación incierta. En caso de incidencias en producción, sigue el manual de operaciones, conserva los registros depurados, notifica al responsable asignado y anota la causa final en el archivo de transmisión del proyecto.