Корпоративная сеть может заблокировать SSE

Симптом

Из внутренней сети корпоративного клиента не устанавливалось SSE-соединение. Обычная часть сервиса работала, но ответы AI не появлялись.

Контекст

Запрос к SSE endpoint с Accept: text/event-stream зависал примерно на 30 секунд и завершался с browser status 0. Временные показатели показывали блокировку до установки DNS-, TLS- или TCP-соединения:

status: 0
blocked: 30007 ms
dns: -1
ssl: -1
connect: -1

При этом предварительный OPTIONS-запрос проходил. Поэтому проверка только доступности host или успешности коротких HTTP-запросов не выявляла проблему.

Корневая причина

Система безопасности корпоративной сети блокировала длительное streaming- соединение к SSE endpoint. Это было ограничение сетевого периметра, а не ошибка обработки AI-ответа в приложении.

Ошибочное предположение

Мы предполагали, что корпоративные firewall и proxy пропустят легитимный протокол, если обычные HTTP-запросы к тому же сервису работают. Для SSE важны не только host и метод запроса, но и длительность соединения, заголовки и потоковая передача данных.

Обнаружение

Сигналом была комбинация признаков:

Такую проверку нужно включать в диагностику отдельно от health check обычного HTTP endpoint.

Исправление

Совместно с командой безопасности клиента настроили исключение для streaming- соединения к SSE endpoint. После этого обычные ответы и AI streaming стали проходить через корпоративный контур.

Проверка

Для каждого поддерживаемого корпоративного контура нужно отдельно проверять:

  1. обычный HTTP-запрос;
  2. preflight OPTIONS;
  3. длительный GET с Accept: text/event-stream;
  4. получение первого события и корректное завершение потока.

В исходной заметке автоматический тест такой сетевой политики не зафиксирован.

Общий вывод

Работающий HTTP endpoint не доказывает доступность streaming-транспорта. Для агентских систем SSE - отдельная инфраструктурная зависимость, которую нужно проверять в реальных сетевых контурах, а не только в локальной среде.