Guía completa de despliegue Astro en Cloudflare: configuración SSR y latencia 3 veces menor

La semana pasada ayudé a un amigo a desplegar su blog Astro y surgió un problema curioso. Tras subirlo a Cloudflare Pages, lo probé desde el extranjero: la página cargaba al instante, experiencia fluidísima. Pero cuando sus amigos en China lo abrieron, tardó casi 5 segundos en cargar. Incómodo.

Cloudflare presume de más de 300 centros de datos en todo el mundo, con ancho de banda gratis e ilimitado. ¿Por qué entonces el acceso desde China es tan lento? Este problema atormenta a muchos desarrolladores. Seguro que has oído hablar de la «IP optimizada», pero ¿cómo se hace en la práctica, hay riesgo de bloqueo y qué resultado da de verdad?

En este artículo recorreremos el flujo completo de despliegue Astro en Cloudflare: desde el sitio estático básico hasta la configuración SSR y la optimización de acceso desde China. He pisado bastantes trampas; aquí dejo la experiencia para que evites los mismos errores.

Aprenderás:

• Desplegar de cero a producción en 20 minutos
• Entender los tres modos del adaptador SSR sin dudas
• Dominar 3 estrategias de optimización de acceso con latencia 3 veces menor

Sin más rodeos, empecemos.

Por qué elegir Cloudflare Pages

Cloudflare vs Vercel: comparativa de plataformas de hosting gratuito

Mucha gente me pregunta: ¿Vercel o Cloudflare? En pocas palabras, depende de lo que necesites.

La diferencia en límite de ancho de banda es la más visible. El plan gratuito de Vercel ofrece 100 GB/mes; el exceso se cobra a $40 por cada 100 GB. Tuve un proyecto que de repente entró en tendencia, el tráfico se disparó y recibí la factura de Vercel; dolió. Cloudflare Pages, en cambio, ofrece ancho de banda ilimitado gratis. Para desarrolladores individuales es muy amigable: no tienes que preocuparte por cargos por pico de tráfico.

En rendimiento global, Cloudflare tiene más de 300 centros de datos con cobertura más amplia. Probé varios puntos en Europa, Asia y América; la latencia fue baja en todos. La red edge de Vercel también es buena, pero con menos nodos. Si tus usuarios están repartidos por el mundo, Cloudflare tiene ventaja.

Otra ventaja muy concreta: protección DDoS. El plan gratuito de Cloudflare incluye protección DDoS sin configuración adicional. En un ataque anterior, Cloudflare lo bloqueó automáticamente y ni siquiera vi los logs. Vercel también tiene protección, pero en el plan gratuito protege principalmente su propia red, no ofrece protección profunda dedicada a tu sitio.

¿Qué ventajas tiene Vercel? La caché de builds está muy bien resuelta. Si tu proyecto tiene muchas imágenes o dependencias, Vercel conserva la caché del build anterior y la segunda compilación tarda 3-4 minutos. Cloudflare Pages reconstruye desde cero cada vez, 15 minutos o más. También está la integración profunda con Next.js: si usas Next.js, Vercel sigue siendo la mejor opción.

Mi recomendación:

• Blog Astro estático → Cloudflare Pages (mucho tráfico gratis)
• Proyectos con tráfico impredecible → Cloudflare Pages (evitas cargos por exceso)
• Usuario avanzado de Next.js → Vercel (mejor experiencia)
• Iteración rápida y builds frecuentes → Vercel (caché de builds más rápida)

Cloudflare Pages vs Workers: novedades de 2025

Al principio yo también me lié. Cloudflare tiene Pages y Workers, ambos sirven para desplegar Astro. ¿Cuál usar?

La diferencia esencial es sencilla. Workers es la plataforma serverless de Cloudflare; puedes ejecutar código JavaScript en el edge. Pages se puede entender como Workers + herramienta de build automatizada. Pages sigue ejecutándose sobre Workers, pero ofrece integración con Git y despliegue automático listo para usar.

