ERR_SSL_PROTOCOL_ERROR: Fix It in Chrome, Edge & Localhost

What Is ERR_SSL_PROTOCOL_ERROR?

ERR_SSL_PROTOCOL_ERROR means the secure connection broke during its TLS handshake, before your browser could load anything. Chrome and Edge show it as "This site can't provide a secure connection. example.com sent an invalid response." If the address is localhost, your development server is almost certainly speaking plain HTTP: open http://localhost instead (see the developer section below).

Every HTTPS connection begins with a TLS handshake, in which the browser and server agree on a protocol version (TLS 1.2 or 1.3) and ciphers and exchange certificates. ERR_SSL_PROTOCOL_ERROR means that negotiation broke down: the other side answered with something that isn't valid TLS, or rejected the handshake in a way the browser couldn't classify.

It happens before any HTTP request is sent, so it is not an HTTP status code. Chromium's error list defines it as error -107 with one line, "An SSL protocol error occurred": the catch-all for a broken handshake, unlike the specific "no common protocol version or cipher" error -113.

What ERR_SSL_PROTOCOL_ERROR Looks Like

Chrome and other Chromium-based browsers display this error as a full-page warning with the message "This site can't provide a secure connection." Below it, you will see the specific error code. Here are the common variations you might encounter.

• localhost sent an invalid response — the version developers see: https:// opened on a local server that speaks plain HTTP
• ERR_SSL_PROTOCOL_ERROR — the error code Chrome prints in small type under the message
• net::ERR_SSL_PROTOCOL_ERROR — the full internal error code shown in Chrome DevTools console
• This site can't provide a secure connection — the user-facing headline message in Chrome
• [domain] sent an invalid response — the detailed error text Chrome displays below the headline
• ERR_SSL_PROTOCOL_ERROR on all browsers — when the error appears across Chrome, Edge, Brave, and Opera simultaneously (indicates a server-side or system-wide issue, not a browser-specific bug)

What Causes ERR_SSL_PROTOCOL_ERROR?

This error has both client-side (your device) and server-side (the website) causes. Identifying which side the problem is on is the first step to fixing it. If the error appears on every website, the problem is on your side. If it only appears on one specific website, the problem is likely server-side.

• HTTPS sent to a server that speaks HTTP — the most searched case: https://localhost on a dev server, or a site whose port 443 isn't set up for TLS. The browser starts a handshake and gets plain text back, which Chrome reports as "sent an invalid response".
• Antivirus SSL/HTTPS scanning — security software that intercepts HTTPS (Avast, Kaspersky, Bitdefender, ESET) inserts itself into the handshake and can break it, on every site at once.
• VPN or proxy interference — VPNs and corporate proxies that inspect HTTPS traffic can corrupt the handshake, especially right after switching networks.
• A network that filters the site — ISP, school, workplace and national filters, and DNS-based blockers, break the handshake on purpose for the sites they block. The tell: the site loads on mobile data or another Wi-Fi.
• A broken TLS setup on the server — port 443 answering in plain HTTP (a server block on 443 without TLS turned on), or another program listening on port 443.
• Browser extensions — privacy, ad-blocking and security add-ons that rewrite HTTPS requests can interfere with the handshake.
• Stale browser state — cached session data that no longer matches the server.
• Often mistaken for it — a server stuck on TLS 1.0 or 1.1 shows ERR_SSL_VERSION_OR_CIPHER_MISMATCH ("uses an unsupported protocol"), and an expired, wrong-name or self-signed certificate or a wrong clock shows a certificate error (NET::ERR_CERT_…), and a QUIC (HTTP/3) problem shows ERR_QUIC_PROTOCOL_ERROR. See ERR_SSL_VERSION_OR_CIPHER_MISMATCH and "Your connection is not private".

ERR_SSL_PROTOCOL_ERROR on Localhost (Developers)

localhost sent an invalid response. ERR_SSL_PROTOCOL_ERROR almost always means you opened https://localhost on a development server that only speaks plain HTTP. The browser starts a TLS handshake, the server answers with ordinary HTTP text, and Chrome reports that answer as invalid. Firefox reports the same mistake as SSL_ERROR_RX_RECORD_TOO_LONG.

