Request timed out в Claude Code: где застрял ответ

Что значит Request timed out в Claude Code

Сообщение Request timed out в Claude Code значит, что API не ответил до крайнего срока соединения. По умолчанию этот срок 10 минут. Но о таймауте Claude Code сообщает тремя разными строками, и каждая указывает на свой участок пути. Сначала найдите участок, который держит ответ, и только потом меняйте настройки.

У большинства читателей из России запрос идёт к Anthropic не напрямую. Между Claude Code и моделью есть ещё одно звено: Anthropic-совместимый ANTHROPIC_BASE_URL агрегатора с оплатой в рублях, свой шлюз LiteLLM за nginx, корпоративный HTTPS_PROXY или VPN-туннель. Каждое звено может задержать ответ. Если поднять таймаут вслепую, вы будете ждать дольше, но ответ быстрее не придёт.

Как вообще добраться до Anthropic из России, здесь не разбирается. Речь только о диагностике таймаутов на том маршруте, который у вас уже есть.

Я сверял текст с официальной страницей ошибок и страницей network-config 16 октября 2026 года. На этот день последняя версия Claude Code в npm 2.1.301. Страницы документации не привязаны к версии: это живая документация, а не документация именно 2.1.301. Поэтому в старых сборках поведение может отличаться. Где документация называет версию, я её указываю. Свою версию смотрите командой claude --version.

Три строки таймаута и что за каждой стоит

Спиннер «Waiting for API response»

Waiting for API response · will retry in … · check your network

Это ещё не ошибка. По документации, спиннер появляется, если запрос ещё ждёт ответа, а данных в потоке нет 20 секунд. Повтор ещё не начался, и запрос ещё не провалился. Обратный отсчёт идёт до момента, когда Claude Code оборвёт зависшее соединение. Пока идёт консультация с advisor, порог равен 90 секундам.

Баннер исчезает сам, когда данные снова пошли или повтор прошёл успешно. Поэтому один такой баннер можно просто переждать. Если он появляется на каждой попытке, документация советует считать это проблемой сети. Такая формулировка баннера появилась в v2.1.185. Более старые версии показывали его уже через 10 секунд и другим текстом.

«API Error: No response from API»

API Error: No response from API (waited 3m, then 10m on the retry). If a proxy or gateway on your network holds responses until they complete, raise API_TIMEOUT_MS or CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS to wait longer.

Claude Code отправил потоковый запрос, но заголовки ответа не пришли до дедлайна первого байта. Тогда Claude Code обрывает запрос и не ждёт полный API_TIMEOUT_MS. Повтор будет максимум один, и только если позволяет бюджет повторов. Если повтор тоже остался без ответа, ход заканчивается этой строкой. В скобках видно, сколько ждала каждая попытка. Длительности в сообщении показываются с v2.1.261. До v2.1.242 такого дедлайна не было, и Claude Code ждал полный API_TIMEOUT_MS.

Сколько ждёт каждая попытка:

• Первая попытка ждёт CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS, если вы задали его не меньше 1. Значение ограничено диапазоном от 10 секунд до 30 минут. Если переменная не задана, берётся значение byte-level watchdog из network-config: на прямом API Anthropic это 180 секунд.
• К этому сроку добавляется одна секунда на каждые 32 КБ тела запроса. Длинный контекст даёт длинное ожидание.
• Повтор ждёт на одну секунду меньше API_TIMEOUT_MS, то есть чуть меньше 10 минут по умолчанию. Так повтор может пережить прокси, который держит ответ до конца генерации.
• Ни одно ожидание не бывает дольше API_TIMEOUT_MS минус одна секунда.

Главная деталь для вашей схемы: где этот дедлайн работает. По network-config, он работает на прямом API Anthropic, в том числе через HTTPS-прокси. Он не работает, когда ANTHROPIC_BASE_URL направляет запросы через шлюз. На таких соединениях запрос просто ждёт API_TIMEOUT_MS. Отсюда практический вывод: если вы видите «No response from API», ваш маршрут прямой, через корпоративный HTTPS_PROXY или через системный VPN. Подсказка в самом сообщении про прокси, который «держит ответы», в вашем случае относится к корпоративному прокси или к сетевому оборудованию между вами и API.

