Production custom domains failing TLS despite verified DNS
braedenlyman
PROOP

a month ago

Hi Railway Support,

I’m experiencing a production outage affecting both of my custom domains:

https://portal.braecodigital.com

https://www.braecodigital.com

Both applications work correctly through their Railway-generated domains. Their deployments are healthy, and the custom domains use the same working target port (8080).

Firefox reports the following error:

SSL_ERROR_RX_RECORD_TOO_LONG

SSL received a record that exceeded the maximum permissible length.

I have completed the following troubleshooting:

  1. Confirmed that both Railway-generated domains work.
  2. Confirmed that both applications are listening on port 8080.
  3. Added the exact CNAME and TXT verification records supplied by Railway to Namecheap.
  4. Confirmed that Railway recognizes the DNS records.
  5. Flushed my local DNS cache and cleared Firefox’s DNS cache.
  6. Tested using Cloudflare DNS (1.1.1.1) and Google DNS (8.8.8.8).
  7. Removed and re-added both custom domains once in Railway.
  8. Updated Namecheap with the newly generated CNAME records.
  9. Confirmed that there are no restrictive CAA records or conflicting DNS records.

The current records are:

portal.braecodigital.com

CNAME: 6554pkwq.up.railway.app

www.braecodigital.com

CNAME: neviiht7.up.railway.app

When the Railway targets are resolved directly, they return working Railway edge addresses:

6554pkwq.up.railway.app → 69.46.46.95

neviiht7.up.railway.app → 69.46.46.28

When I force the custom hostnames through those respective addresses, both sites return HTTP 200 with valid TLS:

portal.braecodigital.com via 69.46.46.95 → HTTP 200

www.braecodigital.com via 69.46.46.28 → HTTP 200

However, normal recursive resolution of both custom-domain CNAME chains returns:

18.204.152.241

TLS negotiation fails when traffic reaches that address. This behavior is reproducible through both 1.1.1.1 and 8.8.8.8.

Recreating the custom domains generated new Railway CNAME targets, but both new targets reproduced the same issue. This appears to be a Railway custom-domain DNS or edge-routing problem rather than an application, port, certificate, or Namecheap configuration issue.

Could you please investigate why these verified custom-domain CNAME chains are being routed to 18.204.152.241 instead of the working Railway edge addresses?

Thank you for your help.

Note: On this ticket the Service dropdown menu doesn't let me scroll through all my services - the bottom of the list gets cut off at the bottom of the screen.

Awaiting User Response$20 Bounty

3 Replies

Railway
BOT

a month 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 about 1 month ago


Try accessing the site from an incognito window, or a different browser/device.

You could also try using 1.1.1.1 as your devices's DNS, or a VPN.


0x5b62656e5d

Try accessing the site from an incognito window, or a different browser/device. You could also try using `1.1.1.1` as your devices's DNS, or a VPN.

braedenlyman
PROOP

a month ago

I have already tried that and didn't work


Does a VPN work?


Status changed to Awaiting User Response Railway 6 days ago


Welcome!

Sign in to your Railway account to join the conversation.

Loading...