500 internal server error у вендора: что приходит через go2llm
Статус 500 означает внутренний сбой на стороне сервера, который обрабатывал запрос, — не ошибку в вашем теле и не проблему с ключом или балансом. OpenAI API возвращает его с кодом server_error и сообщением The server had an error while processing your request, Anthropic — с типом api_error. У go2llm то, что вы увидите, зависит от того, включён ли роутер провайдеров. При включённом роутере он делает ровно одну попытку на запрос: статус поставщика доходит до клиента как есть — пятисотка остаётся пятисоткой, только в конверте go2llm, с error.code: "upstream_http_500". При выключенном роутере работает старый путь: go2llm сначала пробует другие подходящие маршруты, и 502 upstream_unavailable появляется лишь тогда, когда провалились они все. Какой режим сейчас на go2llm.tech, видно без ключа — curl -s https://go2llm.tech/status, поле providerRouterV1: сегодня там true, но это текущая настройка, а не обещание навсегда, так что проверяйте сами, а не полагайтесь на эту страницу.
Страница составлена 2026-10-03, обновлена 2026-10-03.
Как выглядит ошибка
Прямой OpenAI API на внутреннем сбое отвечает так:
{
"error": {
"message": "The server had an error while processing your request. Sorry about that!",
"type": "server_error",
"param": null,
"code": null
}
}Anthropic Messages API в аналогичной ситуации:
{
"type": "error",
"error": {
"type": "api_error",
"message": "An unexpected error has occurred internal to Anthropic's systems."
}
}Оба текста прямо говорят: проблема на стороне вендора, а не в запросе. Оба вендора в своей документации рекомендуют один и тот же рецепт — подождать и повторить запрос.
go2llm на то же самое отвечает статусом 500, когда включён роутер провайдеров, — но в своём конверте:
{
"error": {
"type": "upstream_error",
"code": "upstream_http_500",
"message": "The upstream model is temporarily unavailable. Retry the request (request_id: gw_5e0c92a1d7b3486fa4e18c05b2d7f639).",
"request_id": "gw_5e0c92a1d7b3486fa4e18c05b2d7f639"
}
}На старом пути — когда роутер провайдеров выключён, — 500 сначала ретраится на других подходящих маршрутах, и только когда провалились все, клиент получает 502 upstream_unavailable:
{
"error": {
"type": "upstream_unavailable",
"code": "upstream_unavailable",
"message": "all safe upstream attempts failed",
"request_id": "gw_5e0c92a1d7b3486fa4e18c05b2d7f639"
}
}Статус 502 здесь — код именно go2llm на старом пути, а не переупаковка чужого ответа под тем же именем; на роутере статус — буквальная пятисотка поставщика.
Причины
1. Внутренний сбой у поставщика модели
Единственная причина, которую сами вендоры называют официально: временная неисправность на их стороне, не зависящая от содержимого вашего запроса. Повторный точно такой же запрос через минуту нередко проходит без изменений.
2. На старом пути это могло не дойти до клиента как 500 вовсе
На дороутерном пути go2llm держит несколько маршрутов к одной модели и до начала ответа может переключиться на совместимый fallback-маршрут на разрешённых классах ошибок: если первый маршрут ответил внутренней ошибкой, а второй сработал, клиент получал 200, а не 500 или 502, и сбой оставался незамеченным снаружи; только когда исчерпаны все безопасные попытки, это оборачивалось в 502 upstream_unavailable с сообщением all safe upstream attempts failed. При включённом роутере такого переключения внутри одного запроса нет — он делает ровно одну попытку и отдаёт её результат как есть, поэтому там пятисотка у вендора долетает до вас буквальной пятисоткой, а не прячется за успешным fallback или за 502.
3. Инцидент у вендора шире одного запроса
Если внутренние ошибки повторяются подряд на разных запросах и разных моделях одного поставщика, это уже не единичный сбой, а инцидент на стороне вендора. Признак — повтор 502 через минуты подряд, а не разовая пятисотка.
4. Запрос случайно попал в нестабильный внутренний путь у вендора
Очень длинный вход, редкое сочетание параметров или непубличная временная деградация конкретной модели у поставщика — вендоры такие детали не раскрывают, а публично называют только сам факт внутреннего сбоя.
Как починить по шагам
Шаг 1. Проверьте GET https://go2llm.tech/status — без ключа, показывает состояние шлюза в моменте, включая поле providerRouterV1: true значит, что на этот запрос сработает путь с буквальным статусом (upstream_http_5xx), false — старый путь с общим 502 upstream_unavailable.
Шаг 2. Если ответ пришёл именно от go2llm — читайте error.code, а не только статус. upstream_unavailable, а также любой код вида upstream_http_5xx, безопасно ретраить для текстовых запросов; повторять нельзя только media-запрос с результатом ambiguous_upstream_result и SSE-поток после первого валидного события.
Шаг 3. Внедрите backoff с jitter — тот же принцип, что и для 502/503 в целом, подробный код с обработкой Retry-After — на странице 502 upstream_unavailable и 503. Ретраить нужно весь диапазон 5xx, а не только 502/503: на роутере пятисотка вендора доходит буквальной пятисоткой. Короткая версия под этот конкретный случай:
import random, time
import httpx
def call_with_retry(payload, api_key, max_attempts=4, base=2.0, cap=20.0):
with httpx.Client(timeout=120.0) as client:
for attempt in range(max_attempts):
r = client.post(
"https://go2llm.tech/v1/chat/completions",
headers={"Authorization": f"Bearer {api_key}"},
json=payload,
)
if r.status_code < 500:
return r
if attempt == max_attempts - 1:
return r
delay = min(cap, base * (2 ** attempt))
time.sleep(delay * (0.5 + random.random() / 2))Шаг 4. Если получаете буквально 500 при обращении к go2llm — при включённом роутере провайдеров это чаще всего означает ровно то, что говорит конверт: сбой на стороне вендора, ретранслированный как есть. У такого ответа обычный конверт error.type/error.code/error.request_id, а error.code — вида upstream_http_500. Другой 500 — баг в самом обработчике запроса на go2llm: тело в этом случае голое, {"error": "..."}, без привычного конверта, и разбираться с ним нужно нам, а не в клиентском конфиге. Третий вариант — 500 вообще не от go2llm, а от чего-то в цепочке между вами и шлюзом (свой прокси, CDN, балансировщик) или от неверного base_url в клиенте: у такого ответа обычно нет ни JSON, ни конверта go2llm вовсе — это и есть тот случай, который объясняется проверкой прокси.
Как избежать в будущем
Держите fallback-модель того же протокола и переключайтесь на неё после нескольких повторных отказов от одной модели: на POST /v1/messages парой идут claude-opus-5 и claude-sonnet-5, код запроса не меняется, меняется только строка модели. Не ретрайте бесконечно — если 500 или 502 повторяется дольше нескольких минут, это инцидент у поставщика, и стоит переключиться на другую модель или дождаться дольше, чем поднимать частоту попыток. Считайте, что неудачный запрос к go2llm деньги не списывает: резерв освобождается, если вызов не дошёл до успешного ответа, а фактическая стоимость приходит только в usage.cost_usd успешных запросов.
Связанные ошибки
- 502 upstream_unavailable и 503 — тот же класс отказов поставщика и подробный backoff.
- 529 overloaded_error у Anthropic — соседний случай перегрузки, а не внутреннего сбоя.
- 429 rate_limit_error — лимит запросов, а не сбой на стороне вендора.
- Справочник всех кодов go2llm и docs/errors.
FAQ
Может ли go2llm вернуть буквально статус 500? Да, при включённом роутере провайдеров (проверить — curl -s https://go2llm.tech/status, поле providerRouterV1; на go2llm.tech сегодня там true) статус вендора доходит до клиента как есть, 500 от поставщика приходит буквальной пятисоткой, с error.code: "upstream_http_500" в обычном конверте error.type/error.code/error.request_id. В 502 upstream_unavailable та же пятисотка сворачивается только на старом, дороутерном пути, когда исчерпаны все фолбэк-маршруты. Есть и третий вариант литерального 500 — необработанное исключение в самом обработчике запроса на go2llm: это баг на стороне шлюза, а не ретрансляция чужого сбоя, и тело ответа выдаёт разницу — голое {"error": "..."} вместо конверта.
Значит ли частый upstream_http_500 у go2llm, что у вендоров стало больше сбоев? Нет, значит только то, что при включённом роутере вы видите их честно. На дороутерном пути часть таких сбоев маскировалась автоматическим переключением на другой маршрут до первого байта ответа, и клиент видел либо 200, либо, если фолбэки тоже отказывали, 502. При включённом роутере каждый запрос — это одна попытка на одном маршруте, и её результат отдаётся клиенту как есть.
Чем 500 отличается от 529 у Anthropic? 529 overloaded_error — это явно объявленная перегрузка по всем клиентам API одновременно. 500 api_error — недифференцированный внутренний сбой без уточнения причины. На стороне go2llm разница видна и в ответе: на роутере оба доходят как есть, каждый со своим статусом и кодом вида upstream_http_5xx; в 502 или 503 они сворачиваются только на старом пути, если все безопасные попытки провалились.
Стоит ли ретраить 502 от go2llm так же настойчиво, как 429? Да, тот же принцип экспоненциального backoff с jitter применим к обоим, но лимит попыток лучше держать ниже — три-четыре попытки для интерактивного сценария, больше — только для фоновых задач без пользователя, ожидающего ответ вживую.
Получить ключ и сделать первый запрос за 3 минуты → go2llm.tech. Состояние шлюза — GET /status, подключение — в документации, цены моделей — на странице тарифов.