Este artículo te enseña a auditar a tu proveedor de hosting. A cualquiera. También a nosotros.

No necesitas herramientas de pago, ni cuenta en ningún servicio, ni saber de redes. Necesitas una terminal (en Windows sirve PowerShell) y un rato. Al final tendrás varias señales sobre la ruta y la ubicación probable de tu servicio. Para demostrar una dirección física hacen falta además declaraciones o documentación del operador.

Vamos por pasos, del más fácil al más revelador.

Paso 1. Encuentra la IP real

dig +short tusitio.com

En Windows: nslookup tusitio.com.

Te va a salir una o varias direcciones IP. Anótalas.

Trampa número uno: esa IP puede ser la de un CDN y no la de tu servidor. No adivines por el número: compruébalo con el paso 6 (cf-ray) o con el whois del paso 4 — si el AS que la anuncia es el del CDN, estás midiendo el borde, no tu servidor. Eso no invalida el ejercicio, pero cambia lo que estás midiendo.

Si tienes correo en el mismo hosting, este truco suele destapar el origen:

dig +short mail.tusitio.com
dig +short MX tusitio.com

El correo casi nunca pasa por CDN. Esa IP suele ser la del servidor de verdad.

Paso 2. Mide, y mira el mínimo

ping -c 20 <la IP>

En Windows: ping -n 20 <la IP>.

Al final te da mínimo, promedio y máximo. Anota los tres. El mínimo aproxima el mejor caso de esa ruta; la mediana describe mejor la experiencia habitual. Ninguno certifica por sí solo una ubicación física.

Para orientar tu resultado, aquí está la muestra agrupada por región. Son observaciones puntuales desde una red en Bogotá, no una clasificación de marcas ni una promesa de rendimiento.

RTT mínimo observado Región del endpoint
16,9 ms Conexcol — Colombia
18,4 ms Referencia local A — Bogotá
20,0 ms Referencia local B — Colombia
~69 ms Borde de Cloudflare en Miami
94,9 ms Endpoint A — Asheville, EE. UU.
96,3 ms Endpoint B — Ashburn, Virginia
98-105 ms Endpoint C — Dallas, Texas
117,8 ms Endpoint D — Phoenix
121-126 ms Endpoint E — Phoenix
133-138 ms Endpoint F — Salt Lake City
168-180 ms Endpoint G — São Paulo
173-179 ms Endpoint H — São Paulo
178-186 ms Endpoint I — Phoenix
190-208 ms Endpoint J — Argentina

Medido el 2026-08-30 desde Bogotá, red INTERNEXA (AS18678), ruta pública, RTT mínimo.

Orientación, no ley: la ruta manda más que la distancia. Dos endpoints en Phoenix dieron 121-126 ms y 178-186 ms. Por eso existen los pasos siguientes: el ping solo aporta una señal.

Nota honesta sobre el método: la latencia se mide desde algún lado. La nuestra es desde Bogotá, por red pública, como un visitante. Si un proveedor te muestra un número sin decirte desde dónde lo midió, ese número no significa nada. Incluido el nuestro: por eso ponemos la red, la fecha y el criterio.

Paso 3. Mira el camino, no solo el destino

traceroute -n <la IP>

En Windows: tracert <la IP>. Si puedes instalar mtr, mejor todavía: mtr -rwc 50 <la IP> te da salto por salto con pérdidas.

Quita el -n y vuelve a correrlo para ver los nombres de los routers. Pueden aportar pistas sobre la ruta:

  • bog, bogota → Bogotá
  • mia, miami → Miami
  • iad, ashburn → Virginia
  • dfw, dal → Dallas
  • gru, saopaulo → São Paulo
  • scl, santiago → Santiago de Chile
  • eze, bue → Buenos Aires

En la ruta que medimos hacia São Paulo apareció el recorrido Bogotá → Miami → São Paulo. Ese desvío explica el resultado de esa sesión, pero otras redes o acuerdos de interconexión pueden seguir caminos distintos.

Paso 4. Pregunta quién anuncia ese bloque

Este es el paso que separa al que sabe del que repite lo que le dijeron.

whois -h whois.cymru.com " -v <la IP>"

Te devuelve el AS (sistema autónomo) que anuncia esa IP en BGP. Su nombre puede aportar una pista, pero no certifica una ciudad. En el endpoint C de la muestra, el bloque está registrado en LACNIC a nombre colombiano, el ASN contiene la referencia DAL, la ruta es compatible con Dallas y la propia empresa declara que sus servidores están en dos centros de datos de Estados Unidos. La conclusión sale de la corroboración, no de tres letras.

Regla de oro: el registro en LACNIC dice a quién está asignado el bloque; BGP dice quién lo anuncia y cómo se alcanza. Para afirmar una ubicación física hacen falta más fuentes.

Si prefieres el navegador, cualquier consulta pública de BGP (bgp.tools, RIPEstat) te da lo mismo sin instalar nada.

Paso 5. Busca el geofeed

El RFC 8805 define un archivo CSV público donde el operador declara una ubicación para cada prefijo: país, región, ciudad. Es una fuente directa, pero voluntaria; puede estar incompleta o desactualizada.

whois <la IP> | grep -i geofeed

