How to Fix the SSL_ERROR_RX_RECORD_TOO_LONG Error in Firefox

What This Error Actually Means (and Why the Name Is Misleading)

SSL_ERROR_RX_RECORD_TOO_LONG is a Firefox-specific error code. The name suggests a data size problem, but the actual cause is almost never about size. Understanding why the error has this name makes the cause immediately clear.

When Firefox connects to an HTTPS URL, it expects to receive a TLS handshake: specifically a TLS record starting with the byte 0x16 (the TLS handshake content type), followed by a TLS version, and then a two-byte length field specifying how much data follows. This is the standard structure of every TLS record.

When a server is misconfigured to serve plain HTTP on port 443 instead of HTTPS, the server sends back a plain HTTP response. The first bytes of an HTTP response look something like: HTTP/1.1 200 OK. Firefox’s TLS layer is reading these bytes looking for a TLS record. The byte ‘H’ (the start of ‘HTTP’) is interpreted as the content type field. In ASCII, ‘H’ is decimal 72. TLS content types only use values 20-23. Firefox sees 72 and tries to continue parsing it as a TLS record. The two following bytes (‘TT’ from ‘HTTP’) become the length field. The length comes out as a large, nonsensical number. Firefox reports: record too long.

The error is not saying the TLS record data is too big. It is saying that Firefox received something that is not a TLS record at all, and when it tried to parse it as one anyway, the apparent length was absurdly large. The root cause is plain HTTP being served on a port where TLS is expected.

The same underlying server misconfiguration produces different error messages in different browsers. Firefox shows SSL_ERROR_RX_RECORD_TOO_LONG. Chrome shows ERR_SSL_PROTOCOL_ERROR. Safari shows a connection failure without a specific error code. Edge follows Chrome’s behavior. If you are a site owner receiving error reports that mention both SSL_ERROR_RX_RECORD_TOO_LONG (from Firefox users) and ERR_SSL_PROTOCOL_ERROR (from Chrome users) simultaneously, both point to the same server configuration problem.

The Four Causes in Order of Frequency

If You Are a Visitor: What You Can Try

This error is caused by the website’s server configuration in the vast majority of cases. As a visitor, you cannot fix the server. However, a small number of visitor-side causes exist, and these checks are worth trying before concluding the site is broken.

Check whether the problem is just this one site

Try loading several other HTTPS websites. If they load fine and only this specific site shows the error, the problem is almost certainly on the server side. Contact the site owner or webmaster and tell them you are seeing SSL_ERROR_RX_RECORD_TOO_LONG in Firefox.

If many HTTPS sites are failing, proceed to the browser and network checks below.

Disable HTTPS inspection in antivirus or security software

Antivirus products with web protection features (Kaspersky, Avast, Bitdefender, ESET, Norton with HTTPS scanning) intercept TLS connections and re-encrypt them for inspection. If this interception is misconfigured or incompatible with the current Firefox version, it can produce malformed TLS records and trigger this error.

To test: temporarily disable your antivirus product’s web protection or HTTPS scanning feature (not the entire antivirus, just the HTTP/HTTPS scanning component). Reload the page. If the error disappears, the antivirus interception is the cause. Update the antivirus software, configure it to exclude Firefox from HTTPS inspection, or report the incompatibility to the antivirus vendor.

Check proxy settings

On corporate networks, a proxy server may be handling HTTPS traffic in a way that causes this error. In Firefox, go to Settings, search for Proxy, and click Settings in the Network Settings section. If a manual proxy is configured, try switching to No proxy or Use system proxy settings and reload the page. If the error clears, the proxy configuration is the cause, and this is an issue for your IT department.

Clear Firefox cache and try a private window

In rare cases, a corrupted cached response can trigger unexpected errors. Press Ctrl+Shift+Delete in Firefox, select Everything for the time range, check Cached Web Content and Cookies, and click Clear. Then try the URL again. Alternatively, open a private browsing window (Ctrl+Shift+P) and try the URL there. If it loads in private browsing but not in your regular window, a cache or extension issue is likely.

Disable Firefox extensions

Extensions that modify network requests or add HTTPS filtering can interfere with TLS handshakes. In Firefox, type about:addons in the address bar and disable all extensions. Reload the page. If the error clears, re-enable extensions one at a time to find the conflicting one.

If You Are the Site Owner: The Actual Fixes

If your own site is showing this error, or if your server is generating this error for visitors, the fix is always in the server configuration. These are the three most common specific misconfigurations and their fixes.

Fix 1: Nginx: missing the ‘ssl’ keyword on the listen directive

This is the single most common specific misconfiguration that causes this error in Nginx. The difference between these two configurations is one word:

Incorrect (causes SSL_ERROR_RX_RECORD_TOO_LONG): listen 443; — This tells Nginx to listen on port 443, but it does not enable SSL. Nginx serves plain HTTP on port 443. Firefox connects expecting TLS and receives plain HTTP instead.

Correct: listen 443 ssl; — This tells Nginx to listen on port 443 with SSL enabled. Nginx serves HTTPS on port 443.

