What network configurations may cause responses to be buffered rather than streamed?​

[LauWoods]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
• Please do not modify this template :) and fill in all the required fields.

Content

​What network configurations may cause responses to be buffered rather than streamed? Please provide detailed examples, especially involving intranet penetration and Nginx settings, for easy reference and modification.​

[dosubot[bot]]

The most common network configuration that causes responses to be buffered instead of streamed is reverse proxy buffering—especially with Nginx. By default, Nginx buffers upstream responses, which breaks streaming for APIs using Server-Sent Events (SSE) or similar mechanisms. This is especially problematic for Dify and other LLM apps that rely on real-time output.

To ensure streaming works, update your Nginx config for relevant endpoints (like /api, /console/api, /mcp) as follows:

location /api {
    proxy_pass http://api:5001;
    proxy_http_version 1.1;
    proxy_set_header Connection '';
    proxy_buffering off;
    proxy_cache off;
    proxy_read_timeout 3600s;
    proxy_send_timeout 3600s;
    # ...other proxy settings...
}

Key points:

• proxy_buffering off; and proxy_cache off; are essential to disable buffering.
• Use proxy_http_version 1.1; and clear the Connection header.
• Set high proxy_read_timeout and proxy_send_timeout values for long-lived streams.
• Avoid HTTP/2 for SSE endpoints—Nginx's HTTP/2 implementation often breaks streaming and causes buffering or dropped connections. Use HTTP/1.1 for these endpoints, or move them to a separate server block if you want to keep HTTP/2 elsewhere.
• Never use overlapping location blocks for the same path, as this can break streaming unpredictably.
• If using intranet penetration tools like FRPC, they can interfere with long-lived streaming connections. Test direct backend access to isolate proxy/tunnel issues and ensure FRPC is not prematurely closing or buffering connections.

For Docker/Nginx deployments, always check the official config templates and .env variables like NGINX_PROXY_READ_TIMEOUT and NGINX_PROXY_SEND_TIMEOUT—set them high enough for your use case (e.g., 3600s) [source 1] [source 2].

Other reverse proxies (like Traefik) have similar buffering settings—make sure buffering is disabled for streaming endpoints there as well [source 3].

If you see slow or buffered responses, always check your reverse proxy config first. Most streaming issues are caused by buffering at this layer, not by the backend or application code.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}