Просто «Request timed out»

Request timed out

API не ответил до крайнего срока соединения. Документация называет две причины: высокая нагрузка и очень большой ответ модели. Срок по умолчанию 10 минут. Если причина в медленной сети или прокси, документация советует поднять API_TIMEOUT_MS.

Есть вторая форма той же строки: Request timed out. Check your internet connection and proxy settings. Документация относит её к разделу о сетевых проблемах, а не к ошибкам сервера. Если в вашей строке есть слова про интернет и прокси, ищите причину на своей стороне.

Для пользователей агрегатора или своего шлюза эта строка самая частая. Дедлайн первого байта на маршруте через ANTHROPIC_BASE_URL не работает, поэтому задержанный ответ ждёт весь API_TIMEOUT_MS и заканчивается именно так.

Ответ начался и оборвался на середине

После того как заголовки пришли, правила другие. Byte-level watchdog запускается только после прихода заголовков. Он обрывает поток, если на проводе нет ни одного байта, включая служебные события SSE ping. По network-config, его срок 180 секунд на прямом API и 300 секунд через свой ANTHROPIC_BASE_URL.

Зависший поток без содержимого Claude Code обрывает и запрашивает заново максимум один раз. Если текст или вызовы инструментов уже начались, ответ остаётся частичным, с пометкой The response above may be incomplete. Такой ответ заново не запускается.

Обратите внимание на версию. В v2.1.299 от 14 октября 2026 года исправлена ошибка: потоки через свой ANTHROPIC_BASE_URL обрывались через 180 секунд без данных. Теперь они ждут 300 секунд. На v2.1.298 и старше с агрегатором вы можете видеть обрыв через 180 секунд. Если Claude Code установлен через npm, обновление выглядит так:

npm install -g @anthropic-ai/claude-code@latest
claude --version

[
  {
    "label": "nginx proxy_read_timeout",
    "seconds": 60
  },
  {
    "label": "\u041f\u0435\u0440\u0432\u044b\u0439 \u0431\u0430\u0439\u0442 \u0438 \u043f\u043e\u0442\u043e\u043a, \u043f\u0440\u044f\u043c\u043e\u0439 API",
    "seconds": 180
  },
  {
    "label": "\u041f\u043e\u0442\u043e\u043a \u0447\u0435\u0440\u0435\u0437 ANTHROPIC_BASE_URL (v2.1.299+)",
    "seconds": 300
  },
  {
    "label": "API_TIMEOUT_MS",
    "seconds": 600
  }
]

На графике видно, почему важен порядок звеньев. Самый короткий срок здесь не у Claude Code. Это nginx со своими 60 секундами по умолчанию. Если ваш шлюз стоит за nginx без настройки, nginx оборвёт молчащее соединение раньше любого таймаута Claude Code. Значения взяты из документации nginx и Claude Code на 16 октября 2026 года. К сроку первого байта ещё добавляется секунда на каждые 32 КБ запроса.

429 и 529: это не таймауты

Ошибки с кодами 429 и 529 часто путают с таймаутами, но у них свои разделы в документации и свои причины.

• API Error: Repeated 529 Overloaded errors значит, что API перегружен. Документация прямо пишет: 529 не ваш лимит использования и не расходует вашу квоту.
• Server is temporarily limiting requests (not your usage limit) значит короткое ограничение на стороне сервера. С квотой тарифа оно не связано.
• Request rejected (429) значит, что вы упёрлись в лимит, настроенный для вашего API-ключа, проекта Amazon Bedrock или проекта Google Cloud.

Если вы ходите через шлюз, 429 может прийти и от самого шлюза, например при исчерпанном бюджете. Что делать с перегрузкой, разобрано в статье ошибка Overloaded в Claude Code. Как читать лимиты по заголовкам ответа, описано в разборе заголовков rate limit в Claude API.

Шаг 1: определите свой маршрут

Запустите в Claude Code команду /status. Она показывает, какой base URL и какой источник учётных данных используются, а также строку Proxy. От ответа зависит, какие из трёх строк вы вообще можете увидеть.

