How is this different from ERR_INCOMPLETE_CHUNKED_ENCODING?

Same disease, different framing. ERR_CONTENT_LENGTH_MISMATCH (net error -354) fires when a response declares Content-Length: N and then the connection closes after fewer than N bytes. ERR_INCOMPLETE_CHUNKED_ENCODING (-355) is the chunked-transfer equivalent: the body uses Transfer-Encoding: chunked and the terminating zero-length chunk never arrives before the connection closes. In both cases the server stopped sending mid-body — only the byte-counting mechanism the browser used to catch it differs.

Why does it only happen on large files or only sometimes?

Because the usual causes are resource limits, and bigger or slower responses are the ones that hit them. A worker timeout, a memory cap, or a proxy buffer fills up partway through a long body and the connection dies before the declared length is reached. Small responses finish before the limit bites, which is why a 2 KB page is fine and a 5 MB download fails intermittently.

Can gzip or compression cause ERR_CONTENT_LENGTH_MISMATCH?

Yes, and it's a sneaky one. If one layer sets Content-Length from the uncompressed size and another layer compresses the body — or a transform/edge worker rewrites the body without updating the header — the advertised length no longer matches the bytes on the wire. The browser counts what actually arrived, sees a shortfall, and errors. Audit anything that both compresses and sets Content-Length manually.

Views: 6

ERR_CONTENT_LENGTH_MISMATCH Fix

ERR_CONTENT_LENGTH_MISMATCH means the server sent fewer bytes than promised. Spot the proxy, disk, or worker fault in 3 checks. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

The page or asset half-loads, then fails. DevTools shows Failed to load resource: net::ERR_CONTENT_LENGTH_MISMATCH — Chromium net error -354: the response body transferred fewer bytes than the Content-Length header advertised before the connection closed.

Symptoms

A resource (image, script, download, or whole page) loads partway then stops, often with a broken image or a truncated file.
The DevTools Network tab shows the request in red with ERR_CONTENT_LENGTH_MISMATCH.
It’s intermittent, or hits large files while small ones load fine.

What ERR_CONTENT_LENGTH_MISMATCH Actually Means

A server that sends Content-Length: 500000 is making a promise: “this body is exactly 500,000 bytes.” The browser holds it to that promise. It counts the bytes as they arrive, and if the connection closes after only 410,000, it knows the response was cut off — half a file is worse than no file, so it discards the lot and raises the error.

That makes this a truncation error, not a connection error. The handshake worked, the headers arrived, the body started flowing. Something killed it partway through. So the question is never “why won’t it connect” — it’s “what stopped the body from finishing”: the origin quit writing, a proxy in the middle couldn’t pass the whole thing through, or the declared length was a lie to begin with.

Top 3 Causes

The origin stopped writing mid-response - A worker crashed, hit a memory cap, or a timeout fired (PHP-FPM max_execution_time, FastCGI/proxy_read_timeout, an app-level deadline) after the headers — including Content-Length — had already gone out. The body gets guillotined. This is the classic intermittent-under-load version.
A reverse proxy couldn’t pass the full body - The well-documented case is nginx buffering a response to a temp file on a disk that’s 100% full: the buffered copy is short, so the client receives less than promised. Misconfigured proxy_buffering, an upstream that resets, or a client_max_body_size/buffer limit can truncate the same way.
Content-Length doesn’t match the actual bytes - A compression or transform layer changes the body length without updating the header — gzip applied after Content-Length was set from the uncompressed size, double-compression, or an edge/transform worker rewriting the body. The header says one number; the wire carries another.

Diagnose with DechoNet

HTTP Check from outside your network to capture the real response headers and confirm whether the full body arrives from the origin. If the check pulls the complete response while your browser truncates, suspect something between you and the origin (a proxy, VPN, or local network) rather than the server.
Port Check if the failures cluster around connection drops — confirming the origin port stays open and accepting rules out a flapping listener and points the investigation back at the response body itself.

Resolution Checklist

Reproduce with curl and compare bytes to the header: curl -sv https://yoursite.com/path -o /dev/null — watch the Content-Length value against the bytes actually received.
Check origin logs for crashes, OOM kills, or timeouts (PHP-FPM, app server, FastCGI) at the moment of the failed request — a truncated body almost always has a dead or timed-out worker behind it.
On the proxy/origin host, run df -h — a full disk breaks response buffering in ways that look exactly like this. Clear space or check the proxy_temp_path volume.
As a test, disable proxy buffering (nginx proxy_buffering off;) and see if the error clears — if it does, the buffer/temp-file path is the culprit.
Audit any layer that both compresses and sets Content-Length manually. Let the server compute the header from the final, post-compression body, or use Transfer-Encoding: chunked and drop Content-Length.
Re-run HTTP Check and confirm the full body now arrives with a matching length.

When to Escalate

A consistent mismatch on a static asset is a configuration bug at the proxy or origin (compression/length or buffering) — escalate to whoever owns that config; no client-side fix applies.
An intermittent mismatch under load is a stability problem: escalate it as worker crashes, memory limits, or timeouts rather than chasing it in the browser.