How to Fix ERR_SSL_VERSION_INTERFERENCE in Google Chrome

ERR_SSL_VERSION_INTERFERENCE stands apart from most Chrome SSL errors because it does not point to a specific certificate problem. It fires when something in the TLS negotiation process is disrupted before Chrome can even evaluate the certificate. The word interference in the error name is precise: something between Chrome and the server is interfering with how they agree on a TLS version.

That something can be Chrome’s own experimental settings, antivirus software intercepting the connection, a VPN or proxy layer introducing incompatible TLS parameters, or a hardware acceleration conflict causing faulty packet handling. The fixes are all client-side. If you are a site owner seeing this reported by visitors, the most likely explanation is that the visitors are running security software that conflicts with Chrome’s TLS stack, not that your server configuration is wrong.

This guide covers each cause in order of likelihood, with specific navigation steps and exactly what to look for at each stage.

What the Error Actually Means

During a TLS handshake, Chrome and the server exchange supported protocol versions and negotiate the highest version both sides accept. ERR_SSL_VERSION_INTERFERENCE fires when that negotiation process is interrupted or corrupted rather than when it simply fails to agree. A plain version mismatch where the server only supports old TLS would show ERR_SSL_VERSION_OR_CIPHER_MISMATCH instead. The interference variant specifically indicates that something modified or disrupted the handshake packets mid-flight.

The most common triggers are QUIC protocol conflicts, antivirus HTTPS inspection that corrupts the TLS ClientHello, VPN or proxy layers that alter TLS parameters in transit, and Chrome’s hardware acceleration generating malformed packets on certain graphics hardware configurations.

Fix 1: Disable the Experimental QUIC Protocol

QUIC is a transport protocol developed by Google that runs on UDP rather than TCP. It is built into Chrome and is used by default for connections to Google services and some other sites. QUIC handles its own encryption layer, and on certain network configurations or with specific server software, its interaction with standard TLS negotiation produces ERR_SSL_VERSION_INTERFERENCE. This is the most commonly reported cause of the error and the fastest to test.

To disable QUIC in Chrome, type the following address directly into the Chrome address bar and press Enter:

The flags page opens with the Experimental QUIC Protocol option highlighted. Change the dropdown from Default to Disabled. Chrome will show a Relaunch button at the bottom of the screen. Click it to restart Chrome with QUIC disabled. Reload the page that was showing the error.

If the error clears, QUIC was the conflict. You can leave it disabled permanently if the error does not return on other sites. If it clears only temporarily or the error comes back on other sites, re-enable QUIC and move to the next fix.

QUIC being disabled has a minor performance effect on connections to Google services, as those connections fall back to standard TLS over TCP. For most users on most sites, disabling QUIC makes no perceptible difference. It is a safe setting to leave disabled if it resolves the error.

Fix 2: Disable Antivirus HTTPS Scanning

Antivirus products from Avast, AVG, Kaspersky, ESET, Bitdefender, Norton, and McAfee include HTTPS scanning features that work by inserting a proxy between Chrome and the website. The antivirus decrypts the TLS connection, inspects the content, and re-encrypts it before passing it to Chrome. When this interception process modifies TLS parameters in a way that Chrome’s strict validation rejects, ERR_SSL_VERSION_INTERFERENCE results.

Test this before changing antivirus settings: open the failing site in an incognito window with all extensions disabled. Incognito still passes through antivirus HTTPS scanning, so if the error appears there too, antivirus interference is a likely cause.

To disable HTTPS scanning in the most common antivirus products:

• Avast / AVG: Open the Avast or AVG dashboard and go to Menu, then Settings, then Protection, then Core Shields. Click through to Web Shield settings and uncheck Enable HTTPS scanning.
• Kaspersky: Open Kaspersky and go to Settings, Additional, Network. Under Encrypted connections scanning, select Do not scan encrypted connections.
• ESET: Open ESET and navigate to Setup, Internet Protection. Click on Web Access Protection, then expand the URL Address Management section and locate HTTPS filtering. Disable it.
• Bitdefender: Open Bitdefender and go to Protection, Online Threat Prevention. Find the Encrypted Web Scan toggle and turn it off.
• Norton: Open Norton and go to Settings, Firewall. Look for Traffic Rules or HTTPS scanning options and disable browser scanning.

After disabling HTTPS scanning, reload the page. If the error clears, the antivirus was intercepting and corrupting the TLS handshake. You can add the affected site to the antivirus exclusions list, which allows the connection to bypass scanning for that domain without disabling scanning globally.

Re-enable HTTPS scanning immediately after testing if you choose not to add an exclusion. Leaving HTTPS scanning permanently disabled reduces the antivirus product’s ability to detect malware delivered over HTTPS connections.

Fix 3: Disconnect VPN and Check Proxy Settings