La novedad de 2025 es que Cloudflare recomienda Workers en lugar de Pages para proyectos nuevos. Revisé el blog oficial: Workers ofrece más flexibilidad y control más fino. Para usuarios de Astro, esta recomendación no hay que tomarla al pie de la letra.

Mi experiencia real:

• Método Pages: conectas el repositorio de GitHub, cada push dispara el build automáticamente; simple y directo. Ideal para quien quiere desplegar rápido sin complicaciones.
• Método Workers: requiere despliegue manual con Wrangler CLI y configurar wrangler.jsonc. Permite control más fino de variables de entorno, bindings KV, etc.

¿Qué elegir para un proyecto Astro?

• Sitio estático puro (output: ‘static’): Pages conectado a GitHub desde el Dashboard es lo más cómodo
• Sitio SSR (output: ‘server’ o ‘hybrid’): ambos valen, pero recomiendo Pages + Wrangler CLI para combinar automatización y flexibilidad

En pocas palabras: si es tu primer despliegue, prueba primero la integración Git de Pages; en minutos verás resultados. Wrangler CLI puede esperar.

Flujo completo de despliegue Astro en Cloudflare

Despliegue de sitio estático: primeros pasos en 5 minutos

Si tu proyecto Astro es totalmente estático (blog, documentación, portfolio), el despliegue es muy sencillo. Te guío paso a paso.

Requisitos previos:

• El proyecto ya está en GitHub
• Tienes cuenta de Cloudflare (si no, regístrate; es gratis)

Pasos concretos:

1. Inicia sesión en Cloudflare Dashboard
   Abre dash.cloudflare.com y entra en Workers & Pages en el menú lateral.

2. Crea un proyecto nuevo
   Haz clic en Create application (arriba a la derecha) → elige Pages → Connect to Git.

3. Conecta el repositorio de GitHub
   Selecciona el repositorio de tu proyecto Astro. La primera vez puede que tengas que autorizar a Cloudflare en GitHub; sigue las indicaciones.

4. Configura el build
   Este paso es clave; si lo rellenas mal, el despliegue falla. Configura así:

   • Framework preset: elige Astro (rellena los comandos automáticamente)
   • Build command: npm run build
   • Build output directory: dist
   • Root directory: déjalo vacío si el proyecto está en la raíz del repositorio; si está en un subdirectorio, indica la ruta

5. Despliega
   Haz clic en Save and Deploy y espera unos minutos. Cloudflare descargará el código, instalará dependencias, compilará y desplegará.

Si el build tiene éxito, obtendrás un dominio your-project.pages.dev; ábrelo y verás tu sitio. Cada push a GitHub disparará un build automático en Cloudflare.

Problemas frecuentes:

• Build fallido por versión incorrecta de Node.js: añade un archivo .nvmrc o .node-version en la raíz del proyecto con 18 o 20. Cloudflare lo detectará automáticamente.
• Página 404: comprueba que Build output directory sea dist. Algunas configuraciones usan public o build; ajústalo según tu astro.config.mjs.
• Build con timeout: puede deberse a demasiadas dependencias o problemas de red; vuelve a desplegar; normalmente la segunda vez funciona.

Vincular dominio personalizado (opcional):

Tras el despliegue, en la configuración del proyecto busca Custom domains, haz clic en Set up a custom domain e introduce tu dominio (por ejemplo blog.yourdomain.com). Cloudflare te dará un registro CNAME para añadir en tu proveedor DNS. Si el dominio ya está en Cloudflare DNS, se configura automáticamente, aún más simple.

Despliegue SSR: configuración detallada del adaptador @astrojs/cloudflare

La parte SSR me confundió al principio; la documentación oficial está bastante dispersa. Aquí explico cada paso en el orden real de operación.

¿Cuándo necesitas SSR?

Primero aclaremos el escenario para que sepas si lo necesitas:

• Datos en tiempo real: comentarios, estadísticas de visitas, inicio de sesión, etc.
• Lógica en servidor: llamadas a API, consultas a base de datos, verificación de permisos
• Renderizado bajo demanda: contenido masivo que no quieres prerenderizar todo como estático

Si solo tienes un blog con artículos en Markdown, no necesitas SSR; el despliegue estático basta.

