> ## 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.

# Запросы на генерацию изображений обрываются примерно через 90 секунд при работе через прокси?

> При локальной разработке с включенным VPN или прокси запросы на генерацию изображений массово обрываются через 90–180 секунд независимо от установленного таймаута, но все равно тарифицируются. Прокси закрывает соединения, по которым не передаются данные. Настройте прямое подключение к api.apiyi.com, чтобы это исправить.

## Симптомы

Вы разрабатываете или отлаживаете приложение для генерации изображений на своем компьютере с запущенным VPN- или прокси-клиентом (многие разработчики держат его включенным, чтобы инструменты ИИ для написания кода имели доступ к интернету). При этом наблюдается следующее:

* Запросы на генерацию изображений часто завершаются ошибками соединения, такими как `socket hang up`, `ECONNRESET`, `RemoteDisconnected` или `Connection aborted`
* Таймаут вашего клиента составляет 600 или даже 900 секунд, однако запросы обрываются примерно через **90–180 секунд**
* Несколько запросов часто **завершаются сбоем в один и тот же момент**, словно их оборвали вместе
* Проблема чаще затрагивает более медленные модели (например, `gpt-image-2-vip`, обработка одного изображения в которых обычно занимает 60–120 секунд)
* В [логах вызовов](/ru/faq/call-logs) **большинство этих запросов отображаются как успешные и тарифицированные**

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

<Info>
  **Это не лимит параллельных запросов и не таймаут APIYI. Прокси на вашем компьютере закрывает соединения, по которым некоторое время не передаются данные.**

  Во время генерации изображения данные по соединению вообще не передаются. Чем дольше длится генерация, тем выше вероятность того, что прокси сочтет соединение простаивающим и закроет его. Направьте `api.apiyi.com` напрямую (в обход прокси), и проблема исчезнет. APIYI доступен напрямую из материкового Китая.
</Info>

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

Запрос на генерацию изображений без потоковой передачи проходит три этапа:

1. **Загрузка**: отправляются prompt и референсные изображения, что занимает от нескольких секунд до нескольких десятков секунд
2. **Ожидание**: сервер генерирует изображение, обычно в течение 60–200 секунд. **В это время по соединению не передаются данные**
3. **Скачивание**: готовое изображение возвращается целиком за один раз

Проблема заключается во 2-м этапе. Чтобы освободить ресурсы, прокси-клиенты и прокси-серверы устанавливают для каждого соединения таймаут простоя: если в течение этого времени данные не передаются ни в одном из направлений, соединение закрывается. В широко используемом ядре Xray / V2Ray за это отвечает параметр `connIdle` со значением по умолчанию 300 секунд, однако **оператор прокси-сервера может установить гораздо меньшее значение**, и вы не можете ни увидеть, ни изменить его со своего компьютера. В исследованном нами случае это значение составляло около 90 секунд.

В результате:

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

<Warning>
  **Прерванные запросы обычно все равно тарифицируются.** Запрос уже поступил в APIYI, и генерация началась. Разрыв соединения не останавливает процесс, поэтому изображение генерируется и тарифицируется в обычном порядке, но результат так и не доходит до вашей программы. Проверяйте фактические списания в [журналах вызовов](/ru/faq/call-logs), а не по количеству ошибок в вашей программе.
</Warning>

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

<Steps>
  <Step title="Проверьте время выполнения">
    Зафиксируйте, сколько времени выполнялся каждый неудачный запрос до возникновения ошибки. Если длительность группируется вокруг фиксированного значения (например, 90 или 180 секунд), и несколько запросов часто завершаются сбоем в **одну и ту же секунду**, причиной практически наверняка является тайм-аут простоя прокси.
  </Step>

  <Step title="Сравните с логами вызовов">
    Найдите тот же временной интервал в [логах вызовов](/ru/faq/call-logs). Если ваша программа сообщила о разрыве соединения, но в логе отображается успешный тарифицированный запрос, значит, APIYI завершил генерацию изображения, а соединение обратно к вам было разорвано.
  </Step>

  <Step title="Запустите небольшую партию через прямой маршрут">
    Направьте `api.apiyi.com` напрямую, как описано ниже, и запустите генерацию 10-20 изображений с теми же параметрами. Если разрывы исчезнут, причиной был прокси.
  </Step>
</Steps>

## Как это исправить

<Tabs>
  <Tab title="Правило прямого подключения в прокси-клиенте (рекомендуется)">
    Добавьте правило прямого подключения (direct) для APIYI в вашем прокси-клиенте. Весь остальной трафик продолжит идти через прокси, поэтому работа ваших инструментов разработки на базе ИИ не будет нарушена.

    Для Clash / Clash Verge / mihomo добавьте следующее в начало раздела `rules` в файле конфигурации:

    ```yaml theme={null}
    rules:
      - DOMAIN-SUFFIX,apiyi.com,DIRECT
      # ... your existing rules
    ```

    Для v2rayN и аналогичных клиентов добавьте `apiyi.com` в список прямого подключения (direct) в настройках маршрутизации.

    <Note>
      В **режиме TUN или глобальном режиме** прокси перехватывает трафик от всех программ на компьютере, и обойти его программно в вашем коде невозможно. Единственное решение — настроить такое правило прямого подключения.
    </Note>
  </Tab>

  <Tab title="Обход прокси в вашей программе">
    Если прокси используется только как системный прокси или прокси через переменные окружения (режим TUN выключен), ваша программа может не использовать его:

    ```bash theme={null}
    # Set before running your program so APIYI domains bypass the proxy
    # macOS / Linux
    export NO_PROXY="api.apiyi.com,.apiyi.com"
    # Windows PowerShell
    $env:NO_PROXY="api.apiyi.com,.apiyi.com"
    ```

    * **Python `requests` / `httpx`**: они автоматически считывают настройки системного прокси. Установите `trust_env=False`, чтобы отключить это; пример кода см. в статье [Скрипт получает 502, но в журнале вызовов ничего нет?](/ru/faq/proxy-empty-502)
    * **Node.js**: встроенный `fetch` по умолчанию не считывает системный прокси. Если вы используете `HTTPS_PROXY` с `ProxyAgent`, `global-agent` или аналогичными библиотеками, исключите `api.apiyi.com`. При использовании `axios` передайте `proxy: false` в запросе
  </Tab>

  <Tab title="Если вам обязательно нужно использовать прокси">
    Изменить эти настройки можно только на собственном прокси-сервере. Увеличьте таймаут бездействия (idle timeout) до значения более 600 секунд (в Xray / V2Ray это `policy.levels.<level>.connIdle`). Если сервером управляет кто-то другой, изменить его вы не сможете, поэтому прямое подключение остаётся более предпочтительным вариантом.
  </Tab>