VPNs route your traffic through their servers and apply their own TLS handling. If a VPN client introduces incompatible TLS parameters, alters protocol version negotiation, or has a known conflict with Chrome’s TLS stack, ERR_SSL_VERSION_INTERFERENCE results. Proxy servers configured in Windows network settings can similarly alter TLS traffic in transit.

Disconnect your VPN entirely using its application interface and reload the failing page. If the error clears, the VPN is the source. Try connecting to a different VPN server location, which often resolves server-specific conflicts. If one VPN server consistently produces the error, contact the VPN provider.

To check and clear proxy settings in Chrome, go to the three-dot menu, then Settings, then System, then click Open your computer’s proxy settings. On Windows, ensure the Use a proxy server toggle under Manual proxy setup is switched off. On Mac, confirm all proxy types are unchecked in System Settings under Network.

For proxy settings that persist through manual clearing, check the Windows Registry path at HKEY_CURRENT_USER, Software, Microsoft, Windows, CurrentVersion, Internet Settings. A ProxyEnable value set to 1 with a ProxyServer value present indicates an active proxy. Setting ProxyEnable to 0 disables it. Malware commonly sets proxy values here to intercept browser traffic, which can produce SSL interference errors when the proxy server is not functioning correctly.

Fix 4: Disable Hardware Acceleration

Chrome uses hardware acceleration to delegate rendering and processing tasks to the GPU rather than the CPU. On systems with outdated GPU drivers, misconfigured graphics hardware, or certain integrated graphics chips, hardware acceleration can interfere with network stack operations including TLS packet handling, producing ERR_SSL_VERSION_INTERFERENCE on pages that make heavy use of GPU-accelerated content.

To disable hardware acceleration in Chrome, open the three-dot menu in the top right, select Settings, then click System in the left sidebar. Toggle off Use graphics acceleration when available and click the Relaunch button that appears. This restarts Chrome without GPU acceleration and falls back to CPU-based rendering.

If the error clears after disabling hardware acceleration, the fix is updating your GPU driver to a version that does not conflict with Chrome. For NVIDIA GPUs, download the latest driver from nvidia.com or through NVIDIA GeForce Experience. For AMD GPUs, use AMD Radeon Software or amd.com. For Intel integrated graphics, use Device Manager to check for driver updates or download from your laptop or motherboard manufacturer’s support page. After updating the driver, re-enable hardware acceleration in Chrome and confirm the error does not return.

Fix 5: Clear the Browser Cache and SSL State

Chrome maintains a cache of connection parameters, SSL session data, and previously established TLS contexts. If a cached entry for a site was created under a previous TLS configuration that differs from the current one, Chrome may attempt to resume or reuse parameters that are no longer compatible, resulting in an interference error. This is more likely after a Chrome update that changed TLS handling, after a site’s server certificate or TLS configuration was updated, or after recovering from a previous SSL error.

To clear Chrome’s cache, press Ctrl + Shift + Delete on Windows or Command + Shift + Delete on Mac. Set the time range to All time, check Cached images and files and Cookies and other site data, then click Clear data. Restart Chrome after clearing.

To clear the SSL state specifically, which Chrome maintains separately from the regular cache, press Win + R on Windows, type inetcpl.cpl, and press Enter to open Internet Properties. Click the Content tab and then the Clear SSL state button. Click OK and restart Chrome.

On Mac, Chrome uses the system keychain for SSL state. Open Keychain Access from Applications, Utilities, select the login keychain, and search for the domain name showing the error. Delete any cached certificate entries for that domain, then restart Chrome.

Fix 6: Update Chrome

Chrome’s TLS implementation is updated with each major release. A version that is several months behind the current release may have known TLS negotiation bugs that were patched in later updates. Updating Chrome resolves these cases immediately.

To update Chrome, click the three-dot menu in the top right, hover over Help, and click About Google Chrome. Chrome checks for updates automatically and installs any available update on this screen. Click Relaunch to apply the update. The About screen shows your current version and whether an update is available or already up to date.

Chrome on Windows and Mac updates automatically in the background. If Chrome is showing as up to date but you are still seeing TLS errors, the issue is not the Chrome version and update is not the fix. Automated updates rarely fall far behind unless the user has actively blocked them.

Fix 7: Reset Chrome Flags to Default

Chrome’s flags page at chrome://flags contains experimental features that are not part of the stable build. If any flags related to TLS, network, or protocol handling were modified manually or by a Chrome extension, they can interfere with standard SSL negotiation. Resetting all flags to their default values returns Chrome’s network stack to its designed production configuration.

Navigate to chrome://flags in the Chrome address bar. At the top of the page, click the Reset all button. Chrome will show a Relaunch button. Click it to restart with all flags at default values. This is a safe operation and does not affect bookmarks, passwords, or saved data.

