@@ -18,16 +18,16 @@ The interface provides active feedback on valid and invalid entries. Valid entri
## Fetch
Custom Domains are considered the 'origin' as far as your request is concerned. That means calling `fetch()` on the initial request is, in most cases, an antipattern. Instead, create new `Request` objects to reference any external dependencies, or use Cloudflare's built in primitives via bindings.
Another side effect of the tight integration with Cloudflare DNS is that you can use your Custom Domains like you would any external dependency. Your Workers can `fetch()` Custom Domains and invoke their associated Worker, even if they're on the same Cloudflare zone. The newly invoked Worker is treated like a new top-level request, and will execute in a separate thread.
## Ordering
Custom Domains follow standard DNS ordering and matching logic. Custom Domains do not support wildcard records; as such an incoming request must match the hostname your Custom Domain is registered to. Other parts of the URI are ignored when executing this matching logic. For example, if you create a Custom Domain on `api.example.com` attached to your `api-gateway` Worker, a request to either `api.example.com/login` or `api.example.com/user` would invoke the same `api-gateway` Worker.
## Interaction with Routes
Custom Domains are evaluated before Route rules, but take lower precedence. [Routes](/workers/platform/routing/routes) defined on your Custom Domain will run first, but can optionally call the Worker registered on your Custom Domain. In our example above, a Custom Domain for `api.example.com` can point to our Worker `api`. A Route added to `api.example.com/auth` can point to our Worker `auth`. Using `fetch(request)` within the Worker `auth` will invoke the Worker `api`, as if it was a normal application server. This means you can stack your Workers on top of each other, creating layers of 'proxy' Workers and 'application' Workers.
