How to Fix ERR_SPDY_PROTOCOL_ERROR in Chrome

ERR_SPDY_PROTOCOL_ERROR is a Chrome network error that occurs when the browser fails to establish or maintain a valid SPDY or HTTP/2 session with a web server. It surfaces as a broken page load, typically accompanied by Chrome's standard error screen, and can be triggered by stale socket connections, corrupted cache data, TLS/SSL mismatches, interfering extensions, or misconfigured server-side protocol negotiation.

The error's name references SPDY — Google's now-deprecated multiplexed transport protocol that preceded HTTP/2. Although Chrome dropped native SPDY support after version 51, the internal socket and session management layer still uses SPDY-derived terminology, which is why the error code persists even on modern HTTP/2 and HTTP/3 connections. Understanding this distinction is essential for diagnosing the root cause accurately.

What Actually Causes ERR_SPDY_PROTOCOL_ERROR

Before applying fixes blindly, it helps to know the precise failure modes behind this error:

• Stale SPDY/HTTP2 socket sessions cached in Chrome's connection pool that no longer match the server's current TLS state
• Expired or reissued SSL/TLS certificates on the server side that invalidate an existing session without a clean handshake reset
• ALPN (Application-Layer Protocol Negotiation) mismatches where the server advertises HTTP/2 support but the TLS handshake fails mid-session
• Corrupted browser profile data including cache, cookies, or the network state file
• Proxy, VPN, or security software performing TLS inspection that breaks the HTTP/2 framing layer
• Outdated Chrome builds with known bugs in the HTTP/2 or QUIC implementation
• Server-side misconfiguration — for example, an Nginx or Apache instance with a broken h2 module, or an expired certificate on a CDN edge node

Fix 1: Flush SPDY Sockets Directly

This is the most targeted fix and should be your first action. Chrome maintains a persistent pool of SPDY/HTTP2 socket sessions. If a session becomes corrupted — for instance, after a server restarts or a certificate is reissued — Chrome will keep reusing the broken session until it is explicitly flushed.

1. Open a new Chrome tab.
2. Navigate to chrome://net-internals/#sockets
3. Click Flush socket pools.
4. Then navigate to chrome://net-internals/#dns
5. Click Clear host cache.
6. Close the tab and reload the failing page.

This two-step flush clears both the transport-layer session pool and the DNS resolution cache simultaneously, which addresses the two most common in-browser causes in a single pass.

Why the old URL no longer works: Many guides still reference chrome://net-internals/#events&q=type:SPDY_SESSION%20is:active. Chrome removed the Events tab in newer builds. Use #sockets and #dns directly.

Fix 2: Clear Browser Cache and Cookies

Cached HTTP responses, stored cookies, and stale HSTS (HTTP Strict Transport Security) state can all conflict with a server's current TLS or protocol configuration.

1. Open Chrome and press Ctrl+Shift+Delete (Windows/Linux) or Cmd+Shift+Delete (macOS).
2. Set Time range to All time.
3. Check Cookies and other site data and Cached images and files.
4. Click Clear data.

For a more surgical approach — if you only want to clear data for one specific domain without wiping your entire browser state — use the following:

1. Navigate to chrome://settings/siteData
2. Search for the affected domain.
3. Delete only that site's cookies and storage.

Additionally, clear the HSTS state for the domain at chrome://net-internals/#hsts by entering the hostname under Delete domain security policies. A stale HSTS entry can force Chrome into an upgrade path that conflicts with a server that has changed its TLS configuration.

Fix 3: Update Google Chrome

Chrome's HTTP/2 and QUIC implementations receive frequent patches. Running an outdated build can mean you are carrying known protocol-handling bugs that have already been fixed upstream.

1. Click the three-dot menu and go to Help > About Google Chrome.
2. Chrome will check for and download updates automatically.
3. Click Relaunch to apply the update.

To verify your current version from the address bar, navigate to chrome://version/. Cross-reference the build number against the Chrome Releases blog to confirm you are on the latest stable channel.

Fix 4: Disable VPN, Proxy, and TLS Inspection Tools

VPNs, corporate proxies, and antivirus products that perform SSL/TLS deep inspection (also called HTTPS interception) are a frequent and underdiagnosed cause of ERR_SPDY_PROTOCOL_ERROR. These tools terminate the TLS connection at the client, re-encrypt it with their own certificate, and forward it to the server. If the tool's HTTP/2 implementation is incomplete or its certificate chain is untrusted, Chrome will reject the session.

To disable proxy settings on Windows:

1. Press Win+I to open Settings.
2. Go to Network & Internet > Proxy.
3. Set Automatically detect settings to On and Use a proxy server to Off.

To disable proxy settings via Command Prompt:

netsh winhttp reset proxy

To check if a proxy is currently active:

netsh winhttp show proxy

