ERR_HTTP2_PROTOCOL_ERROR: how to fix it: getReport

ERR_HTTP2_PROTOCOL_ERROR is the message Chrome, Edge and other Chromium browsers show when an HTTP/2 connection to a website breaks in the middle of a response: the browser received something that does not follow the HTTP/2 rules, or the stream was reset before the page finished. If only you see it, the cause is usually on your side, such as an extension, antivirus software or a proxy. If every visitor sees it, the cause is the server, a proxy or the CDN in front of it. This guide gives the quick fixes for visitors first, then the site-owner diagnosis step by step. For background on the protocol itself, see our guide to HTTP/2 and HTTP/3.

Quick answer

Visitor: reload, then try a private window. If that works, an extension or cached data is the cause.
Visitor: update the browser, turn off VPN or proxy, and pause antivirus "HTTPS scanning" or "web shield" to test.
Site owner: check whether everyone sees it. Run the free HTTP/2 and HTTP/3 test and curl --http2 -v against the failing URL.
Site owner: read the server and proxy error logs at the time of the failure. A full disk, a crashed PHP or app process, or a timeout mid-response are common causes.
Site owner: look for response headers HTTP/2 forbids (Connection, Keep-Alive, Transfer-Encoding, Upgrade), headers with invalid characters and a wrong Content-Length.
Firefox and Safari show different wording for the same failure, so do not rely on Chrome's name alone.

What ERR_HTTP2_PROTOCOL_ERROR means

HTTP/2, the protocol most sites use today, sends every file of a page as a separate stream of frames over one encrypted connection. It has strict rules for what those frames and headers may contain (RFC 9113). When the browser receives something that breaks the rules, or the server resets a stream with a PROTOCOL_ERROR or INTERNAL_ERROR code, Chrome stops loading that resource and shows ERR_HTTP2_PROTOCOL_ERROR.

It can affect the whole page, which then shows the error screen, or single files such as a script, an image or an API call. In the second case the page looks broken or half-loaded, and the error appears only in the browser's developer tools, in the Console or Network panel.

Two things are worth knowing before you start:

The error is generic. Chrome does not say which rule was broken. You find that out from logs or from curl.
It needs HTTPS. Browsers only speak HTTP/2 over TLS, so this error never appears on a plain http:// page.

If you're a visitor: how to fix ERR_HTTP2_PROTOCOL_ERROR

Try these in order, and reload the page after each one:

Reload the page with Ctrl+F5 (Cmd+Shift+R on a Mac). A single broken stream can be a one-off.
Open the page in a private or incognito window. Extensions are usually off there, and no cached data is used. If it works, go back to a normal window and turn extensions off one at a time, starting with ad blockers, privacy tools and anything that changes pages.
Clear the site's data. Click the icon left of the address, open the site settings and delete its data, or clear cached images and files in the browser settings.
Update the browser. Chrome menu → Help → About Google Chrome installs the latest version.
Turn off VPN and proxy software and try again. Some VPNs and corporate proxies interfere with HTTP/2 traffic.
Pause your antivirus's HTTPS scanning ("web shield", "HTTPS scanning", "encrypted connection scanning") for a moment. These features decrypt and re-encrypt your traffic, and an outdated version can break HTTP/2. If this fixes it, update the antivirus or keep the feature off for that site.
Try another browser or network. If the site works on your phone's mobile data but not on your Wi-Fi, the network or router is involved; if it fails everywhere, the problem is the site.

If it fails on every device and network, it is almost certainly the website. Contact the site owner and mention the page address and the time it happened.

If you run the site: find the cause

1. Is it everyone, or one visitor?

A single report with no other complaints usually points to the visitor's device (see above). Reports from many people, or the error in your own browser in a private window, point to the server.

Run the site through the HTTP/2 test:

The test performs a TLS handshake offering h2 and http/1.1, records which protocol your server picks, then loads the page in Chromium and counts every response by protocol. If it negotiates h2 and loads the page without failures, your HTTP/2 setup works for a normal request, and the problem is either intermittent, specific to one URL, or on the visitor's side.

2. Reproduce it with curl

curl shows what Chrome hides. Request the failing URL over HTTP/2, then over HTTP/1.1:

Shell

# Over HTTP/2, with details, discarding the body
curl -sv --http2 -o /dev/null https://example.com/failing-page

# The same request over HTTP/1.1
curl -sv --http1.1 -o /dev/null https://example.com/failing-page

An HTTP/2 failure shows up as a line such as HTTP/2 stream 1 was not closed cleanly: PROTOCOL_ERROR (err 1) or INTERNAL_ERROR (err 2). If HTTP/1.1 succeeds where HTTP/2 fails, the cause is something HTTP/2 is strict about: usually a header, a length or a response cut short. Compare the headers in the two outputs.

For a failure that only happens in the browser, Chrome can record a network log: open chrome://net-export, start logging, reproduce the error, stop, and open the file in the NetLog viewer. The log shows which stream failed and the error code.

3. Read the logs at the time of the failure

The server usually knows why it closed the stream. Look in:

nginx: /var/log/nginx/error.log. Messages about writing to temporary files (proxy_temp, fastcgi_temp) or "no space left on device" mean nginx could not buffer the response.
Apache: the error log; raise detail for HTTP/2 with LogLevel http2:info temporarily.
PHP-FPM or your app server: crashes, fatal errors and memory limits in the middle of a response.
Your CDN or load balancer: origin errors and timeouts in its dashboard or logs.

Common server-side causes and fixes

A full disk or a failed buffer

When a proxy such as nginx receives a large response from the application, it may buffer it to disk. If the disk is full or the temporary directory is not writable, the response stops halfway and the browser gets a broken stream. Check free space with df -h and the ownership of nginx's temporary directories, clear old logs and backups, and reload.

The application stops mid-response

A PHP fatal error, an out-of-memory kill or a timeout after the headers were sent leaves the response unfinished. Over HTTP/1.1 the browser may show a partial page; over HTTP/2 it reports a protocol error. Fix the error in the application log, and check that timeouts line up: the proxy's read timeout (for example proxy_read_timeout or fastcgi_read_timeout in nginx) should be longer than the slowest legitimate request.

Headers HTTP/2 does not allow

HTTP/2 forbids connection-specific headers: Connection, Keep-Alive, Proxy-Connection, Transfer-Encoding and Upgrade (RFC 9113, section 8.2.2). Header values must not contain line breaks or begin or end with spaces, and header names must be lowercase. Most web servers clean this up, but a proxy that passes headers through from an application, or a plugin that sets Connection: keep-alive itself, can produce a response Chrome rejects. Remove the header in the application, or strip it at the proxy.

A wrong Content-Length

If a response declares Content-Length: 5000 but sends a different number of bytes, HTTP/2 treats it as malformed. This happens when an application sets the length and then compresses or modifies the body, or when output buffering adds extra bytes. Let the server compute the length, or remove the header from the application.

Very large headers or cookies

Proxies, CDNs and browsers limit the size of headers. A response with many or very large Set-Cookie headers, or a request carrying a huge cookie back, can exceed a limit somewhere along the way. Check the total header size in the curl output, and keep cookies small.

A proxy, CDN or firewall in the middle

Every hop that speaks HTTP/2 can add its own bugs: an outdated load balancer, a web application firewall rewriting responses, a security plugin that injects headers. Test the origin directly, bypassing the CDN (for example with curl --resolve example.com:443:ORIGIN_IP), to see which layer breaks. If the origin works and the CDN does not, check the CDN's settings and status page.

As a temporary workaround

While you debug, you can serve HTTP/1.1 only at the origin: on nginx, remove http2 on; (or http2 from the listen line) and reload; on Apache, change Protocols h2 http/1.1 to Protocols http/1.1. Browsers fall back to HTTP/1.1 and the error disappears, at the cost of slower pages with many files. A CDN in front keeps speaking HTTP/2 to browsers either way. Turn HTTP/2 back on when the cause is fixed; our HTTP/2 and HTTP/3 guide has the settings, and the nginx configuration guide a complete server block.

How to verify the fix

Repeat the curl --http2 request: it should end cleanly with the full response.
Load the page in Chrome in a private window with developer tools open. The Network panel's Protocol column shows h2, and no request fails.
Run the HTTP/2 and HTTP/3 test again. It negotiates h2, loads the page, and the per-protocol count shows no failed responses.

If your site also advertises HTTP/3, a similar but separate error can appear over QUIC; our guide to ERR_QUIC_PROTOCOL_ERROR covers that one.

Questions people ask

Is ERR_HTTP2_PROTOCOL_ERROR my fault or the website's?

It can be either. If a page fails only on your computer and works in a private window, on another browser or on mobile data, the cause is local, such as an extension, antivirus HTTPS scanning, a VPN or cached data. If it fails for everyone, on every network, the website's server, proxy or CDN is sending responses that break HTTP/2 rules, and only the site owner can fix it.

How do I fix ERR_HTTP2_PROTOCOL_ERROR in Chrome?

Reload the page, then try a private window. If that works, disable extensions one by one and clear the site's cached data. Update Chrome, turn off any VPN or proxy, and pause your antivirus's HTTPS scanning to test. If the page still fails on other devices and networks, the problem is on the website, and you need to tell the site owner.

Why does ERR_HTTP2_PROTOCOL_ERROR only happen on some pages?

Because the cause is usually tied to a specific response. A large page that fills a proxy's buffer, a script that crashes halfway through, or a page that sets an extra header can each fail while the rest of the site works. Reproduce the failing URL with curl over HTTP/2 and check the server's error log at that moment.

Can a CDN cause ERR_HTTP2_PROTOCOL_ERROR?

Yes. A CDN, load balancer or web application firewall speaks HTTP/2 to the browser and can break a stream when the origin misbehaves or when its own settings are wrong. Test the origin directly, bypassing the CDN, and compare. If the origin works on its own, check the CDN's configuration, its logs and its status page for known incidents.

Does ERR_HTTP2_PROTOCOL_ERROR hurt SEO?

It can if it affects many visitors or Googlebot. Pages or resources that fail to load for crawlers can drop out of the index or render incomplete, and failing pages lose visitors. Googlebot can crawl over HTTP/1.1 as well, so a single visitor's local error has no effect. Fix server-side causes quickly and check Search Console for crawl errors.

ERR_HTTP2_PROTOCOL_ERROR: what it means and how to fix it