• Use the address the server prints — change https://localhost:3000 to http://localhost:3000. Next.js, Vite, React, Django, Rails and Flask dev servers serve HTTP unless you turn HTTPS on
• Check the port — https://localhost with no port means port 443. If your app runs on 3000 or 5173, the request reaches some other program, or nothing
• Chrome keeps switching to https:// — a redirect cached from an earlier app on the same port can do this: clear cached images and files or test in an Incognito window. (Chrome versions before 132 could also keep an HSTS entry for localhost, which you delete under Delete domain security policies at chrome://net-internals/#hsts)
• You need HTTPS locally (OAuth callbacks, secure cookies) — next dev --experimental-https creates a locally trusted certificate with mkcert; Vite takes certificate options in server.https, or @vitejs/plugin-basic-ssl for a quick self-signed one; anywhere else, mkcert -install && mkcert localhost 127.0.0.1 makes files your server can load
• A self-signed certificate gives a different error — NET::ERR_CERT_AUTHORITY_INVALID, not this one. Click Advanced → Proceed to localhost (unsafe), or better, use a mkcert certificate (the old allow-insecure-localhost flag has expired)

How to Fix ERR_SSL_PROTOCOL_ERROR (For Users)

Start with Fix 1: in two minutes it tells you whether the problem is your browser, your device or network, or the site. Then work down the list.

Fix 1: Try Incognito and Another Network

Incognito starts with no cookies, no cache and no extensions (unless you allowed them there). Open the site in an Incognito window (Ctrl+Shift+N in Chrome and Edge, Ctrl+Shift+P in Firefox), then on another network, such as your phone's mobile data.

If it loads in Incognito, the cause is in your browser: an extension or stale data (Fixes 4 and 5). If it loads only on another network, your network or a VPN or proxy filters or intercepts it (Fix 3). If it fails everywhere, test the site with an SSL checker: when that fails too, only the site's owner can fix it.

Fix 2: Disable Antivirus SSL/HTTPS Scanning

Many antivirus programs (Avast, Kaspersky, Bitdefender, ESET, Norton) include an "HTTPS scanning" or "SSL inspection" feature that intercepts encrypted connections by acting as a man-in-the-middle proxy. When it mishandles a site's handshake, every browser on the computer fails on that site.

Look for settings named Web Shield, HTTPS Scanning, SSL Scanning, or Encrypted connections scanning in your antivirus and temporarily disable it. If the error resolves, you can add the affected domain to your antivirus exclusion list.

Fix 3: Disable VPN or Proxy

VPNs and HTTP proxies sit between your browser and the web server. Some VPNs inspect HTTPS traffic or route connections through servers with broken TLS. Corporate proxies often use SSL interception (similar to antivirus HTTPS scanning) that can break TLS handshakes.

Temporarily disconnect your VPN and try loading the website. If it works without the VPN, the issue is with how your VPN handles SSL connections. Try a different VPN server or contact your VPN provider.

Fix 4: Disable Browser Extensions

Extensions that filter or reroute traffic, such as VPN and proxy extensions and security add-ons, can break secure connections.

Go to chrome://extensions/, turn every extension off, and reload the page. If the error goes, turn them back on one at a time to find the one responsible.

Fix 5: Clear Browser Cache and Cookies

Stale cookies or cached data occasionally get in the way, and clearing them takes a minute.

