Два API-посредника одновременно медленные или недоступны: как проверить общий upstream
Одновременные 5xx или тайм-аут у двух входов не обязательно означают проблему локальной сети. Разделите DNS, TLS, HTTP и бизнес-статус, сравните отпечатки ответов и request ID и используйте недорогие пробы, чтобы отличить общий upstream, сбой одного сервиса и ошибку клиента без лишних повторов и списаний.
Одновременное замедление или ошибка у двух API-посредников не доказывает проблему в локальной сети. Два сервиса могут использовать одного поставщика модели, общий шлюз выхода, DNS или региональный маршрут. Возможен и другой сценарий: клиент несколько раз повторил одну неясную попытку. Для проверяемого вывода нужно отдельно записывать DNS, TLS, HTTP, маршрутизацию и конечный бизнес-статус.
Что считать одновременной аварией
Для каждой попытки создайте локальный probe_id и сохраните время начала, целевой хост, модель, режим потоковой передачи, версию клиента и лимит ожидания. Один клик пользователя может породить несколько сетевых попыток, поэтому итоговый успех нельзя сразу считать показателем стабильности.
Разделите проблему на три слоя:
- Локальный слой или вход: ошибка DNS, невозможность открыть TCP, несовпадение имени в TLS-сертификате или тайм-аут соединения с прокси.
- Слой посредника: HTTP 401/403/404, 429, ошибка шлюза 5xx, отсутствие или изменение формата request ID в заголовках.
- Верхний поставщик и бизнес-слой: оба входа возвращают похожий 5xx или тайм-аут, либо HTTP 200 приходит, но маршрутизация модели, инструменты или асинхронный статус завершаются ошибкой.
Код HTTP описывает результат обработки текущего запроса сервером, но сам по себе не указывает слой отказа. Сверяйте смысл кодов с определениями статусов RFC 9110: 429 означает ограничение текущего ресурса, а 503 обычно говорит о временной невозможности обработки. Всегда добавляйте заголовки и временную шкалу.
Сначала изолируйте локальную сеть безопасными пробами
Не отправляйте настоящий промпт снова только для проверки. Для каждого входа сначала выполните DNS, TCP/TLS и запрос, который не запускает модель и не оплачивается. Если публичного health-endpoint нет, можно отправить OPTIONS или запрос к заведомо ошибочному пути и пометить его как диагностический; не предполагайте, что неизвестный путь бесплатен.
Для одной машины и одинаковых настроек прокси сохраните:
| Этап | Что записать | Возможный вывод |
|---|---|---|
| DNS | адреса, длительность, IPv4/IPv6 | Ошибка только у одного имени указывает на домен или локальный resolver; общая ошибка указывает на сеть или DNS |
| TCP/TLS | время соединения, имя сертификата, версия протокола | Сбой до HTTP нельзя приписывать верхней модели |
| HTTP | статус, заголовки, время до первого байта | Сходство статуса и времени у обоих входов даёт лишь гипотезу об общей зависимости |
| Бизнес | request ID, маршрут модели, конечный статус | HTTP 200 может означать только принятие запроса, а не завершение генерации |
Документация Node.js для dns и tls описывает наблюдаемые события разрешения имени и защищённого соединения. В диагностическом скрипте выводите только длительность, код ошибки и имя в сертификате; Authorization никогда не печатайте. PowerShell, curl или Python дадут те же поля, если условия у двух входов одинаковы.
Сравнивайте отпечаток ответа, а не только текст ошибки
Для каждого ответа сформируйте обезличенный отпечаток: статус, content-type, retry-after, формат request ID, набор верхних ключей ошибки, диапазон времени до первого байта и факт обрыва до тела. Текст ошибки может содержать номер заказа, внутренний адрес или пользовательский ввод, поэтому его следует обрезать и удалить секреты.
Если A и B в один период возвращают одинаковый статус и ключи ошибки, но имеют разные префиксы request ID, заголовок Server или TLS-сертификат, это может означать общую зависимость выше входных шлюзов. Если меняются только DNS, сертификат или 429 у A, сначала проверяйте сам A. Если соединение устанавливается у обоих, но ломается только одна модель, сравните маршрут, группу доступа и возможности верхнего поставщика, а не меняйте сеть наугад.
Записывайте четыре момента: отправка, первый байт, конечный статус и появление записи в расчётах. При отсутствии конечного статуса не делайте вывод «списания нет» по одному тайм-ауту. Дождитесь записи в счёте или результата запроса к сервису, затем решайте вопрос о повторе. Для 202 и конечных статусов см. разбор опроса асинхронных задач API; для правильной статистики повторов — метрики стабильности API.
Три минимальных эксперимента
Эксперимент A: смените модель внутри одного входа
Зафиксируйте вход, Key, прокси и короткий промпт, заменив только модель с подтверждённым доступом. Если ломаются все модели, подозревайте вход или аккаунт; если только одна, проверьте имя, группу и сопоставление с верхним поставщиком. Наличие модели в списке не доказывает право вызова.
Эксперимент B: смените вход при той же модели
Зафиксируйте модель, тело запроса и лимит ожидания. Выполните по одной недорогой пробе через A и B, затем подождите одинаковое окно наблюдения. Ошибка A до TLS — проблема входа. Если оба соединения установились и оба в бизнес-слое вернули похожий 503, гипотеза об общем поставщике или региональном маршруте становится сильнее. Одна пара запросов ничего не доказывает: повторите в другом временном окне и сохраните исходную шкалу времени.
Эксперимент C: смените сеть при том же входе
Не меняя Key и тело, выполните одну пробу через другую разрешённую сеть или контролируемый прокси. Если ломается только одна сеть, проверяйте прокси, NO_PROXY, IPv6 и правила выхода. Не меняйте одновременно вход, модель и сеть: тогда результат нельзя связать с причиной.
Оцените совпадение локальным примером
Следующий скрипт не обращается к API. Он группирует уже сохранённые пробы по пяти минутам и ищет одинаковые отпечатки. Окно без записи одного из входов не считается общей ошибкой.
const samples = [
{ at: '2026-11-13T01:00:04Z', provider: 'A', phase: 'http', status: 503, errorKey: 'upstream_unavailable' },
{ at: '2026-11-13T01:01:12Z', provider: 'B', phase: 'http', status: 503, errorKey: 'upstream_unavailable' },
{ at: '2026-11-13T01:08:10Z', provider: 'A', phase: 'tls', status: null, errorKey: 'handshake_timeout' }
]
function windowKey(iso) {
const ms = Date.parse(iso)
if (!Number.isFinite(ms)) throw new Error('invalid timestamp')
return Math.floor(ms / 300_000)
}
function sharedWindows(rows) {
const buckets = new Map()
for (const row of rows) {
if (!['A', 'B'].includes(row.provider)) continue
const key = windowKey(row.at)
const list = buckets.get(key) ?? []
list.push(row)
buckets.set(key, list)
}
return [...buckets].flatMap(([window, list]) => {
const byProvider = new Map(list.map(row => [row.provider, row]))
const a = byProvider.get('A')
const b = byProvider.get('B')
if (!a || !b) return []
const sameFingerprint = a.phase === b.phase && a.status === b.status && a.errorKey === b.errorKey
return [{ window, sameFingerprint, providers: { A: a, B: b } }]
})
}
console.log(sharedWindows(samples))
Результат означает только «в одном временном окне совпал отпечаток», а не подтверждённый общий upstream. В рабочем журнале храните число проб, окна без данных и сетевые условия; три строки не превращайте в показатель доступности. Запускайте пример с обезличенным локальным JSON, без платных запросов.
Когда переключаться, а когда ждать
- Сбой DNS, TLS или прокси: исправьте resolver, доверие к сертификату или настройки прокси. Не пополняйте баланс повторно и не отключайте проверку сертификата.
- Ошибка HTTP только у одного входа: временно используйте проверенный резерв и сохраните для неисправного входа request ID, время и статус.
- Оба входа ломаются в бизнес-слое: запишите общий upstream или региональный маршрут как неподтверждённую гипотезу, уменьшите частоту повторов и ждите сообщения или проверки статуса. Похожая ошибка не является доказательством недостоверности конкретного бренда.
- Оба входа возвращают успех, но результаты различаются: сравните маршрутизацию модели, параметры, завершение потока и счёт. Полезен чек-лист условий и выхода из сервиса-посредника, чтобы сохранить ответы службы поддержки и доказательства миграции.
Перед переключением отметьте текущий запрос как «результат неизвестен» и используйте ключ идемпотентности или локальное устранение дублей. Запрос с уже полученным конечным статусом не повторяйте вслепую. После обрыва потока сначала проверьте счёт или статус задачи, а затем решайте, нужен ли повтор. Так уменьшается риск двойной оплаты и остаётся проверяемое объяснение, почему два сервиса отказали одновременно.