Connection Reset Error (ERR_CONNECTION_RESET): How to Fix It

What is the connection reset error (ERR_CONNECTION_RESET)?

The connection reset error means the other side of a TCP connection cut it off abruptly by sending a reset (RST) packet. Chrome shows it on the "This site can't be reached" page as ERR_CONNECTION_RESET. Also, a server, firewall, network device or piece of software on your computer ended the connection on purpose.

We are a digital marketing and web team, not a hosting company. In practice, the technical explanations below rest on the Chromium source, RFC 9293, and Google and Microsoft documentation. Our goal is simple: you should understand where the failure starts, and you should know what to tell the right person.

The connection reset error rarely has one cause. So first work out whether the problem sits on your device, on the network or on the server. So the sections below follow that order.

Who should fix the connection reset error: the visitor, the site owner or the server admin?

Responsibility depends on how far the problem reaches. If the site fails only for you, the cause most likely sits on your device or your network. Then, if it fails for everyone, the job moves to the site owner and the server administrator.

You can split the three roles like this:

• Visitor: Checks the browser, antivirus, VPN and network settings, then tries another network.
• Site owner: Confirms the site is down for everyone, recalls recent changes and gives the hosting provider clear facts.
• Server administrator: Reviews the firewall, the web server, the logs and the resource limits.

On shared hosting, the provider plays the administrator role. So if you use cPanel and have no root access, the server commands in this guide belong to your provider, not to you. In that case, the right move is to open a support ticket with the details you collected.

What does a TCP reset (RST) packet actually mean?

TCP is the protocol that opens a connection between two endpoints and carries data in order. RFC 9293 defines the reset bit (RST) as "reset the connection." It is the harshest way to tell the other side to drop a connection right now.

Section 3.5.2 of RFC 9293 explains when a reset goes out. For example, a TCP endpoint in the closed state answers every incoming segment with a reset, except another reset. So a request to a port where nothing listens gets an RST back.

There is one important distinction here. In practice, a normal shutdown uses FIN, and both sides know it happened. An RST is an impolite interruption. So that is why the browser says "the connection was reset" and has no page left to show.

The sender of an RST does not have to be the destination server. A firewall, a load balancer or a filtering device on the path can also generate a reset. In other words, "who sent the reset?" is often the real question behind this guide.

How does ERR_CONNECTION_RESET differ from other connection errors?

Chromium lists its network errors in the net_error_list.h file and gives each a short description. Four similar codes cause the most confusion. Then, the table below summarizes the descriptions from the Chromium source.

In practice, the table says this: ERR_CONNECTION_RESET usually happens after the connection already exists, for example during the TLS handshake or while the request travels. ERR_CONNECTION_REFUSED means the attempt to connect itself failed. Also, a timeout means silence.

Firefox shows similar wording, such as "The connection was reset." Safari uses its own sentence about the server dropping the connection. Still, diagnose by behavior and not by the code, because the same fault can show up with different labels in different browsers.

Is it only you or everyone? How do you tell?

Start by finding out how far the problem reaches. This one step splits all later work in two. In practice, if everyone sees the failure, tweaking your own device is pointless.

Run these three checks in order:

1. Open the site on your phone over mobile data. If it loads while you are off Wi-Fi, the problem lives on your local network.
2. Try another browser, or another computer.
3. Use an outside checker. For example, our is it down tool sends a request from a point outside your network.

If the site opens on mobile data but not on Wi-Fi, suspect the router, the internet provider or a network filter. So if it opens nowhere, the site owner needs to look at the server side.

What is the quick fix order for a visitor facing the connection reset error?

If the problem exists only for you, work from the cheapest test to the most expensive one. That way you avoid changing settings you did not need to change. Then, the usual order looks like this:

1. Reload the page and wait a minute. Short network glitches sometimes clear on their own.
2. Open the page in an Incognito window. If it loads, an extension or the cache probably causes the fault.
3. Turn off your VPN, proxy and security software for a moment and try again.
4. Clear the browser data.
5. On Windows, reset the network stack with the commands further down.
6. Restart the router, or try a different network.

Test after every step. Then you know which step solved the problem. Also, writing that step down will save time if the fault returns. If nothing helps, the cause probably does not sit on your side, so move on to the site owner sections below.

What should you check in Chrome settings and extensions?

Google's Chrome help page suggests trying an Incognito window first when connection errors appear. If the page opens there, an extension or a broken cache usually causes the trouble. That makes sense, because Incognito runs with extensions off by default.

Turn extensions off one by one to find the culprit. In practice, ad blockers, security add-ons and proxy managers are the most common suspects.

Next, clear your browser data. In Chrome, Ctrl+Shift+Delete opens the clearing dialog. Select cached files and cookies, then delete them. So you do not need to wipe your whole history.

If the error stays, try "Reset settings" in Chrome. Also, it disables extensions and returns startup settings to their defaults. Your bookmarks stay in place, but your sessions may end, so expect to sign in again.

How do antivirus, firewalls and HTTPS scanning reset a connection?

Some antivirus and internet security products step into encrypted traffic to inspect it. Google's documentation advises turning off software with "HTTPS protection" or "HTTPS scanning" features for a short test. Also, that software can clash with Chrome's own security checks.

In practice, you will see two scenarios. First, the software treats a connection to one site as harmful and cuts it. Second, the software does not understand newer TLS behavior and breaks the handshake.

Try the following:

• Switch off the web protection or HTTPS scanning feature of your antivirus for a short time.
• Check whether the Windows firewall blocks Chrome.
• If the site opens, add it to the exception list instead of leaving the feature off for good.

Write down the software name and version, because the vendor's support will ask for it. Updating the software also fixes many incompatibilities.

Turn protection back on once the test ends. In practice, leaving security software off costs far more than one unopened site.

Can a VPN or proxy cause a connection reset?

Yes, it can. The exit address of your VPN may sit on a site's firewall block list. The site then cuts the connection because it treats the VPN provider's IP range as automated attack traffic.

Proxy settings can create a similar fault. So a leftover proxy entry from old software may point at a server that no longer exists. In that case every request dies halfway.

To check, do the following:

1. Turn off the VPN and try the site.
2. On Windows, open Settings, Network and Internet, Proxy, and look for a proxy you do not recognize.
3. On a work computer, do not change the proxy yourself. Google's documentation also tells you to contact your administrator for corporate proxy problems.

If the site opens without the VPN, the VPN exit address is the likely cause. Then, choosing another server from your provider is often enough.

What do the DNS and Windows network reset commands do?

Microsoft's support page suggests running the following commands in order, in a Command Prompt window opened as administrator. They reset the TCP/IP stack, renew the IP address and flush the DNS cache.

netsh winsock reset
netsh int ip reset
ipconfig /release
ipconfig /renew
ipconfig /flushdns

Each command has its own job:

• netsh winsock reset returns the Windows socket catalog to its defaults.
• netsh int ip reset resets the TCP/IP configuration.
• ipconfig /release and ipconfig /renew drop your IP address and get a new one.
• ipconfig /flushdns clears the local DNS cache.

You may need to restart the computer afterward. Also remember that these commands affect your local network settings. If you use a static IP, write your settings down first.

This step does not fix every connection reset error. Also, it only helps when the network stack on your own device has broken. If other devices fail too, the commands waste your time.

To check the name resolution side, our DNS lookup tool shows whether your records point at the right IP.

How do you tell if your router, ISP or office network resets the connection?

If the problem appears on one network only, that network is the culprit. Routers, internet provider filters and corporate security devices can reset a connection in the middle of its path.

To find out, change the network with the same computer. In practice, you can use your phone as a hotspot. If the site opens over the hotspot, the problem lives on your home or office network.

At this point, you may want to see where the connection breaks along the path. So Our traceroute guide helps you read where the path stalls. Be careful with the result, though. Then, some devices on the path never answer traceroute probes, and that alone does not mean a problem.

If you sit on an office network and the fault appears only there, send your network administrator or provider the exact time and the site address. Also, do not experiment with device settings on your own.

What phone and tablet steps fix this error?

On mobile devices, the error comes from the same causes as on a desktop. Networks change more often on a phone, though, so short breaks show up more. First, switch between Wi-Fi and mobile data and try again.

Then follow these steps:

1. Turn airplane mode on and off once, so the device reconnects to the network.
2. Turn off any installed VPN or security app and test.
3. Clear the browser cache and site data.
4. Forget the Wi-Fi network and join it again.
5. If possible, open the page in a different browser app.

If the error appears only on one Wi-Fi network, that network is the likely cause. In hotel or cafe networks, for example, a captive portal can cut the connection at first contact. Google's documentation also advises opening a page that starts with "http://" to sign in on such networks.

Can WordPress plugins and themes trigger this error?

Yes, they can trigger it indirectly. Security plugins may read many requests as an attack and block an IP for a while. Caching and redirect plugins can also break connections with wrong rules.

As the site owner, follow this order:

• Recall which plugin, theme or setting you changed before the error began.
• Undo the last change and test the site again.
• Open the blocked IP list of your security plugin and check whether your own address sits there.
• Disable suspect plugins one at a time.

If you cannot log in to the dashboard, you can rename the plugin folder in a file manager or over FTP. In practice, that disables the plugin. Take a backup before you change a live site, though. So Our website backup strategy guide walks you through it.

Which clues should you look for in server logs?

Logs are the most reliable source for the layer where a problem starts. You need to check paths and file names for your distribution and panel, however. cPanel, nginx, Apache and the firewall keep their logs in different places.

The logic is simple and works everywhere. Then, look at the access log for the time of the error:

• If the request never shows up in the log: It never reached the web server. Suspect the firewall, the CDN, the network or the provider layer.
• If the request shows up: It reached the server. This time, inspect the application, the reverse proxy and the resource limits.
• If the error log mentions memory or process limits: Treat the resource problem first.

This split cuts the search in half. Moreover, telling your hosting provider whether the request showed up in the log speeds up the whole support process.

Which server side causes reset connections for site owners?

If everyone sees the failure, the picture changes. The cause most likely sits on the server or one of the layers in front of it. Also, the most common sources are:

• No listening service: The web server crashed or restarts. According to RFC 9293, a request to a closed port gets a reset.
• Firewall or rate limit: An IP that sent many requests got blocked automatically.
• WAF rule: A web application firewall judged a request suspicious and cut the connection.
• TLS configuration: A mismatch in certificate, protocol version or cipher suite breaks the handshake.
• Resource limit: Memory or the connection count ran out, and a process ended.
• Reverse proxy and CDN: The link between the middle layer and the origin server broke.

There is also the case of moves and changes. For example, after a hosting migration, the domain may still point at the old server, where the service could be off, so requests get reset. Compare your DNS records with the new IP for that reason.

The logs tell you which cause applies. So your first job is to note the time when the error began. Then read the logs around that time.

How do you spot a block by the firewall, CSF or ModSecurity?

If the problem hits only you and not other people on the same network, your IP address may sit on a block list. CSF, common on cPanel and VPS servers, blocks an IP automatically when it sees many failed logins or a fast stream of requests. In practice, our CSF guide explains this mechanism in detail.

An administrator with root access can search for the IP address with a CSF command. Note that the IP below comes from a block reserved for documentation.

csf -g 203.0.113.10

The command shows which rule matches the IP. Then, if the block needs to go, use the removal command from the CSF documentation. Opening the wrong IP weakens security.

ModSecurity behaves differently. In most setups, it answers a suspicious request with a 403 and does not reset the connection. Still, depending on the configuration, rules that cut the connection can exist. Also, for details, read our ModSecurity and WAF guide.

How do you check port and service status on the server?

If you manage your own VPS, first confirm that the service actually runs. The commands below are common on Linux servers. In practice, the service name can differ by distribution. For example, you may have apache2 or httpd instead of nginx.

sudo systemctl status nginx
sudo ss -tlnp
sudo nginx -t

The first command shows whether the service is up. The second lists which process listens on which port. The third tests the syntax of the nginx configuration.

To see the behavior from outside, run curl -v https://example.com with your own domain. So the output shows at which stage the connection broke. For the TLS side, use openssl s_client -connect example.com:443 -servername example.com.

If you are not sure what a command does, do not run it. Also, a wrong restart can take down a site that was working.

How do resource limits and connection caps trigger the error?

When server resources run out, the error usually appears with a 5xx code. In some cases, though, the connection dies before the server produces any answer, and the visitor sees a reset.

The typical signs are these:

• Errors grow at busy hours and shrink at night.
• The web server or the application pool has hit its process limit.
• Memory ran out, so the system ended a process.
• Your hosting plan reached its limit for concurrent connections or processes.

When the same resource problems show up as 5xx, read the related guides: the 500 error, 502 Bad Gateway and 503 Service Unavailable. Also, they cover resource limits and upstream faults in more depth.

To learn whether a problem comes from resources, lay the error times over the usage graph. In practice, if errors rise at peak hours, the resource suspicion gets stronger. If they spread at random, a firewall or the network is more likely.

On shared hosting, you cannot change the limits yourself. So if you suspect a resource shortage, send your usage graph and the error times to the provider.

Why do nginx and reverse proxy settings cut connections?

Some servers close a connection on purpose without any answer. The nginx documentation describes this directly: the non-standard code 444 closes a connection without sending a response header. Then, an administrator may use it to drop unwanted requests quickly.

For the visitor, the result looks like an empty response or a connection reset. For example, a wrong rule could push real visitors down this path too. That is why you should test every new blocking rule first.

A reverse proxy adds one more link. Also, even if the proxy in front stays healthy, a broken link to the application server behind it can still show the visitor an error. To find out which layer reset the connection, compare the proxy logs and the application logs for the same time window.

Is it a TLS problem? How do you tell it from SSL errors?

Sometimes the reset arrives during the TLS handshake. If the server does not accept the protocol version or cipher suite the client offers, it cuts the connection. In practice, Chromium even defines a separate code for it: ERR_SSL_VERSION_OR_CIPHER_MISMATCH. That code says the client and server do not support a common protocol version or cipher suite.

This guide does not cover the fix for that error, because it has its own article. Here you only need the difference. So if the code names an SSL mismatch, look at the TLS configuration. If it only says reset, continue down the order above.

You can check quickly whether a certificate is valid with our SSL checker. Then, for the general concepts, our SSL certificate guide is enough.

A DNS fault usually produces one of the DNS_PROBE errors instead. That error family also deserves its own article. In short, if the domain name cannot resolve to an IP, the connection never starts, so no reset appears.

Which cause should you check first for each symptom?

The table below links a symptom you can observe to a likely cause and a first check. Each row is a clue, not a final diagnosis.

Use the table like a checklist. Also, start from the matching row, and if you get no result, move to the next one.

Does the connection reset error hurt SEO and sales?

For a visitor, the problem is an annoyance. For a search engine, it is more serious. Google's network and DNS errors documentation says Google treats network timeouts, connection reset and DNS errors similarly to 5xx server errors. In practice, the same page says that already indexed URLs that stay unreachable can drop out of the index within days.

So a connection reset error is urgent when it affects the crawler as well as single visitors. A firewall rule may block Googlebot by mistake. Google's first recommended step is also to look at your firewall settings and logs.

On e-commerce sites, the effect hits revenue directly. So a broken connection on the cart or checkout page means a lost order. If you want to weigh the technical SEO and infrastructure effect together, take a look at our SEO consulting service.

What should you do to stop the connection reset error from coming back?

Fixing the problem is only half the job. To keep the same error from returning weeks later, you need a few habits. Also, they cost little and only ask for routine.

As a site owner, do the following:

• Monitor your site's availability regularly with an outside tool.
• Test every firewall or WAF rule in a staging setup before you add it.
• Put the certificate expiry date in your calendar and renew early.
• Review your hosting provider's resource usage graph once a month.
• Keep a dated note of every configuration change.

As a visitor, keep your browser and security software up to date. Also remove extensions you no longer use, because each extension is one more layer that can interfere with a connection.

These steps will not bring the error to zero. Still, they speed up your search for the cause when a problem appears, because you have a history to compare against.

We can also fit the diagnosis into one flow. First separate the scope, then check the layers from the outside in.

1. Does everyone see the problem, or only you? Separate the two with mobile data and an outside checker.
2. When only you see it, rule out the browser, extensions, antivirus, VPN and proxy one by one.
3. For one network only, look at the router, the provider and the corporate filter.
4. When everyone sees it, inspect the server service, the firewall and the TLS setup.
5. Find the error time in the logs and, if needed, contact your hosting provider with facts.

This order saves time, because it rules out the most common and cheapest fixes first. After all, the connection reset error is not a mystery. Also, once you find who cut the connection, the fix is usually clear.

When should you hand it to your hosting provider instead of fixing it yourself?

In the following cases, do not step in yourself. Write to your provider instead:

• You use shared hosting and have no root access.
• Everyone sees the error and you changed no configuration.
• You are not sure how to change a firewall or WAF rule.
• The problem appears only at busy hours and you suspect a resource limit.
• Google reports that your site is unreachable.

In the support ticket, give these facts: the time the error first appeared, the affected pages, whether everyone or only some networks see it, and your latest changes. Add a screenshot of the error if you have one. In practice, without this information, the support team has to guess.

If you want help judging the support quality of a provider, our hosting selection guide lists the criteria.