ERR_CONNECTION_REFUSED vs Timed Out vs Reset: What Each Means

Three browser errors look alike but describe very different failures: the connection was refused, it timed out, or it was reset. Each one corresponds to a specific event at the TCP level, and each narrows the cause to a different place. Once you can tell them apart, you can skip half the generic advice online and go straight to the right test.

This guide explains what each error means in network terms, how to confirm it with a command, and the fixes for the server side and the client side.

The 90-second TCP primer

Before a browser can send an HTTP request, it opens a TCP connection with a three-step exchange: the client sends a SYN, the server replies SYN-ACK, and the client confirms with ACK. Only then does HTTP (or TLS, for HTTPS) begin. The three errors correspond to three different ways that sequence can go wrong:

An immediate answer (refused) is more informative than silence (timeout). With a refusal you know the host exists and is awake. With a timeout you know only that you did not hear back.

Browser wording

For ERR_NAME_NOT_RESOLVED, the failure happens earlier, in DNS. See DNS Checker and DNS explained for website owners.

First test: separate DNS from connection

Always confirm the name resolves to the address you expect, or you may debug the wrong server.

dig +short example.com A
dig +short example.com AAAA

Then test the connection itself, bypassing the browser:

nc -vz example.com 443          # TCP only
curl -v --max-time 15 https://example.com/ -o /dev/null

nc -vz prints either succeeded, Connection refused, or hangs until timeout. The same three outcomes map directly to the three errors. For an outside-in view from a different network, the Port Checker tests whether a port accepts connections, and the Website Health Check runs a broader set of tests.

ERR_CONNECTION_REFUSED

A refused connection means the destination operating system replied "no one is listening on that port". The server machine is up and reachable.

Server-side causes

• The web server is stopped or crashed. Check it and its logs:

sudo systemctl status nginx          # or apache2, httpd, caddy
sudo journalctl -u nginx --since "30 min ago"
sudo nginx -t                        # a bad config can stop it restarting

• It is listening on the wrong address or port. Many setups bind to 127.0.0.1 only. Confirm:

sudo ss -tlnp | grep -E ':80|:443'

If the local address column shows 127.0.0.1:443 instead of 0.0.0.0:443 or [::]:443, outside connections will be refused.

• A firewall is configured to REJECT rather than DROP. ufw status, iptables -S, nft list ruleset, or the cloud provider's security group will show it.
• A container or app port is not published. In Docker, the container may be running without -p 443:443.
• A wrong IP in DNS. The record points to a machine that is up but runs no web server.

Client-side causes

If only you see refusals, consider a local firewall, an antivirus HTTPS filter, a leftover proxy setting, or a development server that you expected to run on localhost:3000 but did not start. For local dev, a refusal on localhost simply means the process is not running.

ERR_CONNECTION_TIMED_OUT

A timeout means silence. Your SYN went out and nothing came back before the client gave up, typically after tens of seconds.

Causes

• Host offline or the network path is broken. The server is powered off, suspended, or its provider has a network issue.
• A firewall silently drops the traffic. This is the most common reason a running server times out. Default cloud security groups drop inbound traffic that is not explicitly allowed, so a new instance with port 443 unopened times out. Host firewalls using DROP behave the same way.
• Your IP is blocked. fail2ban, a WAF or hosting provider may drop traffic from specific addresses. Test from another network.
• Overloaded server. When the accept queue is full, new SYNs may be ignored.
• Routing problems. A faulty route or ISP issue between you and the site.
• Wrong IP. DNS points at an address with nothing there, or a private address that is not routable from your location.

Diagnose

# Where along the path do packets stop?
mtr -rw -c 20 example.com
traceroute example.com

# Is the server reachable on other ports? If SSH works but 443 does not, it is a rule, not an outage.
nc -vz SERVER_IP 22
nc -vz SERVER_IP 443

If every port is unreachable and traces end inside the provider's network, check the provider's console and status page. If one port is blocked and the others are fine, review firewall rules for that port. If the site works from other networks, your path is the problem, and you can compare with the Down From Where tool or a mobile hotspot. The full local-versus-global method is in Is a website down for everyone or just me?.

ERR_CONNECTION_RESET

A reset means the connection was established or being established and then abruptly torn down by an RST packet. Something decided to end it, and the question is who.

Common sources of resets

