Cloudflare gratis te sirve desde Dallas: lo medí desde 20 puntos de México

El 4 de octubre de 2026 medí un dominio de prueba en el plan Free de Cloudflare desde 20 sondas en México: las 19 que respondieron salieron por Dallas (DFW), con una conexión TCP mediana de 32 ms. La misma zona, forzada a otra IP de Cloudflare, salió 13 veces por Querétaro con una mediana de 7 ms.

No es un error de configuración ni un caso raro: Cloudflare documenta que, cuando a un centro de datos le falta capacidad, mueve primero a los clientes del plan gratuito. Lo que casi nadie dice es que en México eso se nota, y que lo puedes comprobar en dos minutos. Aquí va cómo medirlo tú, por qué pasa, cuánto cuesta en milisegundos y cuándo vale la pena preocuparse.

Lo que medí

La medición la hice con Globalping, la red de sondas públicas de jsDelivr, el domingo 4 de octubre de 2026 a las 17:55, hora del centro de México (23:55 UTC). Pedí 20 sondas en México y les mandé un HEAD /cdn-cgi/trace a un dominio de prueba en el plan Free. Las sondas cayeron en Querétaro (10), Ciudad de México (5), Morelia (2), Puebla, Guadalajara y Ciudad Juárez (una cada una).

Después repetí exactamente lo mismo, pero obligando a las sondas a conectarse a otra IP de Cloudflare, 104.18.12.15, de un rango que se anuncia desde México. Misma zona, mismo certificado, mismo contenido. Lo único que cambia es a qué dirección llega el navegador.

No es la primera vez. El 22 de septiembre hice la misma prueba contra un dominio Free con 19 sondas y salió igual: 19 de 19 por Dallas. Esa vez, la zona forzada a una IP de ese rango respondió desde MEX, la Ciudad de México. Dos semanas de diferencia, mismo resultado.

Una advertencia honesta sobre las cifras: casi todas las sondas de Globalping en México están en centros de datos (buena parte en Querétaro, donde hay varias regiones de nube), y la única red residencial con sondas que encontré fue Telmex. Un centro de datos en Querétaro está mejor conectado que la casa de tu cliente, así que estos números son el mejor caso, no el típico.

Cómo saber desde qué ciudad te sirve Cloudflare

Cloudflare te lo dice en cada respuesta, solo hay que saber dónde mirar.

La forma rápida, desde tu terminal. Cualquier dominio detrás de Cloudflare responde en la ruta /cdn-cgi/trace:

curl -s https://tu-dominio.com/cdn-cgi/trace | grep colo
# colo=DFW

colo es el código de aeropuerto (IATA) del centro de datos que te respondió: DFW es Dallas, QRO Querétaro, MEX la Ciudad de México. El mismo dato viene al final del encabezado cf-ray de cualquier respuesta:

curl -sI https://tu-dominio.com/ | grep -i cf-ray
# cf-ray: 9a1b2c3d4e5f6789-DFW

Esto te dice desde dónde te sirven a ti, desde tu conexión. Para saber qué pasa con tus visitantes en otras ciudades necesitas medir desde allá.

La forma completa, con Globalping. Su API es pública y no pide registro (sin clave tienes 250 pruebas por hora; cada sonda cuenta como una). Este comando pide 20 sondas en México:

curl -s -X POST https://api.globalping.io/v1/measurements \
  -H 'Content-Type: application/json' \
  -d '{
    "type": "http",
    "target": "tu-dominio.com",
    "locations": [{ "country": "MX", "limit": 20 }],
    "measurementOptions": {
      "protocol": "HTTPS",
      "request": { "method": "HEAD", "path": "/cdn-cgi/trace" }
    }
  }'
# {"id":"<id>","probesCount":20}

Te devuelve un id. Espera unos segundos y pide el resultado; con jq sacas la ciudad de cada sonda, el colo que le respondió y el tiempo de conexión TCP:

curl -s https://api.globalping.io/v1/measurements/<id> \
  | jq -r '.results[] | [.probe.city, (.result.headers["cf-ray"] // "falló"), .result.timings.tcp] | @tsv'
# Queretaro      9a1b2c3d4e5f6789-DFW   31
# Mexico City    9a1b2c3d4e5f6790-DFW   33
# ...

Si el campo status todavía dice in-progress, vuelve a pedirlo. Cambia "country": "MX" por el país que te interese; también acepta ciudades ({"city": "Monterrey"}) o redes ({"asn": 8151} es Telmex).

Cómo leer el tcp: es aproximadamente un viaje de ida y vuelta. Desde México, menos de 10 ms significa que te atendió un nodo local; alrededor de 30 ms, Dallas.

La prueba que explica todo: forzar otra IP

Aquí está lo interesante. Cloudflare no elige el centro de datos por la distancia a tu visitante. Lo decide, en buena parte, la IP a la que resuelve tu dominio. Cloudflare usa anycast: la misma dirección se anuncia desde muchos centros de datos, y el internet lleva al visitante al más cercano de los que anuncian esa dirección. Si el rango de IPs que le tocó a tu zona no se anuncia desde México, el visitante mexicano termina en el más cercano que sí lo anuncia, que en mis pruebas fue Dallas.

Lo puedes comprobar sin tocar tu DNS. Primero mira a qué IPs resuelve tu dominio:

dig +short tu-dominio.com

Y luego compara el colo con DNS normal contra el mismo dominio forzado a una IP del rango 104.18.x:

curl -s https://tu-dominio.com/cdn-cgi/trace | grep colo
# colo=DFW

curl -s --resolve tu-dominio.com:443:104.18.12.15 \
  https://tu-dominio.com/cdn-cgi/trace | grep colo
# colo=QRO

--resolve le dice a curl «para este dominio, conéctate a esta IP», sin cambiar nada más: el certificado y el contenido son los de tu zona, porque Cloudflare sabe qué sitio pides por el nombre, no por la IP. En Globalping se hace lo mismo poniendo la IP como target y tu dominio en request.host:

curl -s -X POST https://api.globalping.io/v1/measurements \
  -H 'Content-Type: application/json' \
  -d '{
    "type": "http",
    "target": "104.18.12.15",
    "locations": [{ "country": "MX", "limit": 20 }],
    "measurementOptions": {
      "protocol": "HTTPS",
      "request": { "method": "HEAD", "host": "tu-dominio.com", "path": "/cdn-cgi/trace" }
    }
  }'

Esto es un diagnóstico, no un arreglo. En el plan Free no eliges qué IPs le tocan a tu zona, y apuntar tu DNS a mano a una IP de Cloudflare que no te asignaron depende de un comportamiento que Cloudflare no documenta ni garantiza: puede dejar de funcionar mañana sin aviso.

Por qué pasa: el plan gratis es el primero en moverse

Cloudflare no lo esconde. En el post donde presentó su Traffic Manager, el sistema que reparte el tráfico cuando un centro de datos se queda corto, lo dice así:

«We move Free customers first, and if there are no more Free customers in a data center, we’ll move Pro, and then Business customers if needed.»

Primero se mueve a los clientes Free; si ya no quedan, a los Pro, y luego a los Business si hace falta.

Y en noviembre de 2024 alguien en el centro de México preguntó en Hacker News por qué sus Workers corrían en Dallas. Le respondió Kenton Varda, ingeniero de Cloudflare y líder técnico de Workers:

«Some of our colos don’t have enough capacity to serve all traffic in their local region, so we selectively serve a subset of sites from that colo and reroute others to a bigger colo further away. […] generally sites on the free plan or lower plan levels are more likely to be rerouted.»

Algunos centros de datos no tienen capacidad para todo el tráfico de su región, así que atienden a una parte de los sitios y mandan a los demás a uno más grande y más lejano, y los sitios en el plan gratuito o en planes bajos tienen más probabilidad de ser los movidos. En la misma respuesta aclara que el ruteo no tiene nada que ver con usar Workers.

