ERR_INCOMPLETE_CHUNKED_ENCODING

What’s actually happening

The page loads partway and then dies, or a download/API call returns truncated data, sometimes only on bigger responses. Reloading may or may not help, which makes it feel random. With Transfer-Encoding: chunked the server promises a final 0-length chunk to mark the end; the browser never got it, so it knows the body is incomplete and discards it.

Common causes

• A PHP fatal or uncaught exception firing mid-output, so the worker dies after sending some chunks but before finishing (look for 'PHP Fatal error' lining up with the failed request time).
• A PHP-FPM or backend worker crashing or being OOM-killed partway through the response.
• mod_deflate / gzip or a FastCGI buffer mangling the stream — compression applied after chunking, or a buffer flushed and then the connection dropped.
• A reverse proxy timeout (Nginx proxy_read_timeout, Cloudflare's 100s limit) closing the upstream connection before the backend finished streaming.
• Disk full or a write error on a cache/temp file the response was being streamed from.

How to fix it

1. Line up the failure with the backend logsCheck the PHP-FPM log (e.g. /var/log/php*-fpm.log), the app log, and the web server error log at the moment of the failed request. A 'PHP Fatal error', 'segfault', or 'child exited on signal 9' at that timestamp tells you the worker died mid-output — fix that error and the chunked truncation goes away.
2. Toggle off compression and buffering to isolate itTemporarily disable mod_deflate/gzip (or set 'gzip off;' in Nginx) and retry. If the page completes, the compression layer is corrupting the chunked stream — usually an ordering issue between chunking and gzip, or a broken output buffer. Re-enable it correctly rather than leaving it off.
3. Raise proxy and FastCGI timeouts for long responsesIf the backend legitimately takes a while to stream, bump 'proxy_read_timeout' and 'fastcgi_read_timeout' in Nginx (e.g. to 120s). Behind Cloudflare, responses must start within ~100s on the free/pro plans — stream earlier or move the long job to a background task.
4. Check disk and memory on the boxRun 'df -h' and look at 'dmesg' for OOM-killer entries. A full disk on the temp/cache partition or a worker getting killed for memory both produce truncated chunked responses that look like network flakiness.