ERR_CONNECTION_REFUSED: What It Means and How to Fix It Completely

The ERR_CONNECTION_REFUSED error means your browser sent a connection request to a web server, and that server actively rejected it — not ignored it, but explicitly refused the TCP handshake. This is a fundamentally different failure mode from a timeout (ERR_CONNECTION_TIMED_OUT) or a DNS failure (ERR_NAME_NOT_RESOLVED), and that distinction matters enormously when diagnosing the root cause.

In practical terms, when Chrome displays "This site can't be reached. ERR_CONNECTION_REFUSED," it means one of three things: the target server is not listening on the requested port, a firewall or security layer is sending a TCP RST (reset) packet back to your client, or your local network stack is misconfigured and routing the request incorrectly before it ever reaches the server. Identifying which of these three categories applies to your situation is the fastest path to a fix.

Understanding the TCP-Level Mechanics

Most browser troubleshooting guides treat ERR_CONNECTION_REFUSED as a vague "network problem." It is not. At the TCP layer, a refused connection means the server (or an intermediary) sent back a RST/ACK packet in response to your browser's SYN packet. This is an explicit rejection, not a silent drop.

This distinction has a practical diagnostic implication: if the connection were being silently dropped by a firewall, you would see ERR_CONNECTION_TIMED_OUT. A refused connection means something is actively responding — which means the host is reachable at the network level, but the service on the target port is unavailable or blocked.

Common port-level causes include:

• The web server process (Apache, Nginx, Node.js) has crashed or stopped
• The server is listening on a non-standard port and the URL does not specify it
• A host-based firewall (iptables, ufw, Windows Defender Firewall) is rejecting connections on port 80 or 443
• A reverse proxy (HAProxy, Nginx, Cloudflare) is configured incorrectly and returning RST packets upstream
• The application behind the proxy has crashed, leaving the proxy with no backend to forward to

Root Causes: A Structured Breakdown

Client-Side Causes

Server-Side Causes

Step-by-Step Diagnostic and Fix Guide

Step 1: Determine Whether the Problem Is Global or Local

Before touching any local settings, establish whether the site is down for everyone or just for you. Use these tools:

• downforeveryoneorjustme.com — simple up/down check
• isitdownrightnow.com — includes response time history
• ping.pe — pings the target from multiple global locations simultaneously

If the site is reachable from external nodes but not from your machine, the problem is local. If it is unreachable globally, the issue is server-side and outside your control — contact the site administrator or wait.

For server administrators managing their own infrastructure, a globally unreachable site warrants immediate investigation into the web server process, firewall rules, and upstream network. If you are running a VPS Hosting environment, check your server's process list and firewall configuration first.

Step 2: Verify the Server Is Actually Listening (For Server Admins)

If you administer the server in question, SSH in and run the following to confirm what is listening on which ports:

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

If the output is empty for port 80 or 443, your web server process is not running. Restart it:

# For Nginx
sudo systemctl restart nginx

# For Apache
sudo systemctl restart apache2

# Check status
sudo systemctl status nginx

Also verify that your firewall is not blocking inbound connections:

# Check iptables rules
sudo iptables -L INPUT -n -v

# If using ufw
sudo ufw status verbose

If port 443 is blocked, allow it:

sudo ufw allow 443/tcp
sudo ufw allow 80/tcp
sudo ufw reload

For administrators running Dedicated Servers, also check whether your hosting provider's upstream firewall or security group rules are blocking the port at the network perimeter — this is separate from the OS-level firewall.

Step 3: Restart Your Router and Flush Local Network State

For client-side issues, a router restart clears NAT tables, DHCP leases, and any transient routing failures. Unplug the router for 30 seconds, then reconnect. This is especially effective when the error appeared suddenly without any configuration changes.

Step 4: Flush the DNS Cache

A stale DNS cache entry pointing to an old or decommissioned IP address is one of the most common causes of ERR_CONNECTION_REFUSED on the client side. The server at the cached IP may no longer be running the target site.

On Windows:

ipconfig /flushdns

On macOS (Ventura, Sonoma, and most modern versions):

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

