2 months ago
Hi Railway team,
Our production backend is seeing a high volume of intermittent outbound TLS failures when calling https://api.joinslash.com. This is ongoing — we are getting many errors every hour.
Slash confirmed the requests never reached their API (they checked our API key and found no errors on their side). The connection drops before the TLS handshake completes:
Client network socket disconnected before secure TLS connection was established
Destination: https://api.joinslash.com (HTTPS :443)
Replica/container id from logs: c32120c9
Impact: production jobs fail frequently; some user-facing flows (e.g. deposit credit) have to be handled manually
Could you check outbound connectivity / TLS from this service’s region? Happy to share project, service, and deployment IDs.
Thanks.
3 Replies
2 months ago
We've looked into this from our side and haven't found anything on the Railway platform that explains what you're seeing, so working it out means digging into your specific setup.
That's exactly what the Railway community is good at, so we'd like to open your thread as a community bounty. Railway pays a bounty to the community member who solves it, and threads like this usually get picked up quickly.
Opening it makes this entire thread public, including everything already posted. Nothing becomes public until you decide. Use the buttons below.
- Open to the community - Before you click, take a moment to edit or remove anything you'd rather not share. The thread becomes publicly visible right away.
- Keep it private and close the thread - Nothing becomes public and the thread closes.
Status changed to Awaiting User Response Railway • about 2 months ago
2 months 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 2 months ago
a month ago
We’re on multi-region, so Railway Static Outbound IP isn’t an option.
We worked around it by adding retries when we see network timeouts like:
{"kind":"network","errorMessage":"Error","errorCode":"ETIMEDOUT","causeCode":"ETIMEDOUT"}
Users may wait an extra 1–2 seconds occasionally. Looking at the logs, every ETIMEDOUT only needed one retry — we haven’t seen three ETIMEDOUTs in a row on the same request.
a month ago
Outbound IPv6
Enable your service to make outbound connections to IPv6 destinations.
that was fixed when i enabled it
Attachments
Status changed to Solved votien1235 • about 1 month ago