Routes: patrones que interceptan tráfico

Una route responde a una pregunta distinta que un custom domain: no “de quién es este hostname”, sino “qué parte del tráfico de esta zona debe atender mi Worker”. Es un patrón que se compara contra cada URL entrante y, cuando encaja, desvía la petición a tu código. Dominar su sintaxis —comodines, especificidad, exclusiones— es lo que te deja componer varios Workers y un origen tradicional sobre un mismo dominio sin que se pisen entre ellos.

Anatomía de un patrón

Un patrón de route es hostname/ruta, sin esquema. La parte del hostname puede llevar un comodín de subdominio; la de la ruta, un comodín de cola. El ejemplo canónico:

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

Ese patrón manda a tu Worker todo lo que cuelgue de /api/, y deja intacto el resto del sitio. El patrón no incluye el esquema ni el puerto: casa igual con http y con https, y se compara contra la URL ya normalizada.

Hay tres formas de declarar la route, según cómo identifiques la zona:

{
  "routes": [
    { "pattern": "ejemplo.com/api/*", "zone_name": "ejemplo.com" },
    { "pattern": "tienda.com/*", "zone_id": "abc123..." },
    "app.ejemplo.com/*"
  ]
}

Comodines: subdominios y rutas

El comodín * casa con cualquier secuencia de caracteres. Combinándolo en las dos posiciones, hostname y ruta, cubres casos muy distintos:

El comodín de subdominio suele acompañarse de un registro de DNS también comodín. Por ejemplo, para capturar todos los subdominios con un solo Worker:

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

Prioridad: gana el más específico

Cuando varias routes podrían casar con una misma URL, Cloudflare aplica una regla simple y determinista: el patrón más específico gana. Un patrón más largo y menos comodinado tiene prioridad sobre uno más amplio.

flowchart TD
A[Peticion entrante] --> B{Que patrones casan}
B --> C[Patron amplio de toda la zona]
B --> D[Patron de una sub ruta]
B --> E[Patron mas fino y exacto]
E --> F[Gana el mas especifico y corre su Worker]

Esto te permite estratificar: una route ancha */* hacia un Worker general y una fina ejemplo.com/api/pagos/* hacia un Worker especializado; la fina se impone justo donde aplica y la ancha recoge todo lo demás.

Piensa en la especificidad como en las capas de una cebolla: cada patrón más concreto recorta un hueco dentro del anterior. Diseñar el enrutado es, en el fondo, ordenar esos huecos de lo general a lo particular.

Rutas vacías para excluir

El complemento natural de la prioridad es la exclusión. En el panel puedes registrar una route más específica y dejar su Worker en “None”: el tráfico que casa con ella se salta cualquier route más amplia y sigue su curso normal hacia el origen. Es la forma de decir “todo a mi Worker, excepto esto”.

Por ejemplo, sobre una zona que manda todo con */* a un Worker, una route api.ejemplo.com/* con Worker en “None” devuelve el control de ese subdominio al backend tradicional. Como la segunda es más específica, se impone sobre la comodín amplia. Es el patrón habitual en plataformas que sirven a muchos clientes con un solo Worker y reservan sus propios hostnames.