On Linux (systemd-resolved):

sudo systemd-resolve --flush-caches

After flushing, verify what IP the domain now resolves to:

nslookup example.com
# or
dig +short example.com

Compare this against the site's known IP. If they differ, DNS propagation may still be in progress.

Step 5: Clear Browser Cache and Cookies

In Google Chrome, navigate to chrome://settings/clearBrowserData or use the keyboard shortcut:

• Windows/Linux: Ctrl + Shift + Delete
• macOS: Cmd + Shift + Delete

Set the time range to All time, check Cached images and files and Cookies and other site data, then click Clear data. Restart Chrome completely (not just the tab) before retesting.

For a faster test without clearing data, open an Incognito window (Ctrl + Shift + N). If the site loads in Incognito but not in a normal window, a cached resource or a browser extension is the culprit.

Step 6: Audit and Disable Proxy Settings

A misconfigured or dead proxy server is a frequent cause of ERR_CONNECTION_REFUSED across all websites simultaneously. Chrome uses the system proxy settings by default.

On Windows:

Navigate to Settings > System > Proxy and disable "Use a proxy server" if it is enabled without your knowledge. Alternatively, run this from an elevated Command Prompt:

netsh winhttp reset proxy

On macOS:

Go to System Settings > Network, select your active interface, click Details, then the Proxies tab, and uncheck all active proxy protocols.

After disabling the proxy, test the site. If it loads, your proxy configuration was the cause. Either reconfigure it correctly or remove it entirely.

Step 7: Change Your DNS Resolver

Your ISP's default DNS resolver may be returning incorrect results, experiencing an outage, or actively blocking certain domains. Switching to a public resolver eliminates this variable.

Recommended public DNS resolvers:

On Windows (via PowerShell):

Set-DnsClientServerAddress -InterfaceAlias "Wi-Fi" -ServerAddresses ("1.1.1.1","1.0.0.1")

On macOS:

Go to System Settings > Network > [Your Interface] > Details > DNS, remove existing entries, and add 1.1.1.1 and 1.0.0.1.

On Linux (systemd-resolved):

Edit /etc/systemd/resolved.conf:

[Resolve]
DNS=1.1.1.1 1.0.0.1
FallbackDNS=8.8.8.8 8.8.4.4

Then restart the resolver:

sudo systemctl restart systemd-resolved

Step 8: Temporarily Disable Firewall and Antivirus

Some antivirus products and host-based firewalls intercept HTTPS traffic through a local proxy and can issue RST packets when their inspection engine fails or when the target domain is on a block list. Temporarily disabling them (for diagnostic purposes only) confirms whether they are the cause.

If disabling the security software resolves the error, add a specific exception for the target domain rather than leaving the software disabled. Re-enable it immediately after testing.

Step 9: Test with a Different Browser and Network

Test the URL in Firefox, Edge, or Safari. If it loads in another browser, the issue is Chrome-specific — likely a corrupted profile, a malfunctioning extension, or a Chrome-specific proxy setting. Try creating a new Chrome profile to isolate the issue.

If the site fails in all browsers, switch to a mobile hotspot. If it loads over mobile data, your ISP or home router is the source of the problem.

Step 10: Check for SSL/TLS Configuration Issues (Server Admins)

A misconfigured SSL certificate can cause the server to crash or refuse TLS connections, which Chrome reports as ERR_CONNECTION_REFUSED rather than a certificate error in some edge cases. Use the following to test from the command line:

curl -vI https://yourdomain.com

Look for the TLS handshake stage in the verbose output. A failure here indicates a certificate or cipher suite problem. You can also test with:

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com

If your SSL certificate has expired or is misconfigured, renewing or replacing it resolves the issue. Ensure your SSL Certificates are valid, properly chained, and installed on the correct server interface.

ERR_CONNECTION_REFUSED vs. Similar Browser Errors

Understanding how this error differs from related errors prevents misdiagnosis:

Advanced Edge Cases and Pitfalls

