Abre la zona CDN → pestaña Origins en my.cubepath.com.
Los orígenes son los backends de los que el CDN descarga contenido cuando falla la caché: tu servidor web, una API o un bucket compatible con S3. Una zona necesita al menos uno para poder servir algo.
Añadir un origen
Pulsa Add Origin y rellena:
| Campo | Qué hace |
|---|---|
| Name | Una etiqueta para reconocer este backend |
| Address | El hostname o la IP de tu backend |
| Protocol / Port | Cómo se conecta el edge a él |
| Host Header | La cabecera Host que se envía al backend. Déjalo vacío para usar la dirección del origen — solo se define si tu backend usa virtual hosting por nombre |
| Verify SSL | Valida el certificado del origen. Mantenlo activado salvo que el backend use un certificado autofirmado |
| Weight | Reparto de tráfico cuando hay varios orígenes activos |
| Priority | Qué origen prefiere el edge |
| Backup Origin | Solo se usa cuando los orígenes principales no están disponibles |
| Health Check + path | Sondea el origen periódicamente para sacar de rotación un backend caído |
Cada origen de la lista muestra su estado de health en vivo, y se puede activar o desactivar sin borrarlo — que es la forma limpia de drenar un backend antes de una intervención.
ConsejoActiva los health checks y apúntalos a un endpoint barato pero honesto (algo como
/healthzque toque tu base de datos), no a tu página más pesada. Un check que solo demuestra que el servidor web escucha seguirá enviando tráfico a un backend cuya aplicación está rota.
Buckets S3 privados (SigV4)
Si tu origen es un almacén de objetos y el bucket es privado, cada descarga sin autenticar recibe un 403. La autenticación de origen S3 lo resuelve: le das al CDN las credenciales del bucket una vez y cada fallo de caché se firma con AWS Signature Version 4 de forma transparente. Los visitantes nunca ven las credenciales y el bucket sigue siendo privado.
| Tu origen | ¿Lo necesitas? |
|---|---|
| Tu propio servidor web (Nginx, Apache, API propia) | No — HTTPS normal, sin firma |
| Bucket compatible con S3 público | No — cualquiera puede descargar con un GET normal |
| Bucket compatible con S3 privado | Sí — sin esto cada descarga da 403 |
Proveedores soportados
Funciona cualquier almacén de objetos que hable AWS SigV4 sobre una API S3:
| Proveedor | Endpoint |
|---|---|
| AWS S3 | s3.<region>.amazonaws.com |
| Cloudflare R2 | <account_id>.r2.cloudflarestorage.com (o <account_id>.eu.r2.cloudflarestorage.com para la jurisdicción EU) |
| Wasabi | s3.<region>.wasabisys.com |
| Backblaze B2 | s3.<region>.backblazeb2.com |
| MinIO (autoalojado) | Tu propio endpoint |
Configurarlo
Configura el origen como cualquier otro: Origin URL es https://<tu-endpoint> sin ruta final, y Host Header se deja en blanco (se autorrellena con el hostname del endpoint; nunca lo pongas a tu dominio CDN). Después despliega Private bucket (S3 SigV4) y rellena:
| Campo | Valor |
|---|---|
| Enable SigV4 signing | Actívalo |
| Access key ID | La access key estilo S3 |
| Secret access key | El secreto estilo S3. Es de solo escritura: una vez guardado no se vuelve a mostrar |
| Region | Déjalo vacío para R2 (por defecto auto). Para AWS / Wasabi / Backblaze usa la región del bucket (us-east-1, eu-central-1…) |
| Service | s3 (el valor por defecto, correcto para todos los proveedores soportados) |
Guarda. Las credenciales se propagan a todos los PoP en unos segundos.
Mapeo de rutas, el fallo típico de la primera vez
S3 interpreta el primer segmento de la ruta como el nombre del bucket. Así que una petición a:
https://tu-zona.cubecdn.io/videos/clip.mp4
la lee S3 como bucket videos, key clip.mp4. Si tus ficheros están en realidad en un bucket llamado my-media, ese bucket no existe y obtienes un 403, un 404 o InvalidBucketName.
Dos formas de arreglarlo:
- Pon el nombre del bucket en tus URLs. Deja Base path vacío y haz que los clientes pidan
https://tu-zona.cubecdn.io/my-media/ruta/al/fichero.mp4. Lo más simple, pero el nombre del bucket queda a la vista. - Ocúltalo con Base path. Pon Base path a
/my-mediay los clientes pidenhttps://tu-zona.cubecdn.io/ruta/al/fichero.mp4— el CDN reescribe la ruta antes de reenviarla. El nombre del bucket no aparece nunca en público.
Permisos de las credenciales
Dales el mínimo permiso necesario: Object Read basta para distribución, que es el caso normal. Evita claves de administrador.
Acótalas solo a los buckets que sirve esta zona: en R2 usa Specify bucket, en AWS escribe una política IAM con Resource: "arn:aws:s3:::my-media/*". No entregues acceso a toda la cuenta.
Rotar credenciales
Regenéralas en el proveedor, edita el origen, despliega Private bucket (S3 SigV4), pega la nueva Access key ID y la nueva Secret access key, y guarda. Dejar el campo del secreto en blanco conserva el actual, así que rellénalo solo cuando de verdad estés rotando.
Las credenciales nuevas se propagan en unos 30 segundos. El contenido ya cacheado se sigue sirviendo hasta que expire su TTL; solo las descargas nuevas usan las claves nuevas.
Jurisdicciones de Cloudflare R2
Los buckets de R2 viven en la jurisdicción default o en la EU, y cada una tiene su propio endpoint. Si apuntas el CDN a la equivocada, R2 devuelve 421 Misdirected Request aun con credenciales perfectamente válidas. Comprueba la jurisdicción del bucket en el panel de Cloudflare (R2 → bucket → Settings → Location) y usa el endpoint que corresponda.
Aviso: Los tokens de API de R2 también están acotados a una jurisdicción. Un token creado desde la vista default no funciona contra buckets EU. Si migras un bucket entre jurisdicciones, regenera también el token.
Referencia de errores
| Estado / Código | Significado | Solución |
|---|---|---|
403 AccessDenied | Firma válida, pero las credenciales no tienen permiso sobre ese bucket/objeto | Revisa el alcance de bucket del token y los permisos de recurso |
403 SignatureDoesNotMatch | La firma en sí es incorrecta | Vuelve a introducir el secreto; verifica que la región coincide con el bucket |
400 InvalidArgument: Authorization | La petición llegó a S3 sin autenticación | Vuelve a guardar el origen; confirma que el conmutador SigV4 está activo |
404 NoSuchBucket | El primer segmento de la ruta no coincide con ningún bucket | Consulta Mapeo de rutas más arriba |
404 NoSuchKey | Bucket correcto, ruta de objeto incorrecta | Verifica la key exacta — las mayúsculas cuentan |
421 Misdirected Request | Endpoint de jurisdicción R2 o account ID equivocados | Consulta Jurisdicciones de Cloudflare R2 |
503 Service Unavailable | El origen no es accesible desde el edge | Revisa la página de estado del proveedor y la URL del endpoint |
El cuerpo XML suele indicar el <Code> exacto. Si el error llega en HTML, el fallo ocurrió antes de S3 — típicamente el desajuste de routing/SNI que hay detrás del caso 421.
Limitaciones
- Todos los orígenes autenticados con S3 de una zona comparten las mismas credenciales. El edge firma por backend, no por servidor. Para buckets distintos con claves distintas, usa zonas distintas.
- El secreto es de solo escritura. Si lo pierdes, regenéralo en el proveedor y vuelve a introducirlo.
- Solo GET y HEAD. El CDN no firma PUT/POST/DELETE: es una red de distribución, no una tubería de subida.