• Агрегатор через ANTHROPIC_BASE_URL. Дедлайн первого байта не работает. Ждите «Request timed out» или обрыва потока после заголовков.
• Свой шлюз на VPS, например LiteLLM как шлюз к LLM на своём сервере, за nginx. Тоже маршрут через ANTHROPIC_BASE_URL, но здесь все звенья ваши, и их можно измерить по отдельности.
• Корпоративный HTTPS_PROXY. Запросы идут на прямой API, поэтому дедлайн первого байта работает. Здесь появляется «No response from API».
• Системный VPN. Для Claude Code это обычный прямой маршрут. Туннель не виден, но его задержки видны.

Claude Code читает HTTPS_PROXY, HTTP_PROXY, NO_PROXY и их варианты в нижнем регистре. SOCKS-прокси он не поддерживает. Если ваш туннель даёт только SOCKS-порт, Claude Code не сможет им пользоваться напрямую. Нужен локальный HTTP-прокси перед ним. Адрес прокси без схемы http:// Claude Code не разберёт и остановит запуск с ошибкой, где названа переменная. Строка Couldn't connect through your proxy (ERR_PROXY_TUNNEL) означает отказ соединения через прокси. Это не таймаут, и настройки ожидания тут не помогут.

Подробный журнал пишет claude --debug. Он сохраняется в ~/.claude/debug/<session-id>.txt.

Про агрегаторы есть одна важная оговорка. Anthropic не одобряет, не поддерживает и не проверяет сторонние шлюзы. По документации, работает любой шлюз с поддерживаемым форматом API, но он должен успевать за релизами Claude Code и передавать заголовки anthropic-* и поля тела без изменений. Поддерживает ли конкретный агрегатор Claude Code, может сказать только его собственная документация.

Шаг 2: измерьте время до первого байта через curl

curl умеет печатать время каждого этапа запроса. Ключ -w выводит переменные: %{time_connect} (TCP-соединение с хостом или прокси), %{time_appconnect} (конец TLS-рукопожатия), %{time_starttransfer} (время до первого полученного байта) и %{time_total}.

Для маршрута через шлюз используйте ту же форму запроса, что в документации Claude Code для проверки шлюза. Поле "stream": true включает потоковый ответ, как у Claude Code. Укажите модель, которую ожидает ваш шлюз:

curl -sS -o /dev/null \
  -w 'connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}\n' \
  "$ANTHROPIC_BASE_URL/v1/messages" \
  -H "Authorization: Bearer $ANTHROPIC_AUTH_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model": "claude-opus-5-5", "max_tokens": 512, "stream": true, "messages": [{"role": "user", "content": "Count from 1 to 100 in words."}]}'

Как читать цифры:

• Большой connect значит медленную сеть до хоста или до прокси.
• Большой tls при быстром connect указывает на TLS-рукопожатие: туннель, фильтрацию трафика или перегруженный прокси.
• Большой first_byte при быстрых connect и tls значит, что сеть доставила запрос, а заголовки задерживает дальняя сторона.

Последний случай на агрегаторе я почти всегда объясняю его очередью, а не вашей сетью. Это мой вывод, а не факт из документации. Снаружи вы не узнаете причину: очередь, лимиты или перегруженный upstream. Отправьте цифры в поддержку агрегатора. Таймаут на своей стороне такое ожидание только продлит.

Время до первого байта не показывает, как идёт тело ответа. Чтобы увидеть сами события, уберите -o /dev/null и -w, добавьте -N. Ключ -N отключает буферизацию вывода самого curl:

curl -sS -N "$ANTHROPIC_BASE_URL/v1/messages" \
  -H "Authorization: Bearer $ANTHROPIC_AUTH_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model": "claude-opus-5-5", "max_tokens": 512, "stream": true, "messages": [{"role": "user", "content": "Count from 1 to 100 in words."}]}'

Здоровый поток печатает строки event: и data: постепенно, пока модель пишет. Если весь ответ появляется одной пачкой в конце, какое-то звено копит его целиком. Документация шлюзов Claude Code говорит об этом прямо: если шлюз буферизует ответ до конца, Claude Code зависает.

Для маршрута через корпоративный прокси отправьте запрос на прямой API через прокси ключом -x, с заголовком x-api-key вместо Authorization:

curl -sS -o /dev/null -x "$HTTPS_PROXY" \
  -w 'connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}\n' \
  https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model": "claude-opus-5-5", "max_tokens": 512, "stream": true, "messages": [{"role": "user", "content": "Count from 1 to 100 in words."}]}'

Если вы работаете по подписке и ключа API у вас нет, отправьте запрос без ключа. API ответит ошибкой авторизации, но connect и tls всё равно покажут, сколько стоит путь через прокси.

Шаг 3: настройте ожидание в Claude Code

Три переменные из раздела документации о повторах:

• API_TIMEOUT_MS: срок одного запроса в миллисекундах. По умолчанию 600000, то есть 10 минут. Максимум 2147483647. Значение выше максимума переполняет таймер, и запросы падают сразу. Положительное значение меньше 11 секунд отключает дедлайн первого байта.
• CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS: дедлайн первого байта потокового запроса. По умолчанию не задан. Требует v2.1.242 или новее. Ограничен диапазоном от 10 секунд до 30 минут.
• CLAUDE_CODE_MAX_RETRIES: число повторов. По умолчанию 10, с экспоненциальной паузой между ними. С v2.1.186 потолок 15.

Переменные можно положить в блок env файла ~/.claude/settings.json (для всех проектов) или .claude/settings.local.json (для одного проекта):

{
  "env": {
    "API_TIMEOUT_MS": "900000",
    "CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS": "300000"
  }
}

Или экспортировать в оболочке перед запуском:

export API_TIMEOUT_MS=900000
export CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS=300000
claude

Если переменная задана и там, и там, побеждает значение из файла настроек. Переменные оболочки читаются один раз при запуске, поэтому работающая сессия их не увидит: перезапустите claude. Ключи и токены не кладите в .claude/settings.json проекта, который попадает в git.

Что менять в каждом случае:

• «No response from API», а повтор проходит. Первой попытке не хватает времени. Документация советует поднять CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS, чтобы первая попытка тоже дождалась. Если ставите больше 10 минут, поднимите и API_TIMEOUT_MS, иначе он ограничит ожидание.
• «Request timed out» через шлюз ровно через 10 минут. Сначала проверьте curl, приходит ли ответ вообще. Если шлюз отвечает через 12 минут, поднимите API_TIMEOUT_MS. Если не отвечает никогда, больший срок ничего не даст.
• Скрипты и CI. Уменьшите CLAUDE_CODE_MAX_RETRIES, чтобы ошибка появлялась быстрее.

Повторю главное: любой из этих параметров только разрешает ждать дольше. Ни один не ускоряет ответ. Таймаут задаёт предел ожидания, а не скорость.

Для долгих сессий без присмотра есть CLAUDE_CODE_RETRY_WATCHDOG. С v2.1.199 он поднимает число повторов при ошибках сервера, таймаутах и обрывах до 300 (это около трёх часов пауз) и снимает потолок. Ошибки 429 и 529 из-за нехватки мощностей он повторяет бесконечно. Исключение: если запрос в обычном режиме скорости получает 429 об исчерпанном лимите расходов или кредитах, в том числе от бюджета шлюза, Claude Code сразу завершается ошибкой. До v2.1.239 watchdog повторял и такие ошибки бесконечно. Это полезно, если Claude Code работает ночью на VPS в сессии tmux, и вредно в интерактивной работе: сломанный маршрут вы заметите через часы.

Шаг 4: свой шлюз за nginx на VPS

Если шлюз ваш, у nginx два параметра решают, дойдёт ли поток до Claude Code.

proxy_buffering по умолчанию включён. С ним nginx получает ответ от upstream как можно быстрее и складывает его в буферы, а при нехватке памяти и на диск. Когда буферизация выключена, nginx передаёт ответ клиенту синхронно, сразу по мере получения. Для потока событий нужен второй вариант.

proxy_read_timeout по умолчанию 60s. Это не срок всего ответа. Это пауза между двумя чтениями от upstream. Если upstream молчит дольше, nginx закрывает соединение. Ожидание до первого байта тоже считается такой паузой, поэтому медленный старт генерации больше минуты оборвёт nginx, а не Claude Code. Во время длинного «раздумья» модели в потоке могут идти только события ping. Шлюз, который их вырезает или копит, по документации Claude Code тоже обрывает поток.

