12 days ago
Custom domains on my gesso service all show "Active" in the
Networking panel (green checkmarks) but the edge returns TLS
Broken pipe / RST during ClientHello for every one.
Affected: gesso.work, www.gesso.work, *.gesso.work
Working baseline: liv-cappello-gesso.up.railway.app serves correctly
Edge IPs hit by curl, all RST mid-handshake:
- gesso.work → 66.33.22.106
- www.gesso.work → 66.33.22.68
- *.gesso.work (tested via livcappello.gesso.work) → 66.33.22.93
DNS verified correct (matches the CNAME targets Railway provided
in the Configure DNS Records panel). I removed and re-added all
three custom domains today; status returned to Active but TLS
still fails. A service restart didn't help.
Pinned Solution
12 days ago
Since the up.railway.app domain works and the custom domains reset during ClientHello, this doesn’t look like your app/container. That’s before HTTP ever reaches your service.
I’d verify it with SNI explicitly:
openssl s_client -connect gesso.work:443 -servername gesso.work -brief
openssl s_client -connect www.gesso.work:443 -servername www.gesso.work -brief
openssl s_client -connect livcappello.gesso.work:443 -servername livcappello.gesso.work -briefIf all three reset there while the Railway generated domain works, the failing layer is the custom-domain edge/cert mapping.
Only local things I’d still check: no stale AAAA records, no proxy/CDN in front, and that the wildcard was added as its own Railway custom domain, not assumed from the apex. But if DNS points to Railway’s provided targets and SNI still RSTs, I’d send Railway the openssl output + those edge IPs. Re-adding domains can show Active even when the TLS attachment/edge state is stuck.
3 Replies
12 days ago
This thread has been marked as public for community involvement, as it does not contain any sensitive or personal information. Any further activity in this thread will be visible to everyone.
Status changed to Open Railway • 12 days ago
12 days ago
Since the up.railway.app domain works and the custom domains reset during ClientHello, this doesn’t look like your app/container. That’s before HTTP ever reaches your service.
I’d verify it with SNI explicitly:
openssl s_client -connect gesso.work:443 -servername gesso.work -brief
openssl s_client -connect www.gesso.work:443 -servername www.gesso.work -brief
openssl s_client -connect livcappello.gesso.work:443 -servername livcappello.gesso.work -briefIf all three reset there while the Railway generated domain works, the failing layer is the custom-domain edge/cert mapping.
Only local things I’d still check: no stale AAAA records, no proxy/CDN in front, and that the wildcard was added as its own Railway custom domain, not assumed from the apex. But if DNS points to Railway’s provided targets and SNI still RSTs, I’d send Railway the openssl output + those edge IPs. Re-adding domains can show Active even when the TLS attachment/edge state is stuck.
11 days ago
Thanks testuser123! On my end --
- No stale AAAA records (the only AAAA results I see now are Cloudflare's — see workaround note below)
- Wildcard (*.gesso.work) is added as its own Railway custom domain in the Networking panel, not inherited from apex
- DNS points to the exact CNAME targets Railway provides for each of the three custom domains
- liv-cappello-gesso.up.railway.app serves valid TLS perfectly, confirming the service itself is healthy
I removed and re-added all three custom domains (gesso.work, http://www.gesso.work, *.gesso.work). Railway now shows them all "Active" with green checkmarks, but earlier (before the workaround) the SNI for each custom domain got RST during ClientHello on every Railway edge IP I tested. curl returned "Send failure: Broken pipe" immediately after ClientHello on all three, with no certificate offered.
To keep the site up while waiting for support, I had to put Cloudflare in front of all three records (proxied, Full SSL mode). So the openssl -servername tests you suggested now complete successfully — but against Cloudflare's edge, not Railway's:
$ openssl s_client -connect gesso.work:443 -servername gesso.work -brief
Connecting to 104.26.6.78
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN=gesso.work
Verification: OK
$ openssl s_client -connect www.gesso.work:443 -servername www.gesso.work -brief
Connecting to 172.67.74.221
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN=gesso.work
Verification: OK
$ openssl s_client -connect livcappello.gesso.work:443 -servername livcappello.gesso.work -brief
Connecting to 104.26.7.78
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN=gesso.work
Verification: OK
Those handshakes confirm the certs themselves are fine end-to-end — the issue seems to be Railway's edge cert binding for my custom domains. This is a temporary workaround ; the moment I flip back to "DNS only", the TLS handshakes fail again at Railway's edge.
11 days ago
Fixed, removed the Cloudflare workaround, all three custom domains serving valid certs directly now. Thanks!
Status changed to Solved mykal • 11 days ago