• Application or web server crash. The process serving the request died, and the OS closed its sockets. Look for segfaults, OOM kills (dmesg -T | grep -i "killed process"), and restart loops.
• Firewall or intrusion prevention. A device in the path may inspect the connection and reset it when a rule triggers. The user sees a reset on specific URLs or after a handshake begins. Rate limiting modules, WAF and DPI middleboxes are frequent culprits.
• Proxy or load balancer. An idle timeout, a closed backend connection or a failed health check can reset the client side.
• Port or protocol mismatch. Speaking HTTPS to a port that serves plain HTTP (or the reverse) can produce a reset or protocol error, depending on the server.
• TLS problems. Old clients connecting to servers that no longer accept their TLS versions or ciphers may see a reset during the handshake. The SSL Checker and openssl s_client show what the server offers.
• MTU or middlebox issues. Large packets silently failing on some paths can cause stalls and resets that appear only on certain networks.
• Server limits. ulimit -n file descriptor exhaustion, connection limits (limit_conn, MaxClients), or a database dropping connections can all end in resets.
• Client-side software. Antivirus HTTPS scanning, a proxy or VPN may reset connections to certain sites.

Diagnose

# Verbose request: does it reset during the TLS handshake or after the request?
curl -v https://example.com/

# TLS-level detail
openssl s_client -connect example.com:443 -servername example.com </dev/null

# Watch for crashes on the server
sudo journalctl -u nginx -u php8.3-fpm --since "15 min ago"
sudo tail -n 100 /var/log/nginx/error.log

The place where curl -v stops tells you a lot. If it resets after * Connected to but before any TLS handshake lines, suspect a firewall or a non-TLS listener. If it resets after the request is sent, suspect the application or proxy. In nginx error logs, recv() failed (104: Connection reset by peer) while reading response header from upstream indicates the backend closed the connection, which results in the 502 described in fix 502 Bad Gateway.

Related errors worth recognising

Windows and IIS notes

On a Windows server, use netstat -ano | findstr :443 to see listeners and Test-NetConnection -ComputerName example.com -Port 443 for reachability. Refusal often means the IIS site binding is stopped or the site is bound to a different port or IP; a timeout often points at Windows Firewall or a cloud security group. IIS's HTTP.sys log (%SystemRoot%\System32\LogFiles\HTTPERR) records connection-level problems such as Connection_Dropped and Timer_ConnectionIdle, which are very useful for resets.

A decision path

1. Run dig and confirm the name resolves to the right IP.
2. Run nc -vz IP 443. Which of the three outcomes?
3. Refused: the server is reachable but not listening. Check the service, the bind address, container port mappings and REJECT rules.
4. Timeout: check provider status, security groups, host firewall DROP rules, IP bans, then routing with mtr.
5. Succeeds, then the browser shows reset or closed: examine curl -v, TLS with openssl s_client, server logs for crashes, firewall or WAF resets.
6. Compare from a second network, so you know whether it is local to you.

When to call your host

Contact your provider if the server's console shows it running but every port times out, if traces show packet loss inside their network, if the machine cannot be rebooted or reached over the console, or if you are on managed hosting and the web service will not stay up. Provide the IP, ports tested, the nc and mtr output, and the start time in UTC. If an ISP is the issue, send them the same traces.

Next steps

Related tools and guides:

• Port Checker to test if a port accepts connections
• Website Health Check for DNS, TLS and response in one pass
• SSL Checker for handshake and certificate problems
• Down From Where to compare locations
• Why is my website down?
• SSL and TLS certificate errors explained

FAQ

What is the difference between connection refused and connection timed out?

Refused means the server actively answered that nothing is listening on the port, so the host is reachable. Timed out means no answer arrived, which points to dropped packets, an offline host, a firewall or a routing problem.

Why do I get connection refused on localhost?

Your development server is not running, or it is listening on a different port or only on a different interface (for example IPv6 ::1 while you request IPv4 127.0.0.1). Check with ss -tlnp or netstat and start the service.

Can a firewall cause connection reset?

Yes. Firewalls, WAFs and intrusion prevention systems can send RST packets to terminate connections that match a rule, and rate limiters can do the same under heavy traffic. A reset on certain URLs or networks only is a typical pattern.

How long does a connection attempt wait before it times out?

It depends on the operating system and client, since the TCP connect timeout is governed by retry settings and application limits. Browsers often give up after a time ranging from tens of seconds to a couple of minutes, so you cannot rely on one fixed value.

Does ERR_CONNECTION_RESET mean the website is down?

Not always. The site may be up for most users while a firewall, proxy, TLS mismatch or local security software resets your connection. Test from another network and with curl -v to see where it fails.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.