• Step 1: Press Ctrl+Shift+Delete (Mac: Cmd+Shift+Delete) to open Delete browsing data
• Step 2: Choose More → All time for the time range
• Step 3: Tick Cookies and other site data and Cached images and files
• Step 4: Click Delete data (Delete from this device if you're signed out) and restart Chrome

For a single site, go to chrome://settings/content/all, search for the domain and delete its data.

Fix 6: Rule Out QUIC (HTTP/3)

Chrome tries QUIC (HTTP/3 over UDP) alongside a normal TCP connection and falls back to TCP when QUIC fails, so QUIC rarely causes ERR_SSL_PROTOCOL_ERROR. If the page or DevTools shows ERR_QUIC_PROTOCOL_ERROR instead, turning QUIC off is the fix (see ERR_QUIC_PROTOCOL_ERROR):

• Step 1: Type chrome://flags/#enable-quic in the address bar
• Step 2: Find Experimental QUIC protocol
• Step 3: Change it from Default to Disabled
• Step 4: Click Relaunch to restart Chrome

Pages still load with QUIC off, over HTTP/2 on TCP; turn it back on once the network or site is fixed.

Fix 7: Update Your Browser

Old browser versions can lack the TLS features and ciphers modern sites expect, and updates fix TLS bugs.

Update Chrome: go to chrome://settings/help or Menu → Help → About Google Chrome. Chrome auto-downloads updates but requires a restart to apply them. For Edge: edge://settings/help. For Firefox: Menu → Help → About Firefox.

Fix 8: Flush DNS Cache

Stale DNS can send your browser to an old server that no longer serves the site over TLS. Flushing the DNS cache forces a fresh lookup.

# Windows (Command Prompt as Admin)
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

# Linux
sudo resolvectl flush-caches

# Chrome internal DNS cache
# Visit chrome://net-internals/#dns → Click "Clear host cache"

After flushing, verify that the domain resolves to the correct IP using DNS Robot's DNS Lookup tool. If the IP address looks wrong, the website may have changed hosting providers and DNS hasn't fully propagated yet.

Fix 9: Check Your System Date and Time

A wrong clock normally shows as a different error, NET::ERR_CERT_DATE_INVALID ("Your clock is ahead" or "Your clock is behind"), because a certificate is only valid between two dates. It still takes ten seconds to rule out:

• Windows: Settings → Time & Language → Date & Time → Toggle on "Set time automatically" and "Set time zone automatically"
• Mac: System Settings → General → Date & Time → Toggle on "Set time and date automatically"
• Linux: Run sudo timedatectl set-ntp true to enable NTP sync

Fix 10: Clear SSL State (Windows)

Many guides suggest Clear SSL state in Windows' Internet Options (inetcpl.cpl → Content → Clear SSL state). It clears the session cache of Windows' own TLS library, which apps built on Windows networking use. Chrome and Edge run their own TLS library, so it rarely changes anything for them.

The browser's equivalent is simpler: close every browser window (check the system tray for a background Chrome) and reopen it. That drops all cached TLS sessions. If the error survives a full restart, move on to the next fixes.

Fix 11: Reset Network Settings (Last Resort)

If nothing else works, reset your network stack. On Windows these commands reset Winsock and TCP/IP, including static IP addresses and DNS servers you set by hand; on macOS and Linux they only flush the DNS cache or restart the network service.

# Windows (Command Prompt as Admin)
netsh winsock reset
netsh int ip reset
ipconfig /release
ipconfig /renew
ipconfig /flushdns

# Then restart your computer

# macOS — flush the DNS cache
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Linux — restart NetworkManager
sudo systemctl restart NetworkManager

How to Fix ERR_SSL_PROTOCOL_ERROR (For Website Owners)

If many visitors report ERR_SSL_PROTOCOL_ERROR, the problem is on the server: usually port 443 answering in plain HTTP, or another program on that port. Certificate problems show their own errors, but check them while you're there. (A certificate and key that don't match stop the server from loading the new config at all: check with nginx -t or apachectl configtest after a change.)

Check Your SSL Certificate

The first step is to verify that your SSL certificate is valid, properly installed, and not expired. Use DNS Robot's SSL Checker to instantly check your certificate status, expiration date, issuer, and certificate chain.

These certificate problems show their own errors rather than ERR_SSL_PROTOCOL_ERROR, but fix them while you're there:

• Expired certificate (NET::ERR_CERT_DATE_INVALID) — Let's Encrypt certificates last 90 days (64 days from February 2027), so renewal must run automatically; if it failed (certbot timer not running, DNS challenge broken), the certificate silently expires.
• Wrong domain (NET::ERR_CERT_COMMON_NAME_INVALID) — The certificate was issued for example.com but the site is served at www.example.com (or vice versa). The certificate must match the exact domain or include a wildcard (*.example.com).
• Self-signed certificate (NET::ERR_CERT_AUTHORITY_INVALID) — fine for development, never trusted by browsers in production.
• Revoked certificate (NET::ERR_CERT_REVOKED) — the certificate authority revoked it after a key compromise or mis-issuance.
• Wrong certificate for the name (NET::ERR_CERT_COMMON_NAME_INVALID) — several sites share one IP address and the server isn't using SNI (Server Name Indication) to pick each site's certificate.

# Check certificate from command line
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>/dev/null | openssl x509 -noout -dates -subject -issuer

# Check certificate chain completeness
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>&1 | grep -E "depth|Verify"

# Renew Let's Encrypt certificate
sudo certbot renew --dry-run   # test first
sudo certbot renew

Enable TLS 1.2 and TLS 1.3

All modern browsers require at least TLS 1.2: TLS 1.0 and 1.1 were formally deprecated by RFC 8996 in 2021. A side that refuses the other's version ends the handshake with TLS alert 70, protocol_version (RFC 8446 §6.2). A server that only supports TLS 1.0 or 1.1 shows ERR_SSL_VERSION_OR_CIPHER_MISMATCH rather than this error, but it fails either way. TLS 1.3 connects in one round trip instead of TLS 1.2's two: enable both.

# Nginx — ssl_protocols in nginx.conf or site config
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers off;

# Apache — in httpd.conf or ssl.conf
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256
SSLHonorCipherOrder off

After updating your TLS configuration, restart your web server (sudo systemctl restart nginx or sudo systemctl restart apache2) and test with DNS Robot's SSL Checker to verify the protocols are active.

Install the Complete Certificate Chain

An incomplete chain shows as a certificate error (NET::ERR_CERT_AUTHORITY_INVALID) on browsers and apps that can't fill in the missing intermediate, so install the full chain while you're checking. Your server must send your certificate plus the intermediate certificates that link it to a trusted root.

