How to Fix ERR_CONNECTION_RESET Error in Chrome

How do you fix ERR_CONNECTION_RESET in Chrome?

At 3 a.m., restarting the server feels like progress. It often is not. To fix ERR_CONNECTION_RESET, I first check whether the problem affects one site or the whole connection. I test the domain over mobile data, compare IPv4 and IPv6 with curl, then inspect DNS, firewalls, proxies, VPNs, and server logs. Chrome or the server gets restarted only after those checks.

What does ERR_CONNECTION_RESET mean?

ERR_CONNECTION_RESET means that the TCP connection between your browser and the web server was closed before the exchange completed. The reset may have come from the server, a firewall, proxy, VPN, DNS-related path, network device, or software on your own computer. If only one site is affected, I start on the server and DNS side. If every site fails, I look at the local network first.

Chrome and other Chromium-based browsers use this message for an unexpected connection reset. It does not prove that the web server is down. A TCP connection may have been established and then terminated when one endpoint or an intermediate device sent an RST packet.

The connection can fail before it reaches the HTTP layer, so the web server’s access log may contain no request at all. That distinction saves time. When there is no log entry, I check DNS, IPv4 and IPv6, firewall rules, and the network path before touching an nginx setting.

Why does ERR_CONNECTION_RESET happen?

The error name comes from the browser, but the cause is often somewhere else. This is where I usually begin:

RFC 9293 describes RST as a TCP control mechanism for aborting a connection unexpectedly. The browser message is the user-facing result of that network event. Saying that the web server definitely sent the reset is too strong.

How can you tell whether the site or your connection is at fault?

Start by narrowing the scope. Open the same domain using mobile data, another Wi-Fi connection, and, if possible, another device. If only your computer is affected, the browser, local DNS, VPN, or security software becomes more likely. If the failure follows the domain across networks, inspect the server, DNS, or hosting side.

These are usually the first commands I run:

dig +short A example.com
dig +short AAAA example.com
curl -IvsS --connect-timeout 10 https://example.com/

The first two commands show the IPv4 and IPv6 addresses. The curl output shows which address was used, whether the TLS handshake started, and where the connection stopped. -I requests only HTTP headers, while -v prints detailed connection information. The verbose output is usually more useful than another browser refresh.

Test both address families separately:

curl -4Iv https://example.com/
curl -6Iv https://example.com/

If curl -4 succeeds but curl -6 ends with a reset, the A record and IPv4 path may be healthy while the AAAA record, IPv6 routing, or the server’s IPv6 listener is wrong. A browser may prefer IPv6, which is why the problem can appear only on certain connections.

What if DNS resolves but the connection still fails?

A correct DNS response does not prove that port 443 is reachable on that address. The domain may point to an old server or an incorrect AAAA record. Some clients can retain an older response until the DNS TTL expires, but calling every DNS problem propagation is not an investigation.

On the server, check the listening ports:

sudo ss -lntp | grep -E ':(80|443)'
sudo systemctl status nginx --no-pager

0.0.0.0:443 generally indicates an IPv4 listener, while [::]:443 indicates an IPv6 listener. If you see only one, compare the DNS records with the addresses and protocols that the service actually supports.

How do you fix ERR_CONNECTION_RESET on the server?

If you can SSH into the server, do not begin by restarting services at random. Record the symptom and its time first. Restarting without reading logs can remove useful evidence, including connection counts, kernel messages, and temporary WAF blocks.

Observe first.

1. Check the nginx or Apache logs

For nginx, watch the access and error logs for the affected site:

sudo tail -f /var/log/nginx/access.log /var/log/nginx/error.log

If the request appears in the access log but the client receives a reset, the problem may be in the proxy, upstream application, or response generation. If there is no entry, the traffic may be stopping before it reaches nginx. On Apache systems, check /var/log/apache2/ or /var/log/httpd/, depending on the distribution.

For recent service messages and a configuration test:

sudo journalctl -u nginx --since '15 minutes ago' --no-pager
sudo nginx -t

nginx -t validates configuration syntax; it does not explain why existing connections dropped. The test can pass while the upstream application has crashed, the file descriptor limit is exhausted, or the kernel is rejecting connections.

2. Check the application service and upstream

If PHP-FPM, Node.js, Python, or another application behind the reverse proxy is not responding, nginx may fail while trying to serve the request. Check the application port and service separately:

sudo ss -lntp
sudo systemctl --failed
sudo journalctl -u php8.2-fpm --since '30 minutes ago' --no-pager

The service name may differ on your system. On Ubuntu, seeing php8.1-fpm or php8.3-fpm is normal. The nginx proxy_pass or fastcgi_pass target must point to a socket or port that is actually listening.

3. Inspect firewall and fail2ban records

If one client is blocked while the site opens from another network, an automated ban becomes more likely. Changing the SSH port is not a security strategy by itself; reading the fail2ban and nftables rules is what reveals an accidental block.

sudo nft list ruleset
sudo fail2ban-client status
sudo fail2ban-client status sshd

On a production system, note the source IP, chain, and counters before removing a rule. Also inspect the WAF, CDN, or hosting panel’s security layer. A client IP on a ban list can explain the reset shown by the browser.

4. Check resource limits and kernel messages

When a web server reaches its file descriptor, memory, or connection queue limits, the failure may look intermittent. These commands do not diagnose the problem alone, but they show where I would look next:

free -h
uptime
sudo dmesg -T | tail -n 80
sudo ss -s

Look in dmesg for out-of-memory events, network driver messages, or connection-table problems. ss -s provides a summary of connection states.

