Latencia de un VPS en Canadá desde Latinoamérica

¿Un VPS en Canadá es adecuado para usuarios de Latinoamérica?

Un VPS en Canadá es una buena opción para usuarios de Latinoamérica cuando cada página necesita pocas solicitudes, y una mala opción cuando la aplicación se comunica con el servidor muchas veces por pantalla. La distancia entre Ciudad de México, Bogotá, Santiago o Buenos Aires y Toronto es grande, y ningún proveedor puede reducirla. Lo que sí puede controlar es cuántas veces atraviesa su aplicación esa distancia antes de que el usuario vea algo.

Esta guía no incluye cifras de latencia a propósito. Un número medido en la ruta de otra persona no le dice nada sobre la suya, porque el retraso depende del operador del usuario y de las redes entre ese operador y el servidor. Puede medir su propia ruta en unos diez minutos con herramientas que ya están instaladas. La segunda mitad de esta guía explica ese método y cómo interpretar lo que muestran las herramientas.

Primero, un término. El tiempo de ida y vuelta (RTT) es el tiempo que tarda un paquete en llegar al servidor más el tiempo que tarda la respuesta en regresar. En esta guía, una ida y vuelta se representa como R. Todos los costes siguientes se expresan en términos de R, de modo que puede introducir su propio valor medido y obtener una respuesta para su aplicación.

El coste de un viaje de ida y vuelta y lo que no incluye

R se cobra una vez por intercambio, no por byte. Ese hecho determina todo lo demás en esta página.

Una descarga grande apenas lo nota. Cuando una conexión TCP (transmission control protocol) está abierta y funciona a toda velocidad, el emisor no se detiene a esperar una respuesta antes de enviar el siguiente segmento. Una transferencia de archivos grande está limitada por el ancho de banda, no por la distancia. R se paga al principio y de nuevo después de una pérdida de paquetes, porque cada segmento perdido se recupera con un viaje de ida y vuelta adicional. Por tanto, una ruta larga sufre más en un enlace con pérdidas que una ruta corta con el mismo ancho de banda.

Una página con muchas solicitudes lo paga por completo. Considere una página que realiza veinte solicitudes consecutivas, donde cada solicitud necesita la respuesta de la anterior. Esa página espera 20R antes de que empiece siquiera la última respuesta. Si R en su ruta resulta ser de aproximadamente una décima de segundo, la página pasa alrededor de dos segundos esperando a la red. Durante ese tiempo, el servidor no hace ningún trabajo. Espera a que llegue la siguiente solicitud, y el usuario también.

Separar una aplicación de su base de datos es el error costoso. La distancia hasta el usuario se paga una o dos veces por página. La distancia hasta la base de datos se paga una vez por consulta, por lo que el código que ejecuta 300 consultas para construir una página paga 300R cuando la base de datos está en otra región. Mantenga la aplicación y su base de datos en el mismo centro de datos. Después, acerque el conjunto a sus usuarios tanto como permitan las demás restricciones.

Cada conexión HTTPS nueva paga los handshakes. TCP necesita un viaje de ida y vuelta antes de poder transportar datos. TLS (transport layer security) 1.3 añade uno más. TLS 1.2 añade dos. Por tanto, un navegador que abre una conexión nueva espera aproximadamente 2R con TLS 1.3 y aproximadamente 3R con TLS 1.2 antes de que el servidor lea un solo byte de la solicitud. Las conexiones reutilizadas omiten todo eso. Por este motivo, keep-alive y HTTP/2 son mucho más importantes en una ruta larga que en una corta.

Una sesión SSH (secure shell) interactiva es el caso que se nota directamente. El extremo remoto devuelve cada pulsación, por lo que cada carácter aparece en pantalla un R después de pulsar la tecla. No hay ningún fallo. Ese retraso es el viaje de ida y vuelta, y puede observarlo directamente. El paquete mosh predice localmente el eco, por lo que editar un archivo de configuración en un equipo remoto deja de ser incómodo.

Por qué la ruta de red es más larga que la distancia en el mapa

Los paquetes siguen los puntos donde se interconectan las redes, y esos puntos rara vez están en la línea más corta del mapa. El tráfico de Sudamérica a Canadá suele pasar primero por Miami o por el noreste de Estados Unidos, porque allí se conectan los operadores. Ejecute traceroute y lea los nombres de DNS inverso (sistema de nombres de dominio) de los saltos. Los códigos de aeropuerto, como mia, nyc, iad y yyz, aparecen dentro de muchos nombres de host de los operadores e indican qué ciudades visitaron realmente sus paquetes.