Si aparece una URL, ábrela y busca tu prefijo. Una línea puede verse así:

207.210.102.0/24,CL,CL-RM,Santiago

CL. Chile. Santiago. Eso es lo que declaró el operador para ese prefijo en el archivo consultado; todavía conviene corroborarlo.

La ausencia de un país en un geofeed no prueba que todos los productos, socios o cuentas del operador estén fuera de allí. Solo permite afirmar que ese archivo no declaraba una ubicación en ese país al momento de consultarlo.

Paso 6. Si hay CDN, sepáralo

curl -sI https://tusitio.com | grep -i 'cf-ray\|cf-cache-status'

Si sale cf-ray, estás detrás de Cloudflare, y las tres últimas letras son el código de aeropuerto del punto de presencia que te atendió. BOG es Bogotá. MIA es Miami.

En nuestra muestra y sesión, el 95% de las respuestas observadas detrás de Cloudflare llegó desde Miami. Eso identifica el borde que atendió esas peticiones, no el origen de los sitios ni un comportamiento permanente del CDN.

La cabecera cf-cache-status: DYNAMIC significa que esa respuesta concreta no salió de la caché. En uno de los endpoints medidos, el RTT al borde fue de 65,3 ms y el TTFB observado de 338,9 ms. Es una demostración del mecanismo, no una evaluación general de quien opera el sitio.

Ese es el punto: el borde acerca lo estático. El login, el carrito, el formulario, la búsqueda y la consulta a base de datos siguen viajando hasta el origen — y la base de datos, el correo y el FTP no los acerca nadie. Un borde cercano acelera las imágenes; no acerca el servidor.

Para medir el origen, usa el truco del mail. del paso 1, o cronometra una página que no se pueda cachear:

curl -o /dev/null -s -w "conexión: %{time_connect}s  primer byte: %{time_starttransfer}s\n" https://tusitio.com/wp-login.php

Así lo medimos el 2026-08-30 desde Bogotá, por red INTERNEXA (AS18678), con entre tres y cinco intentos: el sitio de Conexcol devolvió el primer byte del HTML en 0,085-0,105 s y tres sitios institucionales detrás de CDN lo hicieron entre 0,260 y 0,307 s. Esto compara páginas concretas, no los planes de hosting que venden sus operadores.

Paso 7. Junta las piezas

Tienes cuatro testigos: el reloj (ping), el camino (traceroute), el anuncio (BGP) y la declaración (geofeed). Y un quinto, que es lo que dice el marketing.

  • Las señales coinciden: tienes una conclusión razonablemente sustentada para ese endpoint y fecha.
  • El marketing y la medición difieren: comprueba que estás comparando el mismo producto antes de concluir.
  • El registro y BGP difieren: recuerda que uno habla de asignación administrativa y el otro de enrutamiento.
  • El geofeed difiere: trátalo como declaración del operador y busca corroboración; no es una certificación física.

Para ponerlo en contexto: aplicamos parte de este ejercicio a 1.352 dominios colombianos y alrededor del 11% apareció asociado a redes clasificadas como colombianas. El AS no basta para certificar la ubicación física ni el país donde se almacenan los datos.

Ahora hazlo con nosotros

Este artículo no serviría de nada si te pidiéramos que aplicaras el método a todo el mundo menos a Conexcol. Aplícalo.

Vas a encontrar infraestructura en Colombia, conectada al NAP Colombia. El endpoint de Conexcol medido el 2026-08-30 desde Bogotá por INTERNEXA (AS18678), ruta pública, dio un RTT mínimo de 16,9 ms. Tu resultado dependerá del operador, la ciudad, la ruta y el momento.

Y mide también lo que el ping no ve, porque es donde se decide de verdad: quién te contesta el teléfono, en qué idioma, con qué factura y bajo qué jurisdicción. Nuestro SLA es un compromiso contractual del 100% con compensación; la instalación mide 99,98%. Eso también se audita, y también deberías exigirlo por escrito.

No te pedimos que nos creas. Te pedimos que nos midas, con los mismos comandos que acabas de aprender.

Qué no demuestra la muestra

  • No es un ranking de calidad, precio, disponibilidad ni soporte.
  • No compara necesariamente planes equivalentes.
  • No predice dónde quedará una cuenta nueva.
  • No representa todas las redes ni ciudades de Colombia.
  • No convierte el RTT mínimo en tiempo habitual de carga.
  • No permite atribuir a planes cloud lo observado en una cuenta de hosting compartido, ni al contrario.

Para formular una comparación comercial general repetiremos la medición desde al menos tres redes colombianas, en distintos horarios, y compararemos productos equivalentes. Mientras eso no exista, solo publicamos observaciones acotadas por endpoint.

Conservamos durante al menos tres años la pieza publicada, las capturas de las fuentes, los resultados, la fecha, los hosts y la metodología. Revisaremos esta muestra cada 90 días; si un endpoint cambia o deja de ser reproducible, se corrige o se retira.

Referencias de medición: 2026-08-30, desde Bogotá, una sola red —INTERNEXA (AS18678)—, ruta pública y RTT mínimo. Última revisión editorial: 2026-09-10. Reprodúcelo desde tu propia conexión y registra mínimo, mediana, máximo, fecha, hora, ciudad y operador.