[Bug] ECONNRESET bursts from Cloudflare ZAG edge during streaming responses

Bug Description
Claude Code intermittently fails with ECONNRESET on my home fibre connection.
The same machine on a phone hotspot never reproduces it. The difference tracks
exactly with which Cloudflare edge my traffic lands on.

WHAT I SEE

• Home connection routes to colo=ZAG. ECONNRESET several times per working

session, most often during longer streaming responses.

• Phone hotspot routes to colo=VIE. Zero failures, same machine, same session.
• Confirmed on both networks via https://api.anthropic.com/cdn-cgi/trace

ENVIRONMENT

Claude Code 2.1.234 / Node v22.16.0 / Ubuntu 24.04.4 LTS, kernel 7.0.0-28-generic
ISP: Hrvatski Telekom (AS5391), fibre, Croatia.
Static public IPv4 directly on the router WAN, not behind CGNAT. I can supply
the address privately if it helps correlate against edge logs.

PACKET CAPTURE

Resets arrive from the far end in simultaneous bursts:

15 resets within ~3 ms at 11:38:37
12 resets within ~3 ms at 11:39:14
further resets at 11:39:50

All at TTL 56. My path to the API is 7 hops, so packets sent at 64 arrive at

1. A reset forged by my router would arrive at 63-64, one from ISP access

equipment around 62. Nothing appears in that range, so the resets are genuine
and come from the far end. IP id 0 with DF set indicates a Linux sender rather
than an injecting middlebox.

The burst pattern is what stands out. A per-flow problem (NAT eviction, idle
timeout, path loss) kills one connection at a time. Simultaneous teardown of
10-15 connections looks like a server-side event on a pooled connection set.

LOCAL NETWORK RULED OUT

Two continuous pings through a +/-90 s window around a reproduced ECONNRESET:

to my router (Wi-Fi link only, no NAT): 180 replies, 0 missing
to 1.1.1.1 (Wi-Fi + NAT + line): 181 replies, 0 missing

Neither dropped a packet while the connection was being reset, and there were
no kernel wireless events in the window.

Also measured clean on the home line:

• 0% packet loss across 250 packets to each of two public resolvers
• 7 hops to the API, 0% loss at every hop over 100 mtr cycles, direct

Cloudflare peering at CIX Zagreb

• Path MTU 1492 (correct for PPPoE); 50 MB sustained HTTPS at ~225 Mbps,

no stall

• 60/60 sequential HTTPS connections succeeded; 300 requests at 60-way

concurrency, 0 failures

• Idle sockets survived 900 s, ruling out a NAT idle timeout
• DNS consistent and fast across the router and three public resolvers
• No global IPv6 on either network, so IPv6 is not in play
• TLS chain verifies clean, no interception

Worth noting that the home Wi-Fi link measures better than the hotspot link
that works: gateway RTT 7 ms avg / 20 ms max at home, versus 81 ms avg /
1116 ms max on the hotspot. The worse link is the reliable one, which argues
against any link-quality explanation.

QUESTIONS

• Do other reports cluster on colo=ZAG?
• Is anything at that edge closing pooled keep-alive connections in batches?
• Should CLAUDE_CODE_MAX_RETRIES absorb resets of this shape? They currently

surface to the user rather than being retried.

Happy to supply full pcaps, mtr output, or run further captures.

Environment Info

• Platform: linux
• Terminal: alacritty
• Version: 2.1.234
• Feedback ID: 5b663eed-bdd5-4012-b494-c510ff18efc1

Errors

[]