Thanks, masteraiwork10-cyber — your diagnosis matched what I noticed. The *.fleetdata.pro wildcard on my Django Backend is verified (CNAME + _acme-challenge + _railway-verify TXT in Cloudflare) but does not route new subdomains. hermes/tva/public reach Django; demo and random hosts (zzztest999) got empty edge 404s on the same IP until explicitly registered.

Option 1: I had no individual subdomain entries visible in Railway Networking — only the wildcard. So there was nothing to delete. hermes/tva/public still routed (likely grandfathered).

Option 2: This worked. I registered demo.fleetdata.pro explicitly on the backend with CNAME + _railway-verify.demo TXT in Cloudflare. After Railway showed Active, demo returned 302 + Django 401 JSON on /api/token/pair.

It's still unclear why a fully verified *.fleetdata.pro wildcard does NOT route all subdomains, requiring explicit per-host registration for each new tenant?

Your Option 2 result is the decisive test: DNS, TLS and Django are healthy. The empty 404 with Railway/Hikari headers means the edge had no usable host route for demo; adding an exact demo.fleetdata.pro custom-domain object created that route and immediately restored the Django response.

That is a workaround, not the expected wildcard model. Railway's current domain documentation says a verified *.fleetdata.pro wildcard supports arbitrary first-level subdomains. The networking limits also say an exact subdomain and its wildcard cannot overlap unless they are owned by the same service. Given the history you mentioned, the likely discriminator is an old exact-host object attached to another/deleted service or an orphaned edge route that shadows the wildcard even though it is no longer visible on the Django service's Networking panel.

I would resolve it without touching the healthy app or wildcard DNS:

1. Inventory domain objects across the whole project/environment, not only the current service panel. Use railway domain list --service <service> --environment <environment> for each relevant service and the Public API's custom-domain list/status operations. Record domain ID, owning service ID, target port and certificate/DNS status for *.fleetdata.pro, demo, hermes, tva and public.
2. If an exact hostname is attached to the wrong/deleted service, delete only that exact custom-domain object there. Do not remove the wildcard, Cloudflare records or a healthy exact route first. Wait for the change to show applied/Active.
3. Test a brand-new hostname that has never been registered, for example wildcard-probe-20260808.fleetdata.pro, and capture X-Railway-Request-Id, X-Railway-Edge, status and response headers. A Django response proves the wildcard route is working; an empty Hikari 404 proves the wildcard object is still absent from the edge host-route table.
4. If the API lists only the active wildcard on the correct service and the fresh hostname still returns the empty edge 404, this needs Railway staff to rebuild/remove the stale route index. Send the wildcard domain ID, service/environment IDs and one paired working/failing request ID. The exact-host registration is a safe temporary mitigation, but you should not need one Railway domain object per tenant.

Keep the Cloudflare wildcard CNAME, verification TXT and unproxied _acme-challenge record exactly as Railway generated them. Current docs also require Universal SSL and Full SSL/TLS for first-level Cloudflare wildcards. Since the same wildcard certificate already serves both working and failing names, certificate issuance is not the remaining fault here.

Official references:

• https://docs.railway.com/networking/domains/working-with-domains
• https://docs.railway.com/networking/public-networking/specs-and-limits
• https://docs.railway.com/integrations/api/manage-domains