Cómo Funciona un Sistema de Caché de Contenido (CDN): Guía Completa 2026

📘 Este artículo forma parte de nuestra Guía Completa de Redes 2026 y complementa a Beneficios del uso de CDN para la seguridad y rendimiento de aplicaciones web. Si quieres dominar la infraestructura web, esas guías son tu punto de partida.

Introducción

Cada vez que abres una web moderna —Netflix, Amazon, Spotify, YouTube, o prácticamente cualquier sitio grande— hay un sistema invisible trabajando a toda velocidad para servirte el contenido en milisegundos. Ese sistema es la CDN (Content Delivery Network), y su componente clave es el caché de contenido.

Una CDN bien configurada puede reducir el tiempo de carga de una web un 60-80%, disminuir la carga del servidor origen un 90%, y proteger contra ataques DDoS masivos. En 2026, usar una CDN ya no es opcional: es estándar.

En esta guía completa vas a aprender:

Qué es una CDN y qué problema resuelve.
Cómo funciona el caché por dentro.
Qué se puede cachear (y qué no).
Tipos de caché (browser, proxy, edge, origin).
Headers HTTP de caché (Cache-Control, ETag, Expires).
Estrategias de caché (TTL, invalidación, cache busting).
Cómo configurar una CDN paso a paso.
Optimización para máximo rendimiento.
Solución de problemas comunes.
FAQ con las preguntas más frecuentes.

Si quieres ver los beneficios de seguridad y rendimiento, consulta Beneficios del uso de CDN. Para configuración avanzada de servidores, nuestra Guía Completa de Servidores.

Índice de contenidos

Qué es una CDN
El problema que resuelve
Cómo funciona el caché por dentro
Tipos de caché
Qué se puede cachear (y qué no)
Headers HTTP de caché
Estrategias de caché
Cómo configurar una CDN
Optimización avanzada
Solución de problemas
FAQ
Conclusión

1. Qué es una CDN

Una CDN (Content Delivery Network) es una red de servidores distribuidos geográficamente que sirven contenido estático (y a veces dinámico) a los usuarios desde el servidor más cercano a su ubicación.

1.1 Características principales

Distribución geográfica: servidores en múltiples regiones.
Caché: contenido almacenado temporalmente en cada servidor.
Anycast: la misma IP sirve desde distintas ubicaciones.
Edge computing: procesamiento cerca del usuario.
Failover: si un servidor falla, otro toma el relevo.

1.2 PoPs (Points of Presence)

Cada CDN tiene PoPs (Puntos de Presencia) distribuidos por el mundo.

CDN	PoPs aproximados
Cloudflare	330+
Akamai	4.000+
AWS CloudFront	600+
Fastly	300+
Bunny CDN	120+

1.3 Cómo decide el usuario más cercano

Anycast: múltiples servidores comparten la misma IP. El enrutamiento de internet lleva al usuario al más cercano.

GeoDNS: el DNS resuelve a la IP del PoP más cercano al usuario.

Ambos combinados en CDNs modernas.

1.4 Historia breve

1995: Akamai inventa la CDN.
2000s: CDNs se popularizan (Netflix, YouTube).
2010s: Cloudflare democratiza el acceso.
2020s: CDN + Edge Computing + WAF.
2026: estándar absoluto.

Consulta Guía Completa de Redes para el contexto general.

2. El problema que resuelve

2.1 Latencia

Latencia: tiempo que tarda la información en viajar.

Ejemplo sin CDN:

Servidor origen en Madrid.
Usuario en Tokio.
Distancia: ~10.000 km.
Latencia mínima: ~150 ms por paquete.
Página con 100 recursos: 15 segundos solo en latencia.

Con CDN:

PoP de la CDN en Tokio.
Latencia: ~5-20 ms.
Página con 100 recursos: 1-2 segundos.

2.2 Carga del servidor

Sin CDN:

Todos los usuarios van al servidor origen.
Saturación con tráfico alto.
Escalado vertical necesario (caro).

Con CDN:

80-95% de peticiones servidas desde caché.
Servidor origen solo procesa lo no cacheado.
Escalado horizontal (más barato).

2.3 Ataques DDoS

Sin CDN:

El ataque llega directamente al servidor.
Saturación de ancho de banda.
Servicio caído.

Con CDN:

La CDN absorbe el ataque.
Distribuido entre cientos de PoPs.
El origen nunca ve el ataque.

2.4 Disponibilidad

Sin CDN:

Si el servidor cae, la web cae.
Sin redundancia geográfica.

Con CDN:

Contenido cacheado sigue sirviéndose.
Failover automático entre PoPs.
Alta disponibilidad.

2.5 Costes

Sin CDN:

Servidor potente necesario.
Ancho de banda caro.
Escalado costoso.

Con CDN:

Servidor más modesto.
Ancho de banda distribuido.
Coste predecible.

Consulta Beneficios del uso de CDN.

3. Cómo funciona el caché por dentro

3.1 El flujo de una petición

Usuario → DNS → PoP de CDN → ¿Está en caché?
                              │
                              ├─ SÍ → Devuelve desde caché
                              │
                              └─ NO → Solicita al origen → Cachea → Devuelve

Usuario → DNS → PoP de CDN → ¿Está en caché?
                              │
                              ├─ SÍ → Devuelve desde caché
                              │
                              └─ NO → Solicita al origen → Cachea → Devuelve

3.2 Paso a paso

1. El usuario pide un recurso:

GET /style.css HTTP/1.1
Host: example.com

GET /style.css HTTP/1.1
Host: example.com

2. DNS resuelve a la CDN:

La CDN tiene un PoP cercano al usuario.

3. La CDN comprueba su caché:

¿Tengo /style.css cacheado?
¿Está vigente (no expirado)?

4. Cache HIT:

Si está cacheado y vigente → devuelve desde caché.
Tiempo: 5-20 ms.

5. Cache MISS:

Si no está → solicita al servidor origen.
El origen devuelve el recurso.
La CDN lo cachea.
Lo devuelve al usuario.
Tiempo: 100-500 ms (primera vez).

6. Peticiones posteriores:

Otros usuarios del mismo PoP → cache HIT.
Tiempo: 5-20 ms.

3.3 Cache Hit vs Cache Miss

Cache Hit Ratio (CHR): % de peticiones servidas desde caché.

CDN bien configurada: 80-95%.
CDN mal configurada: 40-60%.

Objetivo: maximizar CHR para reducir carga del origen.

3.4 TTL (Time To Live)

TTL: tiempo que un recurso permanece en caché antes de ser considerado obsoleto.

TTL corto (1 min): contenido fresco pero más misses.
TTL largo (1 año): más hits pero riesgo de contenido obsoleto.

Regla: TTL largo para recursos versionados (CSS, JS, imágenes).

3.5 Invalidación

Si cambias un recurso, hay que invalidar la caché.

Métodos:

Purge manual: pide a la CDN borrar un recurso.
Cache busting: cambia el nombre del recurso (style.v2.css).
TTL corto: espera a que expire.

Consulta Cómo funciona un sistema de caché de contenido CDN (este mismo artículo).

4. Tipos de caché

4.1 Browser cache

Dónde: en el navegador del usuario.

Qué guarda: imágenes, CSS, JS, fuentes.

Controlado por: headers HTTP.

Ventaja: no hay petición al servidor.

Limitación: solo para ese usuario.

4.2 Proxy cache

Dónde: en el ISP o empresa.

Qué guarda: contenido popular.

Ventaja: sirve a múltiples usuarios.

Limitación: control limitado.

4.3 Edge cache (CDN)

Dónde: en los PoPs de la CDN.

Qué guarda: contenido estático y dinámico.

Ventaja: distribución geográfica, control total.

Limitación: coste de la CDN.

4.4 Origin cache

Dónde: en el servidor origen.

Qué guarda: respuestas dinámicas, bases de datos.

Herramientas:

Varnish.
Nginx con proxy_cache.
Redis, Memcached.

Ventaja: reduce carga del backend.

Limitación: solo en el origen.

4.5 Application cache

Dónde: en la aplicación (backend).

Qué guarda: resultados de queries, sesiones, objetos.

Herramientas:

Redis.
Memcached.
APCu.

Ventaja: muy rápido.

Limitación: requiere código.

4.6 Tabla resumen

Tipo	Ubicación	Alcance	Control
Browser	Usuario	1 usuario	Headers
Proxy	ISP/empresa	Múltiples usuarios	Limitado
Edge (CDN)	PoPs	Global	Total
Origin	Servidor	Servidor	Total
Application	Backend	App	Total

