x-railway-fallback: true— cert VALID, DNS PROPAGATED, target port set
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: waw1The 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.appWhat 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):
- Delete + re-create the custom domain (new CNAME target), updated DNS, waited for propagation.
- Re-issued the certificate → went VALID.
- Redeployed the service several times → all SUCCESS.
- Confirmed the app listens on the target port and the domain's target port matches.
- 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!
Pinned Solution
a 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.
2 Replies
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
a 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.
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