During one night shift, clients reported dropped connections. I initially focused on nginx, but ncdu showed that /var was filling with logs because an application’s logrotate configuration had been forgotten. I corrected the rotation before the filesystem filled completely, then confirmed that new nginx connections returned to normal. Since then, disk usage gets checked as early as CPU usage.

What can you try in Chrome and on the computer?

If the server looks healthy, I work through the client side in this order:

1. Open the page in an incognito window and temporarily disable extensions.
2. Temporarily disable the VPN, corporate proxy, and antivirus HTTPS inspection, then test again.
3. Compare the result with another DNS resolver, but record the current DNS response first.
4. Test another network before restarting the modem or local network equipment.
5. Check the operating system’s date and time and its system proxy settings.

Clearing the browser cache sometimes helps, but it cannot repair a reset at the network layer. If the same URL also resets with curl, the browser cache is probably not the only problem.

Flushing the DNS cache on Windows and Linux

On Windows:

ipconfig /flushdns

On Linux, the command depends on the caching service. With systemd-resolved:

sudo resolvectl flush-caches
resolvectl statistics

These commands clear only the local DNS cache. They do not correct a record pointing to the wrong address; verify the A or AAAA value in the DNS control panel as well.

How do you identify an IPv6-specific failure?

IPv6 problems are easy to miss when IPv4 works. I test the two protocols separately instead of guessing which route the browser selected.

$ curl -4I https://example.test
HTTP/2 200

$ curl -6I https://example.test
curl: (35) Recv failure: Connection reset by peer

This output shows that HTTP headers arrived over IPv4, while the IPv6 connection closed before reaching the TLS or HTTP stage. The AAAA record might still point to an old VPS, the IPv6 firewall rule may be missing, or the web service may listen only on IPv4.

When changing DNS, check the A record, AAAA record, CDN origin address, and the server’s actual listening addresses together. The same principle applies when configuring a subdomain: each hostname must point to the correct IP family and service.

Why can a proxy, VPN, or MTU reset the connection?

A VPN or corporate proxy adds another network layer between your client and the web server. If the tunnel’s MTU is wrong, larger packets may fragment or disappear. Some devices block the ICMP messages needed for path discovery, leaving the browser with a generic reset message.

To get a rough view of the path:

mtr -rwzc 50 example.com

The -r flag selects report mode, -w enables wide output, and -c 50 sets the number of test packets. The packet count matters here. Loss at one intermediate hop is not necessarily real end-to-end loss if later hops show no loss; some routers simply give diagnostic packets low priority. Focus on loss at the final destination rather than blaming the ISP from one row in the table.

If the site opens with the VPN off but resets with it enabled, the VPN exit IP may be blocked, the tunnel MTU may be incompatible, or the proxy may be interfering with TLS. Do not add a permanent sysctl setting for packet sizes without measuring first. I have copied a network tweak to more than one machine before and created a second problem while trying to solve the first.

What should hosting customers check first?

With shared hosting or a VPS, you may not have access to every layer. A support request containing more than the words the site is down usually gets a useful answer faster. Include:

• The full domain and URL where the error appears.
• When it first appeared, including the time zone.
• Results from mobile data, home internet, and VPN testing.
• The results of IPv4 and IPv6 tests.
• Your browser, operating system, and the exact error text.
• Where the connection stops in curl -Iv output.

If you suspect traffic overload or a DDoS event, connection counts and bandwidth also matter. The rate-limiting approach in What Is a DDoS Attack? A Practical VPS Protection Guide is relevant here. Changing a port or rebooting the server does not remove attack traffic.

Before changing site files, prepare a backup and rollback plan. Running nginx -t before a reload is a small habit that prevents a configuration mistake from becoming a longer outage. My production sequence is simple: observe, make one change, test the configuration, and reload in a controlled way.

Which fix applies to each symptom?

Uninstalling and reinstalling Chrome is useful only when the other tests point to the client. The error code alone is not proof of one cause; the same reset message can come from a wrong IPv6 record, a blocked address, or a broken VPN tunnel.

Once I’ve ruled out network and browser issues, I sometimes explore harmless JavaScript experiments; my guide, What Is Google Gravity and How Does It Work?, explains how the effect works in Chrome.

Frequently asked questions

Is ERR_CONNECTION_RESET a sign of malware?

Not by itself. A VPN, antivirus HTTPS inspection, local proxy, firewall, or the remote server can close the connection. If you have other suspicious symptoms, run a separate security scan.

What is the difference between ERR_CONNECTION_RESET and ERR_CONNECTION_REFUSED?

ERR_CONNECTION_REFUSED usually means that the destination did not accept the connection, such as when no service is listening on the port. ERR_CONNECTION_RESET means that an established or partially established connection was closed with an RST. They are different network events presented by the browser.

Will restarting the server fix the error?

It may clear a temporary service lockup, but it does not remove the root cause. Save nginx, application, firewall, and kernel logs first, or the restart may erase the evidence needed to diagnose the failure.

What should I do if ERR_CONNECTION_RESET affects only one website?

Check the domain’s A and AAAA records, then compare mobile data with IPv4 and IPv6 tests. If other sites work but this domain fails across networks, the site owner or hosting provider should inspect the server, CDN, and firewall logs.

My first instinct used to be a restart. Now I want one useful fact before touching anything: an address family that fails, a log line, or a packet path that stops somewhere. That small pause has saved me more than once.

Sources

• RFC 9293 – Transmission Control Protocol — rfc-editor.org
• nginx Documentation — nginx.org