Script checks whether your network breaks Claude API uploads

claude-net-check, a single-file Node.js script posted to GitHub on October 20, checks whether the EPROTO, ECONNRESET and bad record mac errors that kill Claude Code sessions are coming from your network path. It works by sending the same request at several sizes. On a network with this fault, small uploads to api.anthropic.com always complete and large ones fail in bursts.

The errors it targets show up in Claude Code as API Error: Unable to connect to API (EPROTO), ECONNRESET or bad record mac / TLSV1_ALERT_DECODE_ERROR, usually on a machine where everything else online works. All of them are connection errors. A 401, 429, 500 or 529 means the API received the request and answered it. When no HTTP status, body or request ID comes back, the request died somewhere on the way to the API.

The script uploads filler, the letter “a” repeated, in four sizes: 1 KB, 50 KB, 300 KB and 1 MB, 25 times each, and counts how many uploads complete. It sends no API key and no real content, so the server only ever answers with an error status. That is enough, because the test is whether the TLS connection (the encrypted link to the API) survives the upload. It also prints who issued the certificate, which shows whether a security product is re-signing your HTTPS traffic. The script needs Node.js and nothing else. It was tested on v24 and uses only the standard library, so older versions should work but haven’t been tried. Run it with node claude-net-check.js. A default run uploads about 34 MB in total; --runs 10 brings that down to about 14 MB, and --timeout sets the limit per upload in milliseconds.

The repository includes output from a machine with the fault, where the certificate issuer was Google Trust Services:

• 1 KB: 25 of 25 completed
• 50 KB: 15 of 25, with 7 BAD_RECORD_MAC and 3 EPROTO failures
• 300 KB: 10 of 25, with 14 BAD_RECORD_MAC and 1 EPROTO
• 1 MB: 13 of 25, with 11 BAD_RECORD_MAC and 1 ECONNRESET

Across the three larger sizes, 37 of 75 uploads failed. Every small one went through.

The script gives one of four verdicts. If every upload completes, the network path is fine and the problem is somewhere else. Small uploads passing and large ones failing is the fault the tool was built to catch. A few scattered failures call for a rerun, since one-offs can be ordinary internet noise. Almost everything failing points to a blocked or broken connection (firewall, proxy, VPN, DNS) rather than this fault. The exit code is 0 for a clean run and 1 otherwise.

When the size-dependent pattern shows up, the author suggests A/B tests, changing one thing at a time and rerunning the script after each change. Join your phone’s hotspot: a clean result there puts the fault in your router or ISP, while continued failures put it in the PC. Switch between Wi-Fi and Ethernet: the same result on both rules out the network card and its driver. Check antivirus and firewall features such as “HTTPS scanning” or “Web Shield”, which can break TLS even when switched off because their network drivers stay loaded. If the script warns about the certificate issuer, try disabling or uninstalling the product. Last, disconnect any VPN or corporate proxy.

Upload size matters because of how Claude Code sends requests. In a write-up posted as a GitHub Gist, a user with a similar problem on a home network says every Claude request uploads the full conversation context as the POST body, so small requests never send enough data to trigger the failure. That user’s symptom: “Short Claude requests always work; long sessions reset after ~5–13 min. Works fine on a phone hotspot, fails on home Wi-Fi.” The cause in that case was different from what the script’s sample output shows. According to the write-up, macOS let one connection push several megabytes into the DSL modem’s upload buffer, which dropped data at about 2.29 MB. The transfer stalled, the server reset the connection about 15 s later, and Claude Code retried 11 times before ending in ECONNRESET. A 100 MB upload test failed at the same 2.29 MB with the default 4 MB send buffer, then completed at 3 MB/s once the buffer was capped at 256 KiB.

The script itself has seen limited testing. Its verdict logic and certificate check have unit tests, all passing. It has been run for real on one Windows 11 machine, where it reproduced the fault with BAD_RECORD_MAC, EPROTO and ECONNRESET errors, and it has not been run on macOS or Linux. It only reads and changes nothing on the machine, and it is MIT-licensed. The author also limits what its result means: “The tool says where the problem isn’t. It can point at a layer; it can’t prove which product is guilty.”