Hello Railway Support,

we are on the Pro plan and need assistance with what appears to be a Railway custom-domain verification and edge-routing issue affecting both our staging and production environments.

Both custom domains were created through Railway's public GraphQL API using customDomainCreate with the corresponding projectId, environmentId, and serviceId.

Affected domains:

1. Staging

   Custom domain: hub-staging.baier-gmbh.de

   Railway CNAME target: f2n5t7la.up.railway.app

   Working Railway service domain: web-production-aac61.up.railway.app

   Environment ID: 9e45ab1a-18f6-4483-bda3-d26f19d0a02e

   Custom domain ID: 85bd1fc8-b10a-4f29-b1bc-a40317057f7b

2. Production

   Custom domain: hub.baier-gmbh.de

   Railway CNAME target: 75iiqim7.up.railway.app

   Working Railway service domain: web-production-71005.up.railway.app

   Environment ID: 26b46151-a4d0-4a79-87ce-fb6db7061899

   Custom domain ID: f41550a5-7c86-4ac4-8629-2fbe685591f7

Project ID: 6ecabc50-4fc6-4400-8a82-094155e974b5

Web service ID: 8f936d20-a0a9-4bf0-9f81-1f1fd6a45bb8

The required CNAME and TXT records are present and return the exact values supplied by Railway. They resolve correctly through all four authoritative Dogado nameservers, Google Public DNS, and Cloudflare DNS. There are no competing A records and no restrictive CAA records.

TXT records:

_railway-verify.hub.baier-gmbh.de

railway-verify=8918fee9e46139adfab50d135c97938b8dde471aaea83c8eb3f13aa3b2bb62ae

_railway-verify.hub-staging.baier-gmbh.de

railway-verify=f96e91412d1f8251b826f1f37bd460870463ade77e05896f41d1362512752f1e

Railway nevertheless continues to display "Waiting for DNS update" for both domains.

HTTPS reaches Railway, but both custom domains return:

{"status":"error","code":404,"message":"Application not found"}

The responses contain x-railway-fallback: true and are served by the ams1 Railway edge. Recent request IDs are:

• Production custom domain: ufcdtMAnTFK95psjWVMv1w
• Staging custom domain: Yi29qGJ4TNeQun9yjUJq2g

We also tested the Railway CNAME targets directly. Both return the same Railway fallback 404 independently of our DNS hostnames:

• f2n5t7la.up.railway.app: request ID MDEwiIedS9Oz30HMjUJq2g
• 75iiqim7.up.railway.app: request ID oB_yRiVSROq0tdIP63j4Ww

At the same time, both Railway-provided service domains respond correctly and redirect to the application's login page. This confirms that the web service is deployed and reachable in both environments.

We also changed staging from targetPort 8080 to automatic port detection and redeployed it, with no change. Production still has targetPort 8080.

A clarification regarding the initial automated diagnosis: serviceDomains and customDomains are separate collections in Railway's public API. The custom hostnames are therefore not expected to appear in serviceDomains. Also, the staging deployment is present and reachable through web-production-aac61.up.railway.app.

We queried both current CustomDomain objects directly through Railway's

GraphQL API. For both domains, status.verificationToken matches the publicly

published TXT record byte-for-byte, certificateStatus is

CERTIFICATE_STATUS_TYPE_VALID, requiredValue equals currentValue, and the DNS

record status is DNS_RECORD_STATUS_PROPAGATED.

This rules out the missing, malformed, duplicated, or stale verification-token

issues reported in similar Central Station cases. Railway's dashboard still

shows "Waiting for DNS update", which contradicts the status returned by the

public API.

Could you please:

1. Inspect the internal verification and routing state for both custom domain IDs and explain why the dashboard still shows "Waiting for DNS update" despite the API reporting VALID and PROPAGATED.
2. Reconcile or repair the hostname-to-service routing associations at the Railway edge.
3. Confirm whether customDomainCreate through the public API can leave the verification or routing association in a stale state.
4. If Railway considers either DNS record invalid, provide the exact expected and observed values stored in the control plane.

This has persisted well beyond the documented DNS and certificate propagation period. Please let us know before deleting or recreating either domain, as production URL changes require coordinated authentication, CORS, and cron configuration updates.

Thank you.