If you are on a corporate network, consult your IT administrator before disabling proxy settings, as doing so may violate network policy. Instead, ask whether the SSL inspection tool supports HTTP/2 passthrough mode.

Fix 5: Reset TCP/IP Stack and Flush DNS Cache

Corrupted TCP/IP stack entries or a poisoned DNS cache can cause connection failures that manifest as protocol errors. This fix operates at the OS network layer, below Chrome itself.

Open Command Prompt as Administrator (press Win+R, type cmd, then press Ctrl+Shift+Enter), then run the following commands in sequence:

netsh int ip reset
netsh winsock reset
ipconfig /flushdns
ipconfig /release
ipconfig /renew

Restart your machine after running these commands. The netsh winsock reset command is particularly important — a corrupted Winsock catalog can cause intermittent and seemingly random protocol errors that are difficult to trace back to their source.

On macOS, the equivalent DNS flush command is:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Fix 6: Disable or Isolate Browser Extensions

Extensions that intercept network requests — ad blockers, privacy tools, antivirus extensions, VPN extensions, and custom proxy switchers — can corrupt HTTP/2 frames or inject headers that violate the HTTP/2 specification, triggering a protocol error.

Systematic isolation method:

1. Open chrome://extensions/
2. Disable all extensions simultaneously.
3. Reload the failing page.
4. If the error is gone, re-enable extensions one at a time, reloading the page after each, until the culprit is identified.

Alternatively, open Chrome in Incognito mode (Ctrl+Shift+N), which disables all extensions by default (unless you have explicitly allowed them in Incognito). If the page loads cleanly in Incognito, an extension is definitively the cause.

Fix 7: Restart Your Router or Modem

NAT (Network Address Translation) tables and stateful packet inspection on consumer routers can hold stale TCP session entries that prevent new HTTP/2 connections from completing their handshake. A full power cycle — not just a software reboot — clears these tables.

1. Power off the router and modem completely.
2. Wait 60 seconds (not 30 — capacitors need time to fully discharge and clear volatile state).
3. Power the modem on first, wait for it to fully sync, then power on the router.
4. Wait for a full connection before testing.

Fix 8: Temporarily Disable Antivirus or Firewall

Security software with HTTPS scanning or web shield features operates similarly to a corporate TLS inspection proxy. It intercepts the TLS handshake, which can break HTTP/2 session negotiation if the security software's engine does not fully support the ALPN extension or HTTP/2 framing.

Common products known to cause this issue include Avast, AVG, Kaspersky, and ESET when their web protection modules are active.

• Temporarily disable the Web Shield or HTTPS Scanning feature specifically (not the entire antivirus).
• Test the failing URL.
• If the error resolves, look for an option to add the affected site to an HTTPS scanning exclusion list rather than disabling protection globally.

Fix 9: Create a New Chrome Profile

A corrupted Chrome user profile — specifically the Network subfolder within the profile directory — can cause persistent ERR_SPDY_PROTOCOL_ERROR that survives cache clears and socket flushes. The profile's network state file stores HSTS data, certificate transparency logs, and cached protocol negotiation results.

To test with a fresh profile:

1. Navigate to chrome://settings/
2. Scroll to People and click Add person (or Add profile).
3. Create a minimal test profile.
4. Open the failing URL in the new profile.

If the URL loads correctly in the new profile, the issue is isolated to your original profile's stored network state. You can manually delete the Network folder from your profile directory without losing bookmarks or passwords:

• Windows: %LOCALAPPDATA%GoogleChromeUser DataDefaultNetwork
• macOS: ~/Library/Application Support/Google/Chrome/Default/Network
• Linux: ~/.config/google-chrome/Default/Network

Delete the Network folder while Chrome is closed, then relaunch.

Fix 10: Diagnose and Escalate Server-Side Issues

If all client-side fixes fail, the error originates on the server. Common server-side causes include:

• Expired or recently reissued SSL/TLS certificate without a server restart to pick up the new certificate
• Broken HTTP/2 configuration in Nginx (http2 directive misconfigured) or Apache (mod_http2 loaded but Protocols h2 http/1.1 not set correctly)
• CDN or reverse proxy misconfiguration where the edge node and origin server have conflicting protocol settings
• TLS version mismatch — for example, a server configured to use only TLS 1.3 while an intermediate proxy only supports TLS 1.2

Nginx HTTP/2 correct configuration example:

server {
    listen 443 ssl;
    http2 on;
    ssl_certificate     /etc/ssl/certs/your_domain.crt;
    ssl_certificate_key /etc/ssl/private/your_domain.key;
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         HIGH:!aNULL:!MD5;
}

Note: In Nginx 1.25.1+, http2 on replaces the older listen 443 ssl http2 syntax. Using the deprecated syntax on newer builds can cause ALPN negotiation failures.

Apache HTTP/2 correct configuration example:

Protocols h2 http/1.1
SSLEngine on
SSLCertificateFile    /etc/ssl/certs/your_domain.crt
SSLCertificateKeyFile /etc/ssl/private/your_domain.key

If you manage your own server infrastructure, ensuring your SSL Certificates are valid, properly chained, and renewed before expiry eliminates the most common server-side trigger for this error. Hosting environments that run on properly maintained VPS Hosting give you direct access to server configuration files, making it straightforward to apply these fixes without waiting on a shared hosting provider.

For teams running web applications on Dedicated Servers, verifying that mod_http2 or Nginx's HTTP/2 module is correctly compiled and enabled should be part of any post-deployment checklist.

Diagnostic Tools to Identify the Root Cause Faster

Before working through every fix sequentially, use these tools to narrow down the source:

The curl command is particularly useful for confirming whether the issue is browser-specific or server-wide:

curl -v --http2 https://your-domain.com 2>&1 | grep -E "ALPN|HTTP|SSL|error"

If curl also fails to negotiate HTTP/2, the problem is definitively server-side. If curl succeeds but Chrome fails, the problem is in the browser's session state or a local intercepting tool.

ERR_SPDY_PROTOCOL_ERROR vs. Related Chrome Network Errors

For sites where QUIC is causing instability, you can disable it at chrome://flags/#enable-quic by setting the flag to Disabled. This forces Chrome to fall back to TCP-based HTTP/2 or HTTP/1.1.

Technical Decision Matrix: Which Fix to Apply First

Use this matrix to prioritize your troubleshooting based on the context in which the error appears:

If you are managing your own web server and need a control panel to simplify SSL and protocol management, VPS Control Panels provide GUI-based interfaces for certificate installation and web server configuration that reduce the risk of manual misconfiguration. For smaller projects on Shared Web Hosting, protocol settings are managed at the infrastructure level — contact support if you suspect a server-side HTTP/2 misconfiguration.

Actionable Checklist Before Escalating

Work through this checklist in order. Stop at the step that resolves the error.

• [ ] Flush socket pools at chrome://net-internals/#sockets
• [ ] Clear DNS host cache at chrome://net-internals/#dns
• [ ] Delete domain HSTS policy at chrome://net-internals/#hsts
• [ ] Clear all browser cache and cookies (All time)
• [ ] Test in Incognito mode to rule out extensions
• [ ] Test in a second browser (Firefox, Edge) to rule out Chrome-specific issues
• [ ] Disable antivirus HTTPS scanning temporarily
• [ ] Disable VPN or proxy
• [ ] Run netsh winsock reset and ipconfig /flushdns as Administrator
• [ ] Power-cycle router and modem (60-second full discharge)
• [ ] Create a new Chrome profile and delete the Network folder from the old profile
• [ ] Run curl -v --http2 https://your-domain.com to determine if the issue is server-side
• [ ] If server-side: audit SSL certificate validity, HTTP/2 module configuration, and reload the server process
• [ ] Update Chrome to the latest stable build

FAQ

What is ERR_SPDY_PROTOCOL_ERROR and why does it still appear if SPDY is deprecated?

Chrome's internal networking stack inherited SPDY-era error codes that were never renamed. The error now surfaces for any failure in the HTTP/2 or QUIC session layer — including ALPN negotiation failures, broken TLS handshakes, and stale connection pool entries — even though SPDY itself has not been used since Chrome 51.

Why does the error appear on only one website but not others?

This almost always indicates either a stale Chrome socket session specific to that domain, or a server-side issue on that particular host — such as a recently reissued certificate that invalidated existing sessions, or a broken HTTP/2 configuration on that server. Flushing socket pools and testing with curl --http2 will confirm which it is.

Can antivirus software really cause ERR_SPDY_PROTOCOL_ERROR?

Yes. Security products that perform HTTPS inspection (Avast, AVG, Kaspersky, ESET, and others) act as a man-in-the-middle TLS proxy. If their HTTP/2 implementation is incomplete or their injected certificate is not trusted by Chrome's certificate store, the HTTP/2 session will fail with this exact error. Disabling only the HTTPS scanning component — not the entire antivirus — is the correct targeted fix.

How do I know if the problem is on my side or the server's side?

Run curl -v --http2 https://your-domain.com from the command line. If curl also fails to negotiate HTTP/2, the server is misconfigured. If curl succeeds but Chrome fails, the issue is local — either a stale Chrome session, an extension, or an intercepting security tool.

Does this error affect SEO or website performance?

For end users, yes — the error prevents the page from loading entirely. For site owners, a persistent ERR_SPDY_PROTOCOL_ERROR caused by a server-side HTTP/2 misconfiguration or an expired certificate will result in failed Googlebot crawl attempts, which can negatively impact crawl coverage and indexing. Ensuring your SSL certificate is valid and your HTTP/2 configuration is correct is a baseline technical SEO requirement.