Содержание
- 1. Что на самом деле означает это сообщение — официальное определение
- 2. Что сделать в первую очередь — ничего не потеряно
- 3. Почему обрывается — три слоя, где закрывается соединение
- 4. Что показал перехват пакетов: закрытие со стороны сервера
- 5. Проверьте версию — хронология исправлений
- 6. Условия, повышающие вероятность
- 7. Что делать прямо сейчас — чек-лист
- 8. Разработчикам — как защититься на уровне API/SDK
- 9. Как отличить от похожих ошибок
- 10. Официальный статус и что остаётся неподтверждённым
- Частые вопросы
Вы работаете в Claude Code, и посреди ответа всё останавливается вот этим:
API Error: Connection closed mid-response. The response above may be incomplete.
Это может случиться во время написания длинного отчёта, во время чтения нескольких файлов или сразу после старта новой сессии. Момент каждый раз разный, надёжно воспроизвести не получается. Дело не в том, как вы написали промпт: это событие транспортного уровня — соединение, по которому шёл потоковый ответ, закрылось, пока ответ ещё передавался.
И есть один факт, который важнее любых теорий. Большая часть публичных сообщений об этой ошибке относится к версиям, вышедшим до того, как Claude Code изменил обработку разорванных соединений. Если пройти по официальному changelog, начиная с 2.1.179 обнаруживаются пять отдельных исправлений, связанных с соединением и повторными попытками. Эта статья опирается только на официальный справочник ошибок, официальный changelog и обращения, подкреплённые перехватом пакетов, и разбирает (1) что именно означает сообщение, (2) что делать прямо сейчас, (3) где на самом деле закрывается соединение, (4) что изменилось между версиями и (5) как защититься разработчику.
Всё, что успело передаться, цело. Документированный способ продолжить — ответить continue.
В 2.1.198 короткие обрывы сети перестали убивать ход, в 2.1.214 повторные попытки перестали переиспользовать мёртвое соединение.
Ваша машина, маршрут (прокси/VPN) или сторона сервера — для каждого нужны разные действия. О закрытии по инициативе сервера сообщали.
1. Что на самом деле означает это сообщение — официальное определение
Прежде всего: этот текст — примечание, которое пишет сам Claude Code, а не ответ об ошибке от API. Официальный справочник ошибок Claude Code объясняет всё семейство сообщений, заканчивающихся на «The response above may be incomplete.», так: когда потоковый ответ обрывается после того, как Claude уже выдал видимый текст, повторная отправка запроса могла бы выполнить те же вызовы инструментов дважды, поэтому Claude Code сохраняет уже переданное и добавляет это примечание вместо того, чтобы отбросить весь ход.
А концовка фразы — это название причины. Справочник перечисляет три варианта.
Официальное объяснение умещается в строку: соединение разорвано. Поток работал, но несущее его соединение закрылось.
Официально: поток перестал отправлять данные. Соединение живо, но замолчало. Не разрыв, а остановка.
Перегрузка или 5xx посреди потока. По документации этот вариант требует v2.1.199 или новее; до неё частичный вывод отбрасывался, а весь ход считался ошибкой.
Все три в одну строку. Connection closed — канал оборвали; Response stalled — он замолчал; Server error — упал сервер. Внешне всё выглядит как «остановилось на середине», но произошло это в разных точках передачи.
Справочник фиксирует ещё одно важное поведение. Если такой же сбой случается до появления видимого текста, Claude Code повторяет запрос, а не завершает ход. Иначе говоря, раз вы читаете это сообщение — текст уже был на экране, а значит повторная отправка могла бы продублировать побочные эффекты, и Claude Code намеренно не стал повторять запрос. Появление ошибки не означает, что ничего не пробовали.
2. Что сделать в первую очередь — ничего не потеряно
Прежде чем в панике повторять ту же инструкцию, пройдите по порядку.
Как сказано в документации, ничего не потеряно. Не хватает, скорее всего, только последних фраз или последнего вызова инструмента.
continueСпособ восстановления, названный в официальном справочнике. Пусть Claude продолжит с места остановки, а не начинает заново.
Если оборвалось на правке файлов или выполнении команд, часть могла уже выполниться. Посмотрите реальное состояние через git status, прежде чем продолжать.
Если за одну сессию это выпадает несколько раз, сначала проверьте версию. Эту область правили неоднократно.
Не пропускайте шаг 3. Раз документация говорит, что повторная отправка «могла бы выполнить те же вызовы инструментов дважды», обратная сторона в том, что часть инструментов уже могла отработать к моменту обрыва. Если это случилось посреди записи файлов, коммита или деплоя, сначала посмотреть реальное состояние — самый быстрый путь назад.
3. Почему обрывается — три слоя, где закрывается соединение
Формулировка «соединение разорвано» сама по себе бесполезна, поэтому разделим места, откуда может исходить закрытие. Сообщения делятся на три слоя.
Просадка Wi-Fi, переключение сот на мобильной связи, выход из сна. В официальном changelog даже есть исправление «потоковые запросы падают после пробуждения машины» (2.1.186) — значит, слой реален.
Что помогает: провод или стабильный канал; не давать машине засыпать во время долгой работы.
В официальной документации по ошибкам Claude API прямо сказано, что некоторые сети рвут простаивающие соединения через переменное время, и рекомендуется включать TCP keep-alive. Корпоративные прокси и VPN склонны именно к этому.
Что помогает: временно обойти прокси/VPN и проверить, воспроизводится ли.
Есть пакетные свидетельства того, что соединение закрывается со стороны сервера прямо во время передачи потока (следующий раздел). Никакая локальная настройка этого не предотвратит.
Что помогает: поведение клиента при повторе — именно поэтому обновление работает.
И действительно, автор issue #69415 на GitHub ([BUG] API Error: Connection closed mid-response ==> frequent enough to make Claude Code unusable for any task, создана 18 июня 2026 года и на момент написания открыта) описывает Windows 11 с WSL2, прямое подключение без корпоративного файрвола и прокси, Claude Code 2.1.181. То есть утверждается, что это происходит даже при исключённых слоях 1 и 2. У issue стоят метки area:networking, platform:vscode и platform:wsl.
Тот же человек пишет, что на той же машине и в той же сети другие ИИ-ассистенты (GitHub Copilot, Cursor и прочие) ту же задачу доводят до конца. Но это сравнение, сделанное пользователем, а не установление причины со стороны Anthropic — разницу стоит держать в уме.
Ещё одно обращение описывает заметно другие условия. Issue #69336 (occurs immediately in new context window, создана 18 июня 2026 года и открыта, Claude Code 2.1.173, Debian 13, самостоятельно развёрнутый Claude Agent SDK) сообщает, что частота растёт после того, как отрабатывает сжатие контекста (compact). Метки — area:agent-sdk, area:api и platform:linux; в качестве временного обхода описан запуск совершенно нового диалога. Issue #69517 (в Claude Cowork, 19 июня 2026 года, macOS, 2.1.183) закрыта как дубликат.
4. Что показал перехват пакетов: закрытие со стороны сервера
Самое глубокое самостоятельное исследование этого класса ошибок — issue #67766 (создана 12 июня 2026 года, открыта). Автор снял дамп пакетов в своей среде и сопоставил десять инцидентов.
Источник: перехват пакетов и записи сессий, опубликованные автором issue #67766 на GitHub. Это измерения одного пользователя, а не результаты, проверенные Anthropic.
Технически самое показательное — избирательность закрытий. По описанию, другие соединения к тому же адресу оставались живыми во время события, а закрывалось именно соединение, принадлежавшее процессу, выполнявшему запрос. Соединения двух других одновременно работавших процессов claude не пострадали. Обрыв канала утащил бы за собой все; этого не произошло.
Автор также заметил, что в четырёх из десяти инцидентов пачки закрытий приходили сразу на несколько соединений из пула, а три сработали на 54-й секунде близких минут (01:19:54, 01:20:54 и 01:22:54 UTC) — он трактует это как признак чего-то, работающего с периодом 60 секунд.
🟡 Насколько можно доверять этому разделу
В issue #67766 на экране выводится «API Error: The socket connection was closed unexpectedly» — формулировка отличается от разбираемой в этой статье. Утверждать, что это один и тот же баг, нельзя. Тем не менее сегодня это единственное общедоступное свидетельство на уровне пакетов о том же классе поведения — закрытии соединения во время передачи потока, — поэтому его стоит использовать как рабочую гипотезу. Добавим, что Anthropic не публиковала объяснений по этому обращению на момент написания.
5. Проверьте версию — хронология исправлений
Это самая практически полезная часть статьи. Если пройти по официальному changelog Claude Code, видно, что обработку обрывов соединения посреди потока улучшали неоднократно. Каждый пункт ниже действительно есть в changelog.
Частичные ответы теперь сохраняются при обрыве соединения посреди потока. До этого выводилась «сырая» ошибка, а индикатор мог зависать на «running tool».
Подсказка о зависании потока сменилась на «Waiting for API response · will retry in …» и теперь срабатывает после 20 секунд тишины вместо 10, так что короткие колебания больше не поднимают предупреждение.
Исправлено прерывание хода из-за коротких обрывов сети посреди ответа. Временные ошибки вроде ECONNRESET теперь повторяются с задержкой вместо того, чтобы завершиться неудачей.
Исправлено отбрасывание потоковых ответов, когда посреди потока приходит перегрузка или серверная ошибка. Теперь частичный вывод сохраняется с пометкой о неполном ответе — отсюда и вариант Server error mid-response.
Пул keep-alive-соединений теперь отключается после ошибки устаревшего соединения, так что повторная попытка открывает новый сокет. Это напрямую отвечает картине из #67766: закрывается переиспользуемое соединение.
Теперь сопоставьте эту хронологию с версиями из приведённых выше обращений.
| Обращение | Версия на тот момент | Ещё не применённые исправления |
|---|---|---|
| #69336 | 2.1.173 | Все: 2.1.179 / 198 / 199 / 214 |
| #69415 | 2.1.181 | 2.1.198 / 199 / 214 (улучшение повторов и починка пула) |
| #69517 | 2.1.183 | 2.1.198 / 199 / 214 |
Все три старше 2.1.198 — версии, которая гасит временные обрывы повторами. Так что первым делом стоит посмотреть собственную версию.
claude --versionЕсли она ниже 2.1.198, обновление выгоднее разбирательств. Последняя запись в changelog на момент написания — 2.1.220, и в неё входят все перечисленные исправления.
При этом обновление не гарантирует исчезновения ошибки. В changelog нет ни одной записи, где называлось бы само «Connection closed»; всё перечисленное — улучшения смежной обработки соединений. Воспринимайте обновление как самый выгодный первый шаг, а не как доказанное лечение.
6. Условия, повышающие вероятность
Эти факторы повторяются в обращениях.
Прочитать несколько крупных файлов и выдать структурированный отчёт — всё, что надолго удерживает поток открытым (#69415).
Сообщается, что частота растёт после сжатия контекста (#69336). После сжатия запросы обычно становятся крупнее.
В измерениях #67766 закрытые соединения несли тела запросов на 1–2,5 МБ. Для справки: официальный лимит Messages API — 32 МБ.
Корпоративные прокси, VPN, трансграничные каналы. Именно этот слой описан в официальной документации, когда речь о сетях, рвущих простаивающие соединения.
В changelog 2.1.186 исправлены потоковые запросы, падавшие после пробуждения машины. Не давайте компьютеру засыпать во время долгих задач.
В #67766 87 из 171 инцидента случились менее чем через пять секунд после предыдущего вызова — обрывами по простою одними это не объяснить.
7. Что делать прямо сейчас — чек-лист
Идите по списку сверху вниз: самое дешёвое — первым.
| № | Что сделать | Зачем |
|---|---|---|
| 1 | Ответить continue | Документированный способ восстановления. Использует уже полученное, а не начинает заново. |
| 2 | Выполнить claude --version и обновиться, если версия старая | Даёт улучшение повторов из 2.1.198 и починку пула из 2.1.214. Делайте это первым. |
| 3 | Проверить побочные эффекты (git status и подобное) | Понять, не отработали ли инструменты частично до обрыва. Спасает от двойного выполнения. |
| 4 | Разбить задачу | Более короткие ответы — меньше времени под риском. Разнесите «прочитай все файлы и напиши отчёт» на этапы. |
| 5 | Временно обойти прокси/VPN и проверить снова | Локализует слой 2. Если перестало — виноват маршрут. |
| 6 | Отключить сон и энергосбережение, подключиться по кабелю | Локализует слой 1 — особенно на ноутбуке с долгими задачами. |
| 7 | Попробовать в совершенно новой сессии | Временный обход из #69336. Иногда помогает, когда всплеск идёт сразу после сжатия контекста. |
| 8 | Если воспроизводится — сообщить с деталями | Как советует официальная документация API, приложите request_id (идентификатор, начинающийся с req_) — так разбор пойдёт быстрее. |
Чего делать нельзя. Отключать проверку TLS (NODE_TLS_REJECT_UNAUTHORIZED=0 и подобное) из-за того, что «соединение рвётся», — это лечение совсем другого симптома ценой безопасности всего трафика. Ошибки сертификатов — другая ошибка с другим решением.
8. Разработчикам — как защититься на уровне API/SDK
Если вы ловите тот же класс обрывов через Claude Agent SDK или собственную интеграцию с API, официальная документация по ошибкам Claude API даёт конкретные проектные ориентиры.
Документация рекомендует потоковый Messages API или Message Batches API для долгих запросов, особенно свыше 10 минут. Большой max_tokens без стриминга — самая уязвимая к обрыву конфигурация.
В документации сказано, что TCP keep-alive снижает влияние таймаутов по простою, если вы пишете прямую интеграцию. Официальные SDK его уже ставят. Проверьте, если делали свой HTTP-клиент.
Официальные SDK повторяют временные сбои — ошибки соединения, лимиты, 5xx — дважды по умолчанию с экспоненциальной задержкой, учитывая заголовок retry-after. Опция клиента позволяет изменить или отключить это.
Ловушка, о которой документация говорит прямо: при SSE ошибка может возникнуть уже после того, как API вернул 200, поэтому она не идёт по обычному пути обработки HTTP-ошибок. Обрабатывайте события ошибок внутри потока отдельно.
Сам Claude Code пошёл этим путём в 2.1.179 и 2.1.199. Сохранить полученные блоки и запросить остаток дешевле — и по токенам, и по побочным эффектам, — чем всё отбросить и отправить заново.
В 2.1.214 Claude Code стал отключать пул keep-alive после ошибки устаревшего соединения, чтобы повтор открывал новый сокет. Стоит проверить, не хватает ли ваш повтор то же мёртвое соединение.
Для нагрузок, где вы вообще не хотите полагаться на непрерывное соединение — очевидный случай — пакетная обработка, — официально рекомендуемый путь это Message Batches API с опросом результатов. Так сетевой риск устраняется структурно, а не смягчается.
9. Как отличить от похожих ошибок
Транспортные ошибки Claude Code выглядят похоже. Быстрее всего разделять их по тому, насколько далеко продвинулся запрос.
| Сообщение | Где остановилось | Основное действие |
|---|---|---|
| Connection closed mid-response (эта статья) | Подключились, поток пошёл, затем обрыв | continue / обновление / локализация маршрута |
| Response stalled mid-stream | Соединение живо, но молчит | Разобрано отдельно (осторожно со сцепкой с циклом повторов) |
| Server error mid-response | 5xx или перегрузка посреди потока | Подождать и повторить. См. статью про 529/500 |
| Unable to connect / SSL certificate verification failed | Соединение так и не установилось | Прокси, корпоративный CA, файрвол. См. статью про ошибки подключения |
| Prompt is too long | Отклонено до отправки (сеть в порядке) | Сократить контекст. См. отдельную статью |
Главная развилка проста: появился ли на экране хоть какой-то ответ. Если не пришло ни символа — подозревайте само соединение: настройки и маршрут. Если текст пошёл и затем прервался — это доказательство, что соединение работало, поэтому не трогайте настройки, а переходите к шагам локализации из этой статьи.
10. Официальный статус и что остаётся неподтверждённым
Чтобы не путаться, вот что подтверждено официально, а что нет.
- Сообщение формально задокументировано в официальном справочнике ошибок и означает «соединение разорвано»
- Уже переданный вывод сохраняется — это задумано
- Способ восстановления — ответить
continue - Сбои до появления видимого текста повторяются автоматически
- Исправления обработки соединений вышли в 2.1.179 / 198 / 199 / 214
- Серверы отправляют FIN посреди потока (измерено в #67766, но при другом сообщении)
- Участие 60-секундного цикла очистки (вывод самого автора)
- Всплески сразу после compact (#69336)
- Другие ИИ-ассистенты не падают в тех же условиях (сравнение автора #69415)
- Официальное объяснение причины от Anthropic (публичных ответов в #69415, #69336 и #67766 нет)
- Запись об исправлении, где названо «Connection closed» (такой строки в changelog нет)
- #69415, #69336 и #67766 по-прежнему открыты
Итого: симптом и действия задокументированы официально, но официального объяснения причины обрыва не публиковалось. В такой ситуации организационные привычки надёжнее охоты за первопричиной: держите ходы короткими, сверяйте состояние по мере выполнения операций с побочными эффектами и оставайтесь на свежей версии.
Частые вопросы
Q1. Если появилось «Connection closed mid-response», выведенное до этого пропадает?
Нет. Как прямо сказано в официальном справочнике ошибок, всё, что успело передаться, сохраняется. Claude Code намеренно добавляет примечание вместо повторной отправки, потому что повтор мог бы выполнить те же вызовы инструментов дважды. Не хватает, как правило, только последних фраз или последнего вызова инструмента.
Q2. Что ответить, чтобы продолжить с места остановки?
Ответьте continue. Это способ восстановления, названный в официальном справочнике ошибок. Повторение исходной инструкции рискует продублировать уже выполненные операции.
Q3. Токены пропадают впустую?
То, что успело сгенерироваться до обрыва, израсходовано. Автор issue #69336 отмечает, что израсходованные токены не возвращаются. Именно поэтому continue вместо начала с нуля важен и по деньгам, и по времени.
Q4. Это то же самое, что «Response stalled mid-stream»?
Нет. По официальным определениям Connection closed означает «соединение разорвано», а Response stalled — «поток перестал отправлять данные»: обрыв против молчания. На экране они похожи, но вариант stalled сообщался в связке с циклом повторов у модели, и решается иначе. См. статью про Response stalled mid-stream.
Q5. Виновата ли моя сеть?
Возможно, но не обязательно. Автор issue #69415 наблюдал ошибку на прямом подключении без прокси и файрвола, а перехват пакетов из issue #67766 указывает, что закрытие инициировал сервер. Сначала обойдите прокси или VPN и проверьте, воспроизводится ли; если ничего не меняется — проблема не чисто локальная.
Q6. Поможет ли обновление Claude Code?
Это то, что стоит попробовать первым: отдача самая высокая. В официальном changelog 2.1.198 исправляет «короткие обрывы сети посреди ответа, прерывавшие ход», а 2.1.214 меняет пул keep-alive так, чтобы он отключался после ошибки устаревшего соединения и повтор открывал новый сокет. Основная масса обращений (2.1.173–2.1.183) старше этих версий. Но поскольку ни одна запись changelog не называет «Connection closed» напрямую, обновление — вероятное улучшение, а не гарантированное лечение.
Q7. На длинных задачах это происходит постоянно. Есть обходной путь?
Надёжнее всего разбить задачу так, чтобы каждый ответ был короче. Пакетные задания вида «прочитай все крупные файлы и напиши отчёт» держат поток открытым долго; разделение чтения и написания сокращает это окно и снижает шанс попасть на обрыв. В issue #69336 также сообщается, что временно помогал запуск нового диалога.
Q8. Как разработчику предотвратить это в своём приложении?
Ориентиры из официальной документации Claude API ясны: (1) длинные ответы всегда потоком, а свыше 10 минут — присмотритесь к Batches API; (2) включите TCP keep-alive (официальные SDK это уже делают); (3) при SSE ошибка может прийти после 200, поэтому события ошибок внутри потока обрабатывайте отдельно; (4) при обрыве сохраняйте полученное и запрашивайте остаток. При обращении в поддержку прикладывайте request_id.
Q9. Та же ошибка возникает в Claude Cowork и Agent SDK.
О том же сообщении сообщали и там. Issue #69517 описывает это в Claude Cowork (закрыта как дубликат), а #69336 — через самостоятельно развёрнутый Claude Agent SDK. Это поведение слоя, отвечающего за потоковые ответы, поэтому подход тот же: продолжать, а не начинать заново, оставаться на свежей версии и продумывать повторные попытки.
Похожие статьи
- Claude Code повторяет «court» и падает с «Response stalled mid-stream»: причины и решение двух багов
- Claude Code: ошибки сети и proxy — connection, TLS, файрвол
- Claude Code: ошибки 529 Overloaded и 500 — что это и как исправить
- Claude Code «Prompt is too long»: почему окно контекста переполняется и как это исправить
- Частые ошибки Claude Code и их исправление — полный справочник
