Hi,

Following up with some additional diagnostics that confirm the issue is on Railway's routing side, not DNS.

DNS is fully propagated:

• CNAME resolves correctly: portfolio.usethesio.app → portfolio-os-production-012e.up.railway.app
• Both domains resolve to the same IP: 66.33.22.160
• SSL cert is valid, issued by Let's Encrypt for portfolio.usethesio.app (expires Aug 21 2026)
• TLS handshake completes successfully

The problem — Railway edge isn't routing the custom domain:

• The connection reaches 66.33.22.160 (Railway's edge) and completes the TLS handshake
• The request then hangs and times out — no HTTP response is ever returned
• The direct Railway domain (portfolio-os-production-012e.up.railway.app) returns 200 OK instantly

This confirms the SSL cert was provisioned correctly but the internal routing table entry for portfolio.usethesio.app is not wired to my service. DNS warmup is complete on my end — the fix needs to happen on Railway's backend.

Could you force-rebind the custom domain routing for this service? Happy to provide any additional info needed.

Thanks

Solved: custom domain stuck on VALIDATING_OWNERSHIP (the missing _railway-verify TXT record)

Posting this in case it helps anyone else. My custom domains sat on VALIDATING_OWNERSHIP for days and never issued a Let's Encrypt cert. The browser kept getting the generic *.up.railway.app certificate, so every branded URL threw a "not secure" error even though the app itself was live on its .up.railway.app URL.

Root cause: each Railway custom domain needs two DNS records, not one:

The traffic CNAME: www.example.com → xxxxxxxx.up.railway.app

An ownership TXT: _railway-verify.www.example.com → railway-verify=

I had only added the CNAME. Without the _railway-verify TXT, Railway never confirms you own the domain, so it never requests the certificate and just sits at VALIDATING_OWNERSHIP indefinitely.

Why it was easy to miss: Railway expects both records, but if you add the CNAME programmatically (or copy only the CNAME), the TXT slips through. If you pull domain status from the public API, note that the verification TXT does not show up in the dnsRecords list (that only returns the CNAME). It lives in separate fields on the domain status: verificationDnsHost (the TXT name, e.g. _railway-verify.www) and verificationToken (the full value, already prefixed with railway-verify=). The dashboard's custom-domain panel shows both records too.

The fix:

Grab the verify TXT for each domain (dashboard, or verificationDnsHost / verificationToken via API).

Add it in your DNS provider, DNS-only / not proxied:

_railway-verify.www.example.com TXT railway-verify=

_railway-verify.api.example.com TXT railway-verify=

Confirm it resolves on your provider's authoritative nameservers (not just a public resolver, which can cache an earlier empty answer for a minute):

dig TXT _railway-verify.www.example.com @

Wait. Railway re-checks DNS on its own cycle. For me, once the TXT was visible, the subdomains flipped verified → ISSUING → VALID within about a minute and served the branded cert automatically.

Bonus, if you're on Cloudflare and your root/apex domain stays stuck even with the TXT in place:

The apex won't validate on Cloudflare DNS-only because Cloudflare flattens the root CNAME into A records, so Railway can't see the apex pointing at it. Trying to force a Railway cert on the apex is a dead end with this setup. What I did instead: redirect the apex to www at Cloudflare's edge, so the apex never needs a Railway cert.

Page Rule: example.com/* → 301 forward to https://www.example.com/$1

Set the apex record to proxied (orange) so Cloudflare's edge serves it. Cloudflare's Universal SSL covers the apex, and the Page Rule returns the redirect before traffic ever reaches the origin.

Keep www and api DNS-only (grey) so Railway serves their own certificates.

End result: www and api get valid Railway/Let's Encrypt certs, and the apex returns a valid 301 to www over HTTPS.

TL;DR: if a custom domain is stuck on VALIDATING_OWNERSHIP, you're almost certainly missing the _railway-verify TXT record (it's separate from the CNAME, and the API hides it outside the dnsRecords list). Add it, wait a minute, done. Apex on Cloudflare is a separate flattening issue, best solved by redirecting apex to www.

your diagnostics are solid — tls completes, edge never forwards = the custom domain → service mapping is orphaned in railway's routing table. nothing else available from your side.

escalation that's worked for similar:

• tag @brody in this thread with the project/service/environment ids you've already shared. he handles routing and edge stuff.
• if no response in a few hours, open a ticket at help.railway.com with the same diagnostics. the "Domain is in use by service portfolio-os" error from the dashboard ui is the key tell — they need to find and clear that orphaned record on their end.

once they clear it, deleting + re-adding via customDomainCreate (or just adding through the dashboard again) should work cleanly. no need to wait for SSL re-issuance since the cert is already provisioned for the hostname.

"@brody Project: 055df035-56b9-4f10-bfc6-d96603292064 Service: motor-auditoria Domain: auditoria.franciscoblanco.net — custom domain stuck in DNS verification for 24+ hours. CNAME and TXT both correct. Please fix the orphaned routing entry."

@brody — following up. The orphaned DB entry is cleared ( customDomains: []  via GraphQL API) and DNS is fully correct — CNAME ✓,  _railway-verify  TXT ✓, SSL cert already issued by Let’s Encrypt ✓. However  customDomainCreate  still returns  INTERNAL_SERVER_ERROR  for  portfolio.usethesio.app . There must be a shadow routing record at the edge layer. Could you clear it?

• Project:  781974a1-f55b-4b7f-ae56-e8f64d542bce 

• Service:  bfa4ab53-32dc-4aed-8937-a601e19d119b 

• Environment:  02ecbded-97da-4719-bb45-5b381dc64e80