7 days ago
Running a Next.js service on Railway Pro. Need wildcard subdomain routing for multi-tenant SaaS (generic.ratioiq.app per customer).
Configuration:
- *.ratioiq.app added as custom domain on Next.js service, port 8080
- Cloudflare SSL/TLS: Full (not Strict)
- *.ratioiq.app CNAME → Railway-provided endpoint, proxied (orange cloud)
- _acme-challenge CNAME → Railway-provided authorize.railwaydns.net value, DNS only
- _railway-verify TXT record present and verified
Result: persistent 525 SSL handshake failed from Cloudflare. app.ratioiq.app (explicitly listed domain) works perfectly. Only the wildcard fails.
Tried: Full vs Full Strict, DNS only vs proxied, re-adding the domain multiple times, waiting 24h+. Same result every time.
This appears to be the same issue reported in tickets 8027afa8 and e544f733 on Railway Help Station. Those were marked resolved — can you check if Railway's cert provisioning for wildcard domains is working correctly on my account?
Service: ratioiq (Next.js production service)
Project: ratioiq-prod
Pinned Solution
6 days ago
The method that worked:
(1) add custom domain *.domain.app (domain = your domain)
(2) add CNAME, TXT, and _acme-challenge to Cloudflare, set to DNS Only
(3) Confirm TLS/SLL is FULL
(4) Disable Universal SLL from Edge Certificates
(5) Delete *.domain.app (domain = your domain) from Railway and wait a few minutes (forces Railway to clear cache)
(6) add the same *.domain.app back to Railway
(7) adjust the CNAME, TXT, and _acme-challenge to the new settings provided by Railway
(8) wait about 5 minutes for the green check in Railway
(9) go back to Cloudflare and enable Universal SSL, and turn on Proxy
(10) wait 5 minutes for the green cloud in Railway.
Thanks for the tips. I took those with a few extra steps and it resolved.
3 Replies
7 days ago
This thread has been opened as a public bounty so the community can help solve it. The thread and any further activity are now visible to everyone.
Status changed to Open Railway • 7 days ago
7 days ago
Since app.ratioiq.app works but *.ratioiq.app consistently returns Cloudflare 525, this does not look like a DNS verification issue. A 525 means Cloudflare reached the origin but could not complete the TLS handshake.
The first thing I'd verify is whether Railway is actually serving a wildcard certificate for arbitrary subdomains.
openssl s_client -connect app.ratioiq.app:443 -servername school.ratioiq.app
Inspect the certificate SANs:
openssl s_client -connect app.ratioiq.app:443 -servername school.ratioiq.app 2>/dev/null | openssl x509 -text -noout
Expected:
DNS:*.ratioiq.app
If the wildcard SAN is missing, Railway ownership verification may have succeeded while wildcard certificate provisioning did not complete.
To isolate Cloudflare from the equation, temporarily switch:
*.ratioiq.app
to:
DNS Only (grey cloud)
and test:
Results interpretation:
Works in DNS Only → Cloudflare ↔ Railway TLS handshake issue.
Fails in DNS Only → Railway is not serving a valid wildcard certificate.
Explicit domain works while wildcard fails → likely wildcard certificate attachment/provisioning issue rather than DNS.
I'd also compare the certificates returned for:
openssl s_client -servername app.ratioiq.app -connect app.ratioiq.app:443
vs
openssl s_client -servername school.ratioiq.app -connect app.ratioiq.app:443
If different certificates are presented, Railway's edge may not be associating the wildcard cert correctly with the service.
Given that:
_railway-verify passes
_acme-challenge exists
explicit domain SSL works
the evidence points more toward wildcard certificate provisioning/serving than DNS configuration.
7 days ago
That 525 is the Cloudflare→origin leg, not the browser side — it means Railway has no valid cert to present for the wildcard, so the handshake to the origin fails. app.ratioiq.app works because it's explicitly listed and got its own cert; the *.ratioiq.app cert just never got bound.
Why: with the wildcard proxied (orange), Railway's domain validator resolves *.ratioiq.app and sees Cloudflare's IPs instead of its own, so the domain sits in REQUIRES_UPDATE and the wildcard cert is never provisioned. Same root cause as the apex-cert threads.
What fixes it: flip *.ratioiq.app to DNS-only (grey) first, so Railway sees it pointing at itself and actually issues/binds the .ratioiq.app cert via your _acme-challenge. Confirm it's live with echo | openssl s_client -connect .up.railway.app:443 -servername x.ratioiq.app | openssl x509 -noout -subject — you want CN=.ratioiq.app. Once it's serving, switch back to proxied (orange) + SSL/TLS Full and the origin handshake succeeds, 525 gone. Don't use Flexible — Railway force-redirects HTTP→HTTPS so you'll hit a redirect loop. And if Railway won't bind the wildcard cert even on grey, that's the known cert-binding bug and only Railway can force-bind it — escalate with that framing.
6 days ago
The method that worked:
(1) add custom domain *.domain.app (domain = your domain)
(2) add CNAME, TXT, and _acme-challenge to Cloudflare, set to DNS Only
(3) Confirm TLS/SLL is FULL
(4) Disable Universal SLL from Edge Certificates
(5) Delete *.domain.app (domain = your domain) from Railway and wait a few minutes (forces Railway to clear cache)
(6) add the same *.domain.app back to Railway
(7) adjust the CNAME, TXT, and _acme-challenge to the new settings provided by Railway
(8) wait about 5 minutes for the green check in Railway
(9) go back to Cloudflare and enable Universal SSL, and turn on Proxy
(10) wait 5 minutes for the green cloud in Railway.
Thanks for the tips. I took those with a few extra steps and it resolved.
Status changed to Solved dev • 3 days ago