SSE Streaming broken through Zscaler VPN proxy (v0.8.2-rc1 / v0.8.3-rc1)

[alain-lim]

Description

Since upgrading to v0.8.2-rc1 / v0.8.3-rc1, SSE (Server-Sent Events) streaming no longer works
when traffic passes through a Zscaler VPN (or any SSL-inspecting corporate proxy).

The chat response never renders at all (timeout/broken stream), the response can still be get when it finished and user reload the page

This was working correctly on the version v0.8.2-rc1.

Environment

• LibreChat version: v0.8.3-rc1
• Deployment: Docker / self-hosted
• Reverse proxy: ALB
• Network: Corporate network with Zscaler ZIA (SSL inspection enabled)
• Browser: Chrome

Steps to Reproduce

1. Deploy LibreChat v0.8.3-rc1
2. Connect client machine to a network routed through Zscaler VPN with SSL inspection enabled
3. Open LibreChat and send any message to an LLM endpoint
4. Observe that the streaming response does not render incrementally

Expected Behavior

Tokens stream progressively in real-time as they are generated by the LLM.

Actual Behavior

The response is buffered and only appears all at once after full generation (or the stream
times out entirely). The same setup works correctly when Zscaler is bypassed or disabled.

Root Cause Analysis

Zscaler acts as a TLS MITM proxy and buffers SSE chunks before forwarding them to the
client. This breaks the incremental nature of SSE streaming.

This may be aggravated in v0.8.3-rc1 if the streaming implementation changed (stricter SSE
handling, new endpoints, HTTP/2 usage, or MCP SSE client changes) making it less tolerant
of intermediary buffering compared to previous versions.

[danny-avila]

Thanks for the detailed report. The root cause is likely the new Resumable Streams architecture.

What Changed:

In v0.8.2-rc1, streaming was a single SSE connection: the POST to /api/agents/chat returned the SSE stream directly in the response body.

In v0.8.3-rc1, streaming now uses a two-phase connection pattern:

1. POST /api/agents/chat → returns JSON: { streamId, conversationId, status: 'started' }
2. GET /api/agents/chat/stream/:streamId → separate SSE subscription (this is the actual event stream)

This is what's likely breaking with Zscaler. Your SSL-inspecting proxy may be:

• Buffering/not forwarding the separate long-lived GET SSE connection properly
• Having issues with the new Content-Encoding: identity response header on the SSE endpoint
• Not expecting this two-step handshake where the POST returns JSON and the SSE is on a different path

What to Try

If your ALB or proxy config was doing any path-based routing or special SSE handling for /api/agents/chat, you'll need to also allowlist/configure the new streaming endpoint:

/api/agents/chat/stream/*

Specifically, ensure your proxy/ALB:

• Allows long-lived GET connections to /api/agents/chat/stream/:streamId
• Disables response buffering for that path (similar to what X-Accel-Buffering: no does for Nginx)
• Doesn't strip or modify the Content-Encoding: identity header

If Zscaler has an SSL inspection bypass list, adding the streaming endpoint pattern may also help.