Routes allow users to map a URL pattern to a Worker script to enable Workers to run on custom domains.
For zones proxied on Cloudflare*, route patterns decide what (if any) script is matched based on the URL of that request. Requests are routed through a Workers script when the URL matches a route pattern assigned to that script.
Cloudflare Site routes are comprised of:
- Route URL (see )
- Worker script to execute on matching requests
- Failure mode for rate-limited accounts on the free plan (see )
Routes with *.workers.dev
To claim a
*.workers.dev subdomain, such as
my-subdomain.workers.dev, select the Workers icon on your account home, or Workers then Manage Workers on your zone's dashboard, and begin setup on the right side of the Workers dashboard under Your subdomain. The
name field in your Worker configuration is used as the secondary subdomain for the deployed script, (e.g.,
Route patterns look like this:
This pattern would match all HTTPS requests destined for a subhost of
example.com and whose paths are prefixed by
A pattern to match all requests looks like this:
The only supported operator is wildcard
*which matches zero or more of any character.
Route patterns may not contain infix wildcards or query parameters, e.g. neither
example.com/?foo=*are valid route patterns.
When more than one route pattern could match a request URL, the most specific route pattern wins. For example, the pattern
www.example.com/*would take precedence over
*.example.com/*when matching a request for
https://www.example.com/. The pattern
example.com/hello/*would take precedence over
example.com/*when matching a request for
Route pattern matching considers the entire request URL, including the query parameter string. Since route patterns may not contain query parameters, the only way to have a route pattern match URLs with query parameters is to terminate it with a wildcard,
Route patterns are case sensitive, e.g.
example.com/images/*are two distinct routes.
A route can be specified without being associated with a Worker; this will act to negate any less specific patterns. For example, consider this pair of route patterns, one with a Workers script and one without:
*example.com/images/cat.png -> <no script>*example.com/images/* -> worker-script
In this example, all requests destined for example.com and whose paths are prefixed by
/images/ would be routed to
worker-script, except for
/images/cat.png, which would bypass Workers completely. Requests with a path of
/images/cat.png?foo=bar would be routed to
worker-script, due to the presence of the query string.
Here is the full set of rules governing route pattern validity:
Route patterns must include your zone
If your zone is
example.com, then the simplest possible route pattern you can have is
example.com, which would match
https://example.com/, and nothing else. As with a URL, there is an implied path of
/ if you do not specify one.
Route patterns may not contain any query parameters
https://example.com/?anything is not a valid route pattern.
Route patterns may optionally begin with http:// or https://
If you omit a scheme in your route pattern, it will match both http:// and https:// URLs. If you include http:// or https://, it will only match HTTP or HTTPS requests, respectively.
Hostnames may optionally begin with
If a route pattern hostname begins with
*, then it matches the host and all subhosts. If a route pattern hostname begins with
*., then it matches only all subhosts.
Paths may optionally end with
If a route pattern path ends with
*, then it matches all suffixes of that path.
Subdomains must have a DNS Record
All subdomains must have a to be proxied on Cloudflare and used to invoke a Worker. For example, if you want to put a worker on
myname.example.com, and you've added
example.com to Cloudflare but have not added any DNS records for
example.com, any request to
myname.example.com will result in the error