Custom domains: tu dominio es el Worker

Un custom domain es la forma de decirle a Cloudflare “este hostname es mi Worker”. A diferencia del subdominio de pruebas, aquí usas un dominio tuyo —api.ejemplo.com, ejemplo.com— y Cloudflare se encarga de lo tedioso: crea el registro de DNS, emite el certificado y enruta todo el tráfico del hostname a tu código. Entender qué hace por dentro, y en qué se diferencia de una simple route, es lo que te permite elegir la herramienta correcta en vez de pelearte con la que elegiste por inercia.

Conectar un dominio a un Worker

Un custom domain asocia un dominio o subdominio completo de una zona tuya a un Worker. Los requisitos son mínimos: una zona activa en Cloudflare —la última lección de este nivel cierra ese tema— y un Worker que invocar. Desde ese momento, cada petición al hostname, sea cual sea la ruta o los parámetros, ejecuta tu Worker.

La configuración vive en Wrangler como una route marcada con custom_domain:

{
  "name": "api-gateway",
  "main": "src/index.ts",
  "compatibility_date": "2026-07-03",
  "routes": [
    { "pattern": "api.ejemplo.com", "custom_domain": true }
  ]
}

Fíjate en el patrón: es un hostname a secas, sin /* ni comodines. Un custom domain reclama todas las rutas de ese hostname; no es un filtro, es una posesión. Si vienes de una route /* con un registro apuntando a 100::, migrar a un custom domain es la mejora recomendada, porque simplifica DNS y certificado a la vez.

El registro y el certificado, automáticos

Aquí está la diferencia operativa más visible frente a una route: al crear el custom domain, Cloudflare crea por ti el registro de DNS —proxied, apuntando a tu Worker como origen— y emite un certificado para el hostname. No hay AAAA 100:: que recordar ni certificado que renovar a mano.

flowchart LR
A[Peticion a api.ejemplo.com] --> B[Registro proxied creado por Cloudflare]
B --> C[Edge de Cloudflare]
C --> D[Tu Worker actua como origen]
D --> E[Respuesta]

Esa gestión automática es la razón por la que un custom domain es lo que quieres para la puerta principal de tu aplicación: DNS y TLS dejan de ser tarea tuya, y no hay un registro placeholder que mantener.

Custom domain o route: la diferencia que importa

Ambos mandan tráfico a un Worker, pero encarnan dos ideas distintas. La route es un filtro sobre un hostname que ya existe; el custom domain es una declaración de que el hostname es el Worker.

Encadenar Workers con un origen real

Como el Worker de un custom domain se comporta como un origen, puedes anteponerle una route y componer dos Workers en la misma petición. El de la route hace de guardián y, si la petición pasa el filtro, la reenvía con fetch(request) al Worker-origen:

flowchart LR
A[Peticion entrante a la ruta auth] --> B[auth-worker en la route]
B --> C{Pasa el control}
C -->|No| D[Responde 401]
C -->|Si| E[fetch request al custom domain]
E --> F[api-worker como origen]

{
  "routes": [
    { "pattern": "api.ejemplo.com/auth", "zone_name": "ejemplo.com" }
  ]
}

El encadenamiento es explícito: lo decides tú en el código del guardián, no la plataforma. Es la base de patrones como autenticación centralizada, límites de tasa o registro previo delante de un servicio.

Cuándo usar cada uno

Usa un custom domain cuando el Worker es el destino final del hostname: una API, un sitio full-stack, un servicio que no delega en otro backend. Es también lo que quieres para la puerta principal de un producto, por la gestión automática de DNS y TLS.

Usa una route cuando quieres que un Worker intercepte solo una porción del tráfico de un dominio que ya sirve otra cosa; la lección siguiente entra en sus patrones y en cómo decide la prioridad.