SSE приходит пачками через Nginx: отключаем буферизацию на потоке событий

Приложение формирует событие каждую секунду. При прямом запросе клиент видит их сразу, а через Nginx получает несколько событий одной пачкой. Сервер не обязательно перестал отправлять данные: промежуточный уровень может накапливать ответ в буферах. Для Server-Sent Events это меняет главное свойство интерфейса — своевременную доставку.

Сравните поток до и после прокси

curl -N --max-time 15 http://127.0.0.1:9000/events
curl -N --max-time 15 https://app.example/events

Первую проверку выполняют с машины, которой доступен backend. Параметр N отключает буферизацию вывода самого curl. Он не меняет сервер и Nginx, но убирает ещё одно место, где могли накапливаться данные. Ограничение времени позволяет завершить диагностический поток автоматически.

Сравнивайте время появления событий, а не только одинаковое содержимое после завершения команды. Полезно, если учебный поток включает отметку формирования события. Тогда видно, что приложение создало данные раньше их отображения. Если уже прямой поток приходит пачками, сначала проверяйте приложение и его flush.

Настройте конкретный потоковый путь

location /events {
    proxy_pass http://127.0.0.1:9000;
    proxy_http_version 1.1;
    proxy_buffering off;
    proxy_read_timeout 90s;
}

proxy_buffering off отключает накопление ответа прокси для этого location. Приложение также может передать X-Accel-Buffering: no, если конфигурация Nginx не игнорирует этот заголовок. Выберите управляемый способ, который соответствует ответственности команд: настройка конкретного location или осознанный сигнал от приложения.

Ответ SSE должен иметь подходящий Content-Type и корректное разделение событий пустой строкой. Клиент может ждать завершения сообщения, даже если отдельные байты приходят сразу. Поэтому отключение буфера не исправляет неправильное форматирование потока.

Проверьте периоды тишины

proxy_read_timeout измеряет ожидание между чтениями от upstream. Если события бывают редко, согласуйте период heartbeat-комментариев SSE и ограничения промежуточных узлов. Значение 90 секунд в примере иллюстрирует настройку; оно должно соответствовать реальному протоколу и ресурсам приложения.

Протестируйте не только активную серию, но и паузу между событиями. Если соединение закрывается через одинаковое время, посмотрите журналы и idle-таймауты балансировщика перед Nginx. Иначе можно исправить один буфер и продолжить терять соединения на другом уровне.

Отключение буферизации увеличивает связь скорости клиента и upstream. Медленный клиент дольше удерживает поток и ресурсы приложения. Поэтому применяйте настройку к SSE-пути, а не ко всем большим ответам сайта. Для обычного скачивания буферизация может выполнять полезную роль.

После проверки синтаксиса и согласованного применения повторите оба curl-вызова. Ожидаемый результат — сопоставимый интервал появления событий напрямую и через прокси. Отдельно убедитесь, что клиент корректно восстанавливает поток при штатном разрыве, если это предусмотрено приложением.

Учитесь видеть различие между доставленными байтами и работающим интерфейсом. Откройте программу Linux и Bash для DevOps-инженеров. Практика HTTP и диагностики сервиса помогает выбирать проверку по поведению приложения и подтверждать результат после изменения конфигурации.

Ещё по теме

• Загрузка файла получает 413: находим лимит тела запроса в Nginx и приложении
• После TLS-терминации приложение зациклило redirect: передаём исходную схему