Junta las dos citas con la medición y la historia cuadra: los centros de datos de Cloudflare en México existen (vi QRO en el cf-ray y MEX en la prueba de septiembre), pero no les alcanza para todos, y el plan Free es el primero que se va a Texas.

Lo que no sé, porque no lo medí: si pasar la zona a Pro la regresa a México. La prioridad por plan está documentada por Cloudflare, pero eso no garantiza que tu zona en concreto cambie de colo. La única forma de saberlo es pagar un mes y volver a correr el curl de arriba.

Cuánto cuesta en milisegundos, y cuándo importa

La diferencia medida es de unos 25 ms por viaje de ida y vuelta (32 ms contra 7 ms de mediana). Una página cargada en frío, sin conexión abierta, paga varios viajes antes de recibir el primer byte: la conexión TCP, el saludo TLS y la petición misma. Con tres o cuatro viajes, son del orden de 100 ms extra en la primera carga. Las siguientes peticiones reutilizan la conexión y pagan un solo viaje cada una.

¿Es mucho? Depende de qué más está pasando:

• Si tu HTML no se cachea y viaja a tu servidor en cada visita, ese salto pesa más que Dallas. En la medición de septiembre, una página que iba al origen esperaba 75 ms al primer byte; un archivo ya cacheado en el mismo Dallas, 43 ms. Recuerda que Cloudflare no guarda el HTML por defecto, ni en el plan gratuito ni en los de pago; lo expliqué con detalle en la guía para que tu tienda no se caiga en el Buen Fin. Arregla eso primero: es gratis y gana más.
• Si tu servidor está lejos de tus usuarios, el viaje del colo al origen se suma, y ahí Dallas incluso puede quedarte de paso.
• Si tu sitio es estático o casi todo se sirve desde caché, 100 ms en la primera carga rara vez mueven tus Core Web Vitals de «bueno» a «malo». Es una mejora de segundo orden.
• Donde sí importa: aplicaciones que hacen muchas peticiones en serie (un panel que llama a la API diez veces para pintar una pantalla, un checkout con varios pasos) o APIs consumidas desde México con muchas llamadas cortas. Ahí los 25 ms se multiplican.

Para comparar con otros proveedores, en la medición del 22 de septiembre con las mismas sondas:

Ojo con Vercel y Netlify: el tcp sale bajo porque abren la conexión cerca, pero el cifrado y la caché se resuelven en una región de Estados Unidos. Si mides esos, mira el tiempo de tls, no el de tcp.

¿Lo cambió la Birthday Week 2026? No

Cloudflare cerró su semana de aniversario el 2 de octubre con un post de rendimiento de red que dice que es el proveedor más rápido en el 74 % de las 1,000 redes más grandes del mundo, contra 60 % en abril. Leído rápido, parece contradecir lo de arriba. No lo contradice, porque mide otra cosa:

• Mide el tiempo de conexión TCP (con un promedio recortado, trimean) desde el navegador del usuario hacia endpoints de varios proveedores, lanzado desde las páginas de error y las Challenge Pages de Cloudflare.
• No distingue planes. Mide contra los endpoints de Cloudflare, no contra tu zona Free.
• No menciona México. Y en los posts de la semana que revisé, ninguno toca el ruteo por plan ni la capacidad de los centros de datos de la región.

Las dos cosas pueden ser ciertas a la vez: Cloudflare puede ser el más rápido hacia sus propios endpoints desde una red mexicana, y tu dominio en el plan gratuito puede seguir saliendo por Dallas. Mi medición de hoy es posterior a todos esos anuncios y salió igual que la de septiembre.

Lo que sí te sirve de la Birthday Week en el plan Free

De los anuncios de la semana, estos son los que aplican a una cuenta gratuita:

• Protected Quick Tunnels. Los túneles rápidos de cloudflared (desde la versión 2026.9.3) aceptan una lista de correos: solo esas personas abren el enlace, con un PIN de un solo uso que les llega por correo. Ni tú ni tu cliente necesitan cuenta de Cloudflare. Para enseñarle un avance a un cliente sin subirlo a un servidor ni dejar un túnel abierto a cualquiera (anuncio):

  cloudflared tunnel --url http://localhost:8080 --allowed-mail [email protected]
  

• Observability unificada, con precio nuevo desde el 1 de diciembre de 2026. En el plan Free tendrás 0.5 GB al día de ingesta de logs y 7 días de retención. Además, la analítica de dominio llega a 30 días y Logpush se abre a los planes de autoservicio (anuncio). Si hoy dependes de logs de Workers, revisa cuánto generas antes de esa fecha.

• AI Search es GA desde el 1 de octubre y empieza a cobrar el 1 de noviembre. Si lo montaste en la versión preliminar pensando que era gratis, revisa la página de precios antes de esa fecha.

Nada de eso cambia por dónde se sirve tu sitio, pero son cambios con fecha que te tocan aunque no pagues.

Qué haría yo

1. Medir antes de decidir. Corre el comando de Globalping contra tu dominio, con sondas en las ciudades donde están tus usuarios. Si sale DFW con ~30 ms, ya sabes cuánto estás pagando; si sale QRO o MEX, este post no es para ti (todavía: el ruteo es dinámico y puede cambiar sin aviso).
2. Quitar primero el salto al origen. Cachea el HTML que se pueda en el borde. Esa mejora es más grande que la de Dallas a Querétaro y no cuesta nada.
3. Decidir por número. Si después de eso tu caso es de los que sí importan (muchas peticiones en serie, usuarios casi todos en México), hay CDNs que en mis pruebas respondieron desde México. Pruébalos con el mismo método y compara milisegundos, no promesas de marketing. Y si quieres probar un plan de pago de Cloudflare, mídelo antes y después: es la única forma de saber si a tu zona le toca otro colo.
4. Volver a medir de vez en cuando. Lo que medí hoy puede no ser cierto en tres meses. El comando tarda un minuto.

Preguntas frecuentes

¿Cloudflare tiene servidores en México?

Sí. En mis mediciones vi responder a centros de datos de Cloudflare en Querétaro (QRO, en el encabezado cf-ray, el 4 de octubre de 2026) y en la Ciudad de México (MEX, el 22 de septiembre de 2026). Que existan no significa que atiendan a tu sitio: cuando les falta capacidad, Cloudflare manda una parte del tráfico a centros de datos más grandes y lejanos, y mueve primero a los sitios del plan gratuito.

¿El plan gratis de Cloudflare es más lento en México?

En mi medición del 4 de octubre de 2026, un dominio de prueba en el plan Free respondió desde Dallas a las 19 sondas mexicanas que contestaron, con una conexión TCP mediana de 32 ms; la misma zona forzada a una IP que se anuncia desde México respondió con 7 ms. Son unos 25 ms por viaje y del orden de 100 ms en una carga en frío. Cloudflare documenta que mueve primero a los clientes Free cuando un centro de datos se queda sin capacidad. No probé si un plan de pago lo cambia.

¿Cómo sé desde qué ciudad me sirve Cloudflare?

Ejecuta curl -s https://tu-dominio.com/cdn-cgi/trace | grep colo y mira el código: DFW es Dallas, QRO Querétaro, MEX Ciudad de México. El mismo código aparece al final del encabezado cf-ray. Eso te dice desde dónde te sirven a ti; para medir desde otras ciudades usa la API pública de Globalping con sondas en el país que te interese, sin registro.

¿Usar Cloudflare Workers cambia el centro de datos que atiende mi sitio?

No. Kenton Varda, de Cloudflare, lo aclaró en Hacker News a un usuario del centro de México cuyos Workers corrían en Dallas: el ruteo depende de la capacidad de cada centro de datos y del plan, y no tiene nada que ver con usar Workers.