20 days ago
Hey Railway team / community,
Running into the exact same issue as this thread:
https://station.railway.com/questions/fastly-returns-x-railway-fallback-for-cl-cf9a7b39
Two custom domains have been stuck in CERTIFICATE_STATUS_TYPE_VALIDATING_OWNERSHIP since they were created on 2026-04-19 — about two weeks. Didn't notice immediately because we have a Cloudflare Tunnel (cloudflared) in front rewriting the Host header, which masked it. Tried to cut over to Railway-direct routing today and discovered every request returns x-railway-fallback: true with "Application not found." That led me to look at GraphQL state, which showed the validation has been stuck since day one.
PROJECT
Project ID: 78d9bbcf-b3ae-4aa5-8541-2d8bf582060d (zealous-unity)
Environment: production (da829480-0d9a-49ef-8303-e031f99b1b87)
CUSTOM DOMAIN 1 (frontend)
Domain ID: 078ac15b-7846-43af-b463-5dd4ab2f7ae8
Domain: cv.emberlabs.ai
Service: frontend (a2db6294-182a-4c9e-a387-6d9aebcb7e62)
Created: 2026-04-19T21:08:53Z
Status: CERTIFICATE_STATUS_TYPE_VALIDATING_OWNERSHIP
cdnProvider: DETECTED_CDN_PROVIDER_CLOUDFLARE
cdnMode: "off"
dnsRecords[0].requiredValue: nilwka36.up.railway.app
dnsRecords[0].currentValue: "" (empty — verifier never returns a value)
dnsRecords[0].status: DNS_RECORD_STATUS_REQUIRES_UPDATE
CUSTOM DOMAIN 2 (backend)
Domain ID: 67c19da8-ec21-4aaf-9f79-5f5f7982bdbc
Domain: api-cv.emberlabs.ai
Service: backend (0e55e92e-5637-4718-bd82-2cb0e648f70a)
Created: 2026-04-19T21:08:54Z
Status: CERTIFICATE_STATUS_TYPE_VALIDATING_OWNERSHIP
cdnProvider: DETECTED_CDN_PROVIDER_CLOUDFLARE
cdnMode: "off"
dnsRecords[0].requiredValue: dchk98pz.up.railway.app
dnsRecords[0].currentValue: ""
dnsRecords[0].status: DNS_RECORD_STATUS_REQUIRES_UPDATE
Already verified everything I can from my side:
• CF DNS records correct: CNAMEs to nilwka36.up.railway.app and dchk98pz.up.railway.app
• Verify TXT records present: _railway-verify.cv.emberlabs.ai and _railway-verify.api-cv.emberlabs.ai with the right railway-verify=… values
• Public DNS resolvers (Google, Cloudflare 1.1.1.1, Quad9) all return the correct CNAME chain
• Cloudflare SSL/TLS mode = Full (NOT Full Strict), per your docs:
https://docs.railway.com/networking/domains/working-with-domains#adding-a-root-domain-with-www-subdomain-to-cloudflare
• Tested with both CF proxy ON (orange) and OFF (grey) — same x-railway-fallback result both ways. With grey cloud the request hits Railway directly with no CF in the middle, and Railway still won't route it. So this isn't a CF interference issue.
• TLS handshake to the Railway endpoint returns the wildcard *.up.railway.app cert. No cert was ever issued for cv.emberlabs.ai or api-cv.emberlabs.ai.
• Tried the dashboard's "One-click DNS Setup" Cloudflare integration — wrote the same records that were already there, no change.
So same pattern as the linked thread: cdnProvider detected as Cloudflare, cdnMode stuck "off", Fastly rejecting Cloudflare-origin traffic.
Asks (any one of these unblocks me):
1. Manually refresh the Fastly VCL routing for these two custom domains, OR
2. Flip cdnMode internally for the two domain IDs above (no public mutation exposes this), OR
3. If there's a known registration gap for first-level subdomains under .ai TLD, please flag — happy to re-test once engineering has a chance to look.
No production impact — staying on the cloudflared tunnel until this is resolved. Just tagging this so it doesn't sit forgotten for another two weeks.
Thanks!
Brandon (Ember Labs AI)2 Replies
Status changed to Open Railway • 20 days ago
20 days ago
Suggested Solution
The issue is a State Desync between Railway's control plane and the Fastly edge routing. Even though Cloudflare is detected, the cdnMode: "off" status indicates that the instruction to update the Fastly VCL (Varnish Configuration Language) was never triggered. This creates a "Catch-22": Railway won't issue the cert until ownership is validated, but validation fails because Fastly isn't routing the traffic to the project.
Proposed Fix Steps:
The "Hard Reset" Strategy: * Delete the custom domains from the Railway dashboard entirely.
In Cloudflare, switch the records to DNS Only (Grey Cloud).
Wait 10-15 minutes for the deletion to propagate through Railway's internal cache.
Re-add the domains. This forces a fresh attempt to flip the cdnMode flag during the initial creation.
Verify SSL Mode: Ensure Cloudflare is set to Full (Strict) after the initial validation if you're using Railway's managed certificates, though Full is usually sufficient.
Manual Sync (Engineer Required): Since you've confirmed that cdnMode is stuck at off via GraphQL, this often requires a Railway engineer to manually trigger a re-sync on the DomainService for your Project ID. This will force the cdnMode to cloudflare and push the hostname to the Fastly edge nodes.
Summary for Support:
"The domains are stuck because cdnMode is off despite Cloudflare being detected. Fastly isn't receiving the routing update. Please manually flip cdnMode to cloudflare or on for Domain IDs 078ac15b... and 67c19da8...."
athir-del
Suggested Solution The issue is a State Desync between Railway's control plane and the Fastly edge routing. Even though Cloudflare is detected, the cdnMode: "off" status indicates that the instruction to update the Fastly VCL (Varnish Configuration Language) was never triggered. This creates a "Catch-22": Railway won't issue the cert until ownership is validated, but validation fails because Fastly isn't routing the traffic to the project. Proposed Fix Steps: The "Hard Reset" Strategy: \* Delete the custom domains from the Railway dashboard entirely. In Cloudflare, switch the records to DNS Only (Grey Cloud). Wait 10-15 minutes for the deletion to propagate through Railway's internal cache. Re-add the domains. This forces a fresh attempt to flip the cdnMode flag during the initial creation. Verify SSL Mode: Ensure Cloudflare is set to Full (Strict) after the initial validation if you're using Railway's managed certificates, though Full is usually sufficient. Manual Sync (Engineer Required): Since you've confirmed that cdnMode is stuck at off via GraphQL, this often requires a Railway engineer to manually trigger a re-sync on the DomainService for your Project ID. This will force the cdnMode to cloudflare and push the hostname to the Fastly edge nodes. Summary for Support: "The domains are stuck because cdnMode is off despite Cloudflare being detected. Fastly isn't receiving the routing update. Please manually flip cdnMode to cloudflare or on for Domain IDs 078ac15b... and 67c19da8...."
16 days ago
SSL should not be set to Full (Strict). It should only be set to Full.
Full (Strict) may cause unexpected behavior.