PR_END_OF_FILE_ERROR in Firefox: what cuts the secure connection and how to fix it

Short answer: PR_END_OF_FILE_ERROR means Firefox started a secure (TLS) connection and the other side closed it before the handshake finished, without an error message. If every HTTPS site fails, a proxy, VPN, antivirus or changed Firefox setting is cutting the connection. If one site fails for everyone, its server has no working TLS setup for that name.

Secure Connection Failed

An error occurred during a connection to example.com. PR_END_OF_FILE_ERROR

Error code: PR_END_OF_FILE_ERROR

Start with one test that tells you whose problem it is: open the same address on a phone over mobile data, Wi-Fi off. Then use the table.

What the error actually means

Firefox uses Mozilla’s NSS library for TLS, and NSS reports an end of file when the connection is closed while it still waits for the server’s part of the handshake. No TLS alert arrived to say why, which is what makes this error vague. A server that refuses properly sends an alert, and Firefox then shows a more specific code. Here is how the same failures look in other clients:

The curl lines in the first three rows are real output from curl 7.88.1 with OpenSSL 3.0.22 on Debian 12, against local test listeners that hang up, reset or answer in plain HTTP. Failures with an alert, such as no common cipher or an unknown name, are covered in SSL handshake failed.

Visitor fixes: when only you see it

Work down the list and reload the page after each step.

• Proxy settings. In Firefox, open Settings, General, scroll to Network Settings and click Settings. Choose No proxy for a test. If it was set to Use system proxy settings, also check the proxy in your operating system. A proxy that is gone, or one that cannot pass HTTPS through, ends every handshake this way.
• VPN. Disconnect, or switch to another server. Some VPN apps filter traffic (ad or malware blocking), and some sites drop connections from VPN addresses.
• Antivirus or security suite with HTTPS scanning. These sit in the middle of every TLS connection. Look for a setting named like HTTPS scanning, Scan encrypted connections or SSL/TLS protocol filtering and switch it off for a test. If that fixes it, update the product or leave the option off. Parental control software and company TLS inspection do the same.
• Router or company firewall. If the error only happens on one network, the filter is there. Old firewalls also choke on the larger first handshake message that current Firefox and Chrome versions send since they added a post-quantum key share. A firmware update is the fix.
• DNS over HTTPS. Under Settings, Privacy & Security, set DNS over HTTPS to Off for one test. A different resolver can send Firefox to a different server address than your other browsers use.

Firefox settings and profile

If only Firefox fails, the cause is in its configuration. Open about:config, accept the warning and search for security.tls.version. The defaults in current Firefox are security.tls.version.min 3 (TLS 1.2) and security.tls.version.max 4 (TLS 1.3). Then search for security.ssl3., the switches for single cipher suites. Changed preferences are shown in bold, with a reset button at the end of the row. Reset every TLS one you did not change on purpose; privacy hardening files often switch off ciphers that some servers still need.

If that is not it, rule out add-ons and the profile:

• Troubleshoot Mode restarts Firefox with add-ons and some settings off: menu, Help, Troubleshoot Mode. If the site loads there, re-enable the add-ons one by one in normal mode.
• A fresh profile tests everything at once: about:profiles, Create a New Profile, then launch it. If the site works in the new profile, Refresh Firefox on about:support resets the old one while keeping bookmarks, history and passwords.

Site owner: reproduce it from outside

If the site fails on every device, run the handshake yourself. Use the name visitors use, because servers pick the certificate by that name (SNI):

# Does the handshake complete for this name?
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>&1 \
  | grep -E 'error|errno|handshake has read|subject='

# The same without a name: works without SNI but not with it = no setup for this name
openssl s_client -connect example.com:443 -noservername </dev/null 2>&1 | grep -E 'error|subject='

# Both address families, they can end on different servers
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://example.com/
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://example.com/

A working server prints the certificate’s subject and reads a few thousand bytes. This is what a hang-up looks like, from a local listener that reads the ClientHello and closes the connection (Debian 12, OpenSSL 3.0.22):

40B71A89647F0000:error:0A000126:SSL routines:ssl3_read_n:unexpected eof while reading:../ssl/record/rec_layer_s3.c:318:
CONNECTED(00000003)
SSL handshake has read 0 bytes and written 328 bytes

CONNECTED means TCP worked; read 0 bytes means the server sent nothing back before closing, and unexpected eof while reading is OpenSSL’s name for what Firefox calls PR_END_OF_FILE_ERROR. A reset shows write:errno=104 instead, and plain HTTP on the port shows wrong version number after reading 5 bytes. More s_client options are in the openssl commands guide.

Without a shell, the SSL checker runs the handshake to port 443 from our test server in Amsterdam, outside your network, and shows whether it completes.

Causes on the server side

No TLS setup for that name

The most common server-side cause: something accepts connections on port 443, finds nothing configured for the requested name and hangs up. Typical cases are a new subdomain that points at the server before it has a server block and a certificate, and an SNI router (nginx stream with ssl_preread, or a TCP load balancer) with no route for that name. Older nginx versions also closed the connection when the default server on a TLS port had no certificate, and logged no "ssl_certificate" is defined in server listening on SSL port while SSL handshaking; current versions refuse a TLS server block without a certificate (or ssl_reject_handshake) already at nginx -t.

Fix it by giving every name a server block with its certificate, as in the nginx reverse proxy and SSL guide. For names you do not serve, a catch-all block (nginx 1.19.4 or later) refuses the handshake with an explicit alert instead of a silent close:

server {
    listen 443 ssl default_server;
    listen [::]:443 ssl default_server;
    ssl_reject_handshake on;
}

sudo nginx -t && sudo systemctl reload nginx

Firefox then shows SSL_ERROR_UNRECOGNIZED_NAME_ALERT for a name you never set up, which says clearly what is missing. This config is written from nginx.org’s documentation of ssl_reject_handshake.

Something other than TLS on port 443

A plain HTTP server on 443 usually answers with an HTTP error page, which Firefox reports as SSL_ERROR_RX_RECORD_TOO_LONG. You get PR_END_OF_FILE_ERROR instead when the service on the port reads the handshake, does not understand it and closes without a word. Check what really listens:

sudo ss -tlnp 'sport = :443'

The process name should be your web server or proxy. The open ports guide explains the output. If an IPv6 address is involved, check both lines: a server can serve TLS on IPv4 and something else on [::]:443.

A proxy, load balancer or firewall in front

When the domain points at a CDN, a WAF or a load balancer, Firefox’s handshake is with that layer, not with your server. A TCP load balancer with no healthy backend, or bot and DDoS protection that drops handshakes from certain networks or clients, produces exactly this error for some visitors and not for others. Test your server directly by connecting to its IP address with the site’s name as SNI:

openssl s_client -connect 203.0.113.10:443 -servername example.com </dev/null 2>&1 | grep -E 'error|subject='

If that works, the layer in front is cutting the connection, and its logs or its support are the place to look.

Old devices that only speak TLS 1.0 or 1.1

Admin pages of old routers, printers, NAS boxes and other appliances may only speak TLS 1.0 or 1.1, which Firefox no longer offers by default. Some answer with an alert, others simply close the connection. A firmware update is the real fix. If there is none, put a reverse proxy with a current TLS setup in front of the device instead of lowering security.tls.version.min for every site you visit.

After the fix

Test every name the site uses, with and without www, over IPv4 and IPv6, from outside your own network, then reload it in Firefox. On a VPS or dedicated server you run the TLS endpoint yourself, so the checklist is short: one server block and certificate per name, a catch-all that refuses unknown names, and an outside check after each change.

Frequently asked