5. Qué se puede cachear (y qué no)

5.1 Contenido estático (siempre cachear)

Imágenes (jpg, png, webp, avif, svg).
CSS (stylesheets).
JavaScript (scripts).
Fuentes (woff, woff2, ttf).
Vídeos (mp4, webm).
Audio (mp3, ogg).
PDFs.
Descargas.

TTL: largo (días, meses, año).

5.2 Contenido semi-estático (cachear con TTL medio)

HTML de páginas estáticas.
APIs con datos que cambian poco.
Feeds RSS.
Sitemaps.

TTL: medio (horas, días).

5.3 Contenido dinámico (cachear con cuidado)

HTML personalizado.
APIs con datos en tiempo real.
Carritos de compra.
Sesiones de usuario.

TTL: corto (segundos, minutos).
Regla: no cachear contenido personalizado sin Vary header.

5.4 Contenido NO cacheable

Contenido autenticado (paneles de admin).
Datos de usuario (perfil, configuración).
Carritos de compra.
Formularios con CSRF tokens.
APIs de pago.
Streaming en vivo.

Headers: Cache-Control: no-store.

5.5 Regla del 80/20

El 80% del tráfico web corresponde a contenido estático.
Cachear ese 80% reduce carga del origen drásticamente.

Consulta Cómo implementar HTTPS correctamente.

6. Headers HTTP de caché

6.1 Cache-Control

El header más importante. Define cómo cachear.

Directivas principales:

Cache-Control: max-age=3600

Cache-Control: max-age=3600

max-age: segundos que el recurso es válido.

Cache-Control: public

Cache-Control: public

public: cacheable por cualquier caché.

Cache-Control: private

Cache-Control: private

private: solo cacheable por el navegador del usuario.

Cache-Control: no-cache

Cache-Control: no-cache

no-cache: revalidar antes de usar caché.

Cache-Control: no-store

Cache-Control: no-store

no-store: no cachear en absoluto.

Cache-Control: must-revalidate

Cache-Control: must-revalidate

must-revalidate: revalidar cuando expire.

Combinaciones típicas:

# Estático, 1 año
Cache-Control: public, max-age=31536000, immutable

# Dinámico, 1 hora
Cache-Control: public, max-age=3600, must-revalidate

# No cachear
Cache-Control: no-store, no-cache, must-revalidate

# Estático, 1 año
Cache-Control: public, max-age=31536000, immutable

# Dinámico, 1 hora
Cache-Control: public, max-age=3600, must-revalidate

# No cachear
Cache-Control: no-store, no-cache, must-revalidate

6.2 ETag

Identificador único del recurso.

ETag: "5d8c72a5-264"

ETag: "5d8c72a5-264"

Uso: el navegador envía If-None-Match: "5d8c72a5-264" para preguntar si ha cambiado.

Respuesta:

304 Not Modified: no ha cambiado (usa caché).
200 OK: ha cambiado (envía nuevo).

Ventaja: eficiente, valida por contenido.

6.3 Last-Modified

Fecha de última modificación.

Last-Modified: Mon, 01 Jan 2026 12:00:00 GMT

Last-Modified: Mon, 01 Jan 2026 12:00:00 GMT

Uso: el navegador envía If-Modified-Since.

Ventaja: simple.
Limitación: menos preciso que ETag.

6.4 Expires

Fecha absoluta de expiración.

Expires: Thu, 31 Dec 2026 23:59:59 GMT

Expires: Thu, 31 Dec 2026 23:59:59 GMT

Limitación: si el reloj está mal, problemas.

Recomendación: usa Cache-Control: max-age (relativo) en lugar de Expires.

6.5 Vary

Define qué headers afectan al caché.

Vary: Accept-Encoding, User-Agent

Vary: Accept-Encoding, User-Agent

Ejemplo: si sirves contenido diferente por User-Agent, incluye Vary: User-Agent.

⚠️ Cuidado: Vary: User-Agent puede reducir el hit ratio drásticamente.

6.6 Age

Tiempo que el recurso lleva en caché.

Age: 1800

Age: 1800

Uso: información para el cliente.

6.7 Ejemplos prácticos

Imagen estática:

Cache-Control: public, max-age=31536000, immutable
ETag: "abc123"

