AIREITERСообщение upstream connect error or disconnect/reset before headers в ChatGPT или OpenAI API почти всегда указывает на проблему на стороне OpenAI. Его возвращает Envoy — прокси-сервер на периметре инфраструктуры OpenAI. Он не смог получить пригодный ответ от внутреннего бэкенда. В веб-версии ChatGPT эта ситуация нередко отображается как Error Code 111. Настоящая подсказка находится после reset reason:, а фраза before headers означает, что Envoy прекратил ожидание, не получив ни одного заголовка ответа. То есть за этим 503 нет ответа от модели или API — только сообщение самого прокси. Починить инфраструктуру OpenAI со своей стороны нельзя, но дальнейшие действия зависят от причины сброса и от того, где вы столкнулись с ошибкой: в браузере или в коде.
Выберите свой сценарий:
- ChatGPT в браузере или приложении: откройте status.openai.com, затем перезагрузите страницу или начните новый сеанс.
- OpenAI API в коде: изучите причину сброса, сохраните ID запроса и настройте повторные попытки.
Что скрывается за этой ошибкой
Envoy находится между клиентом и бэкендом OpenAI. Получив запрос, он устанавливает соединение с бэкендом, пересылает запрос и ждёт заголовки ответа. Если соединение не удалось открыть, оно было сброшено, истекло время ожидания или сработало ограничение ёмкости ещё до получения заголовков, Envoy возвращает это сообщение с HTTP 503, а иногда с 502. Его можно увидеть на экранах сбоев ChatGPT, в трассировках openai.InternalServerError и в логах агентных систем.
Формулировки бывают разными. Надпись retried and the latest reset reason говорит, что Envoy уже повторил запрос и показывает причину провала последней попытки. В любом случае это прокси OpenAI сообщает, что не дождался ответа от собственного бэкенда. К вашему промпту или телу запроса проблема не относится.
Как расшифровать reset reason
Причина сброса показывает, с чем столкнулся прокси OpenAI и имеет ли смысл повторять запрос.
| reset reason | Что произошло на стороне прокси OpenAI | Что делать |
|---|---|---|
connection timeout | Бэкенд слишком долго принимал новое соединение | Повторить запрос с backoff и проверить статус |
overflow | Достигнут лимит ёмкости или запросов; бэкенд перегружен | Снизить параллелизм, выдержать паузу и повторить запрос |
connection failure / remote connection failure | Бэкенд недоступен или отклонил соединение | Повторить запрос; при постоянной ошибке проверить статус и отправить отчёт |
connection termination / connection reset | Бэкенд закрыл соединение в процессе обработки запроса | Повторить запрос; обычно это совпадает с инцидентом |
protocol error | Проблема с протоколом на стороне OpenAI | Повторить запрос; если ошибка не исчезает, сообщить о ней вместе с ID запроса |
В сообщениях сообщества OpenAI чаще всего встречаются overflow и connection timeout — это похоже на ситуацию, когда бэкенду не хватает ёмкости при всплесках нагрузки. Ни одна из этих причин не исправляется настройками на вашем компьютере. Практические меры здесь — проверить статус, использовать backoff и предусмотреть резервный маршрут.
Ошибка в ChatGPT: сайт, приложение и Error Code 111
Сначала проверьте status.openai.com. Если там опубликован инцидент, основное решение — дождаться его устранения. Однако постоянную ошибку только для одного аккаунта стоит отправить в поддержку. Если статус зелёный, перезагрузите страницу, откройте новую вкладку либо выйдите из аккаунта и войдите снова: устаревшая сессия может удерживать неработающее соединение. Также можно сменить сеть или отключить VPN и корпоративный прокси, но это поможет лишь в том случае, если соединение сбрасывает именно этот промежуточный слой. Проверьте это, прежде чем считать причиной OpenAI.
Если ошибка приходит из OpenAI API
В API такая ошибка обычно носит случайный характер и зависит от нагрузки. Разработчик в трекере задач openai-python сообщил, что при сотнях запросов в час примерно 5% вызовов завершались ошибкой openai.InternalServerError: upstream connect error or disconnect/reset before headers, тогда как остальные 95% проходили успешно. Такая доля частичных отказов указывает на насыщение бэкенда. Задачи с пакетной обработкой — массовое создание эмбеддингов, загрузка больших объёмов документов — сталкиваются с ней чаще, поскольку повышают параллелизм. Обычно нужен не другой payload, а политика повторных попыток; при высокой нагрузке столь же важны ограничение параллельности и постановка пакетных задач в очередь.
Прежде чем эскалировать проблему, соберите данные, подтверждающие, что источник у провайдера: время ошибки, endpoint и модель, HTTP-статус и тело ответа, x-request-id, версию SDK, число запросов в работе и совпадают ли сбои с опубликованным инцидентом. После этого примените политику повторов, пригодную для production:
import random, time
from openai import OpenAI, APIStatusError, APIConnectionError
client = OpenAI()
def with_retry(fn, max_attempts=5, cap=30.0):
for attempt in range(max_attempts):
try:
return fn()
except (APIConnectionError, APIStatusError) as e:
status = getattr(e, "status_code", None)
# retry connection drops and 5xx (incl. this 503); never blindly retry 4xx
if isinstance(e, APIStatusError) and status and status < 500 and status != 429:
raise
if attempt == max_attempts - 1:
raise
retry_after = float(getattr(e, "response", None).headers.get("retry-after", 0)) if getattr(e, "response", None) else 0
backoff = retry_after or min(cap, 0.5 * 2 ** attempt) * (0.5 + random.random())
time.sleep(backoff)SDK OpenAI уже самостоятельно повторяют временные ошибки: параметр max_retries по умолчанию равен 2. Поэтому перед тем как оборачивать вызовы собственной логикой, задайте это значение явно — например, OpenAI(max_retries=0). Иначе повторы вашего кода и SDK будут накладываться друг на друга. Ограничьте общее число попыток диапазоном 3–5 и контролируйте общий параллелизм, чтобы ретраи не усиливали всплеск, вызвавший overflow. Для 429 соблюдайте Retry-After; 408/409 повторяйте только тогда, когда операцию безопасно выполнить повторно. Особенно осторожно относитесь к неидемпотентным и потоковым вызовам: слепой повтор может продублировать работу или заново воспроизвести частично прочитанный поток.
Как ошибка выглядит на стороне клиента
Тело 503 от Envoy видно не всегда: иногда соединение обрывается ещё раньше. При обращении curl -v к неработающему endpoint можно получить curl: (52) Empty reply from server после Request completely sent off: запрос ушёл, но ответ не вернулся. В варианте от самого Envoy приходит 503, а текст upstream connect error... находится в теле ответа. Это совпадает с публичными отчётами: пользователь сабреддита OpenAI опубликовал точную строку retried and the latest reset reason: connection timeout вместе с сообщением "Network connection lost", а в трекере openai-python та же ошибка фигурирует как InternalServerError при большом объёме запросов.
Когда стоит переключаться на резервный маршрут
Поскольку сбой происходит между шлюзом OpenAI и его бэкендом, при работе с единственным endpoint вам остаются только повторы и backoff. Другой вариант — резервирование: направлять запросы через слой, который переключается на другой бэкенд, если один upstream зависает или выдаёт overflow. Мультипровайдерные шлюзы вроде OpenRouter и AIReiter работают с несколькими поставщиками моделей и обходят медленный маршрут — по той же модели мультипровайдерной маршрутизации, на которой построен OpenRouter. Тогда замедление одного upstream может привести к перенаправлению, а не к 503 для клиента. Но компромиссы реальны: появляется дополнительный сетевой переход, зависимость от доступности самого маршрутизатора, а также различия в ценах, обработке данных и наблюдаемости. Зато снижается зависимость от стабильности одного провайдера.
FAQ
Что означает ChatGPT Error Code 111?
Некоторые пользователи ChatGPT видят это сообщение вместе с меткой "Error Code 111". Оно означает, что прокси OpenAI не смог получить ответ от своего бэкенда, то есть проблема на стороне сервера. Проверьте status.openai.com и перезагрузите страницу.
Почему ошибка возникает только под нагрузкой или случайно?
Сбои, зависящие от нагрузки, обычно связаны с overflow — ограничением ёмкости или запросов — либо с насыщением бэкенда, из-за которого подключение не укладывается в тайм-аут. Обе ситуации проявляются при росте параллелизма, поэтому тот же код большую часть времени работает нормально.
Могут ли причиной быть VPN или firewall?
Да, но только если соединение между вами и OpenAI сбрасывает именно этот слой. Проверить это сменой сети стоит, однако VPN или firewall не исправят настоящий сбой OpenAI либо 503 на стороне API.
Это то же самое, что ошибка лимита 429?
Нет. Код 429 — это явно полученный ответ о превышении лимита. Этот 503 означает, что пригодного ответа вообще не поступило. При 429 соблюдайте Retry-After, а при 503 используйте backoff и повторите запрос.
Что значит «retried and the latest reset reason»?
Envoy уже повторил запрос, а это причина, по которой не удалась последняя попытка. Формулировка указывает на устойчивую проблему бэкенда на стороне OpenAI, а не на единичный кратковременный сбой.