Is PR_CONNECT_RESET_ERROR a certificate problem?

No — and that's the trap, because it can land on the same 'Secure Connection Failed' page that certificate errors use. PR_CONNECT_RESET_ERROR is Firefox's name for NSPR error -5961, 'connection reset by peer.' It means something sent a TCP reset — an RST packet — and killed the connection outright. That happens before or during the TLS handshake, so no certificate was ever evaluated. If the cert were expired or misnamed, you'd get a SEC_ERROR or NET::ERR code that names the certificate. This one names nothing about a cert, because the conversation was cut off before certificates came up. Don't reissue anything; find who pulled the plug.

What's the difference between PR_CONNECT_RESET_ERROR and PR_END_OF_FILE_ERROR?

They're two different ways a connection dies, and the distinction points you at different culprits. PR_END_OF_FILE_ERROR is a graceful close — the other end sent an end-of-file, zero more bytes, and hung up quietly; it's often a middlebox that couldn't parse a large ClientHello. PR_CONNECT_RESET_ERROR is violent — something sent an actual RST packet, the network equivalent of slamming the phone down mid-sentence. A reset is usually a decision: a firewall, filter, or server looked at your connection and actively refused it, rather than failing to handle it. Reset means someone said no on purpose.

It only fails in Firefox, works in Chrome. Why?

The most common Firefox-specific cause is antivirus or security-suite HTTPS scanning. Products like Avast, Kaspersky, Bitdefender, and ESET sit in the middle of your TLS connections to inspect them, injecting their own certificate. Firefox keeps its own trust store separate from Windows, so unless it's been told to trust that injected root (the security.enterprise_roots setting), or the scanning proxy is buggy or overloaded, Firefox rejects the interception and the connection resets — while Chrome, which trusts the OS store, sails through. Same machine, same site, different trust model. Toggle the AV's HTTPS/SSL scanning off and reload to test.

How do I tell whether it's my side or the server?

Ask whether it fails for everyone or just for you. Run an external check against the site from outside your network. If that check connects fine, the server is healthy and the reset is being injected between you and it — antivirus HTTPS scanning, a VPN or proxy, or a corporate/ISP firewall that resets connections by policy once it sees where you're headed. If the external check also gets reset or can't connect, the fault is at the server or its load balancer — an overloaded box, an IP block, or a firewall set to reject-with-reset — and every visitor is hitting it too.

Views: 10

PR_CONNECT_RESET_ERROR Fix Guide (Firefox)

PR_CONNECT_RESET_ERROR: a TCP reset killed the connection — not a bad certificate. Server-side or a middlebox on your side? Find out in 3 checks. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

Firefox shows a “Secure Connection Failed” or “Unable to connect” page with the error code PR_CONNECT_RESET_ERROR, and the site never loads. The same site may open fine in Chrome, or on your phone, or from a different network.

What PR_CONNECT_RESET_ERROR Actually Means

PR_CONNECT_RESET_ERROR is Firefox’s label for NSPR error -5961, “connection reset by peer.” NSPR is the portable runtime under NSS, Firefox’s cryptography and networking library, so this comes from deep in the connection plumbing, not from the web page.

In plain terms: something sent a TCP reset — an RST packet — and the connection died on the spot. A reset is not a timeout and not a graceful close. A timeout is silence; a graceful close is the other end saying “goodbye” and hanging up politely (that’s PR_END_OF_FILE_ERROR). A reset is the network equivalent of slamming the phone down in the middle of a sentence. It is abrupt, and it is almost always deliberate.

That last part is the whole insight. A reset is usually a decision, not a malfunction. The TCP connection opened successfully — the two machines shook hands — and then, the instant real data started flowing, something looked at that data and killed the line. This is exactly how policy-based blocking works: a firewall or filter lets the connection open, waits until the TLS ClientHello reveals which site you’re reaching (the SNI field), and injects an RST to shut it down. So the tell is timing: the connection gets established and then dies the moment you send the first bytes. A server that were simply down would refuse or time out, giving you a different error entirely.

Your job is to find who sent that reset — and whether they’re standing on your side of the wire or the server’s.

The Fork That Decides Everything: You, or Everyone?

Before changing a single setting, answer one question — does this fail for everyone, or just for you? It splits the problem cleanly in half.

If it fails only in your Firefox, or only on your network, the reset is being injected on your side. The usual suspects, in order: antivirus HTTPS scanning (the classic Firefox-only cause), a VPN or proxy, a browser extension that intercepts traffic, or a corporate/ISP firewall that resets connections to certain destinations by policy. The server is fine; something between you and it is saying no.

If it fails for everyone, including an external check run from outside your network, the reset is coming from the server or its load balancer — an overloaded box dropping connections, an IP-level block (a rate limiter or fail2ban has flagged you), or an edge firewall configured to reject-with-reset instead of dropping silently. Then it’s a server-side problem, and every visitor is hitting the same wall.

That single distinction saves you from the classic waste: reinstalling Firefox and clearing certificates for an hour when the real culprit is a security suite or a firewall two hops away — or, in reverse, fighting your own settings when the server has quietly blocked your IP.

Top 3 Causes

Antivirus or security-suite HTTPS scanning (the Firefox-only tell). Suites like Avast, Kaspersky, Bitdefender, and ESET decrypt and re-encrypt your TLS traffic to inspect it. Because Firefox keeps its own trust store separate from Windows, a scanning proxy whose root isn’t trusted by Firefox — or one that’s buggy, expired, or overloaded — gets its interception rejected, and the connection resets. This is the leading reason a site works in Chrome (which trusts the OS store) but resets only in Firefox. The test: turn off the suite’s “HTTPS/SSL scanning” feature and reload.
A firewall, VPN, or ISP resetting by policy. DPI firewalls and content filters commonly allow the TCP connection, read the SNI hostname out of the ClientHello, and inject an RST if the destination is on a blocklist — corporate filtering, campus networks, and national-level censorship all work this way. A VPN or proxy adds a hop that can do the same, or route you through an IP the destination itself rejects. The signature is selective: some sites reset, others load, and switching networks (a phone hotspot) makes the problem move.
The server or its load balancer is sending the reset. If an external check also gets reset, look at the origin. An overloaded server drops connections; a rate limiter or intrusion-prevention tool like fail2ban resets connections from an IP it has flagged; and some edge firewalls are set to reject-with-reset. Here the fix belongs to whoever runs the server — or, if your IP has been temporarily blocked, to waiting out or appealing that block.

Diagnose with DechoNet

HTTP Check — run it against the site from outside your own network. If it connects and returns a status code, the server is up and answering, so the reset is being injected between you and it — antivirus, VPN, or a filtering firewall on your side. Stop debugging the site. If the HTTP check also fails to connect, the fault is server-side and hits every visitor.
Port Check — confirm the port (443 for HTTPS) is actually open and reachable from outside. If it’s open externally but resets for you, that gap is your local middlebox. If it’s filtered or closed for everyone, the block is at the server’s network edge.
SSL Check — if this completes a clean TLS handshake and reads the certificate from outside, the server’s TLS stack is healthy and the failure is specifically on your path, which is consistent with an injected reset rather than a broken server.

Resolution Checklist

Decide the scope first: reproduce in a private window, then in another browser, then via an external HTTP Check. Only-you means local; everyone means server.
If it’s local, turn off your antivirus/security-suite “HTTPS/SSL scanning” and reload. If that fixes it, update or reconfigure the tool rather than leaving inspection off for good — or add its root to Firefox’s trust (security.enterprise_roots.enabled).
Disable any VPN, proxy, or traffic-intercepting extension, then reload. Test in Firefox’s Troubleshoot Mode to rule out extensions cleanly.
Try a completely different network — a phone hotspot. If the site loads there, the original network’s firewall or filter is resetting the connection, and that’s an IT/network-team matter, not a browser setting.
If the external checks also fail, hand it to the server owner: look at load-balancer health, connection limits, and any IP-based blocking (rate limiter or fail2ban) that might be resetting your address.
Re-run the HTTP Check after any change to confirm the connection now completes instead of resetting.

When to Escalate

If external HTTP, port, and SSL checks all get reset or can’t connect, the problem is the server’s network edge or load balancer, and no browser-side change will fix it — escalate to whoever operates the origin.
If the reset is isolated to a corporate or campus network, a DPI firewall or content filter there is injecting it by policy. That’s a network-team decision, not something a user reconfigures from the browser.
Compare with the closely related “connection cut” conditions when you’re mapping the failure: ERR_CONNECTION_RESET is Chrome’s exact equivalent of this error, ERR_CONNECTION_CLOSED is the graceful-close sibling, and if your own IP is the one being reset, Your IP Has Been Temporarily Blocked covers the rate-limit and fail2ban case.