Recupera la reproducción: elimina errores CDN en vídeos LMS

¿Vídeos del LMS en buffering, devolviendo 4xx/5xx o correctos en local pero fallando en producción? Quien gestione la academia online (responsable técnico o product owner) necesita diagnosticar impacto y raíz: muchos fallos nacen en la CDN —cabeceras, rango de bytes o firmas— y hay que verificar desde edge y origin con comandos reproducibles.

Si los vídeos del LMS fallan por la CDN, hay que empezar comprobando CORS, cabeceras Accept‑Ranges, respuestas 206/200 y URLs firmadas; purgar cachés y revisar reglas WAF. Errores CDN vídeos (LMS) se corrigen con pruebas reproducibles (curl -I/-v, wget), interpretación de salidas y snippets para Nginx, S3+CloudFront y Cloudflare: seguir la lista para validar, purgar y renovar signed URLs.

Resumen del proceso

Ejecuta diagnósticos desde el edge y desde el origin, interpreta cabeceras claves, purga correctamente y valida signed URLs.

1. Comprobar con curl/wget en edge y origin para ver status, Accept‑Ranges y CORS.
2. Corregir cabeceras en Nginx/S3 y ajustar behavior en CloudFront/Cloudflare.
3. Sincronizar TTL con signed URLs y purgar tras rotación de tokens.
4. Detectar reglas WAF/anti‑hotlink que rewritean Range u Origin.

Paso 1: diagnosticar con curl y wget

Ejecute comprobaciones desde el edge y desde el origin para aislar si la CDN modifica cabeceras o respuestas.

Comprobar status y cabeceras básicas

curl -I -L https://cdn.ejemplo.com/video.mp4 devuelve las cabeceras que el player ve.

Busque: Status, Accept‑Ranges, Content‑Range, Cache‑Control, Age, Via, Server.

Probar peticiones con range

curl -v -H "Range: bytes=0-1023" https://cdn.ejemplo.com/video.mp4 debe devolver 206 Partial Content.

Si devuelve 200 sin Content‑Range el reproductor puede fallar al pedir fragmentos.

Añada una checklist reproducible y enlazable para diagnóstico de reproducción:

1. Desde un cliente externo y desde el origen, ejecutar y guardar: curl -v -H "Range: bytes=0-1023" -H "Origin: https://miacademia.es" https://cdn.ejemplo.com/video.mp4 > edge-range.txt
2. En el origin ejecutar el mismo curl o capturar con tcpdump/ngrep para confirmar llegada de 'Range' y 'Origin' (tcpdump -w origin.pcap host origin.ip and port 443)
3. Ejecutar curl -I -L https://cdn.ejemplo.com/video.mp4 > edge-headers.txt y curl -I -L https://origin.ejemplo.com/video.mp4 > origin-headers.txt; comparar cabeceras clave: Status / Age / Via / Cache-Control / Accept‑Ranges / Content‑Range (esperado: 206 Partial Content y 'Accept‑Ranges: bytes' para peticiones parciales)
4. Revisar logs de CDN/edge para códigos 206 vs 200 y 4xx/5xx y cuantificar tasa de 206 (objetivo >95% para streaming HLS/DASH)
5. Si detecta discrepancia (origin = 206, edge = 200 o falta Accept‑Ranges), proceda a purga controlada y repita pruebas. Guardar las salidas (archivos .txt y .pcap) permite compartir evidencias con soporte del CDN y con el equipo de WAF

Paso 2: corregir cabeceras y range en CDN y origen

Asegure que el origin y el edge transmitan y respeten cabeceras clave para streaming segmentado y CORS.

Nginx: snippet mínimo para vídeo

Use este bloque en el servidor que actúa como origin o reverse proxy:

nginx location /videos/ { types { mp4 video/mp4; m3u8 application/vnd.apple.mpegurl; } add_header Access-Control-Allow-Origin "https://miacademia.es" always; add_header Access-Control-Allow-Headers "Range,Authorization,Accept,Content-Type" always; add_header Access-Control-Expose-Headers "Content-Range,Accept-Ranges" always; add_header Accept-Ranges "bytes" always; sendfile on; tcp_nopush on; }

No usar "*" en Access‑Control si el servicio exige control de origen por RGPD o LOPDGDD.