IPv6 vs. IPv4 resolution conflicts: If a domain resolves to an IPv6 address but your network does not support IPv6 properly, Chrome may attempt an IPv6 connection that gets refused, then fail to fall back to IPv4 quickly. Disabling IPv6 on the network adapter temporarily can confirm this. On Linux, you can force IPv4 with curl -4 https://example.com.

Cloudflare or CDN caching stale origin errors: If a site uses Cloudflare and the origin server goes down, Cloudflare may serve a cached version for a while, then start returning 521 (origin refused connection) or 522 errors, which Chrome may display as ERR_CONNECTION_REFUSED depending on how the error is proxied.

Localhost development environments: Developers frequently see ERR_CONNECTION_REFUSED when accessing localhost:3000 or similar. The cause is almost always that the development server process is not running, crashed, or is bound to 127.0.0.1 on a different port than expected. Run ss -tlnp | grep node (or the relevant process) to confirm what is actually listening.

Email server port conflicts: If you are running Email Hosting on the same server as your web application, ensure that port conflicts between SMTP (25, 587), IMAP (993), and HTTP/HTTPS (80, 443) are not causing the web server to fail to bind.

Shared hosting limitations: On Shared Web Hosting environments, a connection refusal may indicate that the hosting provider's server is overloaded, the account has been suspended, or the domain's DNS is not yet pointing to the correct shared IP. Check your hosting control panel for account status and DNS configuration.

Practical Decision Matrix: Which Fix to Apply First

Use this checklist to triage efficiently:

• Error appears on all websites simultaneously — Check proxy settings and VPN/firewall configuration first
• Error appears only on one specific domain — Check if the site is globally down; then flush DNS cache
• Error appears only in Chrome, not other browsers — Clear Chrome cache, disable extensions, or create a new Chrome profile
• Error appears only on your network, not on mobile data — Restart router; check ISP-level DNS or firewall
• Error appears after a server configuration change — Check web server process status, port bindings, and firewall rules on the server
• Error appears intermittently under load — Investigate resource exhaustion (file descriptors, memory, connection limits) on the server
• Error appears only on HTTPS, not HTTP — Investigate SSL certificate validity and TLS configuration
• Error appeared after changing DNS settings — Revert DNS changes and flush the cache; verify new resolver is reachable

FAQ

What is the difference between ERR_CONNECTION_REFUSED and ERR_CONNECTION_TIMED_OUT?

ERR_CONNECTION_REFUSED means the server (or a firewall) actively sent a TCP reset packet, rejecting the connection immediately. ERR_CONNECTION_TIMED_OUT means no response was received within the timeout period — the packets were silently dropped. A refused connection is faster to appear and indicates an active rejection, while a timeout suggests a routing or firewall DROP rule.

Can ERR_CONNECTION_REFUSED be caused by an expired SSL certificate?

Indirectly, yes. In some server configurations, an expired or misconfigured SSL certificate causes the web server process to fail on startup or to crash when handling TLS connections, resulting in no listener on port 443. Chrome then reports ERR_CONNECTION_REFUSED because nothing is listening, even though the underlying cause is a certificate problem.

Why does ERR_CONNECTION_REFUSED appear only on one specific website?

If the error is isolated to a single domain, the most likely causes are: the target server's web service has crashed, the server's firewall is blocking your IP range, the domain's DNS records point to an old IP address where no service is running, or the site has been taken down. Use curl -v https://thatdomain.com from a different network or server to isolate the cause.

How do I fix ERR_CONNECTION_REFUSED on localhost?

The application server is not running or is bound to a different port than you are requesting. Confirm what is listening with ss -tlnp on Linux/macOS or netstat -ano | findstr :PORT on Windows. Start the application server process, and ensure it is bound to 0.0.0.0 or 127.0.0.1 on the expected port.

Does flushing DNS always fix ERR_CONNECTION_REFUSED?

Only when the root cause is a stale DNS cache entry pointing to an IP address where the service is no longer running. If the server is down, the firewall is blocking the connection, or the proxy is misconfigured, flushing DNS will have no effect. Use dig or nslookup to verify DNS resolution before and after flushing to confirm whether DNS was actually the issue.