18 days ago
DESCRIPTION
Outbound HTTPS calls from my service fail with "Invalid response body ... Premature close" whenever the upstream returns a large response. Small responses succeed; large ones get cut mid-body. This has been continuous for ~3 days.
ROOT CAUSE (identified via diagnostics)
Inside the container, /proc/sys/net/ipv4/tcp_mtu_probing = 0 (disabled). With MTU probing off, TCP uses a fixed MSS and relies on ICMP "Fragmentation Needed" for path-MTU discovery. If the real path MTU is smaller (overlay/tunnel) and ICMP is blackholed, large responses lose a fragment and the connection is torn down mid-body — surfacing as "Premature close."
WHY THIS MATCHES EVERY SYMPTOM
- Small responses succeed (fit without fragmentation): HTTP 402 error bodies, api.anthropic.com, api.cisa.gov, nvd.nist.gov, raw.githubusercontent.com.
- Large responses fail: api.openai.com (~100% failure), and api.openrouter.ai intermittently (small error bodies return fine; large completion bodies get cut).
- Reproduces in BOTH iad and sfo → not region-specific.
- curl to the same hosts from an external network succeeds → different path MTU, no blackhole.
- App-side retry (3x exponential backoff), 60s timeout, IPv4-first DNS, and toggling ipv6EgressEnabled all made no difference.
ERROR MESSAGES (samples)
warn: "...fetching https://api.openai.com/v1/chat/completions: Premature close"
error: "...fetching https://openrouter.ai/api/v1/embeddings: Premature close"
REQUESTED FIX (platform-side — I cannot modify /proc/sys at runtime)
Enable TCP MTU probing on the egress path for my containers:
net.ipv4.tcp_mtu_probing = 1
OR apply MSS clamping (clamp to PMTU) on egress so large TLS responses aren't blackholed.
QUESTIONS
- Can you apply tcp_mtu_probing=1 (or MSS clamp) platform-side for my service, and what's the ETA?
- Is this tracked as a broader platform issue? It affects any large-response upstream, not just OpenAI.
ENVIRONMENT
Service ID: a8e393fe-5c75-4b5b-beec-67c8ae6dd909 (Linkedin_Agent)
Environment: production (3561bea0-6f33-4355-9aed-545cb6122cc2)
Project: FeTo (be98b6f4-63de-4346-84d0-3c9b72108b3c)
Regions: iad and sfo (both affected)
I can re-test immediately once applied and run any diagnostic from a shell (curl -v, tracepath, ip link show, ss -i). Thank you.
Pinned Solution
18 days ago
Update — solved, and you were right brody: it was NOT a network/MTU issue. Railway's egress is fine.
Root cause: the official openai npm SDK (v4.96.0, which uses undici/fetch) was throwing "Premature close" on every call to api.openai.com from my container. The moment I swapped that one path to call the same OpenAI endpoint via axios instead of the SDK — same container, same network, same key — it works 100%.
So it's an openai-SDK/undici issue in my environment (Node 22.x + openai 4.96.0 on Railway), not the platform. axios-based calls to both api.anthropic.com and now api.openai.com succeed reliably.
Leaving the axios path on. If anyone knows the specific undici/openai-SDK interaction (keep-alive / connection reuse / HTTP keep-alive agent) behind this on Node 22, I'd be curious for the real fix so I can go back to the SDK — but for now axios is a clean workaround. Thanks for the push to question the wrong diagnosis.
3 Replies
Status changed to Awaiting Railway Response Railway • 18 days ago
18 days ago
I'm sorry to say this, but respectfully, your agent has led you to an entirely incorrect problem. Railway and I run services that talk to OpenAI on Railway without issues.
Going to open this thread up so the community can help you find the real issue.
Status changed to Awaiting User Response Railway • 18 days ago
18 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 • 18 days ago
brody
I'm sorry to say this, but respectfully, your agent has led you to an entirely incorrect problem. Railway and I run services that talk to OpenAI on Railway without issues. Going to open this thread up so the community can help you find the real issue.
18 days ago
Thanks brody, and fair enough — if Railway runs OpenAI traffic fine, then my MTU theory is almost certainly wrong. Appreciate you setting me straight before I went further down that path.
One thing I noticed that might point at the real cause: in my app, calls to api.anthropic.com (via axios) succeed reliably, while calls to api.openai.com fail — and the OpenAI ones go through the official openai npm SDK (v4.96.0), which uses undici/fetch under the hood. So the difference might be the HTTP client, not the network.
I've just added a path that calls the OpenAI API via axios instead of the SDK, to test exactly that. Will report back what happens.
If it's a known issue with the openai SDK / undici on Railway (keep-alive, HTTP/2, connection reuse, etc.), I'd love a pointer. Node 22.x, openai 4.96.0. Service ID a8e393fe-5c75-4b5b-beec-67c8ae6dd909 if useful. Thanks again.
Status changed to Solved muhammadfathyessa • 18 days ago
muhammadfathyessa
Thanks brody, and fair enough — if Railway runs OpenAI traffic fine, then my MTU theory is almost certainly wrong. Appreciate you setting me straight before I went further down that path. One thing I noticed that might point at the real cause: in my app, calls to api.anthropic.com (via axios) succeed reliably, while calls to api.openai.com fail — and the OpenAI ones go through the official openai npm SDK (v4.96.0), which uses undici/fetch under the hood. So the difference might be the HTTP client, not the network. I've just added a path that calls the OpenAI API via axios instead of the SDK, to test exactly that. Will report back what happens. If it's a known issue with the openai SDK / undici on Railway (keep-alive, HTTP/2, connection reuse, etc.), I'd love a pointer. Node 22.x, openai 4.96.0. Service ID a8e393fe-5c75-4b5b-beec-67c8ae6dd909 if useful. Thanks again.
18 days ago
Update — solved, and you were right brody: it was NOT a network/MTU issue. Railway's egress is fine.
Root cause: the official openai npm SDK (v4.96.0, which uses undici/fetch) was throwing "Premature close" on every call to api.openai.com from my container. The moment I swapped that one path to call the same OpenAI endpoint via axios instead of the SDK — same container, same network, same key — it works 100%.
So it's an openai-SDK/undici issue in my environment (Node 22.x + openai 4.96.0 on Railway), not the platform. axios-based calls to both api.anthropic.com and now api.openai.com succeed reliably.
Leaving the axios path on. If anyone knows the specific undici/openai-SDK interaction (keep-alive / connection reuse / HTTP keep-alive agent) behind this on Node 22, I'd be curious for the real fix so I can go back to the SDK — but for now axios is a clean workaround. Thanks for the push to question the wrong diagnosis.
Status changed to Awaiting Conductor Response Railway • 18 days ago
Status changed to Solved muhammadfathyessa • 18 days ago