A script that tests whether your network breaks large uploads

A one-file script named claude-net-check, described in github.com's report, tests whether something on a network is breaking big HTTPS uploads to the Claude API. It is for Claude Code sessions that die with API Error: Unable to connect to API (EPROTO), ECONNRESET, or bad record mac / TLSV1_ALERT_DECODE_ERROR while the rest of the internet still works. The command is node claude-net-check.js. It needs Node.js and has nothing to install.

This piece covers the upload sizes, the four verdicts, the run flags, and the layer checks used when only the large sizes fail. It is for people debugging those TLS errors against api.anthropic.com who want a read-only check of that path. The repository is MIT licensed, and the script changes nothing on the machine.

A script that tests whether your network: what actually changed

The script sends filler bytes, the letter "a", to api.anthropic.com at 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 answers with an error status. The measurement is whether the TLS connection survives the upload. It also prints the certificate issuer, so a reader can see whether a security product is re-signing HTTPS traffic. In the example from a machine with the fault, the line read Certificate issuer: Google Trust Services.

On that machine the counts split by size. At 1 KB the result was ok 25/25 and failed 0. At 50 KB it was ok 15/25 and failed 10, logged as {"ERR_SSL_SSL/TLS_ALERT_BAD_RECORD_MAC":7,"EPROTO":3}. At 300 KB it was ok 10/25 and failed 15, logged as {"ERR_SSL_SSL/TLS_ALERT_BAD_RECORD_MAC":14,"EPROTO":1}. At 1024 KB, the 1 MB size, it was ok 13/25 and failed 12, logged as {"ERR_SSL_SSL/TLS_ALERT_BAD_RECORD_MAC":11,"ECONNRESET":1}. Small requests always pass, and big ones fail in bursts. The notes read that as something between the user and the API that damages long TLS transfers.

A script that tests whether your network: how it works

Exit code is 0 when clean and 1 otherwise. Default volume is about 34 MB of upload in total. node claude-net-check.js --runs 10 uses fewer uploads per size, about 14 MB total at 10. node claude-net-check.js --host api.anthropic.com sets the host. node claude-net-check.js --timeout 15000 sets milliseconds per upload. The script was tested on Node.js v24 and uses only Node's standard library, so older versions should work, though they have not been tried. Verdict logic and the interception check have unit tests in node claude-net-check.test.js, and those tests all pass.

Four verdicts map the counts. All uploads completed means the network path is fine, and the notes say to look elsewhere. Small fine, large fail is the fault this tool is for. A few failed means rerun, because one-offs can be ordinary internet noise. Almost everything fails means a blocked or broken connection from a firewall, proxy, VPN, or DNS. For the size split, the repository states: "That is not a Claude Code bug." It points at something between the PC and the API that damages long TLS transfers.

A script that tests whether your network: why it matters now

Claude Code dies with API Error: Unable to connect to API (EPROTO), ECONNRESET, or bad record mac / TLSV1_ALERT_DECODE_ERROR, while ordinary internet use still works. The sample's failed column is 0 at 1 KB, 10 at 50 KB, 15 at 300 KB, and 12 at 1024 KB. ERR_SSL_SSL/TLS_ALERT_BAD_RECORD_MAC is listed 7, then 14, then 11 times. EPROTO is listed 3, then 1. ECONNRESET appears once, on the 1024 KB row. One Windows 11 machine reproduced large uploads failing with BAD_RECORD_MAC, EPROTO, and ECONNRESET.

Change one layer at a time and rerun. Join a phone hotspot. A clean result means the router or ISP. A result that still fails means this PC. The same result on Wi-Fi and on Ethernet rules out the network card and its driver. Antivirus and firewall "HTTPS scanning" or "Web Shield" features 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 that product. Disconnect a VPN or corporate proxy and rerun.

A script that tests whether your network: who is affected

The people affected are those whose Claude Code process dies on large HTTPS uploads to api.anthropic.com while the rest of the connection works. The runs that match are a clean 1 KB pass and failed bursts at 50 KB, 300 KB, and 1024 KB. All uploads completed tells that person the path is fine. A few failures are a reason to rerun, because they can be ordinary internet noise. Almost everything failing points to a firewall, proxy, VPN, or DNS, and the notes call that a blocked or broken connection.

The tested set is one computer. The script was run for real on one Windows 11 machine, where large uploads failed with BAD_RECORD_MAC, EPROTO, and ECONNRESET. It has not been run on macOS or Linux, though it uses only Node's standard library. Node.js v24 is the version that was tried. Older versions should work and have not been tried. Nothing has to be installed, and there are no dependencies. The tool is read-only and changes nothing on the machine. The license is MIT.

A script that tests whether your network: what to watch

A flagged result has a stated limit. "The tool says where the problem isn't." It can point at a layer. It cannot prove which product is guilty. "The suspect list is a starting order, not a diagnosis." The order is a phone hotspot, then Wi-Fi versus Ethernet, then security software, then a VPN or corporate proxy. "HTTPS scanning" and "Web Shield" stay on that list. The printed certificate issuer is the interception clue. The fault example printed Google Trust Services.

Checked work stops at the tests and that single machine. node claude-net-check.test.js exercises the verdict logic and the interception check, and all of those tests pass. The Windows 11 run is the only live reproduction, with BAD_RECORD_MAC, EPROTO, and ECONNRESET on large uploads. macOS and Linux have not been run, though the script uses only Node's standard library and was tested on v24. The server's error status is expected, because the bytes are the letter "a" and no real content is sent.