{"id":523,"date":"2026-09-06T09:18:53","date_gmt":"2026-09-06T09:18:53","guid":{"rendered":"https:\/\/www.vps.tc\/blog\/?p=523"},"modified":"2026-09-06T17:50:14","modified_gmt":"2026-09-06T17:50:14","slug":"err-connection-reset-fix-chrome","status":"publish","type":"post","link":"https:\/\/www.vps.tc\/blog\/en\/err-connection-reset-fix-chrome\/","title":{"rendered":"How to Fix ERR_CONNECTION_RESET Error in Chrome"},"content":{"rendered":"
Table of Contents<\/strong><\/p>\n
    \n
  1. How do you fix ERR_CONNECTION_RESET in Chrome?<\/a><\/li>\n
  2. What does ERR_CONNECTION_RESET mean?<\/a><\/li>\n
  3. Why does ERR_CONNECTION_RESET happen?<\/a><\/li>\n
  4. How can you tell whether the site or your connection is at fault?<\/a><\/li>\n
  5. How do you fix ERR_CONNECTION_RESET on the server?<\/a><\/li>\n
  6. What can you try in Chrome and on the computer?<\/a><\/li>\n
  7. How do you identify an IPv6-specific failure?<\/a><\/li>\n
  8. Why can a proxy, VPN, or MTU reset the connection?<\/a><\/li>\n
  9. What should hosting customers check first?<\/a><\/li>\n
  10. Which fix applies to each symptom?<\/a><\/li>\n
  11. Frequently asked questions<\/a><\/li>\n
  12. Sources<\/a><\/li>\n<\/ol>\n<\/div>\n

    How do you fix ERR_CONNECTION_RESET in Chrome?<\/h2>\n

    At 3 a.m., restarting the server feels like progress. It often is not. To fix ERR_CONNECTION_RESET<\/code>, 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<\/code>, then inspect DNS, firewalls, proxies, VPNs, and server logs. Chrome or the server gets restarted only after those checks.<\/p>\n

    What does ERR_CONNECTION_RESET mean?<\/h2>\n

    ERR_CONNECTION_RESET<\/code> 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.<\/p>\n

    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<\/code> packet.<\/p>\n

    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.<\/p>\n

    Why does ERR_CONNECTION_RESET happen?<\/h2>\n

    The error name comes from the browser, but the cause is often somewhere else. This is where I usually begin:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n
    Possible cause<\/th>\nTypical symptom<\/th>\nFirst check<\/th>\n<\/tr>\n<\/thead>\n
    Server service is down<\/td>\nThe site fails from every network<\/td>\nsystemctl status nginx<\/code> and listening ports<\/td>\n<\/tr>\n
    Firewall or WAF<\/td>\nSome IP addresses cannot connect<\/td>\nnftables, fail2ban, and WAF logs<\/td>\n<\/tr>\n
    Incorrect proxy configuration<\/td>\nThe failure occurs behind a reverse proxy<\/td>\nnginx error log and upstream connection<\/td>\n<\/tr>\n
    IPv6 problem<\/td>\nIPv6 clients fail while IPv4 clients work<\/td>\nCompare curl -4<\/code> and curl -6<\/code><\/td>\n<\/tr>\n
    VPN, router, or ISP<\/td>\nThe same site opens over mobile data<\/td>\nDisable the VPN and test another network<\/td>\n<\/tr>\n
    MTU or routing problem<\/td>\nSmall requests work but some HTTPS requests fail<\/td>\nmtr<\/code>, packet size, and tunnel settings<\/td>\n<\/tr>\n
    Browser extension or damaged cache<\/td>\nThe page opens in an incognito window<\/td>\nDisable extensions and test again<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    RFC 9293 describes RST<\/code> 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.<\/p>\n

    How can you tell whether the site or your connection is at fault?<\/h2>\n

    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.<\/p>\n

    These are usually the first commands I run:<\/p>\n

    dig +short A example.com\ndig +short AAAA example.com\ncurl -IvsS --connect-timeout 10 https:\/\/example.com\/<\/code><\/pre>\n
    The first two commands show the IPv4 and IPv6 addresses. The curl<\/code> output shows which address was used, whether the TLS handshake started, and where the connection stopped. -I<\/code> requests only HTTP headers, while -v<\/code> prints detailed connection information. The verbose output is usually more useful than another browser refresh.<\/p>\n
    Test both address families separately:<\/p>\n
    curl -4Iv https:\/\/example.com\/\ncurl -6Iv https:\/\/example.com\/<\/code><\/pre>\n
    If curl -4<\/code> succeeds but curl -6<\/code> 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.<\/p>\n
    What if DNS resolves but the connection still fails?<\/h3>\n
    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.<\/p>\n
    On the server, check the listening ports:<\/p>\n
    sudo ss -lntp | grep -E ':(80|443)'\nsudo systemctl status nginx --no-pager<\/code><\/pre>\n
    0.0.0.0:443<\/code> generally indicates an IPv4 listener, while [::]:443<\/code> indicates an IPv6 listener. If you see only one, compare the DNS records with the addresses and protocols that the service actually supports.<\/p>\n
    How do you fix ERR_CONNECTION_RESET on the server?<\/h2>\n
    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.<\/p>\n
    Observe first.<\/p>\n
    1. Check the nginx or Apache logs<\/h3>\n
    For nginx, watch the access and error logs for the affected site:<\/p>\n
    sudo tail -f \/var\/log\/nginx\/access.log \/var\/log\/nginx\/error.log<\/code><\/pre>\n
    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\/<\/code> or \/var\/log\/httpd\/<\/code>, depending on the distribution.<\/p>\n
    For recent service messages and a configuration test:<\/p>\n
    sudo journalctl -u nginx --since '15 minutes ago' --no-pager\nsudo nginx -t<\/code><\/pre>\n
    nginx -t<\/code> 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.<\/p>\n
    2. Check the application service and upstream<\/h3>\n
    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:<\/p>\n
    sudo ss -lntp\nsudo systemctl --failed\nsudo journalctl -u php8.2-fpm --since '30 minutes ago' --no-pager<\/code><\/pre>\n
    The service name may differ on your system. On Ubuntu, seeing php8.1-fpm<\/code> or php8.3-fpm<\/code> is normal. The nginx proxy_pass<\/code> or fastcgi_pass<\/code> target must point to a socket or port that is actually listening.<\/p>\n
    3. Inspect firewall and fail2ban records<\/h3>\n
    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.<\/p>\n
    sudo nft list ruleset\nsudo fail2ban-client status\nsudo fail2ban-client status sshd<\/code><\/pre>\n
    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.<\/p>\n
    4. Check resource limits and kernel messages<\/h3>\n
    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:<\/p>\n
    free -h\nuptime\nsudo dmesg -T | tail -n 80\nsudo ss -s<\/code><\/pre>\n
    Look in dmesg<\/code> for out-of-memory events, network driver messages, or connection-table problems. ss -s<\/code> provides a summary of connection states.<\/p>\n
    During one night shift, clients reported dropped connections. I initially focused on nginx, but ncdu<\/code> showed that \/var<\/code> 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.<\/p>\n
    What can you try in Chrome and on the computer?<\/h2>\n
    If the server looks healthy, I work through the client side in this order:<\/p>\n
      \n
    1. Open the page in an incognito window and temporarily disable extensions.<\/li>\n
    2. Temporarily disable the VPN, corporate proxy, and antivirus HTTPS inspection, then test again.<\/li>\n
    3. Compare the result with another DNS resolver, but record the current DNS response first.<\/li>\n
    4. Test another network before restarting the modem or local network equipment.<\/li>\n
    5. Check the operating system’s date and time and its system proxy settings.<\/li>\n<\/ol>\n
      Clearing the browser cache sometimes helps, but it cannot repair a reset at the network layer. If the same URL also resets with curl<\/code>, the browser cache is probably not the only problem.<\/p>\n
      Flushing the DNS cache on Windows and Linux<\/h3>\n
      On Windows:<\/p>\n
      ipconfig \/flushdns<\/code><\/pre>\n
      On Linux, the command depends on the caching service. With systemd-resolved<\/code>:<\/p>\n
      sudo resolvectl flush-caches\nresolvectl statistics<\/code><\/pre>\n
      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.<\/p>\n
      How do you identify an IPv6-specific failure?<\/h2>\n
      IPv6 problems are easy to miss when IPv4 works. I test the two protocols separately instead of guessing which route the browser selected.<\/p>\n
      $ curl -4I https:\/\/example.test\nHTTP\/2 200\n\n$ curl -6I https:\/\/example.test\ncurl: (35) Recv failure: Connection reset by peer<\/code><\/pre>\n
      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.<\/p>\n
      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<\/a><\/em>: each hostname must point to the correct IP family and service.<\/p>\n
      Why can a proxy, VPN, or MTU reset the connection?<\/h2>\n
      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.<\/p>\n
      To get a rough view of the path:<\/p>\n
      mtr -rwzc 50 example.com<\/code><\/pre>\n
      The -r<\/code> flag selects report mode, -w<\/code> enables wide output, and -c 50<\/code> 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.<\/p>\n
      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<\/code> 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.<\/p>\n
      What should hosting customers check first?<\/h2>\n
      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:<\/p>\n