24 days ago
Custom domain api.abccount-teams.com on service ABC-Teams-Backend, project 12ea8f9a-5505-4d81-a1ea-258c3bf097b7, production environment.
The domain shows verified with a green check in the dashboard, but no TLS certificate is served. The connection reaches port 443 and the handshake fails immediately — Chromium returns ERR_SSL_PROTOCOL_ERROR, curl returns SEC_E_INVALID_TOKEN and exits 35.
Checking the service config shows only Railway-generated subdomains in serviceDomains. The custom domain is not attached, and re-applying it from the dashboard does not persist.
abc-teams-backend-production.up.railway.app on the same service returns {"ok":true}, so the deployment and its Railway-issued certificate are fine.
DNS is a single CNAME to z3bvuymg.up.railway.app with the _railway-verify TXT record present. I removed and re-added the custom domain, which did not resolve it. Failing for roughly four hours.
This blocks all ProMax and Teams traffic, which routes exclusively through this hostname.
Pinned Solution
24 days ago
I'm able to access the /health route just fine on the custom domain. Try using an incognito browser or a different device/network.
Attachments
8 Replies
24 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 24 days ago
24 days ago
I'm able to access the /health route just fine on the custom domain. Try using an incognito browser or a different device/network.
Attachments
24 days ago
Confirmed — you were right. /health returns {"ok":true} from my phone on cellular. The failure is local to my network; DNS-over-HTTPS didn't help, so it's something on this machine or the router rather than resolution. Certificate and service are fine. Thanks for checking from your side — that was the test that settled it.
Status changed to Solved 0x5b62656e5d • 24 days ago
21 days ago
Reopening — I marked this resolved because it worked from my phone, but it has never worked from this machine and I now have hard evidence it is not client-side.
Update with hard evidence. openssl s_client -connect api.abccount-teams.com:443 -servername api.abccount-teams.com -tls1_2 returns:
error: packet length too long
no peer certificate available
SSL handshake has read 5 bytes and written 232 bytes
Port 443 is answering with data that is not a TLS record. No certificate is offered at all. Four independent TLS stacks agree — OpenSSL, Windows schannel, Chromium and Firefox — so this is not client-side.
abc-teams-backend-production.up.railway.app on the same service works normally from the same machine. DNS resolves to 69.46.46.123, matching the CNAME Railway specified. It works from other networks, which suggests a specific edge node.
Please check certificate provisioning on the node serving 69.46.46.123 for this hostname.
Evidence here: openssl s_client -connect api.abccount-teams.com:443 -servername api.abccount-teams.com returns packet length too long and no peer certificate available after reading 5 bytes. Four independent TLS stacks — OpenSSL, schannel, Chromium, Firefox — all report the same: port 443 is answering with non-TLS data. abc-teams-backend-production.up.railway.app on the same service works normally. DNS resolves to 69.46.46.123, matching the CNAME you
Status changed to Awaiting Conductor Response Railway • 21 days ago
Status changed to Awaiting User Response Railway • 21 days ago
21 days ago
I dont use vpn
Status changed to Awaiting Conductor Response Railway • 21 days ago
21 days ago
Well, did you try?
I'm able to access the URL just fine without any issues.
Status changed to Awaiting User Response Railway • 21 days ago
Status changed to Awaiting Conductor Response Railway • 21 days ago
morpheous7
21 days ago
It works from other networks — my phone on cellular reaches it fine, and I understand you do too. It has never worked from this connection, and it is not client-side.
openssl s_client -connect api.abccount-teams.com:443 -servername api.abccount-teams.com -tls1_2
CONNECTED(000001B0)
error:0A0000C6:SSL routines:tls_get_more_records:packet length too long
no peer certificate available
SSL handshake has read 5 bytes and written 232 bytes
Five bytes read, no certificate offered. The server is answering port 443 with something that is not a TLS record. Four independent TLS stacks report the same — OpenSSL, Windows schannel, Chromium and Firefox — so this is not a client certificate store or a browser issue.
From the same machine, abc-teams-backend-production.up.railway.app works normally. DNS resolves to 69.46.46.123, matching the CNAME you specified.
Given it works from other networks and not this one, is 69.46.46.123 anycast? If different networks reach different edge nodes, the certificate may be provisioned on some and not others. Could you check the node serving Comcast traffic out of Houston?