{"slug": "workaround-for-claude-code-api-error-unable-to-connect-to-api-econnreset", "title": "Workaround for Claude Code API Error: Unable to connect to API (ECONNRESET)", "summary": "A developer identified the root cause of Claude Code API ECONNRESET errors on a specific home network: the macOS auto-tuned TCP send buffer causes large uploads to burst into the DSL modem's upstream buffer, which tail-drops at ~2.29 MB. Capping the send buffer to 256 KiB prevents the overflow and resolves the issue without throughput loss.", "body_md": "Fix for Claude Code (and any large HTTPS upload) failing with\n`API Error: Unable to connect to API (ECONNRESET)`\n\non a specific home network.\n\n- Short Claude requests always work; long sessions reset after ~5–13 min.\n- Works fine on a phone hotspot, fails on home Wi-Fi.\n- Debug log shows the same request retried 11 times, each dying at a\nconsistent\n**~15 s**, then`code=ECONNRESET`\n\n.\n\nIt is **not** MTU, IPv6, a proxy, the client, or idle-connection reaping —\nall ruled out by testing. It is the **upload** direction.\n\nEvery Claude request uploads the full conversation context as the POST body.\n\n- macOS auto-tunes the TCP send buffer up to\n`net.inet.tcp.autosndbufmax`\n\n(stock default**4 MB**). - A large body lets a single connection burst multiple MB into the DSL modem's upstream buffer all at once.\n- That buffer tail-drops at ~2.29 MB on this line. The flow stalls and the\nserver resets it ~15 s later → Claude retries 11× →\n`ECONNRESET`\n\n.\n\nSmall requests never burst that far, so they succeed. The hotspot's path\nabsorbs the burst differently, so it succeeds too. The uplink itself is fast\n(~24 Mbit measured) — the only problem is the **unpaced burst**.\n\nCapping the send buffer to **256 KiB** bounds in-flight data far below the\n2.29 MB overflow point, so a single connection can never overflow the modem\nbuffer. The link's bandwidth-delay product is only ~22 KB, so the cap costs\n**zero throughput**.\n\nA 100 MB upload to `https://speed.cloudflare.com/__up`\n\nreproduced it exactly:\nreset at 2.29 MB / 15 s with the default 4 MB buffer; full 100 MB at 3 MB/s\nwith the 256 KiB cap. Throttled `curl --limit-rate`\n\nuploads also always\nsucceeded, proving pacing — not size or time — was the fix.\n\n```\nupload-fix on        # apply cap + install LaunchDaemon (persists across reboot)\nupload-fix off       # remove LaunchDaemon + restore macOS defaults\nupload-fix status    # show current state (no sudo)\nupload-fix on 131072 # tighter 128 KiB cap (if a heavily-parallel session resets)\n```\n\n`on`\n\n/ `off`\n\nself-elevate (one sudo prompt). `status`\n\nis read-only.\n\n| setting | stock macOS | this fix |\n|---|---|---|\n`net.inet.tcp.autosndbufmax` |\n4194304 | 262144 |\n`net.inet.tcp.sendspace` |\n131072 | 262144 |\n\nThis is a CPE/line trait — a modern line shouldn't tail-drop a burst like this. The device-independent fix is a router doing SQM / fq_codel (e.g. put the Speedport in bridge mode behind an OpenWrt router, or a Fritz!Box with shaping). Until then, this per-host cap keeps things working.", "url": "https://wpnews.pro/news/workaround-for-claude-code-api-error-unable-to-connect-to-api-econnreset", "canonical_source": "https://gist.github.com/arutkayb/f56e7a4e1d8b50a6064645c327749fbc", "published_at": "2026-06-23 06:41:48+00:00", "updated_at": "2026-07-18 21:25:12.911815+00:00", "lang": "en", "topics": ["developer-tools", "artificial-intelligence", "large-language-models"], "entities": ["Claude Code", "macOS", "Cloudflare", "OpenWrt", "Fritz!Box", "Speedport"], "alternates": {"html": "https://wpnews.pro/news/workaround-for-claude-code-api-error-unable-to-connect-to-api-econnreset", "markdown": "https://wpnews.pro/news/workaround-for-claude-code-api-error-unable-to-connect-to-api-econnreset.md", "text": "https://wpnews.pro/news/workaround-for-claude-code-api-error-unable-to-connect-to-api-econnreset.txt", "jsonld": "https://wpnews.pro/news/workaround-for-claude-code-api-error-unable-to-connect-to-api-econnreset.jsonld"}}