Скрипт проверит, не ломает ли сеть загрузки в Claude API

20 октября на GitHub появился claude-net-check. Это однофайловый скрипт на Node.js, который проверяет, виновата ли в обрывах Claude Code сеть между вами и API. Он отправляет на api.anthropic.com загрузки растущего размера и следит, на каком объёме TLS-соединение начинает рваться.

Автор репозитория claude-net-check на GitHub написал его под конкретный набор симптомов. Claude Code раз за разом падает с API Error: Unable to connect to API (EPROTO), ECONNRESET или bad record mac / TLSV1_ALERT_DECODE_ERROR, хотя всё остальное в интернете работает. Ошибки такого вида относятся к сетевым: Claude Code не получил вообще никакого HTTP-ответа. Если бы вернулись 401, 429, 500 или 529, это значило бы, что API ответил, и копать нужно было бы в другом месте.

Как устроена проверка

Запускается одной командой node claude-net-check.js. Нужен только Node.js: автор тестировал на v24, скрипт берёт только стандартную библиотеку, поэтому старые версии, скорее всего, тоже подойдут, но их не пробовали. Устанавливать ничего не надо, зависимостей нет.

Скрипт шлёт наполнитель из буквы «a» четырёх размеров: 1 КБ, 50 КБ, 300 КБ и 1 МБ, по 25 раз каждый, и считает, сколько загрузок дошло до конца. Ключ API он не отправляет, реального содержимого тоже, сервер просто отвечает статусом ошибки. Ответ скрипту не важен. Он проверяет только одно: переживает ли TLS-соединение саму загрузку. Заодно печатается издатель сертификата, и по нему видно, не подписывает ли HTTPS-трафик заново какой-нибудь защитный продукт.

По умолчанию скрипт выгружает около 34 МБ. С флагом --runs 10 загрузок на каждый размер будет меньше, и объём упадёт примерно до 14 МБ. Флаг --host задаёт адрес, а --timeout 15000 задаёт таймаут на одну загрузку в миллисекундах.

Автор приводит вывод с машины, где сбой был. Сертификат там выпустил Google Trust Services, так что перехвата нет. Килобайтные запросы прошли все 25 из 25. На 50 КБ дошли 15 из 25 (семь раз BAD_RECORD_MAC, три раза EPROTO), на 300 КБ дошли 10 (14 и одна соответственно), на 1024 КБ дошли 13 (11 раз BAD_RECORD_MAC, один ECONNRESET). Всего из 75 загрузок от 50 КБ и выше оборвались 37. Автор описывает эту картину так: маленькие запросы проходят всегда, большие падают пачками. По его словам, ошибка не в Claude Code, а где-то между машиной и API, и это звено портит длинные TLS-передачи.

Почему всё упирается в размер

Похожий случай подробно разобран в заметке на GitHub Gist, только там другая система и, видимо, другая поломка. Короткие запросы к Claude проходили всегда, а длинные сессии обрывались через 5-13 минут. Через раздачу с телефона всё работало, через домашний Wi-Fi нет. Автор заметки объясняет это направлением трафика: каждый запрос Claude загружает весь контекст разговора телом POST, а маленькие запросы никогда не отправляют достаточно данных за раз, чтобы упасть. Объём контекста растёт быстро: на одной машине в октябре context-tax насчитал 47 700 токенов уже в первом запросе.

Механизм в той заметке такой. macOS сама наращивает буфер отправки TCP до 4 МБ, и одно соединение выбрасывает несколько мегабайт в исходящий буфер DSL-модема. На этой линии буфер начинал отбрасывать пакеты примерно на 2,29 МБ, поток вставал, и примерно через 15 секунд сервер сбрасывал соединение. Claude повторял запрос 11 раз, а в конце выдавал ECONNRESET. Загрузка 100 МБ на speed.cloudflare.com с буфером по умолчанию оборвалась на тех же 2,29 МБ и 15 секундах. Когда буфер ограничили 256 КиБ, она прошла целиком на 3 МБ/с. По выводу автора, помог темп отправки, а не размер или время.

Как читать результат

• Все загрузки дошли: сетевой путь в порядке, причину надо искать в другом месте.
• Маленькие проходят, большие падают: тот самый сбой, ради которого скрипт написан.
• Упало несколько штук: запустите ещё раз, единичные обрывы бывают обычным сетевым шумом.
• Падает почти всё: соединение заблокировано или сломано (файрвол, прокси, VPN, DNS), и это другая проблема.

Код выхода 0, если всё чисто, и 1 во всех остальных случаях.

Если скрипт нашёл сбой, зависящий от размера, автор предлагает искать слой через A/B-тесты: менять по одному параметру и после каждого шага перезапускать проверку. Подключитесь к раздаче с телефона: если стало чисто, виноваты роутер или провайдер, если нет, дело в самом компьютере. Переключитесь между Wi-Fi и Ethernet: одинаковый результат на обоих исключает сетевую карту и её драйвер. Проверьте, не ругается ли скрипт на издателя сертификата, и попробуйте отключить или удалить антивирус. Функции вроде «HTTPS scanning» или «Web Shield» могут ломать TLS даже в выключенном состоянии, потому что их сетевые драйверы остаются загруженными. Последний шаг: отключите VPN или корпоративный прокси и прогоните скрипт снова.

Автор отдельно описывает, насколько скрипт проверен. На логику вердиктов и проверку перехвата есть юнит-тесты (node claude-net-check.test.js), все они проходят. По-настоящему скрипт запускали на одной машине с Windows 11, и там он воспроизвёл реальный сбой с BAD_RECORD_MAC, EPROTO и ECONNRESET. На macOS и Linux его не запускали. Скрипт только читает и ничего на машине не меняет, лицензия MIT. Список подозреваемых автор называет порядком проверки, а не диагнозом.

Инструмент говорит, где проблемы нет. Он может указать на слой, но не может доказать, какой продукт виноват.