5 days ago
We are making long-running POST requests to https://api.anthropic.com/v1/messages from our Railway service (US West region). Requests that take 2-3 minutes to complete are consistently failing with "Invalid response body: Premature close" / "Error: Premature close". This started today July 1, 2026. We have tried both streaming and non-streaming requests — both fail. The Anthropic API status page shows all systems operational. We believe Railway's proxy or egress infrastructure is dropping long-lived outbound connections before they complete.
Confirmed via node test inside Railway console: a minimal streaming request to api.anthropic.com/v1/messages with max_tokens=100 fails immediately with "Premature close". This rules out our application code, connection pooling, request duration, and payload size as causes. The failure is at the Railway network/egress layer. We need investigation of outbound connections from our service to api.anthropic.com. Please help!
2 Replies
5 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 5 days ago
5 days ago
Recently, Node have issue with fetch (issue link), to fix it, you have to pin the version to 22.23.1 or newer, if you're using railpack (railway default builder) you can easily set the node version via environment variable RAILPACK_NODE_VERSION=22.23.1
5 days ago
Confirming @mayoriii's diagnosis (nodejs/node#63989) — we hit this exact issue and
fully resolved it. One important correction to the fix, because it burned us:
The regression was INTRODUCED in Node v24.17.0. So "22.23.1 or newer" is misleading —
24.17.0 is "newer" and is BROKEN. If you pin engines.node to "24" or any bare major,
it re-resolves to the latest patch (24.17.0) and you stay broken. We did exactly this
and lost hours to it.
Pin an EXACT pre-regression patch:
- 24.15.0 or 24.16.0 (confirmed clean — we run 24.15.0 in prod now, 100% fixed), or
- 22.23.1 on the 22.x line if you prefer staying on 22.
On Railpack, pin BOTH to be safe: engines.node = "24.15.0" (exact, not "24") AND set
RAILPACK_NODE_VERSION=24.15.0. Railpack honors the exact patch; a bare major does not.
Verify it actually landed: check your live Node version after deploy (process.version
or a /health field) reads EXACTLY v24.15.0 — not just "v24.x". A pin that silently
didn't take looks identical to one that didn't work.
Your symptom fits this: minimal max_tokens=100 request failing IMMEDIATELY (not a
timeout) is the socket-reuse regression, not request duration. Same class of bug
whether the endpoint is api.anthropic.com or api.openai.com — it's the Node fetch
layer, not the API.