ERR_CONNECTION_REFUSED Fix: 5 Steps That Work

ERR_CONNECTION_REFUSED means nothing is listening on the port you're trying to reach. Here's how to find and fix it fast, without rebooting half your network gear.

Quick answer

Check if the service you're connecting to is actually running and listening on the right port — netstat -ano | findstr :8080 on Windows or netstat -an | grep 8080 on macOS/Linux. If nothing shows up, start the service or fix its config. If it is listening, your firewall or a proxy is blocking you.

What's actually happening here is that ERR_CONNECTION_REFUSED means the network connection was made, but the target machine actively refused it — because no process is listening on that port, or a firewall sent a rejection packet. It's different from a timeout (where packets just get dropped) or a DNS error (where the hostname can't be resolved). This error is the server saying "nope, not me" in network terms.

The most common trigger is trying to reach a local development server — like http://localhost:3000 for a React app or http://127.0.0.1:8000 for Django — and the server process crashed, or you never started it. But it also happens with remote services that are down, or when a VPN or proxy hijacks your traffic and points it at a dead port.

Step 1: Confirm the service is actually listening

Before you touch any settings, prove the service is running. Open your terminal and run:

# Windows
netstat -ano | findstr :8080

# macOS / Linux
netstat -an | grep 8080

If you see a line with LISTENING (Windows) or LISTEN (Unix), the port is open. If not, the service isn't running — that's your answer. Start it, and the error goes away.

I've seen people spend an hour updating firewall rules when their Node server just wasn't started. Always check this first.

Step 2: Try a different port or URL

Sometimes you're wrong about the port. A dev server might bind to 3000 by default, but if another process already grabbed 3000, it'll silently move to 3001. Or you typed localhost but the server only binds to 127.0.0.1 or a specific network interface.

Try hitting the IP directly: http://127.0.0.1:8080 instead of localhost. On some systems, localhost resolves to IPv6 ::1 first, and if your server only listens on IPv4, you get a refusal. This one bites macOS users regularly.

Step 3: Check your proxy and VPN

Chrome has a built-in proxy setting that can redirect traffic. If you're behind a corporate proxy or using a VPN, your request might be sent to the proxy's port, which then refuses the connection.

Go to Chrome settings → System → Open your computer's proxy settings. On Windows, make sure "Automatically detect settings" is on and the manual proxy IP/port are correct. On macOS, check System Preferences → Network → Proxies. Disable the proxy temporarily and retry the URL. If it works, your proxy config is the culprit.

Also, kill any VPN client that's running. Some VPNs route all traffic through a local proxy on ports like 1080 or 3128. If that proxy service crashed, you get exactly this error.

Step 4: Review firewall rules (Windows and macOS)

If the service is listening but you still get refused, the firewall might be actively blocking the connection. On Windows, check inbound rules for your app or port:

# Allow inbound on port 8080 (run as admin)
netsh advfirewall firewall add rule name="Allow 8080" dir=in action=allow protocol=TCP localport=8080

On macOS, go to System Settings → Network → Firewall. Click "Options" and make sure your dev server binary is allowed to receive incoming connections.

Don't forget that some antivirus suites have their own firewall that overrides the OS one. If you have Norton, McAfee, or Kaspersky, check their logs too.

Step 5: Clear Chrome's socket pool

Chrome keeps a pool of open connections. Occasionally it reuses a dead socket that's been closed by the server, and you get a spurious refusal. Rebooting the browser clears the pool. But you can do it faster:

Type chrome://net-internals/#sockets in the address bar.
Click "Flush socket pools."
Retry the URL.

This is a real fix when the server is fine but Chrome insists on failing. I've seen it happen after a laptop wakes from sleep, when the network stack reconfigures.

If nothing works: alternative fixes

Here's what to try when the steps above don't clear it:

Restart the service properly

Kill the process and start it again. On Linux, use pkill node or pkill -f your-app.jar. Then restart. This clears stale PID files and releases the port. Sometimes a service listens on a port but hasn't actually bound to it correctly — a restart forces a clean bind.

Check the hosts file

A stray line in /etc/hosts (Linux/macOS) or C:\Windows\System32\drivers\etc\hosts (Windows) can point localhost to the wrong IP. Look for entries like 0.0.0.0 localhost or ::1 localhost that might be missing. Also, some apps add entries for localhost pointing to a specific IP that isn't bound.

Temporarily disable Windows Defender Firewall

Not a permanent solution, but a good diagnostic. Turn it off for a minute (Control Panel → Windows Defender Firewall → Turn off) and retry. If the error disappears, you know the firewall is the cause. Turn it back on and then add a proper rule.

Prevention tip

The single best way to avoid this error is to use a tool like lsof -i :8080 (macOS/Linux) or netstat -ano | findstr :8080 (Windows) to see what's listening before you start your day's work. Make it a habit to check the port when you launch a dev server.

Also, if you're working with Docker, remember that containers may reuse ports after restarts — a stale container can hold the port hostage. Run docker ps to see if something else is occupying your port.

The real fix is understanding that ERR_CONNECTION_REFUSED is a server-side rejection, not a network failure. Once you know that, you stop rebooting your router and start checking processes.