> ## Documentation Index
> Fetch the complete documentation index at: https://docs.apiyi.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Запрос на генерацию изображения зависает без результата, но в журнале указана ошибка записи?

> Ваша программа обходит прокси и подключается напрямую к APIYI. Изображения 1K/2K создаются успешно, но большие изображения 4K зависают без ошибки, а в журнале вызовов указано write_response_body_failed; списания нет. Ваше прямое соединение не может передавать ответы размером в десятки МБ; направляйте запросы на генерацию изображений через свой прокси.

## Симптомы

Вы генерируете изображения на своём компьютере с помощью скрипта или навыка в инструменте для программирования с ИИ (Codex, Claude Code и т. д.) и наблюдаете следующее:

* Изображения в разрешении 1K и 2K в основном возвращаются, но **изображения в разрешении 4K или запросы с несколькими референсными изображениями часто так и не приходят**
* Программа не показывает **никаких ошибок** и продолжает ждать, пока не сработает ваш собственный тайм-аут (600 с, 900 с) с `read timed out` или пока вы не завершите её принудительно
* Пока программа ждёт, ничего не приходит — **ни единого байта**, даже заголовки ответа (код состояния HTTP отсутствует)
* В [журнале вызовов](/ru/faq/call-logs) соответствующий запрос завершился **через 30–90 секунд** после отправки со статусом ошибки и кодом ошибки `write_response_body_failed`, а **оплата за него не взималась**
* Программа **обходит прокси и подключается напрямую**: вы задали `NO_PROXY` или `trust_env=False` либо добавили правило прямого подключения для `apiyi.com` в приложении прокси

## Краткий ответ

> [!NOTE]
>
> **Изображение уже было сгенерировано. Оно потерялось по пути к вашему компьютеру.**
>
> Ответ с изображением в разрешении 4K занимает десятки МБ. В некоторых домашних и офисных сетях прямое подключение к зарубежным узлам обрывается, когда передано всего несколько десятков КБ из такого большого ответа: сервер обнаруживает разрыв соединения, а ваш компьютер ничего не получает, поэтому программа продолжает ждать. **Обычно проблему решает маршрутизация запросов на генерацию изображений через прокси (VPN).** За такие сбои плата не взимается.

## Почему это происходит

Нестриминговый запрос на генерацию изображений возвращает результат **целиком в конце**:

| Размер изображения | Размер ответа (после кодирования в base64) |
| - | - |
| 1K | 1-3 МБ |
| 2K | 3-10 МБ |
| 4K | 30-50 МБ |

В изученных нами случаях сервер завершал генерацию изображения за 40-60 секунд и начинал отправлять его обратно. Заголовки ответа и первые 64-135 КБ уже были отправлены, а примерно через 1 секунду соединение обрывалось. Программа клиента получала 0 байт и не получала никакого сигнала о «закрытии соединения», поэтому ждала до наступления собственного тайм-аута. В тот же период:

* Небольшие изображения 1K и 2K с того же компьютера в большинстве случаев приходили без проблем
* Запросы с того же аккаунта, **отправленные через прокси**, доставляли почти все изображения 4K размером 40-50 МБ

Проблема в том, что **прямое соединение между вашим компьютером и APIYI не может передавать большие ответы**. Модель не дала сбой, и сеть не отключена полностью. Проверка подключения с помощью `curl` или браузера на таком соединении выглядит вполне успешной (небольшие запросы возвращаются менее чем за секунду), поэтому проблему сложно обнаружить самостоятельно.

> [!NOTE]
>
> Это полная противоположность ситуации из статьи [Вызовы генерации изображений обрываются примерно через 90 секунд при работе через прокси?](/ru/faq/proxy-idle-timeout-disconnect). Там **прокси** закрывает соединение, пока оно простаивает в ожидании изображения, и решение — подключиться напрямую. Здесь **прямое** соединение не может передавать большой ответ, и решение — использовать прокси. Какой вариант подходит вам, покажет сравнительный тест ниже.

## Как проверить

**1. Проверьте журнал вызовов**

Найдите соответствующий временной интервал в [журнале вызовов](/ru/faq/call-logs). Если ваша программа всё ещё ожидает, а в журнале уже есть запись о сбое `write_response_body_failed`, значит, сервер завершил генерацию изображения и начал отправлять его обратно. Соединение прервалось на обратном пути.

**2. Проверьте, чаще ли возникают сбои с изображениями большего размера**

Если при одинаковых prompt и эталонных изображениях результат с разрешением 1K / 2K приходит, а с 4K — нет, почти наверняка причина в этом.

**3. Проверьте, использует ли ваша программа прокси**

Многие инструменты для написания кода с помощью ИИ запускают дочерние процессы Python / Node, которые **не используют системный прокси**. Даже если Clash работает в глобальном режиме, такие процессы всё равно могут подключаться напрямую. Выполните эту команду в том же терминале или инструменте:

```bash theme={null}
curl -s https://ipinfo.io/ip
```

Если команда выводит IP-адрес вашего домашнего интернет-подключения, запросы из этой среды отправляются напрямую.

**4. Чередуйте запуск через прокси и напрямую для нескольких изображений 4K**

Запускайте их по очереди: через прокси, напрямую, через прокси, напрямую. Не запускайте сначала 5 запросов одного типа, а затем 5 другого: временные колебания сети могут ввести вас в заблуждение. Если запросы через прокси стабильно выполняются успешно, а прямые часто зависают, причина подтверждена.

## Решения

**Направьте программу через прокси (рекомендуется)**

Удалите все настройки, из-за которых программа обходит прокси, чтобы запросы на генерацию изображений проходили через него:

* Удалите `apiyi.com` из `NO_PROXY`
* Python `requests` / `httpx`: удалите `trust_env=False`
* Python `urllib`: не создавайте opener с помощью `ProxyHandler({})`
* Node.js: встроенный `fetch` по умолчанию не использует прокси; укажите его явно с помощью такой библиотеки, как `ProxyAgent`

Если дочерний процесс не использует системный прокси, задайте адрес прокси в переменной окружения перед запуском (замените порт на HTTP-порт вашего прокси-приложения):

```bash theme={null}
# macOS / Linux
export HTTPS_PROXY="http://127.0.0.1:7890"
# Windows PowerShell
$env:HTTPS_PROXY="http://127.0.0.1:7890"
```

**Включите режим TUN в прокси-приложении**

При включённом **режиме TUN** Clash / Clash Verge / mihomo и аналогичные приложения перехватывают трафик всех программ на компьютере. Весь трафик проходит через прокси независимо от того, использует программа системный прокси или нет, — это самый простой вариант.

Если вы ранее добавили правило `DIRECT` для `apiyi.com`, следуя инструкции [Прокси разрывает неактивные соединения](/ru/faq/proxy-idle-timeout-disconnect), удалите его. Иначе соединение в режиме TUN всё равно будет устанавливаться напрямую.

**Пока уменьшите размер ответа**

Если вы не можете сменить сеть, пока генерируйте изображения в разрешении 2K. Размер ответа уменьшится до нескольких МБ, и прямые соединения будут устанавливаться гораздо чаще. Выполняйте задачи в 4K позже, в среде, где можно использовать прокси.

> [!WARNING]
>
> **Обе проблемы могут возникнуть одновременно.** Если после переключения на прокси запросы начинают пакетно обрываться через 90–180 секунд, это тайм-аут простоя узла прокси; см. [Запросы на генерацию изображений обрываются примерно через 90 секунд при работе через прокси?](/ru/faq/proxy-idle-timeout-disconnect). В этом случае сначала переключитесь на узел прокси с более длительным тайм-аутом простоя или запустите программу для генерации изображений на сервере.

### Также задайте разумный тайм-аут

В такой ситуации программа не получает сигнал об отключении, поэтому обнаружить сбой можно только по тайм-ауту самой программы. При тайм-ауте в 900 секунд вам придётся ждать 15 минут, чтобы узнать, что запрос завершился ошибкой.

При генерации изображения запрос без потоковой передачи не передаёт данные, поэтому тайм-аут чтения не может быть меньше времени генерации. Задайте его **немного больше обычного времени генерации**: около 300 секунд для 4K и около 180 секунд для 1K/2K. После тайм-аута сначала проверьте журнал вызовов, чтобы узнать, была ли тарификация запроса, а затем решите, повторять ли его, чтобы не сгенерировать одно и то же изображение дважды.

## Произойдёт ли это после развёртывания на сервере?

Подключение к APIYI с облачных серверов в материковом Китае или за рубежом обычно намного лучше, чем через домашний интернет, поэтому эта проблема чаще всего возникает при локальной разработке. Если на сервере тоже наблюдается ситуация, когда «заголовки приходят, а тело обрывается на полпути», следуйте инструкциям в разделе [Устранение обрывов подключения к API генерации изображений](/ru/api-capabilities/image-connection-drops).

## Часто задаваемые вопросы

> **За эти неудачные запросы взималась плата?**
>
> Нет. Запросы, отмеченные как `write_response_body_failed` в журнале вызовов, не тарифицируются. Сумма, указанная в каждой записи журнала, является окончательной.

> **Прямая проверка подключения к api.apiyi.com проходит успешно. Почему вы считаете, что проблема в канале связи?**
>
> При проверке подключения отправляется и принимается всего несколько сотен байт, а сама проверка занимает значительно меньше секунды. Проблема проявляется только при передаче ответа размером в десятки МБ, чего небольшой запрос выявить не может.

> **Продолжает ли сервер генерацию после завершения моей программы?**
>
> После отправки запроса сервер, как обычно, генерирует изображение. Поэтому, если вы завершите программу и сразу отправите запрос повторно, генерация может выполняться одновременно для двух запросов. Однако в описанной здесь ситуации к моменту завершения программы сервер обычно уже давно заканчивает генерацию изображения, но не может отправить его вам, поэтому плата не взимается.

> **Проблема должна затрагивать только 4K. Почему иногда зависает и 2K?**
>
> Чем больше ответ, тем выше вероятность его обрыва, но нет строгого порога размера, выше которого сбой происходит всегда. Ответ 2K всё равно занимает несколько МБ, поэтому при плохом канале связи проблема может возникнуть и с ним, хотя и гораздо реже.

## Связанные документы

> **[Вызовы для генерации изображений через прокси обрываются примерно через 90 секунд?](/ru/faq/proxy-idle-timeout-disconnect)**
>
> Противоположная проблема: прокси закрывает неактивные соединения; устраните её, подключившись напрямую

> **[Устранение проблем с обрывами соединения с Image API](/ru/api-capabilities/image-connection-drops)**
>
> Полное руководство по устранению ошибок write\_response\_body\_failed, SSL EOF и других ошибок разрыва соединения

> **[В журнале указано, что вызов завершился и был тарифицирован, но клиент так и не получил ответ — как устранить проблему?](/ru/faq/log-duration-vs-client-wait)**
>
> Откуда возникает разница между длительностью, указанной в журнале, и временем ожидания на стороне клиента

> **[Как просмотреть записи о вызовах?](/ru/faq/call-logs)**
>
> Проверьте статус и стоимость каждого запроса за выбранный период


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.