Fix 8: Create a New Chrome Profile

A corrupted Chrome user profile can produce persistent SSL errors that survive cache clearing, flags reset, and extension removal. The profile stores settings files that Chrome reads at startup, and corruption in any of these can affect TLS behavior. Creating a new profile provides a completely clean configuration.

Click the profile icon in the top right corner of Chrome. Click Add, then choose Continue without an account to create a local profile. In the new profile window, navigate to the page that was showing the error. If it loads without the error in the new profile but fails in the original one, the original profile contains the corruption. You can use Chrome sync to transfer bookmarks and passwords from the old profile. The new profile resolves the issue even if you cannot identify the specific corrupted setting.

If You Are a Site Owner Receiving Reports of This Error

ERR_SSL_VERSION_INTERFERENCE is almost always a client-side error. However, two server-side conditions can contribute to it in specific circumstances.

The first is a TLS configuration that offers only a narrow range of cipher suites or protocol versions, making the negotiation particularly sensitive to any client-side interference. A server that supports only TLS 1.3 with no TLS 1.2 fallback will fail for clients whose TLS 1.3 negotiation is being disrupted by antivirus or VPN software. Adding TLS 1.2 support alongside TLS 1.3 provides a fallback path that many interference scenarios do not block.

The second is a misconfigured TLS 1.3 early data (0-RTT) implementation. If 0-RTT is enabled but implemented incorrectly, the server may accept early data from clients in a way that confuses Chrome’s TLS state machine on reconnection. Disabling 0-RTT on the server resolves cases where ERR_SSL_VERSION_INTERFERENCE appears specifically on repeat visits to a site but not on first connection.

If multiple visitors report the error and they are not all running the same antivirus product, run your server through the SSL Labs test at ssllabs.com/ssltest. The test evaluates your TLS configuration comprehensively and flags protocol range, cipher suite, and 0-RTT configuration issues that could contribute to interference errors on client devices.

Fix Summary: Which to Try First

Frequently Asked Questions

What causes ERR_SSL_VERSION_INTERFERENCE in Chrome?

The error fires when something disrupts Chrome’s TLS version negotiation before a handshake can complete, rather than when the negotiation simply fails due to incompatible versions. Common causes include Chrome’s experimental QUIC protocol conflicting with certain server configurations, antivirus HTTPS scanning software modifying TLS packets in transit, VPN clients altering protocol parameters, hardware acceleration generating malformed packets on certain GPU configurations, and corrupted Chrome flag settings or user profile data.

Is this a server-side error or a client-side error?

In the overwhelming majority of cases, this is a client-side error caused by something on the visitor’s device or network interfering with the TLS handshake. The error would typically show as ERR_SSL_VERSION_OR_CIPHER_MISMATCH if the server genuinely did not support Chrome’s TLS version. If you are a site owner and only some visitors report the error, ask those visitors whether they are running antivirus HTTPS scanning or a VPN, as those are by far the most common sources.

What is QUIC and why does disabling it fix the error?

QUIC is a network transport protocol developed by Google that operates over UDP rather than TCP. It is built into Chrome and used by default for connections to certain services. QUIC implements its own encryption that interacts with TLS at the application layer. On some network configurations, QUIC’s protocol negotiation interferes with standard TLS handshake packets, causing Chrome to report ERR_SSL_VERSION_INTERFERENCE. Disabling QUIC forces Chrome to use standard TCP-based TLS for all connections, eliminating the conflict. The performance impact of disabling QUIC is minimal for most users.

Does ERR_SSL_VERSION_INTERFERENCE mean the website is insecure?

No. The error means Chrome could not complete the TLS negotiation, not that the site has a security vulnerability. You cannot reach the site at all when this error appears, so no data is being exchanged insecurely. The error is a connection failure, not a warning about a site that is reachable but insecure. Once the underlying cause is fixed, the connection establishes normally and the site’s HTTPS encryption works as intended.

The error only appears on one specific site. Why?

Site-specific occurrences point to QUIC as the most likely cause, since QUIC conflicts tend to be server-specific rather than affecting all HTTPS connections. Less commonly, the site may use a TLS configuration that is particularly sensitive to interference from local software on your device. Disable QUIC first using chrome://flags/#enable-quic and reload the site. If that does not resolve it, try the site in an incognito window to check whether an extension or Chrome profile setting is specific to that site.

I see this error only at work, not at home. What does that mean?

Your work network likely has a deep packet inspection appliance, a corporate proxy, or content filtering software that modifies TLS traffic. These systems are common in enterprise environments and can interfere with Chrome’s TLS negotiation when they process connections to sites outside the corporate firewall policy. Contact your IT department with the specific URL and error message. They can check whether the corporate proxy or DPI system is incorrectly handling that connection and whitelist the site if appropriate.