Paso 1: instalar el adaptador @astrojs/cloudflare

Railway - Plataforma de despliegue moderna, sin ops complejas, en producción en minutos

Empezar ahora →Anuncio

En la raíz del proyecto ejecuta:

npx astro add cloudflare

Este comando hace tres cosas automáticamente:

1. Instala el paquete @astrojs/cloudflare
2. Modifica astro.config.mjs y añade la configuración del adaptador
3. Crea wrangler.jsonc (archivo de configuración de Cloudflare Workers)

Tras ejecutarlo, tu astro.config.mjs quedará más o menos así:

import { defineConfig } from 'astro/config';
import cloudflare from '@astrojs/cloudflare';

export default defineConfig({
  output: 'server', // Esta línea es nueva
  adapter: cloudflare(),
});

Paso 2: elegir el modo de renderizado (¡importante!)

Aquí hay tres opciones y mucha gente se atasca. Te lo explico con detalle:

1. output: 'server' — SSR en todo el sitio

• Todas las páginas se renderizan en servidor
• Ideal para: aplicaciones basadas en datos, contenido que se actualiza con frecuencia
• Desventaja: cada solicitud requiere renderizado; rendimiento algo menor

2. output: 'hybrid' — modo híbrido (recomendado)

• Por defecto todas las páginas son estáticas
• Páginas concretas pueden elegir SSR
• Ideal para: blogs mayormente estáticos con pocas funciones dinámicas
• Ventaja: máxima flexibilidad y mejor rendimiento

3. output: 'static' — estático puro

• No requiere adaptador; es el despliegue estático descrito antes

Mi recomendación: en el 90 % de los casos elige hybrid, salvo que estés seguro de que todo el sitio necesita SSR.

Ejemplo de uso del modo hybrid:

// astro.config.mjs
export default defineConfig({
  output: 'hybrid', // Cambiar a hybrid
  adapter: cloudflare(),
});

Luego, en las páginas que necesiten SSR, añade una línea:

// src/pages/api/comments.js
export const prerender = false; // Esta página usará SSR

export async function GET() {
  // Obtener comentarios desde la base de datos
  const comments = await fetchComments();
  return new Response(JSON.stringify(comments));
}

El resto de páginas siguen siendo estáticas por defecto; no hace falta tocarlas.

Paso 3: configurar bindings de servicios Cloudflare (opcional)

Si necesitas KV, D1 o R2, configura los bindings en wrangler.jsonc.

Por ejemplo, para guardar sesiones de usuario en KV:

// wrangler.jsonc
{
  "name": "my-astro-app",
  "compatibility_date": "2024-01-01",
  "kv_namespaces": [
    {
      "binding": "MY_KV",
      "id": "your-kv-namespace-id"
    }
  ]
}

Primero crea un KV namespace en Cloudflare Dashboard, copia el ID y pégalo aquí.

Luego en el código:

// src/pages/api/session.js
export const prerender = false;

export async function GET({ locals }) {
  const { MY_KV } = locals.runtime.env;
  const sessionData = await MY_KV.get('user:123');
  return new Response(sessionData);
}

Paso 4: desarrollo y pruebas locales

Instala Wrangler CLI (herramienta oficial de Cloudflare):

npm install wrangler --save-dev

Ejecución local:

npm run build
npx wrangler pages dev ./dist

Esto levanta un servidor local que simula el entorno Cloudflare; puedes probar SSR y bindings.

Paso 5: despliegue a producción

Dos formas:

Forma 1: despliegue con Wrangler CLI (recomendado; control más fino)

# Iniciar sesión en Cloudflare
npx wrangler login

# Compilar el proyecto
npm run build

# Desplegar
npx wrangler pages deploy ./dist

En el primer despliegue te pedirá el nombre del proyecto; después es un solo comando.

Forma 2: despliegue automático con integración Git

Igual que el despliegue estático: conecta el repositorio de GitHub y Cloudflare detectará el adaptador @astrojs/cloudflare. Pero con este método los bindings KV y similares hay que configurarlos manualmente en el Dashboard, algo más engorroso.

Solución de errores frecuentes:

1. “Hydration completed but contains mismatches”
   Este error es bastante común: la función Auto Minify de Cloudflare comprime el HTML de forma incorrecta.
   Solución: Cloudflare Dashboard → tu dominio → Speed → Optimization; desactiva HTML, CSS y JS en Auto Minify.

2. “Cannot find module ‘MY_KV’”
   El binding no está bien configurado. Comprueba que el nombre binding en wrangler.jsonc coincida con el del código.

3. Error 500 tras el despliegue
   Revisa Cloudflare Dashboard → Workers & Pages → tu proyecto → Logs (logs en tiempo real) para ver el error concreto. Lo más probable es que el código acceda a un recurso sin binding configurado.

Variables de entorno y gestión de secretos

Las variables de entorno confunden a mucha gente; yo mismo subí una API key a GitHub por error y tuve que revertirlo rápido. Aquí va la forma correcta.

Entorno de desarrollo local:

Crea un archivo .dev.vars en la raíz del proyecto (nota el punto al inicio):

# .dev.vars
DATABASE_URL=postgres://localhost:5432/mydb
API_KEY=your-secret-key-for-dev

Importante: añade .dev.vars a .gitignore; no lo subas a GitHub.

En desarrollo local, Wrangler lee este archivo automáticamente. En el código accedes así:

export const prerender = false;

export async function GET({ locals }) {
  const apiKey = locals.runtime.env.API_KEY;
  // Usar apiKey para llamar a la API de terceros
}

Entorno de producción:

No uses .dev.vars; configura en Cloudflare Dashboard.

Pasos:

1. Entra en Workers & Pages → selecciona tu proyecto
2. Haz clic en Settings → Environment Variables
3. Haz clic en Add variable, introduce nombre y valor
4. Elige el entorno (Production o Preview)

Datos sensibles con Secrets:

Para información muy sensible (por ejemplo, claves de API de pago), usa Secrets de Cloudflare; se almacenan cifrados:

npx wrangler secret put API_KEY

Tras ejecutarlo te pedirá el valor; no se muestra en la terminal, más seguro.

Mi recomendación:

• URL de base de datos, claves de API de terceros → Secrets
• Configuración pública (nombre del sitio, URL del CDN) → variables de entorno normales

Optimización de velocidad de acceso desde China

Diagnóstico: medir la velocidad real de tu sitio en China

Tras el despliegue, no te apresures a optimizar; mide primero la velocidad real. No todos los sitios lo necesitan; si tus usuarios están principalmente fuera de China, la configuración por defecto de Cloudflare suele bastar.

Herramientas de medición online:

Alibaba Cloud - Opción preferida para desarrolladores, 15 % de descuento exclusivo en Lighthouse

Obtener 15% dto. →Anuncio

1. 17ce.com (recomendado)
   Abre 17ce.com, introduce tu dominio y elige «prueba de velocidad de sitio web». Prueba desde distintas provincias y operadores de China. Fíjate en la columna «tiempo de respuesta»: si suele estar por debajo de 200 ms, está bien; por encima de 300 ms conviene optimizar.

2. Herramienta Ping de Chinaz
   tool.chinaz.com/speedtest, funcionalidad similar, con información de ruta más detallada.

Prueba local:

Si estás en China, puedes usar las herramientas de desarrollo de Chrome:

1. Pulsa F12 para abrir DevTools
2. Cambia a la pestaña Network
3. Recarga la página y mira el valor Time de la primera solicitud

Criterios de evaluación:

• Latencia < 150 ms: muy bien, no hace falta optimizar
• Latencia 150-250 ms: aceptable, según tus necesidades
• Latencia > 250 ms o tiempo de carga > 3 s: conviene optimizar

¿Por qué es lento en China?

En resumen, Cloudflare usa tecnología Anycast; el entorno de red en China es especial y el enrutamiento a menudo da rodeos. Por ejemplo, desde Pekín el tráfico puede ir primero a Hong Kong y volver, con latencia alta. La IP optimizada y el CNAME buscan nodos con rutas más directas.

Opción 1: usar IP optimizada (gratis, mejor resultado)