Most certificate authorities provide a "CA bundle" or "full chain" file. For Let's Encrypt, use fullchain.pem (not just cert.pem). For other CAs, download the intermediate certificate from their documentation and concatenate it with your certificate.

# Nginx — use fullchain, not just cert
ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

# Apache
SSLCertificateFile /etc/letsencrypt/live/yourdomain.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/yourdomain.com/privkey.pem

Check HSTS Configuration

HSTS (HTTP Strict Transport Security) tells browsers to always use HTTPS for your domain. If your HSTS policy has a long max-age and your TLS setup later breaks, browsers can't fall back to HTTP: visitors get an error page with no way to click through.

Check your HSTS header with DNS Robot's HTTP Header Checker. If you set a very long max-age (like 2 years) and your certificate expired, users who previously visited your site are locked into HTTPS with no fallback. To fix this, first fix your SSL certificate, then browsers will connect normally again.

Verify Server Configuration

This server mistake breaks the handshake even with a valid certificate, and one more shows a different error:

• Port 443 serving plain HTTP — the classic owner-side cause: in nginx, listen 443; without ssl (it must be listen 443 ssl;), or another service bound to port 443.
• Cipher suite mismatch — a server that only offers ciphers browsers refuse shows ERR_SSL_VERSION_OR_CIPHER_MISMATCH. Use modern AEAD ciphers (AES-GCM, ChaCha20).

Test from outside with openssl s_client -connect example.com:443 -servername example.com </dev/null: "wrong version number" (OpenSSL) or "tlsv1 alert protocol version" (macOS's built-in openssl) means port 443 isn't speaking TLS, and a certificate printout means the handshake works.

ERR_SSL_PROTOCOL_ERROR on Android

Android users encounter ERR_SSL_PROTOCOL_ERROR in both Chrome for Android and in WebView-based apps. The fixes differ slightly from desktop because Android manages certificates and network settings differently.

• Switch networks — turn Wi-Fi off and try mobile data (or the reverse). If the site loads, the network is filtering or intercepting it
• Turn off Private DNS to test — Settings → Network & internet → Private DNS → Off (and in Chrome: Settings → Privacy and security → Use secure DNS). A filtering DNS service (ad-blocking, parental control) sends the sites it blocks to a server that can't complete the handshake
• Clear Chrome data — Settings → Apps → Chrome → Storage → Clear cache (then Manage space if that didn't help)
• Update Chrome — Play Store → your profile picture → Manage apps & device → update Chrome
• Clear network credentials — Settings → Security (on newer phones: More security settings → Encryption & credentials) → Clear credentials. This removes all user-installed certificates
• Check date and time — Settings → System → Date & time → automatic. A wrong clock shows a certificate error, but it's quick to rule out
• Reset network settings — Settings → System → Reset options, then the Wi-Fi and mobile network reset (its name varies by Android version)

ERR_SSL_PROTOCOL_ERROR on iPhone and iPad

On an iPhone, Chrome shows ERR_SSL_PROTOCOL_ERROR and Safari says it "can't establish a secure connection to the server". The causes are the same as on a computer; the switches are in different places:

• Switch networks — turn Wi-Fi off and try mobile data. If the site loads, the Wi-Fi network is filtering or intercepting it
• Remove VPNs and profiles you don't recognise — Settings → General → VPN & Device Management. A profile that installs its own certificate or VPN can intercept HTTPS
• Test without iCloud Private Relay — Settings → [your name] → iCloud → Private Relay → off, then retry
• Check Screen Time limits — Settings → Screen Time → Content & Privacy Restrictions, then the web content setting. A blocked site fails instead of loading
• Set the clock automatically — Settings → General → Date & Time → Set Automatically

ERR_SSL_PROTOCOL_ERROR in Other Browsers

ERR_SSL_PROTOCOL_ERROR is a Chromium-specific error code. Other browsers display different error messages for the same underlying SSL handshake failure.

If the error appears in all browsers at once, the problem is either on your system (antivirus HTTPS scanning, a VPN or proxy, your network) or on the server (port 443 not serving TLS properly). If only one browser fails, check that browser's extensions and cached data.

Related SSL/TLS Error Codes

Chrome has several SSL-related error codes. They all indicate different TLS handshake or certificate problems.

For all SSL errors, you can quickly diagnose the issue using DNS Robot's SSL Checker — it shows the certificate status, chain completeness, TLS versions supported, and expiration date in one scan.

If your page says the site "uses an unsupported protocol", you have ERR_SSL_VERSION_OR_CIPHER_MISMATCH, not this error: see how to fix ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

If the page instead says "example.com unexpectedly closed the connection" (ERR_CONNECTION_CLOSED), the connection was cut off rather than broken. See ERR_CONNECTION_CLOSED for that case.