Skip to content

ERR_QUIC_HANDSHAKE_FAILED

Key idea:

ERR_QUIC_HANDSHAKE_FAILED — initial cryptographic handshake in QUIC failed. QUIC uses TLS 1.3 (mandatory), so all TLS 1.3 handshake errors can manifest. Usually: server cert invalid/expired, client does not support required cipher, ALPN negotiation failed (server does not advertise h3). Fix: verify cert + enable modern ciphers + correct ALPN.

Below: causes, fixes, FAQ.

Check your site's SSL →

Common Causes

  • TLS 1.3 cert invalid (expired, wrong SAN, missing intermediate)
  • Server does not support QUIC v1 (draft versions deprecated)
  • ALPN h3 not advertised in server hello
  • Cipher suite mismatch (QUIC requires TLS_AES_128_GCM_SHA256 minimum)
  • X25519 curve disabled in server OpenSSL

Step-by-Step Fix

  1. Verify cert: Enterno SSL Checker
  2. nginx QUIC: ssl_protocols TLSv1.3; (not TLSv1.2)
  3. Enable modern ciphers: ssl_ciphers TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384;
  4. Check ALPN: openssl s_client -connect host:443 -alpn h3
  5. Curl test: curl --http3 https://example.com -v

Check SSL Certificate →

Related SSL Errors

TL;DR: Understanding ERR_QUIC_HANDSHAKE_FAILED

The ERR_QUIC_HANDSHAKE_FAILED error indicates a failure during the QUIC protocol's initial handshake, which is crucial for establishing a secure connection. This typically occurs due to issues like network misconfigurations, server incompatibilities, or firewall settings blocking UDP traffic. To resolve this, check your server's QUIC configuration, ensure correct firewall settings, and verify that both client and server support QUIC.

Technical Insights into QUIC Handshake Mechanism

The QUIC (Quick UDP Internet Connections) protocol, developed by Google, is designed to improve web performance by reducing latency during connection establishment. Unlike traditional TCP, QUIC operates over UDP and incorporates built-in encryption, making it faster and more secure. The handshake process involves several key steps:

  1. Initial Handshake: The client sends an Initial packet to the server, which includes the client's cryptographic parameters.
  2. Server Response: The server replies with its own parameters and a ServerHello packet, potentially including a Retry packet if the initial packet is received out of order.
  3. Finalizing Handshake: The client and server exchange Finished packets to confirm that both parties are synchronized and agree on the encryption keys.

Common causes of the ERR_QUIC_HANDSHAKE_FAILED error include:

  • Server not configured for QUIC
  • Firewall settings blocking UDP traffic
  • Incompatible client/server QUIC versions
  • Network issues leading to packet loss

To troubleshoot, verify server settings using commands such as:

curl -v --http3 https://example.com

This command checks if the server supports QUIC. If QUIC is enabled, the output should indicate HTTP/3 support. If not, review server configurations, focusing on the nginx.conf or httpd.conf files, depending on your server setup.

Practical Steps for Resolving ERR_QUIC_HANDSHAKE_FAILED

To effectively resolve the ERR_QUIC_HANDSHAKE_FAILED error, follow these systematic steps:

  1. Check Server Configuration: Ensure that your server is correctly set up to handle QUIC connections. For example, in Nginx, you need to enable HTTP/3 and specify the QUIC protocol:
  2. server { listen 443 quic; listen [::]:443 quic; ... } 
  3. Update Firewall Rules: Confirm that your firewall allows UDP traffic on port 443. For Linux systems, use:
  4. sudo iptables -A INPUT -p udp --dport 443 -j ACCEPT
  5. Verify QUIC Version Compatibility: Ensure both client and server support the same version of QUIC. You can find the supported versions in the server documentation or by checking the QUIC_VERSION variable in your server's configuration.
  6. Test Network Stability: Use tools such as ping or traceroute to monitor for packet loss or high latency that could disrupt the handshake process:
  7. ping example.com
  8. Review Browser Settings: If you’re testing in Chrome, ensure that QUIC is enabled. You can check this by navigating to chrome://flags/#enable-quic and ensuring it is set to Enabled.

After making these adjustments, retest the connection. If the error persists, consider consulting server logs for more detailed error messages that may provide further insight into the handshake failure.

CertificateExpiry, issuer, domains (SAN)
ChainIntermediate and root CA validation
TLS ProtocolTLS version and cipher suite
VulnerabilitiesHeartbleed, POODLE, weak ciphers

Why teams trust us

TLS 1.3
supported
Full
CA chain check
<2s
result
30/14/7
days-to-expiry alerts

How it works

1

Enter domain

2

TLS chain verified

3

Expiry date & vulnerabilities

What Does the SSL Check Cover?

SSL/TLS is the encryption protocol that protects data between the browser and server. Our tool analyzes the certificate, chain of trust, TLS version, and knownvulnerabilities.

Certificate Details

Issuer, validity period, signature algorithm, covered domains (SAN), and validation type (DV/OV/EV).

Chain of Trust

Full chain verification: from leaf certificate through intermediates to root CA.

TLS Analysis

Protocol version (TLS 1.2/1.3), cipher suites, Perfect Forward Secrecy (PFS) support.

Expiry Alerts

Set up a monitor — get Telegram and email alerts 30/14/7 days before expiration.

DV vs OV vs EV Certificates

DV (Domain Validation)
  • Confirms domain ownership only
  • Issued in minutes automatically
  • Free via Let's Encrypt
  • Suitable for most websites
  • Most common certificate type
OV / EV
  • Organization (OV) or Extended Validation (EV)
  • Issued in 1-5 business days
  • Costs $50 to $500/year
  • For finance, e-commerce, government sites
  • Increases user trust

Who uses this

DevOps

SSL certificate monitoring

Security

TLS config audit

SEO

HTTPS as ranking factor

E-commerce

customer trust

Common Mistakes

Expired certificateBrowsers block sites with expired SSL. Set up auto-renewal or monitoring.
Incomplete certificate chainWithout intermediate CA, some browsers and bots cannot verify the certificate.
Mixed content on HTTPS siteHTTP resources on an HTTPS page — the browser lock icon disappears, reducing trust.
Using TLS 1.0/1.1Legacy TLS versions have known vulnerabilities. Use TLS 1.2+ or 1.3.
Domain mismatch in certificateThe certificate must cover all site domains, including www and subdomains.

Best Practices

Set up auto-renewalLet's Encrypt + certbot with cron — certificate renews automatically every 60-90 days.
Enable HSTSStrict-Transport-Security header forces browsers to always use HTTPS.
Use TLS 1.3TLS 1.3 is faster (1-RTT handshake) and safer — legacy ciphers removed.
Monitor expiration datesCreate a monitor on Enterno.io — get notified well before expiration.
Verify chain after renewalAfter certificate renewal, confirm that intermediate certificates are installed.

Get more with a free account

SSL certificate monitoring, check history and alerts 30 days before expiry.

Sign up free

Learn more

Sources

Frequently Asked Questions

TLS 1.2 in QUIC possible?

No. QUIC v1 (RFC 9000) mandates TLS 1.3. If no TLS 1.3 on server — QUIC impossible.

Are draft QUIC versions deprecated?

Yes, draft-29, draft-33 deprecated in 2022. Chrome v105+ supports only final QUIC v1. Server must upgrade.

Does curl --http3 need a special build?

curl 7.66+ with ngtcp2 and quiche backends. Fedora/Arch — included. macOS brew: <code>brew install curl --HEAD</code>.

Wireshark QUIC?

Wireshark 3.5+ decodes QUIC if TLS keys exported (SSLKEYLOGFILE env). Essential for debugging.

Try the live tool that powered this guide

Free plan — 10 monitors, checks every 5 min, no card required. Upgrade for 1-minute interval and multi-region monitoring.