# Проверка буферизации SSE на reverse proxy

Как измерить буферизацию SSE на reverse proxy: прямой и проксированный маршрут, proxy_buffering, X-Accel-Buffering и временная трасса событий.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/provider-proxy-sse-buffering-test/
Language: ru

Модель может генерировать постепенно, а клиент получать ответ большими порциями. Это не доказывает, что inference-движок игнорирует streaming. Между источником и читателем находятся буферы, транспортные слои и клиентская обработка. Для локализации нужно сравнить один и тот же controlled stream напрямую и через reverse proxy, сохранив моменты отправки и получения. По одному визуальному наблюдению в интерфейсе причину установить нельзя.

## Начните с известного источника

Используйте небольшой fake upstream, который отправляет несколько SSE-событий с заранее заданными паузами. Содержимое и время событий известны, поэтому результат не зависит от очереди модели, GPU и случайного числа выходных токенов. Общую длительность и объём теста ограничьте заранее.

[Стандарт SSE](https://html.spec.whatwg.org/multipage/server-sent-events.html) определяет framing событий, но не обещает конкретную частоту доставки каждого сетевого пакета. Тест должен измерять появление полных событий у клиента, а не требовать совпадения размеров read с размерами отправленных строк. Иначе нормальное транспортное объединение будет ошибочно считаться нарушением протокола.

## Сохраните прямую контрольную трассу

Подключитесь к upstream в разрешённом тестовом контуре без исследуемого прокси. Запишите время отправки каждого события источником и время получения полного события клиентом. Сохраните client version и способ чтения. Буферизация самой библиотеки способна исказить сравнение ещё до появления NGINX в пути.

Если уже на прямом маршруте все данные появляются в конце, сначала исследуйте reader и источник. Добавление настроек прокси в этой ситуации может случайно изменить результат, но не даст объяснения исходной проблемы. Контрольная трасса нужна как основание, а не как формальность.

## Проверьте реальные настройки NGINX

[Документация proxy-модуля](https://nginx.org/en/docs/http/ngx_http_proxy_module.html) описывает proxy_buffering и влияние X-Accel-Buffering при соответствующей обработке заголовка. По умолчанию и в конкретном location возможны разные условия из-за наследования и дополнительных директив. Сохраните эффективную конфигурацию тестируемого маршрута без секретных сведений.

Не копируйте универсальный набор «выключить всё» до измерения. Изменяйте один существенный фактор и повторяйте ту же трассу. Если отправитель задаёт заголовок, проверьте, учитывает ли его прокси; наличие строки в ответе приложения ещё не доказывает действие настройки на промежуточном слое.

## Сравните форму задержек

[MDN о Streams API](https://developer.mozilla.org/en-US/docs/Web/API/Streams_API/Concepts) объясняет чтение chunks разного размера. Поэтому таблица должна содержать время готового события, его порядковый номер и общий путь запроса. Несколько событий в одном read сами по себе допустимы; подозрение возникает из повторяемой дополнительной задержки относительно контрольного маршрута.

Сравните интервалы между событиями и время первого полезного content. Не складывайте служебный comment с токенами ответа. Отдельно отметьте холодное соединение, потому что время установления транспорта не является тем же самым эффектом, что накопление уже отправленных событий.

## Ограничьте вывод исследованным путём

Если изменение buffering устранило задержку на этом location, это объясняет конкретную конфигурацию, а не все будущие маршруты. Другой балансировщик, compression или клиентский reader может снова изменить доставку. Сохраняйте fixture рядом с настройками для повторной проверки после обновления.

Связанные темы — [HTTP proxy Runpod](/ru/journal/runpod-http-port-proxy/) и [проверка streaming vLLM](/ru/journal/vllm-openai-streaming-test/). Полученный артефакт связывает симптомы с transport path и не устанавливает универсальную скорость генерации или требования внешнего маршрутизатора.