De aquí se derivan dos datos útiles. Las rutas suelen ser asimétricas. Esto significa que la ruta desde el usuario hasta el servidor no es la inversa de la ruta de regreso. Por eso, un traceroute ejecutado desde cada extremo puede mostrar ciudades diferentes. La interconexión local también es determinante. IX.br, en São Paulo, es uno de los mayores puntos de intercambio de Internet (IXP) del mundo. Por tanto, el tráfico brasileño que permanece dentro de Brasil recorre una ruta corta, mientras que el mismo tráfico enviado a Canadá sale del país y entra en una ruta internacional larga.

La geometría de España vuelve a ser diferente. La ruta de España a Canadá cruza el Atlántico hacia el oeste. La ruta de España a Frankfurt es un salto corto por tierra entre dos ciudades europeas con muchas conexiones. Por tanto, una audiencia española casi nunca obtiene el mejor servicio desde Canadá, independientemente de lo atractivo que parezca el precio.

Cuándo un VPS canadiense es la opción correcta

Canadá es la opción adecuada cuando las personas importantes están cerca de ese país o cuando el requisito que debe cumplir está relacionado con la jurisdicción y no con la velocidad.

• Sus clientes o su empleador están en Canadá o en el norte de Estados Unidos. Su equipo de Latinoamérica absorbe entonces la latencia en lugar de sus usuarios, y un equipo de desarrollo tolera mucha más latencia que un cliente de pago.
• Quiere que los datos se almacenen fuera de Estados Unidos. Es una cuestión legal y contractual, no de red. Lea lo que realmente garantiza la residencia de datos en Canadá antes de hacer esa afirmación a un cliente, porque «alojado en Canadá» y «fuera del alcance de una orden extranjera» son afirmaciones distintas.
• Su procesador de pagos y los demás proveedores de API operan en Norteamérica. Cada llamada que su servidor les hace también implica un viaje de ida y vuelta, y esas llamadas suelen ser más numerosas que las que su usuario le hace a usted. Estar cerca de sus dependencias puede ser más importante que estar cerca de sus usuarios.
• Ya ejecuta sistemas en Toronto o Montreal y quiere una sola red y una sola ruta de copias de seguridad, en lugar de dos de cada una.

Si esa es su situación, los criterios de compra que realmente importan para un VPS canadiense cubren el lado del proveedor, y qué ofrece un VPS en Toronto cubre la ubicación canadiense con más actividad. Si todavía está evaluando la frontera en sí, la comparación entre Canadá y Estados Unidos separa el argumento de red del argumento legal.

Cuándo Canadá es la razón equivocada

La razón equivocada es elegir Canadá porque parece un punto intermedio neutral entre Estados Unidos y el resto del mundo. En la red no existe un punto intermedio, y Canadá está en el extremo norte de Norteamérica. Para la mayor parte de América Latina, queda más lejos de sus usuarios que Estados Unidos.

• Sus usuarios están en España. Madrid es la ubicación natural para ellos. Si no se ofrece una ubicación en Madrid, un VPS en Frankfurt o un VPS en Ámsterdam se encuentra en la zona con mayor densidad de interconexión de Europa, y ambos están mucho más cerca de los usuarios españoles que cualquier ciudad de Norteamérica.
• Sus usuarios están en Brasil. En ese caso, aloje el servicio en Brasil: un VPS en São Paulo mantiene el tráfico en el punto de intercambio nacional en lugar de enviar cada petición a otro continente y de vuelta.
• Sus usuarios están en México. Compare una ubicación del sur de Estados Unidos, como un VPS en Dallas, con Canadá antes de decidir, porque, en términos de red, la ruta más corta suele ser la de Texas.
• Sus usuarios están en Colombia, Ecuador, Venezuela o el Caribe. Mida también un VPS en Nueva York, porque gran parte de ese tráfico ya pasa por la costa este de Estados Unidos de camino a cualquier otro destino.
• Aloja un servidor de juegos o cualquier servicio en el que R sea el producto que vende. La ubicación se convierte en una característica, no en un detalle, y elegir una ubicación para un servidor de juegos es un proceso distinto de elegir una para un sitio web.

¿Cómo mido la ruta hasta un VPS en Canadá?

Instale las herramientas una sola vez. En Ubuntu o Debian:

sudo apt update
sudo apt install -y mtr-tiny traceroute curl

Empiece por la medición más sencilla. Indique la dirección que está considerando o una dirección de prueba que publique el proveedor.

ping -c 20 vps.example.com

Lea las dos últimas líneas. El porcentaje de pérdida de paquetes indica si la ruta funciona correctamente. El resumen de rtt min/avg/max/mdev muestra R, y el valor de avg es el tiempo de ida y vuelta que debe tener en cuenta. La diferencia entre min y max es el jitter, y el jitter perjudica más al trabajo interactivo que un promedio alto, porque es más difícil ocultar un retraso impredecible que uno constante. Tenga en cuenta que ping usa ICMP (protocolo de mensajes de control de Internet), y muchos routers limitan la tasa de ICMP o lo descartan. Por tanto, un ping fallido no demuestra que el servidor sea inaccesible.

A continuación, examine la ruta.

mtr --report --report-cycles 50 vps.example.com

mtr combina ping y traceroute, y envía cincuenta sondas a cada salto. Lea sólo la línea final, porque ese es el salto con el que se comunican realmente los usuarios. Si un salto intermedio muestra pérdidas pero la línea final no muestra ninguna, significa que un router limita la tasa de sus propias respuestas, no que haya pérdida de paquetes en su ruta. Lo mismo ocurre con un salto que muestra un tiempo alto cuando los saltos posteriores funcionan correctamente. Los nombres de host de la columna central indican las ciudades.

Si ICMP está filtrado en algún punto y mtr muestra una pared de asteriscos, haga una consulta que no pueda ignorar mediante TCP al puerto 443:

sudo traceroute -T -p 443 vps.example.com

Por último, mida lo que experimenta realmente un navegador. Este es el número que permite resolver la discusión.

curl -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' \
  -o /dev/null -s https://vps.example.com/

Todos los valores están expresados en segundos y se cuentan desde el inicio del comando, por lo que debe leerlos como diferencias. time_connect menos time_namelookup es el handshake TCP, que se aproxima a un R. time_appconnect menos time_connect es el handshake TLS adicional. time_starttransfer menos time_appconnect es otro tiempo de ida y vuelta más el tiempo que su servidor tardó en procesar la solicitud. Vigile esa última diferencia: si es mucho mayor que las demás, la parte lenta es su aplicación, y trasladarla a otro país no ayudará.

for i in 1 2 3 4 5; do
  curl -w 'tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer}\n' \
    -o /dev/null -s https://vps.example.com/
done

¿Cómo mido desde dónde se conectan mis usuarios?

Su portátil no representa a sus usuarios. Aquí es donde suelen fallar las decisiones sobre ubicación. Hay cuatro formas de obtener una medición real, de menor a mayor coste.

1. Pida a un usuario real de ese país que ejecute el comando curl y le envíe la salida. Es la medición más fiable que puede obtener y no cuesta nada.
2. Alquile por horas el VPS más pequeño de la región de destino, ejecute mtr y curl desde allí hacia su dirección canadiense y después destrúyalo. Una hora de una instancia pequeña cuesta muy poco y el resultado procede de las redes de ese país.
3. Use RIPE Atlas, una red pública de medición formada por sondas pequeñas alojadas por voluntarios de todo el mundo. Puede programar un ping o un traceroute desde sondas de un país concreto hacia su propio servidor y leer el resultado sonda por sonda.
4. Abra las herramientas de desarrollo del navegador en el equipo de un usuario, vaya a la pestaña de red y consulte los tiempos de la primera solicitud. Muestra por separado la resolución de nombres, TCP, TLS y el tiempo de procesamiento del propio servidor.

Haga las pruebas antes de pagar, no después. Muchos proveedores publican una página de looking glass o un archivo de prueba por ubicación precisamente para este fin.

Si mantiene Canadá, elimine los viajes de ida y vuelta

Una vez corregida la ubicación, todas las mejoras restantes consisten en reducir el número de solicitudes.

• Sirva una página en una sola solicitud cuando sea posible, en lugar de encadenar solicitudes en las que cada una espera la respuesta anterior.
• Active HTTP/2 y mantenga las conexiones abiertas, para que los handshakes se realicen una vez por visita y no una vez por solicitud.
• Prefiera TLS 1.3 y active la reanudación de sesión. Esto elimina un viaje de ida y vuelta en las conexiones posteriores.
• Coloque los archivos estáticos detrás de una red de distribución de contenido (CDN) con puntos de presencia (PoP) en Latinoamérica, para que las imágenes y los scripts se sirvan localmente mientras la aplicación permanece en Canadá.
• Corrija los patrones de consultas N+1, en los que el código ejecuta una consulta adicional por cada fila que ya obtuvo. Cada consulta que elimina también elimina un R.
• Almacene en caché las respuestas costosas cerca del usuario, aunque sólo sea durante unos segundos.
• Use mosh en lugar de ssh sin formato para la administración interactiva a través de una ruta larga.

Estos cambios actúan sobre el multiplicador y no sobre la distancia. En una ruta larga, el multiplicador suele ser el número mayor.

Qué pagas y en qué moneda

Los proveedores que prestan servicio en Canadá y Estados Unidos facturan en dólares estadounidenses o dólares canadienses, y en agosto de 2026 esa sigue siendo la norma. Si tu presupuesto está en pesos mexicanos, pesos colombianos, pesos chilenos, pesos argentinos o euros, prevé dos costes adicionales. El emisor de tu tarjeta añade un margen de conversión en cada cargo, y varios países aplican sus propios impuestos a las compras en moneda extranjera. Comprueba la normativa local antes de comprometerte con un importe mensual.

Hay un segundo efecto que suele pasar inadvertido. Un precio fijo en dólares no es un precio fijo en tu moneda. Por eso, el mismo plan puede costar bastante más un mes que el anterior después de una variación del tipo de cambio. Pagar un año por adelantado fija el precio en dólares, pero no fija el precio en pesos. Un plan facturado en dólares canadienses tiene la misma exposición en otra dirección, porque esa moneda también fluctúa frente al dólar estadounidense y frente a tu moneda.

FAQ

¿Un VPS canadiense es demasiado lento para usuarios de México o Colombia?

Para la mayoría de los sitios web y las API, no. La latencia se acumula en cada intercambio, por lo que una página que responde en unas pocas solicitudes sigue siendo ágil, mientras que una página que realiza veinte solicitudes secuenciales espera veinte viajes de ida y vuelta y se percibe lenta desde cualquier ubicación distante. Mida su propia ruta con ping -c 20 y mtr --report --report-cycles 50 hacia la dirección de prueba del proveedor y cuente cuántas solicitudes realiza realmente la página. Cuando ese número es alto, reducirlo ayuda más que cambiar de país.

¿Debo elegir Canadá o Estados Unidos para usuarios de Latinoamérica?

En términos estrictamente de red, una ubicación en Estados Unidos, como Dallas para México o Nueva York para el norte de Sudamérica, suele estar más cerca de los usuarios latinoamericanos que una ubicación canadiense, porque allí se produce una mayor parte de la interconexión. Canadá es la mejor opción cuando el requisito es la jurisdicción y no la velocidad, o cuando sus clientes y proveedores ya están en Canadá. Mida ambas opciones desde la región de sus usuarios antes de decidir, porque los acuerdos de peering determinan el resultado y el mapa no lo refleja.

¿Dónde debería alojar el servicio si mis usuarios están en España?

En Europa. Madrid es la opción más cercana cuando un proveedor la ofrece, y Frankfurt o Amsterdam suelen ser la segunda opción, porque ambas ciudades tienen una interconexión muy densa y están conectadas con España por una ruta terrestre corta. Un VPS canadiense envía a los usuarios españoles a través del Atlántico en la dirección equivocada, lo que añade latencia a cada solicitud sin aportar ninguna ventaja, salvo que exista un motivo legal o comercial específico para conservar los datos en Canadá.

¿Cómo pruebo la latencia desde un país en el que no estoy?

No necesita contratar un servicio para hacerlo. Pida a un usuario real de ese país que ejecute curl -w 'tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer}\n' -o /dev/null -s https://your-host/ y le envíe la línea resultante. Alquile un VPS por horas en esa región, mida desde él y destrúyalo después. Programe mediciones de ping y traceroute desde sondas de RIPE Atlas ubicadas en ese país. También puede consultar la pestaña de red de las herramientas de desarrollo del navegador en el equipo del propio usuario. Registre la ciudad y la fecha con cada resultado, porque las rutas cambian.

¿Alojar el servicio en Canadá mantiene mis datos fuera de la jurisdicción de Estados Unidos?

Alojar el servicio en Canadá sitúa la máquina física en Canadá, pero esto es un punto de partida, no una garantía. Lo importante es la empresa que controla la máquina, el país donde está registrada su empresa matriz y los lugares donde se copian las copias de seguridad y los datos de monitorización. Un centro de datos canadiense operado por una empresa bajo propiedad estadounidense tiene una posición jurídica distinta de la de uno que no lo está. Confirme por escrito la estructura corporativa y las ubicaciones de las copias de seguridad antes de prometer a un cliente cualquier condición sobre la jurisdicción.