S3 y CloudFront: CORS y forward headers

En S3 aplicar CORS al bucket:

xml https://miacademia.es GET * Content-Range Accept-Ranges

En CloudFront configure Cache Policy y Origin Request Policy de forma explícita:

• Si necesita que el origin reciba el header Origin para CORS, añada Origin en la Origin Request Policy.
• Para permitir peticiones parciales, asegúrese de que Range esté permitido y de que la política de caché/clave incluya los elementos necesarios (query string o headers) que forman parte de la firma. Las signed URLs no obligan por sí mismas a "forwardear" Range.
• Lo correcto es crear la política que permita Range en el origen y decidir si la firma debe formar parte de la cache key (query string forwarding) para evitar servir contenido con firmas inválidas.

Para entornos que usan Bunny o KeyCDN y WordPress con offload, incluya configuraciones concretas:

• Bunny permite tokenización por URL (ej. Https://zona.b-cdn.net/video.mp4?token=HASH) con expiración y salt en el panel
• configure el tiempo de vida del token y active "Respect origin cache-control" para que el edge respete Cache‑Control del origen si se desea invalidación vía purga. En KeyCDN cree una Zone API Key y use la API de purge via curl -X POST "https://api.keycdn.com/zones/purge/{zone_id}.json" -d "url=https://cdn.ejemplo.com/video.mp4" para invalidar objetos tras rotar firmas. En WordPress, ajustes de plugins como WP Offload Media deben preservar metadata del objeto (Content‑Type y Cache‑Control) al subir a S3/Bunny
• además, desactive cualquier limpieza agresiva de cabeceras en plugins de seguridad/cache que pueden eliminar 'Accept‑Ranges' u 'Origin'

Estos ajustes reducen buffering, aseguran '206 Partial Content' y evitan problemas de reproducción en producción.

Paso 3: firmas, TTL y purga correcta

Sincronice la validez de las signed URLs con el TTL del edge para evitar 403 intermitentes.

Regla práctica de TTL y firma

Si la firma dura 1 hora, el Edge TTL debe ser menor o la purga debe ejecutarse al rotar tokens.

Ejemplo: firma 1 hora; TTL 5 minutos. Otra opción: firma corta y purga al rotar.

Purgas reproducibles

CloudFront (AWS CLI):

aws cloudfront create-invalidation --distribution-id EXXXXX --paths "/videos/*"

Cloudflare (API):

curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone}/purge_cache" / -H "X-Auth-Email:..." -H "X-Auth-Key:..." / --data '{"files":["https://cdn.ejemplo.com/video.mp4"]}'

Para signed URLs conviene una explicación más práctica:

• en AWS CloudFront se pueden generar signed URLs con una política corta (por ejemplo 1 hora) usando el SDK o la utilidad de firma (CreateCloudFrontSignedURL con policy o canned policy)
• alternativamente, para usuarios concurrentes es recomendable usar signed cookies para evitar generar millones de URLs únicas. Al emitir firmas por query string hay que decidir si la firma forma parte de la clave de caché (cache key) o no: si la firma no forma parte del cache key el edge puede servir contenido cacheado aunque la firma cambie, lo que provoca 403 intermitentes
• la solución es incluir la query string en la key o usar TTL muy corto + purga automática al rotar firmas. En CDNs como KeyCDN o Bunny existe una opción análoga de tokenización en la URL (token expiración + salt)
• al renovar tokens siempre purgue el edge o reduzca el TTL y, si es posible, use signed cookies para sesiones de usuario con alto volumen de peticiones

Este flujo práctico —generar con SDK, decidir cache key y estrategia de TTL/purge, y optar por cookies cuando haya muchos usuarios— reduce 403 y problemas de reproducción.

Paso 4: detectar WAF y reglas que rompen vídeos

Comparar cabeceras enviadas por el cliente y las que llegan al origin para localizar rewrite o bloqueos del WAF.

Test de cabeceras para detectar rewrites

Ejecute:

curl -v -H "Range: bytes=0-1" -H "Origin: https://miacademia.es" https://cdn.ejemplo.com/video.mp4

Luego capture en origin con tcpdump para confirmar si Range y Origin llegan.

Revisar eventos del WAF