Cache-Control: public, max-age=31536000, immutable
ETag: "abc123"

HTML dinámico:

Cache-Control: public, max-age=300, must-revalidate
ETag: "def456"
Vary: Accept-Encoding

Cache-Control: public, max-age=300, must-revalidate
ETag: "def456"
Vary: Accept-Encoding

API privada:

Cache-Control: private, no-store

Cache-Control: private, no-store

Consulta Cómo implementar el protocolo HTTPS correctamente.

7. Estrategias de caché

7.1 TTL según tipo de contenido

Tipo	TTL recomendado
Imágenes versionadas	1 año
CSS/JS versionados	1 año
Fuentes	1 año
HTML estático	1 hora – 1 día
APIs semi-estáticas	5 min – 1 hora
HTML dinámico	0 – 5 min
APIs dinámicas	0 (o muy corto)
Contenido privado	No cachear

7.2 Cache busting

Problema: si cambias style.css, los usuarios siguen viendo la versión antigua (cacheada).

Solución: cambiar el nombre del archivo.

Ejemplos:

style.css → style.v2.css
style.css → style.abc123.css

style.css → style.v2.css
style.css → style.abc123.css

En HTML:

<link rel="stylesheet" href="/style.css?v=abc123">

<link rel="stylesheet" href="/style.css?v=abc123">

En frameworks modernos:

Webpack: hash en el nombre.
Vite: hash automático.
Next.js: hash en _next/static.

Ventaja: TTL largo sin problemas de caché obsoleta.

7.3 Invalidación selectiva

Por URL:

# Cloudflare
curl -X POST "https://api.cloudflare.com/client/v4/zones/ZONE_ID/purge_cache" \
    -H "Authorization: Bearer TOKEN" \
    -H "Content-Type: application/json" \
    --data '{"files":["https://example.com/style.css"]}'

# Cloudflare
curl -X POST "https://api.cloudflare.com/client/v4/zones/ZONE_ID/purge_cache" \
    -H "Authorization: Bearer TOKEN" \
    -H "Content-Type: application/json" \
    --data '{"files":["https://example.com/style.css"]}'

Por tag (si la CDN lo soporta):

# Cloudflare Enterprise
--data '{"tags":["css","homepage"]}'

# Cloudflare Enterprise
--data '{"tags":["css","homepage"]}'

Por todo:

--data '{"purge_everything":true}'

--data '{"purge_everything":true}'

7.4 Stale-While-Revalidate

Estrategia moderna: servir contenido obsoleto mientras se revalida.

Cache-Control: public, max-age=3600, stale-while-revalidate=86400

Cache-Control: public, max-age=3600, stale-while-revalidate=86400

Cómo funciona:

Contenido expira.
Usuario recibe versión obsoleta (rápido).
En background, se revalida.
Próximos usuarios reciben versión fresca.

Ventaja: rendimiento sin perder frescura.

7.5 Stale-If-Error

Si el origen falla, servir contenido obsoleto.

Cache-Control: public, max-age=3600, stale-if-error=86400

Cache-Control: public, max-age=3600, stale-if-error=86400

Ventaja: alta disponibilidad.

7.6 Preload / Prefetch

Precargar contenido antes de que se necesite.

<link rel="preload" href="/style.css" as="style">
<link rel="prefetch" href="/next-page.html">

<link rel="preload" href="/style.css" as="style">
<link rel="prefetch" href="/next-page.html">

En HTTP:

Link: </style.css>; rel=preload; as=style

Link: </style.css>; rel=preload; as=style

7.7 Configuración por tipo de archivo

Nginx ejemplo:

# CSS/JS: 1 año
location ~* \.(css|js)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

# Imágenes: 1 año
location ~* \.(jpg|jpeg|png|gif|webp|svg|ico)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

# Fuentes: 1 año
location ~* \.(woff|woff2|ttf|otf|eot)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

# HTML: 1 hora
location ~* \.html$ {
    expires 1h;
    add_header Cache-Control "public, must-revalidate";
}

# CSS/JS: 1 año
location ~* \.(css|js)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

# Imágenes: 1 año
location ~* \.(jpg|jpeg|png|gif|webp|svg|ico)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

# Fuentes: 1 año
location ~* \.(woff|woff2|ttf|otf|eot)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

