Fixing Nginx SSL_ERROR_RX_RECORD_TOO_LONG: The Complete Guide

TL;DR: The Quick Fix

This error usually boils down to a simple misunderstanding: Nginx is speaking plain HTTP while your browser is expecting the encrypted handshake of HTTPS. The most common fix is adding the ssl parameter to your listen directive.

# THE WRONG WAY
server {
    listen 443;
    server_name example.com;
    ...
}

# THE RIGHT WAY
server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;
    ...
}

Once you've updated the file, run nginx -t to check for syntax errors and apply the changes with systemctl reload nginx.

What actually causes SSL_ERROR_RX_RECORD_TOO_LONG?

Whether you see SSL_ERROR_RX_RECORD_TOO_LONG in Firefox or ERR_SSL_PROTOCOL_ERROR in Chrome, the root cause is a protocol mismatch. Your browser sends a "Client Hello" to start a TLS handshake, fully expecting an encrypted response.

Instead, your server replies with plain text—often a 404 page or a 301 redirect. The browser tries to read the first few bytes of that plain text as a TLS record length. Because ASCII characters like "HTTP" translate to massive numbers in binary, the browser assumes the record is giant and hits a hard limit. In technical terms, the response exceeds the standard 16,384-byte TLS record maximum.

Common Fixes

1. Add the 'ssl' Parameter to Listen

Nginx is literal. It won't assume port 443 needs encryption just because it's the industry standard. You must explicitly toggle the SSL engine for that specific socket.

server {
    listen 443 ssl; # This 'ssl' tag is mandatory
    server_name myapp.io;

    ssl_certificate /etc/letsencrypt/live/myapp.io/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/myapp.io/privkey.pem;

    # ... rest of your config
}

2. Resolve Default Server Conflicts

If your /etc/nginx/sites-enabled/ directory contains multiple files, one might be acting as a default_server for port 443 without SSL enabled. Nginx might be catching your request in that "plain" block before it ever reaches your actual site configuration.

Scan your configuration for every instance of port 443:

grep -r "443" /etc/nginx/sites-enabled/

Every block listening on 443 must have the ssl parameter. If one is missing it, you've found your culprit.

3. Avoid the Port 80 SSL Trap

I've seen developers accidentally force SSL on port 80 when copying templates. If your config says listen 80 ssl;, and you visit https://yourdomain.com (which defaults to port 443), you'll get a connection failure. However, hitting https://yourdomain.com:80 will trigger the record length error immediately.

4. Fix Cloudflare "Flexible" Mode Loops

Cloudflare users frequently hit this when their SSL/TLS setting is set to "Flexible." In this mode, Cloudflare talks to your Nginx server over port 80. If your Nginx config is set to automatically redirect all port 80 traffic to HTTPS, you create a protocol loop. For any server with a valid certificate (like Let's Encrypt), switch Cloudflare to "Full (strict)" mode to ensure end-to-end encryption.

5. Check Your Proxy Pass Logic

While less common, this can happen if Nginx is a reverse proxy. If you try to proxy an HTTPS request to a backend that only understands HTTP—or vice versa—without correctly handling the headers, the response can become garbled. Usually, though, the error happens during the very first connection between the browser and Nginx.

Verification Steps

Browser caches are stubborn and can hide your progress. Use curl to see exactly what the server is spitting out.

Step 1: Run a Verbose Test

curl -v https://example.com

Look at the output. If you see TLS handshake, Client hello followed by a 400 Bad Request or a plain HTML snippet, the protocol mismatch is confirmed.

Step 2: Force HTTP on the SSL Port

Test if the server is improperly serving plain text on the secure port:

curl http://example.com:443

If this returns a 200 OK or a 301 Redirect, your Nginx config is definitely broken. It should refuse to serve plain HTTP on port 443.

Step 3: Confirm the Process

sudo ss -tulpn | grep :443

Make sure nginx is the process actually listening on that port and not a stray service or a Docker container bound to the same host port.

Further Reading

- [Nginx Official Docs: Configuring HTTPS](https://nginx.org/en/docs/http/configuring_https_servers.html)
- [Let's Encrypt: Using Certbot with Nginx](https://letsencrypt.org/docs/getting-started/)