El servidor más cercano empeoró mi ping: la ruta que sí llegó bien a São Paulo

El marcador mostraba 11–11 cuando mi personaje retrocedió hasta una esquina que yo ya había cruzado. Disparé, la imagen se quedó quieta y aparecí eliminado medio segundo después. El ping había saltado de 48 a 176 ms. Elegí Buenos Aires en la aplicación de la VPN porque era el servidor más cercano, reinicié el juego y volví a entrar. La app marcaba apenas 9 ms; dentro de la partida seguía por encima de 160.

Estaba en Córdoba, a dieciocho minutos de jugar una semifinal amateur de Counter-Strike 2. El servidor de la competición estaba en São Paulo y no se podía cambiar. Mi equipo había practicado allí toda la semana con unos 45–55 ms.

Esa tarde, la conexión directa de mi proveedor había empezado a superar los 140 ms. Las páginas abrían rápido, las descargas mantenían su velocidad y el test de internet parecía normal. Solo la ruta hasta el servidor del juego se había vuelto absurda.

Por eso había encendido la VPN. No buscaba ocultar mi ubicación ni entrar en otra región. Quería una ruta distinta hacia el mismo servidor.

En Argentina, el interés por estas herramientas aumentó durante 2026 después de nuevas medidas contra plataformas de streaming ilícitas y bloqueos coordinados de sitios. (Techradar) (Justice) Más usuarios terminaron frente a una lista de países que parecía sugerir una regla sencilla: elegir la bandera más cercana.

Yo también seguí esa regla.

El resultado fue peor.

Los 9 ms de la aplicación no eran los 9 ms del juego

Antes de culpar a la VPN, reinicié el router.

La conexión directa siguió en 146 ms. Volví a activar el túnel y probé otra vez Buenos Aires. La aplicación mostró 9 ms, pero el juego osciló entre 158 y 190.

Entonces elegí Montevideo.

La app marcó 18 ms. Dentro del juego, el ping bajó a 112 durante el calentamiento, pero cada pocos segundos aparecía un salto por encima de 200. El promedio era mejor; el movimiento seguía sintiéndose roto.

Probé Santiago. Después, São Paulo.

El endpoint brasileño parecía lógico porque estaba en la misma ciudad que el servidor del torneo. Durante el primer minuto vi 61 ms. Luego llegaron dos picos de 240 y una pérdida breve de paquetes que me devolvió detrás de una caja.

El proveedor era una opción razonable. Tenía años de historia pública, una aplicación madura y suficientes ubicaciones para cubrir casi cualquier necesidad geográfica.

Pero yo no necesitaba una ubicación. Necesitaba un recorrido.

El número de la aplicación medía el primer tramo, desde mi laptop hasta el servidor de la VPN. La partida todavía debía recorrer otro tramo desde esa salida hasta el servidor de São Paulo. Un endpoint cercano a mi casa podía terminar enviando el tráfico por una interconexión congestionada o por un camino innecesariamente largo.

Las plataformas de alojamiento de juegos comparan la latencia real hacia cada región porque la distancia geográfica, por sí sola, no revela cuántas redes atraviesa el tráfico ni dónde empieza la demora. (Amazon)

Yo estaba eligiendo con el dato equivocado.

El mejor promedio todavía podía arruinar una ronda

Para dejar de cambiar banderas al azar, abrí una sala de práctica y anoté el comportamiento de cada conexión durante tres minutos.

Esta vez no miré solo el número más bajo.

Con Buenos Aires, el juego nunca bajó de 150 ms.

Montevideo promedió cerca de 105, pero alternaba entre momentos razonables y tirones bruscos.

São Paulo llegó a mostrar 58, aunque no podía mantenerlo.

Santiago se sostuvo alrededor de 82. Era más lento en su mejor momento, pero mucho menos errático.

Ese último servidor fue el primero que me permitió caminar por el mapa sin retroceder de golpe. Aun así, la mira respondía tarde y la semifinal empezaba en menos de diez minutos.

La diferencia entre esas pruebas era la ruta completa. Herramientas como traceroute o MTR muestran los saltos, la latencia y la pérdida de paquetes que aparecen entre el usuario y el destino. (Cloudflare) Yo no tenía tiempo para convertir la previa del torneo en una auditoría de red, pero el principio ya estaba claro.

El ping no pertenecía al país elegido. Era el resultado de todo el camino hasta el servidor del juego.

No podía observar las reglas internas de enrutamiento o filtrado del proveedor de internet ni de la VPN. Sí podía ver su consecuencia: dos endpoints cercanos producían rutas muy distintas hacia el mismo servidor de São Paulo.

Una conversación breve entre jugadores argentinos reflejaba la parte más frustrante: algunos superaban los 100 ms hacia Brasil y terminaban dudando de su propia puntería antes de reconocer cuánto los perjudicaba la conexión. (Reddit)

Yo ya estaba haciendo lo mismo. Había empezado a corregir mi forma de jugar cuando la pantalla simplemente me mostraba cada duelo demasiado tarde.

Los datos móviles dieron un buen número durante muy poco tiempo

