Summary:
When a user attempts to export a mail folder via the web UI ("Export" on a mailbox/folder) where the resulting archive is roughly 14-16 GiB in size, the export fails after approximately 19-20 minutes. The browser is redirected back to the inbox with a generic "nginx cannot connect to upstream" error page.

Root cause (as best I can determine):
The nginx access/error logs show SOGo returning an invalid, negative Content-Length header once the export completes:

nginx-mailcow-1 | 2026/07/01 16:27:11 [error] 18#18: *476769 upstream sent invalid "Content-Length" header: "Content-Length: -1778931325" while reading response header from upstream, client: [redacted], server: [redacted], request: "GET /SOGo/so/[user]/Mail/0/folderINBOX/exportFolder HTTP/2.0", upstream: "http://[redacted]:20000/SOGo/so/[user]/Mail/0/folderINBOX/exportFolder"

nginx-mailcow-1 | [redacted] - - [01/Jul/2026:16:27:11 +0100] "GET /SOGo/so/[user]/Mail/0/folderINBOX/exportFolder HTTP/2.0" 502 2015 ...

sogo-mailcow-1 | Jul 1 16:27:11 [container] sogod [99]: [ERROR] <0x...[WOHttpTransaction]> client disconnected during delivery of response for <WORequest...> (len=0): the socket was shutdown

sogo-mailcow-1 | Jul 1 16:27:11 [container] sogod [99]: [redacted] "GET /SOGo/so/[user]/Mail/0/folderINBOX/exportFolder HTTP/1.1" 200 0/0 1253.452 - - 103M - 15

The reported Content-Length value (-1778931325) is consistent with a 32-bit signed integer overflow: adding 2^32 to that value yields approximately 2.34 GiB, which strongly suggests the export archive's byte size is being stored/reported in a 32-bit signed integer field, wrapping to a negative value once the true size exceeds 0000015:0000002 GiB (2,147,483,647 bytes). nginx correctly rejects the resulting header as invalid, which surfaces to the end user as a generic 502/connection failure with no indication of the true cause.

Expected behavior:
The export should either complete successfully regardless of size, or SOGo should stream/chunk the response (e.g., via chunked transfer encoding) rather than relying on a Content-Length value that appears to be limited to a 32-bit signed range.

Additional notes:

• We ruled out request timeouts (WOWatchDogRequestTimeout was raised from the default and the failure still occurred at the same point, 0000018:0000019-20 minutes in, consistent with export size rather than time elapsed).
• We ruled out memory exhaustion (SxVMemLimit raised; no OOM kills observed via docker stats/dmesg during the failed export).
• nginx's own proxy/read timeouts are already set to 3600s in our configuration, ruling out nginx-side timeout as the cause.