How to Fix ERR_CONNECTION_REFUSED in Chrome

Network Beginner 6 min read Published July 16, 2026

ERR_CONNECTION_REFUSED is a Chrome error that appears when your browser tries to open a TCP connection to a server, and the server actively rejects it. Unlike a timeout, where the request simply gets no answer, a refusal means a machine responded — it just told your browser "nothing is listening on that port." The reset happens fast, usually within milliseconds, which is the key clue that distinguishes a refused connection from a timed-out one.

Because the rejection is immediate, the problem is almost always local to the server side: the web server is not running, it is listening on the wrong port, a firewall is blocking the port, or another process has hijacked the port the server expects to use. Occasionally the cause is on the client side — a misconfigured proxy, a stale DNS cache, or the wrong port in the URL. The seven steps below cover both server and client causes in the order you are most likely to encounter them.

Step 1: Check if the Web Server Is Running

The most common cause is simply that no web server is listening. If you control the server, SSH in and check the service:

# Nginx
sudo systemctl status nginx

# Apache
sudo systemctl status apache2

If the status shows inactive or failed, start it:

sudo systemctl start nginx
sudo systemctl enable nginx   # start at boot

If you are running a local development server (npm run dev, python -m http.server), make sure it is actually running and did not exit with an error in the terminal.

Step 2: Verify the Port Is Correct

Browsers default to port 80 for HTTP and port 443 for HTTPS. If your server runs on a non-standard port, the URL must include it. A common mistake is typing http://localhost when the dev server is on port 3000 — Chrome tries port 80, nothing is there, and you get ERR_CONNECTION_REFUSED.

# Correct URLs for non-standard ports
http://localhost:3000
https://example.com:8443

If you recently enabled HTTPS but are still loading the HTTP URL, or vice versa, the mismatched port can also trigger this error.

Step 3: Check Firewall Rules

A firewall may be dropping or rejecting traffic on the port your server uses. Check the firewall configuration on the server:

# ufw (Ubuntu)
sudo ufw status

# firewalld (CentOS/RHEL)
sudo firewall-cmd --list-ports

# iptables
sudo iptables -L -n | grep -E "80|443"

Open the required ports:

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

Do not forget cloud-provider security groups (AWS, Azure, GCP) — a closed security group rule produces an instant refusal that looks identical to a local firewall block.

Step 4: Clear Browser Cache and DNS Cache

A stale cached redirect or a poisoned DNS entry can send Chrome to the wrong place. Start by clearing the browser cache, then flush the OS DNS cache:

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux (systemd-resolved)
sudo resolvectl flush-caches

After flushing, restart Chrome completely (not just reload the tab) and try again. A cached HSTS redirect from HTTP to HTTPS is another common trap: once Chrome remembers that a site must use HTTPS, it will refuse to connect over HTTP even if that is what you typed.

Step 5: Check Proxy Settings

A misconfigured proxy — or a leftover proxy from a VPN that is no longer running — routes your connection to a dead endpoint, and Chrome reports it as refused. Check the OS and browser proxy settings:

# Check environment proxy variables on Linux/macOS
echo $http_proxy $https_proxy

On Windows, go to Settings > Network & Internet > Proxy and disable any manual proxy that is no longer needed. In Chrome, ensure no extension is forcing a proxy. If a VPN client crashed without cleaning up its proxy entry, the stale setting will silently break all connections.

Step 6: Verify the Service Is Listening

If the service is running but Chrome still cannot connect, confirm it is actually bound to the right interface and port. A server listening only on 127.0.0.1 cannot accept connections from external IPs:

# netstat
sudo netstat -tlnp | grep -E "80|443"

# ss (modern replacement)
sudo ss -tlnp | grep -E "80|443"

Look at the Local Address column. 0.0.0.0:80 means it accepts connections on all interfaces; 127.0.0.1:80 means localhost only. If you need external access, reconfigure the server to bind to 0.0.0.0 or the public IP.

Step 7: Check for Port Conflicts

Two processes cannot bind to the same port. If another service grabbed port 80 first, your web server may fail to start silently, and Chrome sees a refused connection. Find what is holding the port:

# Linux
sudo ss -tlnp | grep :80
sudo lsof -i :80

# Windows
netstat -ano | findstr :80

If a rogue process (often Skype, a Docker container, or a previous server instance) owns the port, stop it and restart your web server. Then verify Chrome can connect.

Quick Reference: Causes and Fixes

Symptom / Log Message	Root Cause	Fix
Instant refusal, no server running	Web server stopped	`systemctl start nginx/apache2`
Refusal only on `http://localhost`	Dev server on non-standard port	Add port to URL (e.g., `:3000`)
Refusal from outside, works locally	Server bound to 127.0.0.1 only	Bind to `0.0.0.0` in config
Refusal after firewall change	Port blocked by ufw/security group	Allow 80/443 in firewall and cloud SG
Refusal with VPN/proxy enabled	Dead proxy endpoint	Disable proxy; flush DNS
Refusal + "Address already in use"	Another process owns the port	Stop conflicting process; restart server