HTTP/2 multiplexes many streams over one connection, framed in binary. This error means the framing broke the protocol's rules: a malformed frame, a stream reset by the server (you may also see ERR_HTTP2_PROTOCOL_ERROR alongside “stream reset” notes in consoles), or a middlebox that damaged the stream. The server side and its load balancers are the usual authors; certain antivirus proxies that intercept and re-emit HTTP/2 are the local exception.
--disable-http2 (or the equivalent flag) forces HTTP/1.1. If the site then loads, you have proven the fault is in the HTTP/2 path, not your machine; this is a test, not a lifestyle, since you lose HTTP/2 everywhere.Check the HTTP/2 implementation versions in your chain (server, load balancer, CDN) against known errata; early and buggy HTTP/2 stacks in proxies are the leading cause. Server logs typically record the stream error (PROTOCOL_ERROR, REFUSED_STREAM, or flow-control errors) with the connection's timestamp, and an upgrade of the terminating component is the usual cure.
A site that fails over HTTP/2 for everyone will keep failing until its operator fixes or upgrades the terminating component; visitors can only fall back (another browser that negotiates HTTP/1.1) or wait.
What is HTTP/2 and why does it get its own error? HTTP/2 is the binary, multiplexed successor to HTTP/1.1: many requests share one connection as numbered streams of frames. Because the framing is strict, malformed frames are protocol violations with their own error, rather than the garbled-page failures HTTP/1.1 produced.
Does ERR_HTTP2_PROTOCOL_ERROR mean the site is insecure? No. It means the transport framing broke, not that encryption or identity failed. It is a reliability bug in an implementation somewhere between you and the content, most often the server's or a middlebox's.