Con seis minutos disponibles, activé el hotspot del teléfono.

Sin VPN, la conexión móvil llegó al servidor del juego en 57 ms. Durante la primera ronda de práctica se sintió mejor que cualquier opción anterior.

Luego subió a 96.

Bajó a 63.

Volvió a 130.

La prueba confirmó que existía una ruta mejor que la de mi fibra, pero no una que pudiera sostener una serie completa. El teléfono se calentaba, perdía batería aun conectado al cargador y consumía datos móviles.

El hotspot servía como rescate. No servía como plan.

Eso terminó de corregir mi criterio. Ya no buscaba el ping más bajo durante diez segundos. Buscaba una conexión capaz de mantener un ping suficientemente bajo durante cada ronda.

En un shooter competitivo, 52 ms estables resultan más útiles que 35 seguidos por saltos a 200.

La aplicación más pequeña eligió la tarea, no la bandera

Abrí OnlydogVPN y seleccioné el ajuste orientado a una conexión inestable y en tiempo real.

No tuve que decidir si Argentina, Uruguay, Chile o Brasil debía funcionar mejor. Inicié la conexión y entré en la misma sala de práctica.

El juego mostró 53 ms.

Esperé el salto.

Pasó un minuto. El ping se movió entre 50 y 57.

Crucé varias veces la puerta donde las conexiones anteriores me habían devuelto hacia atrás. El movimiento se mantuvo continuo. Lancé granadas, cambié de arma y pedí a un compañero que entrara para probar un duelo real.

Cuando apareció en la esquina, la imagen y el disparo llegaron en el orden esperado.

Entramos en la semifinal.

Durante las primeras rondas dejé activado el indicador de red. El número no fue espectacularmente bajo. Tampoco necesitaba serlo. Permaneció cerca de los 50 ms sin los picos que habían convertido la práctica en una sucesión de correcciones tardías.

En el 6–4, defendí una entrada rápida y eliminé a dos jugadores antes de retroceder. Unas horas antes habría dicho que por fin estaba apuntando bien.

Ahora sabía que también estaba viendo la jugada a tiempo.

La aplicación había resuelto algo más importante que la elección de un país: encontró una ruta estable para una sesión en tiempo real y la mantuvo sin obligarme a seguir probando endpoints durante la partida.

Su transporte basado en HTTP/3 sobre QUIC recupera mejor el flujo cuando algunos paquetes se retrasan o se pierden. (IETF) En el mapa, la explicación se reducía a una observación sencilla: el ping dejó de saltar y mi personaje dejó de retroceder.

No necesitaba una cifra más bonita. Necesitaba que la siguiente ronda se pareciera a la anterior.

El cambio de red no nos sacó de la partida

Ganamos el primer mapa y comenzamos el segundo.

En la tercera ronda, la fibra se interrumpió. El icono de red cambió, el juego quedó inmóvil y escuché a mis compañeros decir mi nombre por voz.

Activé el hotspot y conecté la laptop.

La partida volvió después de una pausa breve. El túnel se recuperó sobre los datos móviles sin pedirme otra ubicación, y regresé antes de que terminara la ronda.

El hotspot seguía sin ser mi conexión principal, pero ahora cumplía una función distinta. Era un respaldo de segundos, no una alternativa que debía sostener toda la noche.

Esa recuperación resolvió una fricción menor que apareció después del problema principal: no tuve que reconstruir la ruta en medio del torneo.

Terminamos el mapa 13–10.

Cuando cerré el juego, llevaba más de una hora sin volver a mirar la lista de países.

Cómo terminé eligiendo servidor

Después del torneo repetí las pruebas con más calma.

El proveedor grande seguía ofreciendo más ubicaciones, más documentación y una historia pública mucho más larga. Para alguien que necesita una IP de un país específico, esa amplitud es una ventaja clara.

La aplicación más pequeña tiene menos ubicaciones, menos reseñas independientes y una trayectoria más corta. Esa es su limitación más evidente.

Pero ninguna de esas diferencias respondía a la pregunta que había provocado la búsqueda.

Yo no necesitaba ver “Argentina” o “Brasil” en la pantalla. Necesitaba llegar desde Córdoba hasta un servidor concreto de São Paulo con el menor retraso sostenido posible.

Buenos Aires era el endpoint más cercano y mostraba el mejor número dentro de la aplicación. También produjo el peor ping dentro del juego. São Paulo parecía correcto por nombre, pero sufría picos. Santiago fue más estable que ambos, aunque todavía demasiado lento para la semifinal.

La aplicación pequeña fue la única que convirtió la elección en la tarea correcta: mantener una sesión en tiempo real sobre una ruta irregular.

Desde entonces, cuando pruebo una VPN para jugar, ignoro el primer número atractivo. Entro al destino real, observo el ping durante varios minutos y presto atención a los saltos, la pérdida de paquetes y la continuidad.

Para aquella semifinal, el servidor correcto no fue el que quedaba más cerca de Córdoba ni el que mostraba 9 ms en el menú. Fue el que mantuvo unos 50 ms hasta São Paulo cuando cada disparo empezó a contar.