How to fix ERR_CONNECTION_REFUSED as a visitor or site owner

What ERR_CONNECTION_REFUSED means

ERR_CONNECTION_REFUSED means your browser reached the server's IP address, asked to open a TCP connection on a port (80 for http, 443 for https), and the machine at that address answered with a refusal. In TCP terms, nothing was listening on that port, so the operating system sent back a reset (RST) instead of completing the handshake. Chrome and Edge show it as error -102, "This site can't be reached ... refused to connect". Firefox shows the same failure as "Unable to connect".

The useful part is what the refusal tells you: the network path to the server works, and a machine replied. The problem is almost always that no program is accepting connections on that address and port, or that a firewall is actively rejecting them.

Quick-fix checklist

1. Check the address bar for typos, an extra port such as :8080, or http:// where the site only serves https:// (or the reverse).
2. Open the site from your phone on mobile data. If it loads there, the problem is on your computer or network.
3. Turn off any VPN, proxy or browser extension that routes traffic, then retry.
4. Pause the antivirus web shield or third-party firewall briefly and retry.
5. Flush your DNS cache so you are not connecting to an old IP address.
6. If you run the site: confirm the web server is running and listening on the right port, and that the firewall allows ports 80 and 443.

Refused vs timed out vs reset

Three Chrome errors look alike but point to different faults. Chromium's own error list describes them as a refused connection attempt, a timed-out connection attempt, and a connection reset that corresponds to a TCP RST.

A firewall rule that denies traffic usually discards it silently, which gives a timeout. A rule that rejects sends a reply back, which gives a refusal. The ufw manual describes exactly this difference between its deny and reject actions.

Visitor side vs site owner side

If the site fails for you but loads on another network or device, the fix is on your side. If it fails everywhere, including on mobile data and through an online checker, the site owner has to fix it. Do not spend an hour on your router settings before trying a second network.

Fixes for visitors

Wrong URL, port or scheme

A bookmark or a link may include a development port such as :3000 or :8080 that only existed on someone's test machine. Remove the port and try the plain domain. Also try switching between http:// and https://: some servers only listen on one of them.

Proxy or VPN

If your system or browser sends traffic through a proxy that is no longer running, every site fails with this error, because the refusal comes from the proxy address, not the website. On Windows, check Settings > Network & internet > Proxy and switch off any manual proxy you did not set up. Disconnect the VPN client and retry.

Antivirus or firewall software

Security suites with HTTPS scanning or "web protection" sit between the browser and the internet. If that component fails, connections are refused locally. Pause it for a minute to test, then update or reinstall it rather than leaving it off.

Stale DNS cache

If a site has just moved hosts, your computer may still be connecting to the old server, which no longer runs the site. Clear the cache:

# Windows (Command Prompt as administrator)
ipconfig /flushdns

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

# Chrome's own cache: open chrome://net-internals/#dns and click "Clear host cache"

If the problem persists, switching your network to a public resolver can help; our DNS resolver guide compares the common choices.

Fixes for site owners

The web server is not running

This is the most common cause. Log in over SSH and check the service:

systemctl status nginx
systemctl status apache2      # Debian/Ubuntu; the service is httpd on RHEL-based systems
systemctl status lsws         # OpenLiteSpeed / LiteSpeed

If it shows inactive or failed, test the configuration before starting it, because a syntax error is often why it stopped:

sudo nginx -t && sudo systemctl restart nginx
sudo apachectl configtest && sudo systemctl restart apache2
journalctl -u nginx --since "1 hour ago"

Listening on the wrong port or interface

A server can be running yet listen only on 127.0.0.1, or on a port other than 80 and 443. List every listening TCP socket with the owning process:

sudo ss -tlnp

Here -t limits output to TCP, -l shows listening sockets, -n prints port numbers instead of service names, and -p shows the process. You want lines such as 0.0.0.0:80, 0.0.0.0:443 or [::]:443. A line like 127.0.0.1:8000 means the program only accepts connections from the server itself.

In nginx the listen directive sets this; listen 80; and listen [::]:80; cover all IPv4 and IPv6 addresses. In Apache, Listen 80 binds every interface while Listen 192.0.2.1:80 binds only one, and a <VirtualHost> for port 443 is unreachable unless there is also a Listen 443. If the site has an AAAA record, make sure the server listens on IPv6 too, or visitors on IPv6 will be refused while IPv4 users get through.

Firewall or security group

Check the host firewall:

sudo ufw status verbose
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

If ufw status reports inactive, ufw is not what is blocking you. Do not run sudo ufw enable over SSH until you have also run sudo ufw allow 22/tcp (or your custom SSH port): the ufw manual warns that enabling it can drop existing SSH connections.

Also check any firewall in front of the server, such as a provider's network firewall or a cloud security group. A reject rule there produces this error; a drop rule produces a timeout instead.

Test from the outside with curl

From another machine, curl -v shows each stage of the connection:

curl -v http://203.0.113.10/
curl -v https://example.in/
curl -v --resolve example.in:443:203.0.113.10 https://example.in/

"Connection refused" in the output confirms that nothing accepted the connection on that port at that IP, either because no service is listening or because a firewall rejected it. The --resolve form tests a specific server directly without changing DNS, which is useful during a migration.

Behind Cloudflare

When the site uses the Cloudflare proxy, visitors connect to Cloudflare, not to you, so they see Cloudflare's error 521 rather than ERR_CONNECTION_REFUSED. Cloudflare defines 521 as the origin refusing connections from Cloudflare. Check that the origin web server is up, that your firewall does not block Cloudflare's IP ranges, and that the origin listens on port 443 if your SSL/TLS mode is Full or Full (strict), or port 80 for Flexible.

localhost during development

On your own computer, localhost refused to connect means the development server is not running, has crashed, or is on a different port from the one in your URL. Check the terminal where you started it for the exact address it printed. Inside Docker or a virtual machine, an app bound to 127.0.0.1 cannot be reached from outside the container; bind it to 0.0.0.0 and publish the port.

How this applies on Bigdomainhost

On KVM VPS and dedicated servers you have root access and run the web server yourself, so every owner-side check above is yours to do. One point matters on a new VPS: the server firewall's default policy denies inbound traffic except SSH on port 22. After installing nginx, Apache or OpenLiteSpeed, add inbound rules for ports 80 and 443 in the panel, or visitors will not reach the site even though ss -tlnp shows it listening. Rules are set per instance and can be edited without SSH; see the networking and firewall docs. If a firewall change locks you out of SSH, the out-of-band console in the control panel still gets you in.

On Web & cPanel hosting and WordPress hosting, the LiteSpeed web server runs on shared hosting servers in Mumbai that we manage, so the server-side checks are ours to do. If your site shows this error, check the URL and DNS first, then contact support on 24x7 phone or WhatsApp at +91 75994 50220 or at support@bigdomainhost.com with your domain and the time you saw the error. If you have just moved a site, our migration guide covers the DNS steps where stale records cause exactly this problem.

Sources (checked 15 November 2026)

• Chromium: net/base/net_error_list.h
• IETF: RFC 9293: Transmission Control Protocol (TCP)
• nginx.org: Module ngx_http_core_module: listen
• Apache HTTP Server: Binding to Addresses and Ports
• Ubuntu Manpages: ufw(8)
• Cloudflare Docs: Error 521: web server is down