Custom domain returns 404 with
x-railway-fallback: true
— cert VALID, DNS PROPAGATED, target port set
tenderiopl
HOBBYOP

a month ago

Hi all — hoping someone has seen this before.

I added a custom domain to a web service. Everything looks correctly provisioned on both

sides (DNS propagated, certificate valid, target port set), but **every request to the custom

domain gets a 404 from the edge with the header x-railway-fallback: true** — as if the edge

has no mapping from that hostname to my service.

Symptom — the custom domain (served by the edge, never reaches the app):

$ curl -sI https://sub.example.com/
HTTP/1.1 404 Not Found
Server: railway-hikari
x-railway-fallback: true
x-railway-edge: waw1

The same service, same edge answers 200 OK on its Railway-provided *.up.railway.app

domain, so the app is healthy and listening — only the custom-domain → service mapping seems

missing.

DNS — a plain CNAME to the value Railway asked for, no proxy/CDN (no Cloudflare) in front:

sub.example.com  ->  <token>.up.railway.app

What Railway's dashboard/API reports for the domain:

  • Certificate: VALID

  • CNAME record: PROPAGATED (purpose = TRAFFIC_ROUTE)

  • Target port: set, and it matches the port the app listens on

  • Only one required record is listed (the CNAME). No TXT record is requested or shown as

    missing — even though the docs mention a TXT verification record, the dashboard never issued one

    for this domain, so there's nothing to add.

Already tried (no change):

  1. Delete + re-create the custom domain (new CNAME target), updated DNS, waited for propagation.
  2. Re-issued the certificate → went VALID.
  3. Redeployed the service several times → all SUCCESS.
  4. Confirmed the app listens on the target port and the domain's target port matches.
  5. Confirmed no proxy/CDN in front of the DNS record.

Question: has anyone hit a custom domain that stays stuck on x-railway-fallback: true (404)

even though cert + DNS + target port all check out? Is there a hidden verification step, or is this

an edge-routing entry that only Railway staff can re-register? Any pointers before I open a private

support thread would be great.

Thanks!

Solved$10 Bounty

Pinned Solution

Make sure to add the TXT record at _railway-verify.<DOMAIN> (where <DOMAIN> is the domain you’re trying to add). You can get the content for it from the verificationToken property under status.

2 Replies

Railway
BOT

a month ago

This thread has been opened as a bounty so the community can help solve it.

Status changed to Open Railway about 1 month ago


Make sure to add the TXT record at _railway-verify.<DOMAIN> (where <DOMAIN> is the domain you’re trying to add). You can get the content for it from the verificationToken property under status.


tenderiopl
HOBBYOP

a month ago

Yes — that was exactly it, thank you! Adding a TXT record at _railway-verify. with the value from status.verificationToken fixed it.

▎ For anyone hitting the same wall: my custom domain reported certificateStatus: VALID and the CNAME as PROPAGATED, yet every request returned 404 with x-railway-fallback: true. What threw me off is that status.dnsRecords only listed the CNAME (purpose TRAFFIC_ROUTE) — no TXT — so it looked like no verification record was needed. The requirement is actually exposed in separate fields on status: verified: false, verificationDnsHost: _railway-verify., and verificationToken: railway-verify=. Until that TXT is in place, verified stays false and the edge refuses to route the host (hence the fallback 404), even with a valid certificate and a propagated CNAME.

▎ Two things that cost me the time and might be worth documenting: (1) the docs page (networking/domains/working-with-domains) doesn't mention that a plain subdomain needs this _railway-verify TXT; (2) the API surfaces it in verificationToken/verificationDnsHost, not in dnsRecords, so if you only inspect dnsRecords you'll wrongly conclude no TXT is required. Thanks again!


Status changed to Solved 0x5b62656e5d about 1 month ago


Welcome!

Sign in to your Railway account to join the conversation.

Loading...