8 days ago
We run a Node.js service on Railway Pro that holds a long-lived, high-throughput bidirectional WebSocket with Twilio Voice Media Streams — continuous audio at ~50 frames/sec (~20ms cadence) in both directions, for the full duration of a phone call.
The problem: these WebSocket connections drop at random points mid-call — anywhere from ~7 seconds to ~2 minutes in. When it happens:
• Our server is completely healthy — no errors, no exceptions, the process keeps running and serving other requests normally.
• There are no application-level logs at the drop; the socket just goes silent.
• The remote peer (Twilio) reports the connection as severed with a WebSocket protocol error.
• We have instrumented our side thoroughly: no event-loop stalls, no send backpressure, no socket errors, and we send only valid frames. Inbound data is flowing normally right up to the instant it drops.
This matches the pattern in your community threads about the proxy terminating long-lived connections and TCP_OVERWIN windowing errors on high-throughput WebSockets.
Details:
• Plan: Railway Pro
• Service: kitchenline (project celebrated-truth), single replica
• Endpoint: wss://kitchenline-production.up.railway.app/api/realtime/ws (default *.up.railway.app domain)
• WebSocket server: the ws library (Node), perMessageDeflate at library default
Questions:
- Does Railway's proxy terminate or interfere with long-lived, high-throughput WebSocket connections like this? If so, what configuration keeps them stable?
- Is routing the WebSocket through a linked custom domain (instead of the default *.up.railway.app) the recommended path here?
- Are there proxy-level settings (TCP proxy, keepalive/idle windows, perMessageDeflate) we should adjust for a continuous media stream?
- For a low-latency, always-on media WebSocket at this throughput, is the Railway proxy a supported use case, or do you recommend a different setup?
Happy to provide CallSids, timestamps, or logs. Thanks.
1 Replies
8 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 • 8 days ago
8 days ago
This is a Railway side issue, not your app. Central Station has an active report of the US East public proxy dropping established TCP connections to Postgres since around Jul 18 04:00 UTC, described as ongoing and not showing up on the status page. Once you're on a custom domain your WebSocket traffic rides that same edge layer, so the symptom class lines up even though the protocol is different. There is no client side fix for a proxy dropping you underneath. StatusGator logged an intermittent connectivity incident affecting Outbound Static IPs in US East starting around 6pm on Jul 18, plus a short minor incident shortly after. Railway's own status page shows US East Networking Public uptime already down for July, consistent with degradation starting mid month rather than a one off blip.