Before any page data moves, browser and server perform the TLS handshake: agreeing on encryption and proving the server's identity. This error means that conversation broke down at the protocol level: the two sides could not agree on how to speak securely. The server's configuration is the most common cause, but a wrong clock, stale state, or intercepting software on your side can break it too.
chrome://flags, set QUIC to Disabled and retest. If that fixes it, a middlebox is mangling UDP-based handshakes; the network, not the site, is at fault.If the error affects exactly one site on every device and network, the server's TLS setup is broken or obsolete, full stop. Site operators fix it by enabling current TLS versions and a sane cipher order on the server; visitors cannot compensate for it.
Is ERR_SSL_PROTOCOL_ERROR my fault or the website's? Usually the website's: an old or misconfigured TLS setup on the server. Your side contributes when the system clock is wrong, the OS or browser is very old, or security software is intercepting the connection. The phone test separates the two quickly.
Why is there no “proceed anyway” option for this error? A failed handshake means no secure channel could be established at all, so there is nothing to proceed over. Certificate warnings sometimes offer a bypass because a channel exists but its identity is in doubt; here the channel itself failed.