Wildcard Subdomains on Cloudflare Workers: Routing and TLS Boundaries

A hostname such as demo.instara.app can reach a Cloudflare Worker through one wildcard DNS record and one Worker Route. A deeper hostname such as web.demo.instara.app can resolve through the same wildcard DNS record and still fail before the Worker runs because the edge certificate does not cover that hostname.

That distinction matters because three independent mechanisms participate in the request:

DNS resolution
      |
      v
Worker Route matching
      |
      v
TLS certificate coverage

They all use wildcard syntax, but they do not have identical matching rules.

Wildcard DNS gets the hostname onto Cloudflare

For an originless Worker setup, a proxied wildcard DNS record can use the reserved IPv6 discard prefix as a placeholder:

Type:    AAAA
Name:    *
Content: 100::
Proxy:   Proxied

The important part is the proxy status. Cloudflare receives the request at its edge instead of sending the client directly to 100::. The placeholder does not identify a Worker and is not the Worker’s IP address.

A wildcard DNS record for *.instara.app is multi-level by default. In the absence of a more specific DNS record, it can resolve both:

demo.instara.app
web.demo.instara.app

This DNS behavior is broader than the certificate coverage provided by Universal SSL.

For a fixed hostname where the Worker is the application origin, Cloudflare recommends a Custom Domain because it creates the DNS record and certificate automatically. Custom Domains, however, require an exact hostname match and do not support wildcard DNS records. Dynamic subdomains therefore need a different routing arrangement.

The Worker Route decides which Worker executes

DNS only makes the hostname reachable through Cloudflare. The Worker Route associates a URL pattern with a Worker.

A Wrangler configuration for all first-level and deeper subhosts under instara.app can use:

{
  "name": "instara-worker",
  "main": "src/index.js",
  "compatibility_date": "2026-09-19",
  "workers_dev": false,
  "routes": [
    {
      "pattern": "*.instara.app/*",
      "zone_name": "instara.app"
    }
  ]
}

The route:

*.instara.app/*

matches subhosts such as:

demo.instara.app
alice.instara.app
web.demo.instara.app

but it does not match the apex hostname:

instara.app

If the apex must invoke the same Worker, add a second route instead of using *instara.app/*:

{
  "routes": [
    {
      "pattern": "instara.app/*",
      "zone_name": "instara.app"
    },
    {
      "pattern": "*.instara.app/*",
      "zone_name": "instara.app"
    }
  ]
}

The distinction is deliberate. A route beginning with *instara.app also matches names such as myinstara.app, because the wildcard can consume arbitrary characters. Using separate apex and subhost routes avoids that accidental match.

When several routes match, Cloudflare uses the most specific pattern. This makes it possible to send most subdomains to one Worker while reserving a hostname such as api.instara.app for a different Worker.

The Worker can derive tenant identity from the hostname

Once the request reaches the Worker, tenant routing can happen in code. A minimal Worker can validate the zone suffix and extract everything before .instara.app:

const ROOT_DOMAIN = "instara.app";

function getTenant(request) {
  const hostname = new URL(request.url).hostname.toLowerCase();
  const suffix = `.${ROOT_DOMAIN}`;

  if (!hostname.endsWith(suffix)) {
    return null;
  }

  const tenant = hostname.slice(0, -suffix.length);

  return tenant || null;
}

export default {
  async fetch(request) {
    const tenant = getTenant(request);

    if (!tenant) {
      return new Response("Tenant not found", {
        status: 404,
      });
    }

    return Response.json({
      tenant,
      hostname: new URL(request.url).hostname,
    });
  },
};

A request to:

https://demo.instara.app/api

produces a tenant value of:

demo

For:

https://web.demo.instara.app/api

the same function returns:

web.demo

That may be useful if the complete prefix is the tenant key. If the architecture treats web as an application name and demo as the tenant, the parser needs an explicit hostname schema instead of simply taking the entire prefix.

DNS can succeed while TLS still fails

This is the boundary that often causes confusion.

Cloudflare Universal SSL covers the zone apex and one level of subdomain:

instara.app          covered
demo.instara.app     covered
web.instara.app      covered

It does not, by default, cover deeper hostnames:

web.demo.instara.app
api.demo.instara.app

A browser can therefore resolve web.demo.instara.app through the wildcard DNS record, connect to Cloudflare, and then fail during the TLS handshake before the Worker executes.

Chrome commonly reports:

ERR_SSL_VERSION_OR_CIPHER_MISMATCH

The apparent contradiction disappears when the request is separated into stages:

web.demo.instara.app
        |
        | wildcard DNS resolves
        v
Cloudflare edge
        |
        | certificate does not cover hostname
        X
Worker never receives the request

A successful DNS lookup is not evidence that HTTPS certificate coverage is correct.

Wildcard certificates cover one hostname level

A certificate for:

*.instara.app

covers:

demo.instara.app
web.instara.app

but not:

web.demo.instara.app

To cover that deeper namespace, the certificate must include an appropriate hostname such as:

*.demo.instara.app

Cloudflare Advanced Certificate Manager supports multi-level subdomains, but each wildcard still covers only one subdomain level. Total TLS is another option: it can automatically issue individual certificates for proxied hostnames that are not covered by Universal SSL.

This certificate rule is independent of Cloudflare DNS wildcard behavior. DNS *.instara.app can be multi-level while TLS *.instara.app remains one level.

Prefer a one-level tenant namespace when possible

For a multi-tenant service, the simplest hostname model is usually:

{tenant}.instara.app

Examples:

demo.instara.app
acme.instara.app
customer-123.instara.app

That structure aligns three useful properties:

wildcard DNS    -> *.instara.app
Worker Route    -> *.instara.app/*
Universal SSL   -> *.instara.app

No per-tenant DNS record is required, one Worker can inspect the hostname, and Universal SSL covers the resulting first-level tenant hostnames.

A structure such as:

{app}.{tenant}.instara.app

is valid, but it changes the certificate requirement. If web.demo.instara.app and api.demo.instara.app are part of the public design, certificate provisioning becomes part of tenant onboarding rather than an incidental detail.

Treat the hostname as three separate configuration layers

The reliable mental model is not “the wildcard points to the Worker.” It is:

DNS:
Can this hostname resolve through Cloudflare?

Route:
If the request reaches Cloudflare, which Worker runs?

TLS:
Can Cloudflare present a certificate valid for this exact hostname?

For *.instara.app, a proxied wildcard DNS record and a wildcard Worker Route can route a large dynamic hostname space through one Worker. The TLS namespace still needs its own design. Keeping those layers separate makes errors such as ERR_SSL_VERSION_OR_CIPHER_MISMATCH much easier to diagnose and prevents a working wildcard DNS record from being mistaken for complete HTTPS support.