Cómo saber dónde está alojado tu sitio web, paso a paso

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 vas a saber en qué ciudad está tu sitio, y vas a poder demostrarlo.

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 .

Al final te da mínimo, promedio y máximo. Usa el mínimo. El promedio lo ensucian el wifi, el vecino viendo streaming y cualquier congestión pasajera. El mínimo es el mejor caso físico: la distancia real, sin ruido.

Para comparar tu resultado, aquí están los nuestros. No son rangos teóricos: es lo que medimos, proveedor por proveedor.

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. Fíjate en Phoenix, que aparece dos veces: GoDaddy contesta en 121-126 ms y Namecheap, desde la misma ciudad, en 178-186 ms — un número que a ojo parecería Brasil. Por eso existen el paso 3 y el paso 4: el traceroute y el AS deciden; el ping solo sospecha.

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 . Si puedes instalar mtr, mejor todavía: mtr -rwc 50 te da salto por salto con pérdidas.

Quita el -n y vuelve a correrlo para ver los nombres de los routers. Ahí está el mapa del viaje, escrito por los propios operadores:

• 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

Aquí es donde ves el fenómeno más contraintuitivo de todos: si tu servidor está en Brasil, el traceroute va a mostrar Bogotá → Miami → São Paulo. Sube al norte para poder bajar al sur. Pagas el desvío dos veces, y por eso Brasil te sale más lento que Virginia.

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, con su nombre. Ese nombre suele delatar la ciudad. El caso más limpio que hemos documentado: un bloque de ColombiaHosting está registrado en LACNIC a nombre colombiano, pero lo anuncia AS36454, «WHG-DAL». DAL de Dallas. Y la propia empresa lo declara en su página /nosotros/, donde habla de «dos de los mejores centros de datos en Estados Unidos, en dos ubicaciones diferentes».

Regla de oro: el registro en LACNIC dice de quién es el bloque; el anuncio BGP dice dónde está enchufado. El primero lo llenas tú. El segundo lo ve todo internet.

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 dónde está cada prefijo: país, región, ciudad. Es la fuente más directa que hay, porque la publica quien opera la red.

whois <la IP> | grep -i geofeed

Si aparece una URL, ábrela y busca tu prefijo. Vas a ver una línea como esta, que es la real del bloque donde vive la cuenta de Colombia Cloud, declarada por el operador que lo administra:

207.210.102.0/24,CL,CL-RM,Santiago

CL. Chile. Santiago. Dicho por el operador, sin que nadie tenga que medir nada.

Y a veces el geofeed prueba algo por lo que no dice. Hostinger publica el suyo en abierto en github.com/hostinger/geofeed, ciudad por ciudad, y Colombia no está en la lista. Publicarlo es un gesto de transparencia que hay que reconocerles. Y ese mismo gesto responde la pregunta: si Colombia no está en su inventario, tu sitio no está en Colombia.

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.

Prepárate para ver MIA: el 95% de los sitios colombianos con Cloudflare se sirven desde Miami, no desde Bogotá. Son unos 69 ms.

Y mira la otra cabecera, que es la que de verdad importa. cf-cache-status: DYNAMIC significa que el CDN no está sirviendo esa página desde caché: la fue a buscar al origen. Lo vimos el 2026-08-30 en wnpower.net, y es el CDN declarándolo por sí mismo. En esa misma sesión, ese sitio respondió el ping del borde en 65,3 ms y el primer byte del servicio en 338,9 ms. El ping halaga; el servicio no.

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 nosotros el 2026-08-30 desde Bogotá, por red INTERNEXA (AS18678), quedándonos con el mejor de entre tres y cinco intentos: conexcol.net.co devolvió el primer byte del HTML en 0,085-0,105 s; colombiahosting.com.co, en 0,260-0,307 s; wnpower.net, en 0,283-0,294 s; hostdime.com.co, en 0,293 s. Los tres últimos están detrás de Cloudflare.

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.

• Los cuatro coinciden: listo, sabes dónde estás.
• El marketing dice Colombia y el reloj dice 100 ms: gana el reloj. Siempre.
• El registro dice Colombia y el AS dice Dallas: gana el AS.
• Todo apunta a un país y el geofeed dice otro: gana el geofeed, porque lo firmó el operador.

Para ponerlo en contexto: hicimos exactamente este ejercicio sobre 1.352 dominios colombianos y solo el 11% resultó estar servido desde infraestructura físicamente colombiana. Si tu resultado te decepciona, no eres la excepción. Eres la norma.

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. Nuestro número, medido el 2026-08-30 desde Bogotá por INTERNEXA (AS18678), ruta pública y RTT mínimo, es 16,9 ms. El tuyo dependerá de tu operador y de tu ciudad, y esa es exactamente la gracia del ejercicio: mídelo y anota desde dónde mediste.

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.

Referencias de medición: 2026-08-30, desde Bogotá, red INTERNEXA (AS18678), ruta pública, RTT mínimo. Reprodúcelo desde tu propia conexión y anota desde dónde mediste: un número sin punto de medición no es un dato.