# HTML: 1 hora
location ~* \.html$ {
    expires 1h;
    add_header Cache-Control "public, must-revalidate";
}

8. Cómo configurar una CDN

8.1 Elegir una CDN

Opciones:

CDN	Gratis	WAF	DDoS	Ideal para
Cloudflare	✅	✅	✅	Todos
CloudFront	❌	✅	✅	AWS
Fastly	❌	✅	✅	Medios
Bunny	❌	✅	✅	Pequeñas
Akamai	❌	✅	✅	Grandes

Recomendación: Cloudflare para empezar (tier gratuito generoso).

8.2 Configurar Cloudflare (paso a paso)

1. Registrarse:

Ir a https://www.cloudflare.com/
Crear cuenta gratuita.

2. Añadir el dominio:

Introducir tu dominio.
Cloudflare escanea los DNS.

3. Cambiar nameservers:

Cloudflare te da 2 nameservers.
Cámbialos en tu registrador.
Espera propagación (24-48h).

4. Configurar DNS:

Los registros se importan automáticamente.
Verifica cada uno.
Activa el proxy (nube naranja) para los que quieras cachear.

5. Configurar SSL/TLS:

SSL/TLS → Overview.
Modo: Full (Strict).
Habilitar HSTS.

6. Configurar caché:

Caching → Configuration.
Caching Level: Standard.
Browser Cache TTL: según tipo de contenido.
Always Online: activado.

7. Configurar Page Rules:

Page Rules → Create Page Rule.
Ejemplo: cachear todo /static/*.

8. Configurar WAF:

Security → WAF.
Activar reglas gestionadas.
Activar OWASP Core Ruleset.

9. Configurar DDoS:

Activado por defecto.
Ajustar sensibilidad si es necesario.

10. Verificar:

Test de velocidad (GTmetrix, WebPageTest).
Ver headers de caché:

curl -I https://tudominio.com/style.css

curl -I https://tudominio.com/style.css

Deberías ver:

CF-Cache-Status: HIT
Cache-Control: public, max-age=31536000

CF-Cache-Status: HIT
Cache-Control: public, max-age=31536000

8.3 Configurar AWS CloudFront

1. Crear distribución:

CloudFront → Create Distribution.
Origin: tu servidor.
Behaviors: definir reglas.

2. Configurar caché:

Cache Policy: CachingOptimized.
TTL: 86400 (1 día).

3. Configurar SSL:

Certificado ACM (gratuito).
Redirigir HTTP → HTTPS.

4. Configurar WAF:

AWS WAF → Web ACL.
Reglas gestionadas.

5. Verificar:

CloudFront → Distributions → Domain name.
Test.

8.4 Configurar Fastly

1. Crear servicio:

Fastly → Create Service.
Origin: tu servidor.

2. Configurar VCL:

sub vcl_recv {
    # Cachear todo excepto admin
    if (req.url ~ "^/admin/") {
        return (pass);
    }
}

sub vcl_backend_response {
    # TTL por tipo de archivo
    if (bereq.url ~ "\.(css|js|jpg|png|gif|svg|woff2)$") {
        set beresp.ttl = 365d;
        set beresp.http.Cache-Control = "public, max-age=31536000, immutable";
    }
}

sub vcl_recv {
    # Cachear todo excepto admin
    if (req.url ~ "^/admin/") {
        return (pass);
    }
}

sub vcl_backend_response {
    # TTL por tipo de archivo
    if (bereq.url ~ "\.(css|js|jpg|png|gif|svg|woff2)$") {
        set beresp.ttl = 365d;
        set beresp.http.Cache-Control = "public, max-age=31536000, immutable";
    }
}

3. Configurar dominio.

4. Test.

8.5 Configurar caché en Nginx (origin)

Si quieres cachear en tu propio servidor:

# En http {}
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m use_temp_path=off;

# En server {}
location / {
    proxy_cache my_cache;
    proxy_cache_valid 200 302 60m;
    proxy_cache_valid 404 1m;
    proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
    proxy_cache_background_update on;
    proxy_cache_lock on;
    add_header X-Cache-Status $upstream_cache_status;
    proxy_pass http://backend;
}

# En http {}
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m use_temp_path=off;

# En server {}
location / {
    proxy_cache my_cache;
    proxy_cache_valid 200 302 60m;
    proxy_cache_valid 404 1m;
    proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
    proxy_cache_background_update on;
    proxy_cache_lock on;
    add_header X-Cache-Status $upstream_cache_status;
    proxy_pass http://backend;
}

Estados de X-Cache-Status:

HIT: servido desde caché.
MISS: no estaba en caché.
EXPIRED: expirado, revalidado.
STALE: obsoleto, servido por fallo.

9. Optimización avanzada

9.1 Maximizar el hit ratio

Objetivos:

CHR > 90% para estáticos.
CHR > 60% para semi-estáticos.

Técnicas:

TTL largo para estáticos.
Cache busting para actualizar.
Reducir Vary headers.
Normalizar URLs (mayúsculas/minúsculas, trailing slash).
Cachear respuestas de API con TTL adecuado.

9.2 Compresión

Comprimir respuestas antes de enviar:

gzip: universal.
brotli: mejor compresión.

Nginx:

gzip on;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml;
gzip_min_length 1000;
gzip_comp_level 6;

# Brotli
brotli on;
brotli_comp_level 6;
brotli_types text/plain text/css application/json application/javascript text/xml application/xml;

gzip on;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml;
gzip_min_length 1000;
gzip_comp_level 6;

# Brotli
brotli on;
brotli_comp_level 6;
brotli_types text/plain text/css application/json application/javascript text/xml application/xml;

En Cloudflare:

Speed → Optimization → Brotli: ON.

9.3 HTTP/2 y HTTP/3

HTTP/2: multiplexación, mejor rendimiento.
HTTP/3: sobre QUIC, aún mejor.

Cloudflare: HTTP/3 activable en Network.

9.4 Early Hints

Enviar hints tempranos al navegador:

Link: </style.css>; rel=preload; as=style

Link: </style.css>; rel=preload; as=style

Ventaja: el navegador empieza a cargar antes.

9.5 Imágenes optimizadas

WebP/AVIF en lugar de JPG/PNG.
Lazy loading.
Responsive images (srcset).
CDN con transformación (Cloudflare Images, Cloudinary).

9.6 Edge computing

Cloudflare Workers:

addEventListener('fetch', event => {
    event.respondWith(handleRequest(event.request));
});

async function handleRequest(request) {
    <em>// Lógica personalizada en el edge</em>
    const response = await fetch(request);
    <em>// Modificar respuesta</em>
    return response;
}

addEventListener('fetch', event => {
    event.respondWith(handleRequest(event.request));
});

async function handleRequest(request) {
    <em>// Lógica personalizada en el edge</em>
    const response = await fetch(request);
    <em>// Modificar respuesta</em>
    return response;
}

Ventaja: procesamiento cerca del usuario.

9.7 Monitorización

KPIs:

Cache Hit Ratio (CHR).
TTFB (Time To First Byte).
Latencia por región.
Ancho de banda servido.

Herramientas:

Cloudflare Analytics.
AWS CloudWatch.
Grafana + Prometheus.

Consulta Las mejores herramientas de monitorización.

9.8 Costes

Factores:

Ancho de banda servido.
Requests.
Transformaciones de imágenes.
Regiones.

Optimización:

Aumentar CHR (menos requests al origen).
Comprimir contenido.
Usar formatos modernos.
Negociar tarifas con volumen.

10. Solución de problemas

10.1 «El contenido no se actualiza tras cambios»

Causas:

Caché obsoleta.
TTL muy largo.
Cache busting mal implementado.

Solución:

Purge el recurso en la CDN.
Cambia el nombre del archivo (cache busting).
Reduce el TTL para desarrollo.

10.2 «Cache HIT ratio bajo»

Causas:

Vary: User-Agent mal configurado.
TTL muy corto.
Contenido dinámico cacheado.

Solución:

Elimina Vary: User-Agent si no es necesario.
Aumenta TTL para estáticos.
Revisa qué se cachea.

10.3 «El sitio va lento con CDN»

Causas:

Origen lento.
CDN mal configurada.
DNS lento.

Solución:

Optimiza el origen.
Configura stale-while-revalidate.
Usa DNS rápido (Cloudflare 1.1.1.1).

10.4 «Errores 522 / 524 con Cloudflare»

Causas:

Origen no responde.
Timeout.

Solución:

Verifica el origen.
Aumenta timeout en Cloudflare (Business+).
Revisa firewall del origen.

10.5 «El certificado SSL falla»

Causas:

Origen sin SSL.
Modo SSL incorrecto.

Solución:

Usa modo Full (Strict).
Instala certificado en el origen (Let’s Encrypt).
Configura Cloudflare Origin Certificate.

Consulta Guía completa para configurar SSL en Nginx.

10.6 «Cloudflare bloquea tráfico legítimo»

Causas:

WAF demasiado agresivo.
Rate limiting.

Solución:

Ajusta reglas del WAF.
Añade IPs a whitelist.
Reduce sensibilidad.

10.7 «Los formularios no funcionan»

Causas:

Caché de POST.
CSRF tokens cacheados.

Solución:

No cachear POST (por defecto).
Cachear solo GET.
Añadir no-store a páginas con formularios.

10.8 «Contenido mixto (mixed content)»

Causas:

Recursos HTTP en página HTTPS.

Solución:

Usa HTTPS en todo.
Activa Automatic HTTPS Rewrites en Cloudflare.
Actualiza URLs en el HTML.

10.9 «Imágenes no se actualizan»

Causas:

Mismo nombre de archivo.
Caché agresiva.

Solución:

Cambia el nombre (imagen-v2.jpg).
Purga la caché.
Usa transformaciones con versión.

10.10 «El sitio se rompe en algunos navegadores»

Causas:

Contenido cacheado para otro User-Agent.

Solución:

Revisa Vary headers.
Evita cachear por User-Agent.
Test en múltiples navegadores.

10.11 «Cache poisoning»

Causas:

Headers mal validados.
Host header injection.

Solución:

Valida el header Host.
No caches respuestas con Set-Cookie.
Configura el WAF.

Consulta Beneficios del uso de CDN para la seguridad.

10.12 «Coste elevado de CDN»

Causas:

Mucho tráfico no cacheado.
Transformaciones costosas.
Regiones lejanas.

Solución:

Aumenta CHR.
Optimiza imágenes.
Configura límites.

11. FAQ

¿Qué es una CDN y cómo funciona?

Una CDN (Content Delivery Network) es una red de servidores distribuidos geográficamente que sirven contenido a los usuarios desde el servidor más cercano.

Funcionamiento:

Usuario pide un recurso.
La CDN busca en su caché.
Si está (HIT), lo devuelve rápido.
Si no (MISS), lo pide al origen, lo cachea y lo devuelve.

Resultado: carga más rápida, menos carga del origen, más seguridad.

¿Cuál es la diferencia entre caché y CDN?

Caché: técnica de almacenar copias de contenido.
CDN: red distribuida que usa caché para servir contenido.

Toda CDN usa caché, pero no todo caché es una CDN.

¿Qué se puede cachear en una CDN?

Sí, cacheable:

Imágenes, CSS, JS, fuentes.
Vídeos, audio, PDFs.
HTML estático.
APIs semi-estáticas.

No cacheable:

Contenido autenticado.
Carritos de compra.
Datos de usuario.
Formularios con tokens.

¿Qué es el TTL y cómo lo configuro?

TTL (Time To Live): tiempo que un recurso permanece en caché.

Recomendaciones:

Imágenes/CSS/JS versionados: 1 año (31536000).
HTML estático: 1 hora – 1 día.
APIs semi-estáticas: 5 min – 1 hora.
Contenido dinámico: 0 – 5 min.

Configuración:

Cache-Control: public, max-age=31536000, immutable

Cache-Control: public, max-age=31536000, immutable

¿Qué es un Cache HIT y un Cache MISS?

HIT: el recurso está en caché, se devuelve rápido.
MISS: no está, se pide al origen.

Objetivo: maximizar HITs (>90%).

¿Qué es el cache busting?

Técnica para forzar a los navegadores a descargar la nueva versión de un recurso.

Métodos:

Cambiar nombre: style.v2.css.
Query string: style.css?v=abc123.
Hash en frameworks: style.a1b2c3.css.

¿Qué headers HTTP controlan el caché?

Principales:

Cache-Control: directivas de caché.
ETag: identificador del recurso.
Last-Modified: fecha de modificación.
Expires: fecha absoluta de expiración.
Vary: headers que afectan al caché.

¿Qué diferencia hay entre `no-cache` y `no-store`?

no-cache: revalidar antes de usar caché. El recurso puede cachearse pero debe revalidarse.
no-store: no cachear en absoluto. Ni en memoria ni en disco.

Uso:

no-cache: contenido que cambia frecuentemente.
no-store: contenido sensible (banca, admin).

¿Qué es `stale-while-revalidate`?

Estrategia que sirve contenido obsoleto mientras revalida en background.

Cache-Control: public, max-age=3600, stale-while-revalidate=86400

Cache-Control: public, max-age=3600, stale-while-revalidate=86400

Ventaja: rendimiento sin perder frescura.

¿Cuánto cuesta una CDN?

Tier gratuito (Cloudflare):

Ilimitado en plan Free.
WAF básico.
DDoS ilimitado.

Planes de pago:

Cloudflare Pro: 20 €/mes.
Cloudflare Business: 200 €/mes.
Cloudflare Enterprise: desde ~2.000 €/mes.
CloudFront: variable según uso (~0,085 $/GB).

Recomendación: empieza gratis con Cloudflare.

¿Qué CDN uso?

Recomendaciones:

Cloudflare: la más popular, tier gratuito generoso.
AWS CloudFront: si usas AWS.
Fastly: para medios y rendimiento.
Bunny CDN: económica y buena.
Akamai: para grandes empresas.

Cloudflare es la apuesta segura.

¿La CDN afecta al SEO?

Sí, positivamente:

Mejora velocidad (factor de ranking).
Mejora Core Web Vitals.
Aumenta disponibilidad.
Protege contra DDoS.

No hay efectos negativos si está bien configurada.

¿Cómo sé si mi CDN funciona?

Test:

curl -I https://tudominio.com/style.css

curl -I https://tudominio.com/style.css

Busca:

CF-Cache-Status: HIT (Cloudflare).
X-Cache: Hit from cloudfront (CloudFront).
X-Cache-Status: HIT (Nginx).

Herramientas:

WebPageTest.
GTmetrix.
Pingdom.

¿Qué es el Cache Hit Ratio (CHR)?

% de peticiones servidas desde caché.

Objetivos:

Estáticos: >90%.
Semi-estáticos: >60%.
Dinámicos: >30%.

Fórmula:

CHR = HITs / (HITs + MISSes) * 100

CHR = HITs / (HITs + MISSes) * 100

¿Cómo limpio la caché de una CDN?

Cloudflare:

Dashboard → Caching → Purge Cache.
Purge Everything: limpia todo.
Custom Purge: limpia URLs específicas.

CloudFront:

Distribution → Invalidations.
Crear invalidación (/* para todo).

Fastly:

Purge → Purge All o URL específica.

¿Qué es un PoP en una CDN?

PoP (Point of Presence): ubicación física donde la CDN tiene servidores.

Función: servir contenido desde el PoP más cercano al usuario.

Cantidad: desde 100 hasta 4.000+ según la CDN.

¿La CDN protege contra DDoS?

Sí, es una de sus funciones principales.

Distribuye el ataque entre cientos de PoPs.
Absorbe tráfico malicioso.
Protege el origen.

Cloudflare: DDoS ilimitado en todos los planes.

Consulta Cómo mitigar un ataque DDoS paso a paso.

¿Qué es el edge computing?

Procesamiento de datos en el edge (cerca del usuario) en lugar del datacenter central.

Ventajas:

Latencia mínima.
Menos ancho de banda.
Mejor privacidad.

Ejemplos: Cloudflare Workers, Lambda@Edge, Deno Deploy.

¿Cómo optimizo el caché para máximo rendimiento?

Estrategia:

Cachea todo lo estático con TTL largo.
Usa cache busting para actualizaciones.
Reduce Vary headers al mínimo.
Añade stale-while-revalidate.
Comprime con gzip/brotli.
Usa HTTP/3.
Monitoriza CHR regularmente.
Optimiza imágenes (WebP/AVIF).

Consulta Beneficios del uso de CDN.

12. Conclusión

Las CDNs con caché de contenido son imprescindibles en 2026. Ya no son un lujo para grandes empresas: cualquier web moderna —desde un blog personal hasta una plataforma de streaming— se beneficia enormemente de ellas.

Puntos clave: