--- title: "Orígenes" description: "Configura los backends de los que tira tu CDN: dirección, host header, health checks, pesos y respaldo, más la autenticación SigV4 para buckets S3 privados." category: "Despliegue" language: es source: https://cubepath.com/es/docs/products/despliegue/cdn-origins-es updated: 2026-10-29 --- # Orígenes Abre la zona CDN → pestaña **Origins** en [my.cubepath.com](https://my.cubepath.com). ![Dos orígenes sanos en una zona CDN](https://cdn.cubepath.com/img/uploads/3930762c-7478-4b0b-99f9-8a34976171c4.png) 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 | ![Diálogo Add Origin: origen, nombre y URL](https://cdn.cubepath.com/img/uploads/24727018-b346-419c-aa1e-b0baf43a4d9f.png) 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. > Consejo: Activa los health checks y apúntalos a un endpoint barato pero honesto (algo como `/healthz` que 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..amazonaws.com` | | **Cloudflare R2** | `.r2.cloudflarestorage.com` (o `.eu.r2.cloudflarestorage.com` para la jurisdicción EU) | | **Wasabi** | `s3..wasabisys.com` | | **Backblaze B2** | `s3..backblazeb2.com` | | **MinIO** (autoalojado) | Tu propio endpoint | ### Configurarlo Configura el origen como cualquier otro: **Origin URL** es `https://` 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-media` y los clientes piden `https://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 `` 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.