Es la opción con resultado más visible; en mis pruebas la latencia bajó de 280 ms a unos 70 ms. Requiere algo más de manos a la obra y conlleva cierto riesgo, que comentaré después.

¿Qué es la IP optimizada?

Cloudflare tiene cientos de direcciones IP; cada una corresponde a un centro de datos distinto. Desde China, la velocidad varía mucho: unas van por rutas largas y son lentas, otras son directas y rápidas. La IP optimizada consiste en encontrar las rápidas y hacer que tu dominio resuelva directamente a ellas.

Paso 1: probar IP optimizada

Usa la herramienta CloudflareSpeedTest, disponible en GitHub: XIU2/CloudflareSpeedTest

En Windows descarga CloudflareST.exe; en Linux/Mac la versión correspondiente.

Ejecución (Windows):

# Doble clic o ejecución desde terminal
CloudflareST.exe

La herramienta prueba automáticamente cientos de IP de Cloudflare; tarda unos 5-10 minutos. Al terminar muestra la lista de IP más rápidas, por ejemplo:

Dirección IP    Latencia    Velocidad de descarga
104.16.160.10   68ms        15.2MB/s
172.64.32.5     75ms        14.8MB/s
104.23.240.28   82ms        13.9MB/s

Anota la primera IP (la de menor latencia).

Paso 2: modificar la resolución DNS

Requisito importante: el DNS de tu dominio no puede estar en Cloudflare; debe estar en otro proveedor (Alibaba Cloud, DNSPod, etc.). Si ahora está en Cloudflare DNS, primero hay que trasladarlo.

¿Por qué? Porque Cloudflare DNS fuerza Anycast; cambiar el registro A no sirve.

Configuración (ejemplo con DNSPod):

1. Inicia sesión en tu proveedor DNS

2. Busca tu dominio y añade o modifica un registro A:

   • Host: @ (dominio raíz) o www
   • Tipo: A
   • Valor: 104.16.160.10 (tu IP optimizada)
   • TTL: 600 (10 minutos)

3. Guarda y espera la propagación (normalmente 5-10 minutos)

Paso 3: verificar el resultado

Cuando el DNS esté activo, vuelve a medir con 17ce.com; deberías ver una mejora clara.

Advertencia de riesgo (¡importante!):

En enero de 2025, Cloudflare actualizó sus términos de servicio con una cláusula sobre posibles restricciones o sanciones por «uso indebido». No dice explícitamente si la IP optimizada cuenta, pero hay riesgo.

Mi recomendación:

• Blog personal, proyecto pequeño: se puede usar; el riesgo es bajo
• Sitio comercial con mucho tráfico: con cautela; mejor opción 2 (CNAME) u opción 3 (resolución por región)
• Revisión periódica: la IP puede dejar de funcionar; mide cada uno o dos meses y cambia si hace falta

Problemas frecuentes:

1. El cambio DNS no surte efecto

   • Limpia la caché del navegador o prueba en modo incógnito
   • Comprueba que el DNS esté activo con nslookup yourdomain.com

2. La IP optimizada vuelve a ser lenta tras un tiempo

   • La IP puede haber dejado de funcionar; vuelve a medir y cambia

3. Rápido en algunas regiones, lento en otras

   • La IP óptima varía por operador (telecom/unicom/mobile); la opción 3 (resolución por línea) lo resuelve

Opción 2: usar dominio CNAME optimizado (gratis, más estable)

Si medir IP te parece engorroso o te preocupa que caduquen con frecuencia, puedes usar dominios CNAME públicos optimizados. Detrás hay IP optimizadas que otros mantienen y actualizan periódicamente; mucho más cómodo.

Principio:

Algunos desarrolladores u organizaciones montan un dominio que prueba y resuelve periódicamente a la IP optimizada más reciente. Solo tienes que hacer CNAME de tu dominio al suyo para obtener la aceleración.

Paso 1: elegir un CNAME público

Dominios CNAME públicos habituales (solo ejemplos; prueba antes de usar):

• cdn.cloudflare.quest
• cf.xiu2.xyz

Nota: los CNAME públicos pueden dejar de funcionar en cualquier momento; conviene unirse a comunidades o grupos de Telegram para obtener dominios actualizados.

Paso 2: modificar la resolución DNS

Igual que antes, el DNS del dominio no puede estar en Cloudflare. Configuración (ejemplo con DNSPod):

1. Inicia sesión en el proveedor DNS

2. Añade un registro CNAME:

   • Host: @ o www
   • Tipo: CNAME
   • Valor: cdn.cloudflare.quest (el dominio público que elijas)
   • TTL: 600

3. Guarda y espera la propagación

Paso 3: resolver posible error 403

Con CNAME es fácil encontrar error 403 Forbidden: Cloudflare detecta que tu dominio no está registrado en su sistema pero accede por su IP.

Solución:

1. Traslada el DNS del dominio fuera de Cloudflare (si aún está ahí)
2. Elimina el sitio en Cloudflare Dashboard
3. Espera unos minutos y vuelve a acceder; debería funcionar

Paso 4: verificar el resultado

Cuando el CNAME esté activo, usa nslookup yourdomain.com para comprobar que resuelve al dominio CNAME público y luego mide la velocidad.

Comparativa de pros y contras:

• Ventajas:

  • No tienes que medir IP tú mismo
  • Los mantenedores actualizan periódicamente; más estable
  • Riesgo algo menor que usar IP optimizada directamente

• Desventajas:

  • Dependes de terceros; si dejan de mantenerlo, tú también te quedas sin servicio
  • La velocidad puede ser inferior a una IP que midas tú (no está optimizada específicamente para ti)

Mi recomendación: ideal para quien quiere optimizar sin complicarse demasiado; buena relación esfuerzo-resultado.

KiloClaw - OpenClaw gestionado para empresas: orquestación de agentes IA y enrutamiento inteligente

Empezar →Anuncio

Opción 3: resolución por línea (DNS de pago, mejor resultado)

Es la solución definitiva: mejor resultado, pero con algo de costo. Ideal para sitios con usuarios en China y en el extranjero que exigen buena velocidad.

Idea central:

Devolver IP distintas según la región del usuario. Por ejemplo:

• Usuarios telecom en China → IP optimizada telecom
• Usuarios unicom en China → IP optimizada unicom
• Usuarios en el extranjero → dirección Cloudflare por defecto (o your-project.pages.dev)

Así cada uno accede por la ruta óptima.

Herramientas necesarias:

Proveedores DNS con resolución inteligente, por ejemplo:

• DNSPod (Tencent Cloud; plan personal gratuito con funciones básicas)
• Alibaba Cloud DNS (de pago, pero muy potente)
• Cloudflare DNS (no admite líneas en China; no sirve para este escenario)

Configuración (ejemplo con DNSPod):

1. Probar IP optimizada por operador

   Con CloudflareSpeedTest, mide en redes telecom, unicom y mobile por separado y anota la IP más rápida. O usa estos rangos habituales (medir tú mismo es más fiable):

   • Telecom: 104.16.160.0/24
   • Unicom: 104.23.240.0/24
   • Mobile: 172.64.32.0/24

2. Configurar resolución por línea

   En DNSPod, añade varios registros A, cada uno con distinto «tipo de línea»:

   Registro 1:
   - Host: @
   - Tipo: A
   - Línea: Telecom
   - Valor: 104.16.160.10

   Registro 2:
   - Host: @
   - Tipo: A
   - Línea: Unicom
   - Valor: 104.23.240.5

   Registro 3:
   - Host: @
   - Tipo: A
   - Línea: Mobile
   - Valor: 172.64.32.8

   Registro 4 (línea por defecto, usuarios en el extranjero):
   - Host: @
   - Tipo: CNAME
   - Línea: Por defecto
   - Valor: your-project.pages.dev
   

3. Guarda y espera la propagación

Resultado:

Con resolución por línea, usuarios de distintos operadores en China acceden al nodo más rápido; usuarios en el extranjero usan Cloudflare nativo. Todos quedan cubiertos.

Costo:

• DNSPod plan personal: gratis (resolución por línea básica)
• DNSPod plan profesional: 20 yuanes/mes (resolución por región más fina)
• Alibaba Cloud DNS: facturación por consultas; sitios pequeños, unos yuanes al mes

Mi recomendación: si tu sitio supera 10 000 visitas mensuales, merece la pena invertir este costo; la mejora de experiencia es notable.

Comparativa de resultados y monitorización

Tantas opciones, ¿qué resultado dan? Comparo con datos reales.

Comparativa de velocidad antes y después (blog de prueba, red telecom en Pekín):

Como ves, tras optimizar la velocidad mejora 3-5 veces; la experiencia de usuario cambia por completo.

Monitorización a largo plazo:

Optimizar no es el final; conviene monitorizar porque la IP puede dejar de funcionar.

Herramientas recomendadas:

1. UptimeRobot (uptimerobot.com)

   • Monitorización gratuita de 50 sitios
   • Ping cada 5 minutos; aviso por email si cae
   • Muestra tendencia de tiempo de respuesta

2. Cloudflare Analytics

   • Incluido en Cloudflare Dashboard, gratis
   • Origen de visitas, uso de ancho de banda, tasa de errores
   • No muestra latencia concreta en China

3. Better Uptime (betteruptime.com)

   • De pago, con plan gratuito
   • Puedes crear página de estado pública para generar confianza

Cuándo ajustar la IP optimizada:

Configura un recordatorio para revisar cada 1-2 meses:

1. Mide con 17ce.com; si la latencia sube claramente
2. Si supera 200 ms, vuelve a ejecutar CloudflareSpeedTest y cambia la IP
3. Actualiza el registro DNS

En mi experiencia, la IP suele fluctuar notablemente cada 2-3 meses; basta con cambiarla a tiempo.

Conclusión

Resumiendo los puntos clave.

En el flujo de despliegue, Cloudflare Pages hace muy fácil desplegar Astro. Sitio estático puro: conecta GitHub y en minutos está listo. Si necesitas SSR, npx astro add cloudflare configura todo de un golpe; elige hybrid o server, estático donde toca y dinámico donde haga falta: flexible y eficiente.

En configuración SSR, recuerda:

• En el 90 % de los casos, hybrid es la mejor opción
• Si necesitas KV/D1/R2, configura bindings en wrangler.jsonc
• Desarrollo local con .dev.vars; producción con variables en Dashboard
• Si aparece error de Hydration, desactiva Auto Minify

En optimización de acceso desde China, cada opción tiene su escenario:

• Opción 1 (IP optimizada): mejor resultado, gratis, pero requiere mantenimiento y conlleva cierto riesgo
• Opción 2 (CNAME público): cómoda, gratis, resultado moderado; ideal si no quieres complicarte
• Opción 3 (resolución por línea): solución definitiva, costo mínimo, atiende China y extranjero

Mi recomendación:

• Blog personal con poco tráfico → opción 1 u opción 2
• Mucho tráfico y alta exigencia de experiencia → opción 3
• Proyecto comercial → usa IP optimizada con cautela; prioriza opción 3 o acepta la velocidad por defecto

Próximos pasos:

Si aún no has empezado:

1. Crea una cuenta de Cloudflare, prueba un despliegue estático y comprueba la velocidad
2. Si el acceso desde China es lento, mide primero con 17ce.com y decide si optimizar
3. Tras optimizar, configura un recordatorio para revisar periódicamente si la IP sigue siendo válida

Aprendizaje avanzado:

El despliegue es solo el primer paso; el ecosistema Cloudflare tiene muchas funciones potentes:

• Workers KV: almacenamiento clave-valor, ideal para caché y sesiones
• D1: base de datos SQLite que corre directamente en el edge
• R2: almacenamiento de objetos comparable a AWS S3, con generosa cuota gratuita
• Pages Functions: funciones serverless directamente en Pages

Todo se integra sin fricciones con Astro; puedes explorarlo poco a poco.

Por último, si este artículo te ha ayudado, comparte en los comentarios tu experiencia de despliegue o las trampas que hayas encontrado; aprendemos todos juntos.