</Tabs>

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

**Обычно нет.** Серверы, как правило, работают без прокси и подключаются к APIYI напрямую, поэтому прокси не закрывает неактивные соединения. Это также рекомендуемая конфигурация для продакшена: облачный сервер в материковом Китае может обращаться к `api.apiyi.com` напрямую.

Если между вашим сервером и APIYI есть другие уровни, у них также есть таймауты неактивности. Проверьте их при развертывании:

| Уровень | Обычное значение по умолчанию | Примечания |
| - | - | - |
| Облачный NAT-шлюз / балансировщик нагрузки | Azure: 4 минуты; NAT-шлюз AWS: 350 секунд | Применяется, только если у сервера нет публичного IP и выход наружу идет через NAT; в большинстве случаев значение можно увеличить в консоли |
| Собственный обратный прокси Nginx | В `proxy_read_timeout` по умолчанию установлено 60 секунд | Если вы размещаете Nginx между вашим сервисом и APIYI, это значение необходимо увеличить; см. [Как избежать таймаутов API?](/ru/faq/timeout-configuration) |
| Прокси, установленный на сервере | Зависит от его настроек | Та же проблема, что и при локальной разработке; направляйте запросы к APIYI напрямую |

Генерация одного изображения обычно занимает от 60 до 200 секунд, что укладывается в стандартные лимиты облачных NAT. Дополнительная настройка требуется только в том случае, если вы используете собственный обратный прокси или трафик сервера также идет через прокси.

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

<AccordionGroup>
  <Accordion title="Помогает ли включение TCP keepalive?">
    Это помогает в случае облачных NAT-шлюзов, поскольку зонды keepalive сообщают NAT, что соединение всё ещё активно. Однако это практически не даёт эффекта при использовании прокси-клиентов: они определяют простой по наличию реальных данных, а зонды keepalive данными не считаются. Для сценария локальной разработки решением по-прежнему остаётся прямая маршрутизация.
  </Accordion>

  <Accordion title="Почему веб-консоль и мои AI-инструменты для написания кода работают нормально?">
    Их запросы либо быстро возвращают ответ, либо непрерывно передают данные через потоковую передачу, поэтому соединение никогда не простаивает 90 секунд и дольше. С этой проблемой сталкиваются только такие запросы, как генерация изображений, которые ничего не отправляют в течение нескольких минут, а затем возвращают весь результат разом.
  </Accordion>

  <Accordion title="Это то же самое, что и проблема с пустым 502?">
    Обе проблемы вызваны локальным прокси, но симптомы различаются. В [случае с пустой ошибкой 502](/ru/faq/proxy-empty-502) прокси сам формирует ответ 502 без тела. Здесь же соединение обрывается во время ожидания изображения, и ваша программа видит разорванное соединение. Решение для обеих ситуаций одинаковое: направлять запросы к APIYI в обход прокси.
  </Accordion>

  <Accordion title="Можно ли вернуть средства за оборванные запросы?">
    Эти обрывы происходят на прокси между вами и APIYI уже после того, как APIYI сгенерировал изображение и выполнил тарификацию. Если сумма существенна, отправьте в службу поддержки временной интервал (с указанием часового пояса, например 16:30-17:00 (UTC+8)) и ваше имя пользователя, и мы вместе проверим журналы вызовов.
  </Accordion>

  <Accordion title="Можно ли отправлять вызовы без столь долгого ожидания?">
    Эндпоинты генерации изображений в настоящее время возвращают ответ синхронно, без опроса по task ID; см. раздел [Существует ли асинхронный API для изображений? Можно ли опрашивать результаты по task ID?](/ru/faq/image-async-api). Как только для APIYI будет настроена прямая маршрутизация, само по себе долгое ожидание перестанет быть проблемой.
  </Accordion>
</AccordionGroup>

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

<CardGroup cols={2}>
  <Card title="Скрипт возвращает 502, но в логах вызовов ничего нет?" icon="unplug" href="/ru/faq/proxy-empty-502">
    Пустая ошибка 502, сформированная локальным прокси; для исправления настройте обход системного прокси
  </Card>

  <Card title="Нужен ли прокси для использования API?" icon="wifi" href="/ru/faq/network-proxy">
    Прямой доступ из материкового Китая, прокси или VPN не требуются
  </Card>

  <Card title="Как избежать таймаутов API?" icon="timer" href="/ru/faq/timeout-configuration">
    Настройки таймаутов и пошаговая диагностика
  </Card>

  <Card title="Есть ли асинхронный API для изображений?" icon="clock" href="/ru/faq/image-async-api">
    Почему ответы синхронные и как сделать для них асинхронную обертку
  </Card>
</CardGroup>


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