Consultar Cloudflare Firewall Events, AWS WAF logs o los logs del proveedor de CDN para reglas 403.

Buscar reglas clásicas: anti-hotlink, bloqueo por Referer, size limit en requests con Range.

Errores que arruinan la reproducción

Revisar estas causas antes de cambiar arquitectura o migrar a otra CDN.

Range requests servidas como 200

Si la CDN responde 200 en lugar de 206, el reproductor puede no reproducir o bufferizar indefinidamente.

Medir: objetivo >95% de respuestas 206 para contenido HLS/DASH en condiciones normales.

Signed URLs cacheadas sin control

El comportamiento varía por CDN: algunos edges validan la firma en cada petición y devolverán 403 cuando la firma expire; otros servirán el contenido cacheado hasta que expire el TTL del objeto. Por tanto, detalle la estrategia:

1. Incluir la firma en la cache key (forward query string) si desea invalidación por firma, o
2. Usar TTL corto y ejecutar purge al rotar firmas, o
3. Usar signed cookies para evitar generar URLs únicas por objeto. Explicar esta diferencia evita diagnósticos erróneos

Solución: TTL corto o purge automatizada al emitir nueva firma.

Cabeceras CORS ausentes

Sin Access-Control-Allow-Origin correcto, el player en el navegador bloqueará la reproducción por políticas del navegador.

Ver MDN para reglas CORS y ejemplos: MDN CORS

Comparativa: alojar en LMS vs plataformas de vídeo

La decisión depende de control, coste y necesidades de seguridad. La tabla muestra diferencias clave.

La evidencia práctica señala dos ideas clave: HLS impulsó la reproducción adaptativa, HTTP/2 modernizó la entrega web y WCAG 2.1 se publicó en 2018; estas fechas contextualizan la evolución de streaming y accesibilidad.

La recomendación esencial: priorizar control de cabeceras y sincronía entre TTL y validez de firmas → si no se hace, la experiencia de usuario empeora y aparecen 403 intermitentes.

Esto funciona bien en teoría, pero en la práctica la mayoría de configuraciones olvidan purgar el edge al rotar firmas; el resultado es intermitencia en horas punta y tickets difíciles de reproducir.

Cuándo no funciona este método / alternativas

Si se prefiere una revisión técnica con logs y comandos reproducibles, puede solicitarse un diagnóstico puntual para aislar el origen del fallo y proponer correcciones concretas.

Preguntas frecuentes

¿Cómo distinguir si el fallo viene del edge o del origin?

Comparar la respuesta del edge y del origin con curl. Si origin devuelve 206 y edge devuelve 200, la CDN está modificando la petición.

¿Qué comandos uso para comprobar range y CORS?

Usar curl -v -H "Range: bytes=0-1" y curl -I -L. Para HLS probar la m3u8 con wget --server-response.

¿Por qué aparecen 403 solo a algunos usuarios?

Firmas expiradas en combinación con cache largo en el edge producen 403 intermitentes. Revocar y purgar resuelve el síntoma.

¿Cómo medir si la CDN responde correctamente por región?

Ejecutar comandos desde varias ubicaciones y comparar Age, Via, TTFB y status. Si un POP falla, revisar reglas por región.

¿Puede un plugin de WordPress causar estos fallos?

Sí. Plugins de cache o seguridad pueden eliminar Range u Origin. Desactivar temporalmente y reproducir la prueba ayuda a aislarlo.

¿Qué KPIs conviene vigilar para detectar problemas?

Vigilar tasa de 206 por vídeo (>95% objetivo), TTFB median por región (<300ms objetivo), y error rate 4xx/5xx por hora (>0.5% como umbral de alerta).

• La CDN suele ocultar el fallo real al activar SSL
• Tu offload en WordPress puede romper SEO y URLs

Josu Barrios

Somos especialistas en mantenimiento WordPress para empresas, profesionales y tiendas online. Contamos con experiencia en seguridad web, optimización de rendimiento, actualizaciones, copias de seguridad y resolución de incidencias técnicas, ayudando a que cada sitio funcione de forma rápida, estable y protegida. Nuestro enfoque combina soporte técnico profesional, buenas prácticas de seguridad y seguimiento continuo para ofrecer un servicio fiable, transparente y orientado a resultados reales.