Fix ERR_HTTP2_PROTOCOL_ERROR on Large Images (Chrome)

I ran into this on a site I was managing — thumbnails loaded fine, but the second a full-size product photo tried to load, Chrome dropped it with ERR_HTTP2_PROTOCOL_ERROR and just left a broken image icon behind. Reloading sometimes fixed it, sometimes didn’t. If you’re seeing this specifically on bigger image files while everything else on the page loads fine, the cause is narrower than the generic “clear your cache” advice you’ll find everywhere.

Quick Answer

• This error means an HTTP/2 stream got closed mid-transfer, and large images are more likely to trigger it because they take longer to transfer and produce bigger response headers.
• If you’re just browsing, clearing cached images/files and disabling extensions fixes it for a lot of people.
• If you manage the site yourself, this is very often a reverse proxy or CDN buffer size limit choking on large image responses — not a browser problem at all.
• Disabling QUIC (chrome://flags) is worth trying if it happens consistently on the same network.
• If it’s your own server behind Nginx or a proxy like Nginx Proxy Manager, check proxy_buffer_size and related directives before anything else.

Why It Happens

So this error shows up after the secure connection is already established — TLS handshake succeeded, HTTP/2 session started, and then something interrupted the actual data stream partway through. That distinction matters because it rules out certificate problems as the cause; it’s specifically an HTTP/2 framing or transport issue.

Response buffer limits on a reverse proxy or CDN. This is the one that matters most for the “large images” part of this error specifically. Large image files produce larger response payloads and sometimes larger headers than a proxy’s default buffer settings expect. Nginx, in particular, has default buffer sizes that are fine for typical HTML and API responses but can choke on big image payloads, especially when a CDN or reverse proxy sits in front of the origin server. The failure mode often looks like “upstream sent too big header” in server logs even though what the browser sees is just ERR_HTTP2_PROTOCOL_ERROR.

Corrupted browser cache or stale cached headers. Chrome caches response headers alongside content, and if a large image’s headers get cached in a state that no longer matches what the server sends on a fresh request, the HTTP/2 session can get confused mid-stream. This is more likely to surface on large images just because they’re more likely to be re-requested (scrolling, zooming, reloading a gallery) than small static assets.

QUIC/HTTP-3 interference. Chrome tries to use Google’s QUIC protocol opportunistically, and on some networks it doesn’t play well with certain servers or proxies handling large transfers, causing it to fall back or conflict in a way that surfaces as an HTTP/2 error instead of a QUIC-specific one.

CDN or proxy misconfiguration between two hops. If your image is served through a CDN that has HTTP/2 enabled but the origin server behind it doesn’t handle HTTP/2 the same way — or vice versa — larger payloads are more likely to expose the mismatch than small ones, since there’s more data and more time for something in the relay to go wrong.

An overlooked cause: third-party antivirus or firewall software doing HTTPS inspection. So security software that decrypts and re-encrypts HTTPS traffic to scan it sometimes handles large binary payloads (like high-res images) differently than small text responses, and can interrupt the stream in a way that looks identical to a server-side HTTP/2 problem.

Common Scenarios

This shows up a little differently depending on which side of the site you’re on:

• As a visitor browsing a site, you’ll usually see it on product galleries, portfolio sites, or any page with large unoptimized images — smaller thumbnails load, full-resolution versions fail.
• As a site owner using a CDN like Cloudflare, it tends to appear right after a caching or proxy setting change, or intermittently across multiple images on the same page during high-traffic periods.
• As a self-hosted server admin behind Nginx or a reverse proxy manager, it’s frequently tied directly to buffer size settings and shows up in server logs as a distinct “too big header” error even though the browser only reports the generic code.

Step-by-Step Fixes (Browsing as a Visitor)

Step 1: Reload the page

Sounds too simple, but a chunk of these are transient — a momentary proxy or CDN hiccup rather than a persistent misconfiguration. Try a hard reload with Ctrl+Shift+R before anything else.

Step 2: Clear cached images and files

1. Go to chrome://settings/clearBrowserData
2. Set time range to “All time”
3. Check “Cached images and files” (you can leave history and passwords alone)
4. Click Clear data

And if you only care about this one site, you can also just open the page in an Incognito window first, to check whether cache is actually the cause before wiping anything.

Step 3: Disable extensions temporarily

Go to chrome://extensions, toggle everything off, and reload the page. Ad blockers and privacy extensions that inspect or modify network requests are the most common offenders here. Turn them back on one at a time if the page loads clean, so you can identify which one’s responsible instead of leaving them all off.

Step 4: Try disabling QUIC

Go to chrome://flags/#enable-quic, set it to Disabled, and relaunch Chrome. This isn’t a permanent fix you should leave in place indefinitely, but it’s a useful diagnostic step — if the images load fine with QUIC off, that tells you where to focus.

Step 5: Test on a different network

If you can, try mobile data or a different Wi-Fi network. A firewall, router-level content filter, or antivirus doing HTTPS inspection on your current network is a real possibility, and this step rules it in or out quickly.

Step-by-Step Fixes (If You Manage the Server)

Step 1: Check your reverse proxy buffer settings

If you’re running Nginx directly or through something like Nginx Proxy Manager, add or increase these in your server or location block:

proxy_buffer_size 128k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;

This is the fix that resolves it most often when the issue is specifically tied to large image payloads rather than general site instability. Default buffer sizes are tuned for typical web traffic, not large binary responses.

Step 2: Check your CDN’s HTTP/2 settings

If you’re using Cloudflare or a similar CDN, verify that HTTP/2 is consistently enabled (or consistently disabled) on both the CDN edge and your origin server. A mismatch — HTTP/2 at the edge talking to HTTP/1.1 at the origin, or the reverse — is a common source of exactly this kind of intermittent large-asset failure.

Step 3: Check SSL/TLS configuration

HTTP/2 requires a properly configured SSL setup, and a marginal or misconfigured certificate chain can produce protocol errors under load, even if the connection appears to work fine most of the time. Run an SSL checker against your domain to rule this out.

Step 4: Test with HTTP/2 temporarily disabled

On Nginx, change listen 443 ssl http2; to listen 443 ssl; and restart. If large images suddenly load reliably, you’ve confirmed the issue is HTTP/2-specific rather than a general server problem, and you can focus your fix there instead of chasing something else.

What Actually Worked For Me

My first assumption was that it was something wrong with the images themselves — maybe corrupted files from a bad upload. So I spent a while re-exporting and re-uploading a few of the worst offenders, which didn’t change anything at all.

Turned out to be the proxy buffer settings the whole time. I was running the site behind Nginx Proxy Manager, and once I dug into the actual server error log instead of just staring at the browser console, I found the “upstream sent too big header” line, which pointed straight at the real cause. Added the proxy_buffer_size and related directives, restarted, and every large image on the site loaded clean on the first try. Would’ve saved myself a chunk of time if I’d checked the server logs before touching the images at all.

Advanced Fixes and Edge Cases

Use chrome://net-export for detailed diagnosis. If the error is inconsistent and you can’t reproduce it reliably, Chrome’s network export tool captures detailed connection-level logs you (or your host’s support team) can use to pinpoint exactly where the stream is failing.

Check for gzip or compression header conflicts. Some setups send conflicting Content-Encoding headers when compression is layered incorrectly between a CDN and origin — one Cloudflare user’s fix for this exact error was disabling gzip compression that was producing mismatched headers, which is worth checking if you’re running multiple caching or compression layers.

Rule out folder upload or bulk-transfer prioritization bugs. This is a narrower edge case, but some developers have hit this specifically during large bulk uploads where HTTP/2 stream prioritization gets tangled — downgrading temporarily to HTTP/1.1 for that specific interaction resolved it in reported cases.

Prevention Tips

• If you manage a site with large images, set generous proxy buffer sizes from the start rather than waiting for this to show up under real traffic.
• Serve genuinely large images through a properly configured CDN rather than directly from your origin server when possible.
• Keep browser cache clearing as a normal occasional habit rather than something you only do when something breaks.
• If you’re a visitor and this only ever happens on one specific site, it’s not something you can permanently fix on your end — it’s worth reporting to the site owner with the exact error and a screenshot of the browser console.

FAQ

Is this error dangerous or a sign of malware? No, it’s a protocol-level transfer error, not a security issue on its own — though if it started right after installing new software, it’s worth ruling that software out as a cause.

Does this happen on Firefox too? Firefox surfaces a related but differently labeled error, usually NS_ERROR_NET_RESET, for similar underlying causes — the ERR_HTTP2_PROTOCOL_ERROR code itself is specific to Chromium-based browsers.

Can I just permanently disable HTTP/2 in Chrome to avoid this? There’s no built-in user-facing toggle for that, and you wouldn’t want one anyway — HTTP/2 is core to how most modern sites perform, so the better path is fixing the actual cause rather than avoiding the protocol.

Why does it only happen on some images and not others on the same page? Usually because it’s tied to file size or a specific caching state — smaller assets stay under whatever buffer or timeout threshold is causing the problem, while larger ones cross it.

Editor’s Opinion

wasted a good hour re-uploading images before i thought to actually check the server error log, which had the real answer sitting right there the whole time. if you run your own site behind nginx or a reverse proxy and only your big images are failing, go straight to the buffer size settings, don’t mess with the images first like i did.