¿Qué tan rápido es Gcore desde tu casa?

Casi todas las webs de “ping a la nube” y todos los looking glass de los proveedores miden desde sus servidores, metidos en centros de datos con tránsito de primera. Eso te dice lo rápido que va un centro de datos a otro. No dice nada de lo que tú notas: tu fibra o tu móvil, la red de tu operador, sus salidas internacionales y lo saturadas que van esta noche.

Me2Cloud envía cada petición desde tu navegador, así que el resultado lo incluye todo: Wi‑Fi, router, operador, la ruta que elige tu operador y la hora punta.

1. Una petición de calentamiento abre DNS, TCP y TLS. Su tiempo se muestra pero nunca se cuenta.
2. Después el navegador envía 5, 10 o 20 peticiones más al mismo host por la misma conexión. Cada una cuesta un viaje de ida y vuelta más el tiempo de proceso del proveedor.
3. Cada proveedor usa el tipo de petición que comprobamos que mantiene la conexión: GET para AWS, Azure, Google Cloud, Huawei Cloud, DigitalOcean y Scaleway; HEAD para Oracle, IBM Cloud, Alibaba Cloud, Tencent Cloud, Volcengine, Baidu AI Cloud, Naver Cloud, Linode, Vultr, OVHcloud, IONOS Cloud, Aruba Cloud, Leaseweb, Gcore y Yandex Cloud (su GET cierra la conexión y triplicaría cada muestra); <img> solo para Hetzner.
4. Damos la mediana (el valor típico), la media, el P90 (9 de cada 10 muestras quedan por debajo), el jitter (cambio medio entre muestras seguidas) y la pérdida (muestras sin respuesta en el tiempo límite).
5. El nivel sale de la mediana: T0 ≤ 30 ms, T1 ≤ 80 ms, T2 ≤ 150 ms, T3 ≤ 250 ms y T4 por encima. La puntuación de las recomendaciones es mediana + 2 × jitter + penalización por pérdida, así que unos 60 ms estables ganan a unos 45 ms que saltan.

• El mismo camino que tu tráfico. Webs, APIs, túneles por 443, inicios de sesión en juegos y descargas van por TCP. Muchos operadores ponen el ICMP en otra cola, lo limitan o lo enrutan aparte, así que el ping puede verse bien mientras las páginas se arrastran, o al revés.
• No se pierde por limitaciones. Routers y nubes limitan o descartan ICMP a menudo. Un endpoint HTTPS público siempre responde.
• Incluye tu configuración real. DNS, la elección entre IPv4 e IPv6, proxies y aceleradores se aplican al tráfico del navegador, así que mides lo que de verdad obtendrías.
• La pega: cada muestra incluye también un pequeño tiempo de proceso del servidor, bastante constante. Medimos 0–5 ms en AWS, unos 8 ms en Alibaba Cloud y unos 20 ms en Huawei Cloud OBS. Por encima de 100 ms no importa; en regiones muy cercanas el número sale algo más alto que el ping.

• Las redes domésticas se saturan sobre todo de 20:00 a 23:00, y los enlaces internacionales todavía más. Una región que a mediodía es T1 puede caer a NPC por la noche.
• Prueba una vez de día y otra en hora punta. Las pruebas guardadas llevan la marca “hora punta” y puedes alternarlas en Resultados.
• Pausa descargas grandes, streaming y sincronizaciones mientras pruebas. Por cable mejor que por Wi‑Fi; si usas Wi‑Fi, quédate cerca del router.
• Con datos móviles, el resultado cambia con la cobertura. Prueba donde vayas a usar el servicio.

• Hacer una lista corta de regiones antes de contratar un servidor, un servidor de juegos o el origen de una CDN.
• Comparar regiones de un mismo proveedor, o la misma ciudad entre proveedores.
• Comprobar la estabilidad (jitter, pérdida) para juegos, videollamadas, escritorio remoto y SSH.
• Ver cómo rinde de verdad tu proxy, tu acelerador o tu nueva tarifa, probando con y sin ellos.
• Probar tu propio servidor o CDN junto a los grandes con un destino personalizado.

