Introduction

Server-Sent Events, AI token streams, and other incremental HTTP responses need immediate flushes from upstream to browser. Nginx proxy buffering can coalesce those chunks and release them only after enough data accumulates, which makes a live stream appear frozen or delayed even though the upstream app is sending events continuously.

Symptoms

  • EventSource connections open but updates arrive in large bursts instead of live
  • Streaming responses work locally but stall behind Nginx
  • Browsers show pending network requests while no visible tokens or events appear
  • The issue affects only the proxied environment, not direct upstream access

Common Causes

  • Nginx proxy buffering is enabled on the streaming endpoint
  • Upstream responses are compressed or buffered before reaching Nginx
  • The application does not send the correct SSE headers
  • A CDN or second proxy in front of Nginx adds another buffering layer

Step-by-Step Fix

  1. 1.Confirm the stream works when bypassing Nginx
  2. 2.Test the upstream directly first so you know whether buffering is really introduced at the proxy layer.
bash
curl -N http://127.0.0.1:3000/events
  1. 1.Disable proxy buffering on the streaming location
  2. 2.SSE and chunked streaming endpoints need immediate pass-through instead of buffered proxy behavior.
nginx
location /events {
  proxy_pass http://app_backend;
  proxy_http_version 1.1;
  proxy_set_header Connection "";
  proxy_buffering off;
  proxy_cache off;
  chunked_transfer_encoding on;
}
  1. 1.Verify the upstream sends streaming-friendly headers
  2. 2.The application should identify the response as an event stream and avoid buffering headers of its own.
http
Content-Type: text/event-stream
Cache-Control: no-cache
Connection: keep-alive
  1. 1.Re-test from the public URL and watch events arrive in real time
  2. 2.Use a no-buffering client such as curl -N after the Nginx reload so you can see whether chunks now pass through immediately.
bash
nginx -t && systemctl reload nginx
curl -N https://example.com/events

Prevention

  • Treat streaming routes differently from normal JSON API routes in proxy config
  • Disable proxy buffering explicitly on SSE and token-stream endpoints
  • Test live streaming through every proxy layer before release
  • Document which routes require chunked pass-through behavior

Verification

After applying the fix, verify the exact symptom that made the incident visible instead of relying on one green log line. Re-run the command, request, deployment, or browser path that failed before the change and capture the new output for the incident record.

  • Confirm the original error message no longer appears in application, platform, or edge logs.
  • Check the affected dependency path from the client side and from the server side when both are available.
  • Watch the next scheduled job, deploy, cache refresh, or certificate renewal cycle so the fix survives the normal operating path.
  • Record the final configuration value, command output, and timestamp in the runbook for Nginx Proxy Buffering Breaks Server-Sent Events or Streaming Responses.

Rollback

If the fix changes routing, credentials, certificates, state, cache behavior, or runtime configuration, keep a rollback path ready before applying it to production. Save the previous configuration, identify the owner of the affected service, and define the signal that will trigger rollback.

  1. 1.Restore the last known-good configuration or state reference if validation shows a wider blast radius.
  2. 2.Re-run the same diagnostic checks from the fix section to confirm the rollback returned the system to the previous behavior.
  3. 3.Leave a short note explaining why the attempted fix was reverted so the next responder does not repeat the same change.

Operational Notes

Use this guide as an incident workflow, not as a blind checklist. The safest order is to collect the current state, confirm the narrowest failing component, apply one focused change, and then re-test the same path that failed. Avoid combining unrelated fixes during Nginx Proxy Buffering Breaks Server-Sent Events or Streaming Responses; otherwise the team will not know which change restored service or which change caused a later regression.

For production systems, capture command output before and after each change. Include timestamps, hostnames, environment names, account IDs, namespaces, certificate names, or configuration keys when they are relevant. These details make the guide useful during a future incident and help separate a real recurrence from a similar-looking but unrelated failure.

Escalate when the failing path crosses a boundary your team does not own, such as a managed cloud control plane, identity provider, external DNS service, payment gateway, or shared network appliance. Share the exact failing request, correlation ID, command output, and change window with the owning team. Keep customer-facing mitigation separate from root-cause repair: it is often safer to route around the broken dependency first, then schedule the permanent cleanup after traffic is stable.

  • [Nginx troubleshooting: Fix Lambda Permission Denied - Complete ](fix-lambda-permission-denied)
  • [Nginx web server troubleshooting: Fix Client Max Body Size Large Upload Nginx Issue ](client-max-body-size-large-upload-nginx)
  • [Fix Apache 502 Proxy Error](fix-apache-502-proxy-error)
  • [Fix Apache LogLevel Core Debug Configuration](fix-apache-loglevel-core-debug)
  • [Fix Cloudflare 502 Bad Gateway Error](fix-cloudflare-502-bad-gateway)

<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "TechArticle", "headline": "Nginx Proxy Buffering Breaks Server-Sent Events or Streaming Responses", "description": "Resolve Nginx SSE and streaming response issues by disabling proxy buffering on the event endpoint and verifying flush behavior end to end.", "url": "https://www.fixwikihub.com/nginx-proxy-buffering-breaking-server-sent-events-stream", "publisher": { "@type": "Organization", "name": "FixWikiHub", "url": "https://www.fixwikihub.com" }, "author": { "@type": "Person", "name": "FixWikiHub Editorial Team" }, "datePublished": "2026-04-10T04:23:00.000Z", "dateModified": "2026-04-10T04:23:00.000Z" } </script>