Check your Nginx virtual host configuration file (typically in /etc/nginx/sites-available/ or /etc/nginx/conf.d/). Find the server block for your domain. Ensure the listen directive for port 443 includes the ssl keyword. The full minimal correct Nginx HTTPS configuration also requires ssl_certificate and ssl_certificate_key directives pointing to the certificate and private key files.

After making the change, test the configuration with nginx -t and reload Nginx with systemctl reload nginx or nginx -s reload.

On Nginx 1.15.0 and later (released 2018), you can also use the http2 parameter on the listen directive: listen 443 ssl http2; to enable HTTP/2 alongside HTTPS. This does not affect the SSL_ERROR_RX_RECORD_TOO_LONG error but is the recommended modern configuration.

Fix 2: Apache: SSLEngine not enabled

In Apache, HTTPS is enabled by the mod_ssl module and the SSLEngine on directive inside the VirtualHost block. A VirtualHost that listens on port 443 without SSLEngine on configured will serve plain HTTP on port 443, causing this error.

The correct Apache HTTPS VirtualHost block includes: VirtualHost *:443 as the opening tag, SSLEngine on as a directive inside it, SSLCertificateFile pointing to the certificate file, and SSLCertificateKeyFile pointing to the private key. If SSLEngine on is missing, Apache listens on port 443 without SSL. The fix is to add SSLEngine on to the VirtualHost block and restart Apache.

Also verify that mod_ssl is loaded: on Debian/Ubuntu systems, run a2enmod ssl and restart Apache. On Red Hat/CentOS systems, ensure mod_ssl is installed.

Fix 3: HTTP redirect points to HTTPS but HTTPS is not configured

A common setup error: a redirect rule in the port 80 virtual host sends all HTTP traffic to https://yourdomain.com, but the port 443 virtual host does not exist or is not configured with SSL. Traffic arriving at port 443 finds either no virtual host or one without SSL configured.

The redirect alone is not sufficient. Both the HTTP-to-HTTPS redirect and the working HTTPS virtual host must be present. Check that you have a properly configured server block or VirtualHost for port 443 with SSL enabled, in addition to the redirect from port 80.

To verify quickly whether port 443 is actually serving SSL, use the curl command: curl -v https://yourdomain.com and the -v (verbose) output shows the TLS handshake as it happens. If the first line after connecting says something like SSL_ERROR_HANDSHAKE_FAILURE or shows an HTTP response header, the server is serving plain HTTP on port 443. If it shows TLS negotiation (certificate exchange, cipher selection), the SSL layer is at least initiating correctly.

Fix 4: Hosting panel: AutoSSL not completed or SSL not bound

On shared hosting with cPanel or Plesk, SSL certificates are managed through the hosting panel. If AutoSSL ran but did not complete, or if you uploaded a certificate manually but did not correctly bind it to the domain, the domain may serve HTTP on port 443.

In cPanel: go to SSL/TLS, then Manage SSL Sites. Verify your domain appears in the list with a valid certificate shown. If it does not appear, install the certificate. If it appears but the certificate information is blank or shows an error, remove and reinstall.

In Plesk: go to Websites and Domains, then SSL/TLS Certificates for your domain. Verify the certificate is assigned to the domain. If Let’s Encrypt shows a failed issuance, check the error log and try reissuing.

Quick Diagnosis: Which Fix Applies to You?

Frequently Asked Questions

What does SSL_ERROR_RX_RECORD_TOO_LONG mean?

This Firefox error means Firefox connected to port 443 expecting a TLS handshake but received something that did not follow TLS record formatting. Most commonly, the server is configured to serve plain HTTP on port 443 instead of HTTPS. Firefox tries to parse the plain HTTP response as a TLS record, the apparent record length comes out as a large nonsensical number, and Firefox reports the error as ‘record too long.’ Despite the name, the error is about receiving non-TLS data rather than any actual size limit being exceeded.

Is this a Firefox bug?

No. The error correctly identifies a problem with the server’s TLS configuration. Firefox is stricter than some browsers about expecting valid TLS records on HTTPS connections. Chrome shows the same underlying issue as ERR_SSL_PROTOCOL_ERROR, which is less informative. Firefox’s specific error code is actually more descriptive because it pinpoints exactly what went wrong at the protocol level.

Can I fix SSL_ERROR_RX_RECORD_TOO_LONG without accessing the server?

If you are a visitor with no control over the server, you cannot fix the root cause. You can try the visitor-side checks: disabling antivirus HTTPS inspection, checking proxy settings, clearing the Firefox cache, and disabling extensions. These address the minority of cases where the error originates from visitor-side network interception. If none of these help, the problem is on the server and requires the site owner to reconfigure it.

My site works in Chrome but shows this error in Firefox. What is different?

Chrome uses a different TLS implementation and is more tolerant of certain server misconfigurations that Firefox enforces strictly. When the same server causes SSL_ERROR_RX_RECORD_TOO_LONG in Firefox, Chrome may show ERR_SSL_PROTOCOL_ERROR or in some cases connect successfully despite the misconfiguration. If your site works in Chrome but not Firefox, the most reliable diagnostic is to run the SSL Labs test at ssllabs.com/ssltest, which checks from a neutral external perspective and often identifies the specific configuration issue that Firefox is rejecting.