• Una sola ubicación. Es tu línea, no la de tus usuarios. Pide a algunos usuarios que la ejecuten, o exporta y compara.
• Destinos, no tu futura VM. Probamos el endpoint público de API o almacenamiento de cada proveedor en la región. Los servidores de la misma región suelen compartir red, pero las rutas premium (por ejemplo CN2, BGP frente a un solo operador, Lightsail frente a EC2) pueden diferir.
• Sin ancho de banda, sin UDP, sin traza de ruta. Mide viajes de ida y vuelta, no la velocidad de descarga, el tráfico UDP de juegos ni los saltos intermedios.
• Efectos del navegador. Extensiones, proxies, VPN y pestañas pesadas añaden ruido. Cierra pestañas pesadas y deja esta página delante.
• Hetzner no puede mantener la conexión desde un navegador, así que sus cifras incluyen un saludo cada vez. Algunos destinos pueden no ser accesibles desde ciertos países.

• La página son archivos estáticos en Cloudflare. No hay servidor propio, ni cuentas, ni analítica, y los resultados nunca se suben.
• Todas las peticiones de prueba van directamente de tu navegador al proveedor. Abre el Registro de peticiones o las herramientas de desarrollo (pestaña Network) para verlas una a una.
• La información de red viene de Cloudflare (speed.cloudflare.com/meta y /cdn-cgi/trace), y la comprobación WebRTC opcional pregunta a stun.cloudflare.com tu dirección de salida UDP. Puedes desactivarla en Ajustes.
• La detección de IPv4/IPv6 también consulta ipify.org e ident.me, dos proveedores ajenos a Cloudflare, para que una red que bloquee a uno de ellos no se dé por red sin IPv6.
• Los ajustes, los destinos personalizados y las últimas pruebas se quedan en el almacenamiento local de este navegador. “Borrar datos de prueba” elimina los resultados.

Golpear demasiado fuerte los endpoints públicos podría activar la limitación o el WAF del proveedor y estropear el resultado. La prueba está hecha para quedarse muy por debajo:

• Una petición a la vez por host, con una pausa de 250–370 ms entre muestras (2–3 peticiones por segundo por host como mucho).
• Como mucho 2 hosts por proveedor a la vez, y 8 en total (4 por defecto).
• Como mucho 21 peticiones por host en cada prueba (calentamiento + 20). Sin modo continuo.
• Un host se descarta tras 3 fallos seguidos en lugar de reintentarlo.
• Peticiones “simples” anónimas, sin cookies ni referer: sin preflight, respuestas diminutas (unos cientos de bytes), HEAD cuando se puede y sin descargas grandes.

Es menos tráfico que abrir una página web normal. Hemos comprobado que cada destino responde con normalidad a peticiones anónimas (200, 403 o 404 valen igual para medir).

Si tu tráfico pasa por un proxy, el navegador mide tu ruta hasta el proxy más la del proxy al proveedor, no tu propia línea. El panel de red busca las señales típicas: una red de salida de centro de datos, una zona horaria que no coincide con el país de salida, WARP, o una salida WebRTC distinta de la HTTPS.

Usa Reglas de conexión directa para mandar en directo solo los hosts de prueba (Clash / Mihomo, Surge, Shadowrocket, Quantumult X, Loon, sing-box, Xray, SwitchyOmega o lista simple) y vuelve a comprobar. Si lo que quieres es medir el propio proxy, déjalo activado: los números serán su rendimiento real.

• La franja de cada fila usa una escala común (logarítmica, de 2 ms a 3 s). Los puntos son muestras, la caja sombreada cubre la mitad central de las muestras y la barra es la mediana.
• Caja estrecha, estable; caja ancha o puntos dispersos, jitter. Una × roja cuenta las muestras perdidas.
• Pulsa una fila para ver cada muestra en orden, todas las estadísticas y el destino usado. ✓ marca lo que cumple tus requisitos.