Hello,

When you say streaming, do you mean SSE?

No SSE, we use

response = StreamingHttpResponse()

to stream chunks from LLMs responses

Is that going to be WebSockets? What is the underlying technology in use here? A function name is unfortunately not too helpful.

Ah, it is SSE:

https://dev.to/epam_india_python/harnessing-the-power-of-django-streaminghttpresponse-for-efficient-web-streaming-56jh

Then that would be an application-level issue; SSE on Railway does work:

https://utilities-metal-us-east-zfs.up.railway.app/sse

I have gone ahead and placed a bounty on this thread so that the community can help you, because the Railway team is only able to provide support for Railway platform or product issues.

No, it's not WebSockets either. We're using standard HTTP chunked transfer encoding via Django's native StreamingHttpResponse class.

https://docs.djangoproject.com/en/5.2/ref/request-response/#django.http.StreamingHttpResponse

- Protocol: Standard HTTP/1.1 with Transfer-Encoding: chunked

- Server-side: Django's built-in StreamingHttpResponse (native to django.http module)

- Client-side: Standard fetch() with ReadableStream processing

- Connection: Single HTTP request/response, not persistent like WebSockets

Server implementation:

async def async_streaming_response(generator):

    async def encoded_generator():

        async for chunk in generator:

            if isinstance(chunk, str):

                yield chunk.encode('utf-8')

            elif isinstance(chunk, bytes):

                yield chunk

    return StreamingHttpResponse(encoded_generator())

Client implementation:

const response = await fetch(url, {method: 'POST', body: formData});

const reader = response.body.getReader();

const decoder = new TextDecoder('utf-8');

while (true) {

    const { done, value } = await reader.read();

    if (done) break;

    const newText = decoder.decode(value);

    appendTextWithFadeIn(newText);

}

This worked perfectly for months on Railway using the same exact code, but suddenly stopped streaming and now everything arrives buffered. The issue appears to be infrastructure-related since identical code that previously streamed in real-time now delivers complete responses. Even though we've made a lot of changes recently, 1) in development it does stream, and 2) Even deloying to an old repository does not correct the issue

thanks for the bounty

I've demonstrated that SSE or chunked responses work without issue, so I will take my leave from this thread and let the community help.

Try disabling buffering manually:
Add headers in your Django response:

response = StreamingHttpResponse(encoded_generator())

response['Cache-Control'] = 'no-cache'

response['X-Accel-Buffering'] = 'no'

return response

    response['X-Accel-Buffering'] = 'no'  
    response['Cache-Control'] = 'no-cache, no-store, must-revalidate'
    response['Pragma'] = 'no-cache' 
    response['Expires'] = '0'
    response['Content-Type'] = 'text/plain; charset=utf-8'
    
    return response

tried this, did't work

response = StreamingHttpResponse(encoded_generator())

response['Transfer-Encoding'] = 'chunked'

response['Content-Encoding'] = ''

Try this as the last resort: chunked encoding headers explicitly

OR

Reduce concurrency/workers – sometimes Gunicorn’s multiple workers or an ASGI misconfiguration causes the app itself to buffer internally.

If these don't help, then the problem is likely not at the Django level—it’s happening further up the chain. Railway may now be using a proxy (or CDN layer) that buffers all responses and doesn’t honour X-Accel-Buffering.

I would like to reiterate that there are no issues with SSE/chunked transfers on our side, as demonstrated by this example:

https://utilities-metal-us-east-zfs.up.railway.app/sse

these:

response['Transfer-Encoding'] = 'chunked'

response['Content-Encoding'] = ''

didn't work either.

But I pause the cloudfare proxy, and yes, chunk streaming!

We obviously want cloudfare's services, so, the only thing left is to find the switch to turn off.

Any help is appreciated.

Thanks clashing, thanks brody.

Lastly I posted this and got this response in cloudfare support:

Django StreamingHttpResponse works locally and when Cloudflare is paused, but gets buffered when Cloudflare is active. Already tried X-Accel-Buffering=no, Transfer-Encoding=chunked, Content-Encoding=’’ headers. Need solution to bypass Cloudflare buffering for streaming responses

Response from cloudfare (AI bot):

According to the Cloudflare documentation, you can bypass buffering for streaming responses by including the Content-Type: text/event-stream response header. This tells Cloudflare to stream data as it arrives instead of buffering the entire response.

Here is the relevant section from the documentation:

“Proxied traffic through Cloudflare Tunnel is buffered by default unless the origin server includes the response header Content-Type: text/event-stream. The Content-Type: text/event-stream response header tells cloudflared to stream data as it arrives instead of buffering the entire response.”

Source: https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/troubleshoot-tunnels/common-errors/

You can try adding this header to your Django StreamingHttpResponse to see if it resolves the issue.

Additionally, you can also try setting the Cache-Control header to no-cache or no-store to prevent Cloudflare from caching the response.

It’s also worth noting that Cloudflare has a specific section on response buffering in their documentation, which may be helpful in troubleshooting this issue.

Source: https://developers.cloudflare.com/network/response-buffering/

If you’re still having issues, you may want to try reaching out to Cloudflare support for further assistance.

Sources:

• Common errors - Cloudflare Zero Trust docs

• Response Buffering - Cloudflare Network settings docs

Frequently asked questions about Cloudflare Stream - Cloudflare Stream docs

And I worked! this was the exact header:

Content-Type: text/event-stream