Выключите буферизацию и поднимите таймаут только для потокового маршрута:

location /v1/messages {
    proxy_pass http://127.0.0.1:8080;  # адрес вашего шлюза
    proxy_buffering off;
    proxy_read_timeout 600s;
}

Проверьте синтаксис и перечитайте конфигурацию:

sudo nginx -t
sudo systemctl reload nginx

nginx -t должен напечатать syntax is ok и test is successful. Затем повторите тест с -N два раза: на порт шлюза напрямую и через домен с nginx. Если напрямую события идут постепенно, а через nginx одной пачкой, буферизация осталась в nginx. Проверьте, что запрос попадает в нужный location. Если оба варианта копят ответ, причина за nginx, в самом шлюзе или дальше. Настройки таймаутов самого LiteLLM здесь не разбираются, смотрите его документацию.

Есть и другой способ: upstream может прислать заголовок X-Accel-Buffering: no, и nginx отключит буферизацию для этого ответа. Директива proxy_ignore_headers умеет этот заголовок игнорировать, так что проверьте, не стоит ли она в вашей конфигурации. Директива proxy_request_buffering касается тела запроса, а не ответа, и к зависанию потока отношения не имеет. Общая логика блоков location и заголовков разобрана в статье как устроен конфиг nginx как обратного прокси.

Одна ошибка похожа на сетевую, но это не таймаут. Если шлюз отвечает HTML-страницей 403 Forbidden, а в его журнале запроса нет, тело запроса мог заблокировать веб-фаервол перед шлюзом. Документация называет ModSecurity с правилами OWASP CRS для nginx и правило CrossSiteScripting_Body в AWS WAF.

Тот же принцип, сравнить срок клиента со скоростью модели, работает и для локальных моделей. Пример с Ollama разобран в статье ошибка context deadline exceeded в Ollama.

FAQ

Почему Claude Code пишет Request timed out, хотя интернет работает?

Интернет может работать, а одно звено маршрута держит ответ. Обычная строка «Request timed out» значит, что ответ не пришёл до крайнего срока, по умолчанию 10 минут. Через агрегатор или свой шлюз в ANTHROPIC_BASE_URL дедлайн первого байта не работает, поэтому задержанный ответ ждёт весь API_TIMEOUT_MS. Измерьте curl с -w '%{time_starttransfer}': если соединение и TLS быстрые, а первый байт идёт минутами, держит дальняя сторона.

Чем «No response from API» отличается от «Request timed out»?

«No response from API» значит, что заголовки ответа не пришли до дедлайна первого байта, и Claude Code оборвал запрос раньше API_TIMEOUT_MS. Этот дедлайн работает на прямом API Anthropic, в том числе через HTTPS_PROXY, и не работает через шлюз в ANTHROPIC_BASE_URL. «Request timed out» значит, что истёк полный срок запроса. Если первая попытка падает, а повтор проходит, поднимите CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS (нужна v2.1.242 или новее).

Поможет ли увеличить API_TIMEOUT_MS?

Только если ответ в итоге приходит, но позже срока. Таймаут разрешает ждать дольше и ничего не ускоряет. Сначала убедитесь через curl, что шлюз или прокси вообще отвечает. Не ставьте значение больше 2147483647: таймер переполнится, и запросы будут падать сразу. Значение в блоке env файла ~/.claude/settings.json важнее, чем export в оболочке.

Как понять, что nginx буферизует потоковый ответ Claude?

Выполните curl с -N и "stream": true дважды: прямо на порт шлюза и через nginx. Если напрямую строки event: идут постепенно, а через nginx приходят одной пачкой в конце, буферизует nginx. По умолчанию proxy_buffering включён. Поставьте proxy_buffering off; и поднимите proxy_read_timeout (по умолчанию 60s) в location потокового маршрута.

Ошибка 529 Overloaded это тоже таймаут?

Нет. 529 значит, что API перегружен, и по документации это не ваш лимит использования и не расход квоты. Request rejected (429) значит лимит вашего API-ключа или облачного проекта. Обе ошибки не лечатся параметрами API_TIMEOUT_MS или CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS.