ERR_CONNECTION_REFUSED
DIRECT ANSWER
ERR_CONNECTION_REFUSED means the browser reached a destination address, but the connection was rejected before the website returned a response. Common causes include a stopped web server, no process listening on port 80 or 443, a service bound only to localhost, an incorrect DNS destination, or a firewall rule blocking access. Check the destination and listener first, then test from an external network.
Key takeaways
- A fast refusal usually indicates a service, port, binding, or network-rule problem rather than a slow connection.
- Check whether Nginx, Apache, or the application server is running before changing browser settings.
- Confirm that a process listens on the requested port, commonly 80 for HTTP or 443 for HTTPS.
- A listener on
127.0.0.1can work locally while refusing external connections. - Test from outside the server after each change so local success does not hide an external access problem.
Site Administrator
What this error means & how to recognize it
- Chrome, Edge, or another Chromium-based browser displays “This site can’t be reached — ERR_CONNECTION_REFUSED.”
- The error appears quickly instead of after a long wait. A long delay is more consistent with a timeout such as
ERR_CONNECTION_TIMED_OUT. - A site that worked previously fails after a server restart, deployment, DNS change, configuration update, or firewall change.
- SSH or another application port on the same machine may remain reachable while the web port refuses connections.
- Requests made on the server may succeed while requests from outside fail when the service listens only on localhost or an external firewall blocks the port.
Root causes, ordered by likelihood
- The web server or application process is stopped — Nginx, Apache, or the application server may have crashed, been stopped, or failed during startup.
- Nothing is listening on the requested port — the service may use a different port, while the request is going to 80 or 443.
- The service is bound to the wrong interface — a listener on
127.0.0.1accepts local requests but not direct external connections. - A host or cloud firewall rejects the traffic — an operating-system firewall, security group, network ACL, or provider firewall may have changed.
- DNS points to the wrong destination — the domain may resolve to an old, rebuilt, or otherwise unconfigured server. An AAAA record can also direct some visitors to an IPv6 address without a working web listener.
How to fix it
1. Confirm the destination address
Check the domain’s A and AAAA records and compare the resolved addresses with the server that should receive the request. If the domain points to an old, decommissioned, or newly rebuilt server, correct DNS before changing the web-service configuration. If both IPv4 and IPv6 records exist, verify that the service and firewall support both paths.
2. Check whether the service is running
Using an authorized administration method such as SSH, check the relevant service. For example, inspect Nginx with systemctl status nginx; use the equivalent service name for Apache or the application server.
If the service is stopped or failed, review its status and logs before starting it. A configuration error introduced by a recent change is a common startup failure. Validate the configuration with nginx -t for Nginx or apachectl configtest for Apache. Only after the test passes and you are authorized to change the service should you restart or reload it. A restart can interrupt active requests and may not be appropriate during a production peak.
3. Verify the listening port and interface
On the server, inspect listeners with ss -tlnp or the platform equivalent. Confirm that the expected process is listening on the port being requested, commonly :80 or :443.
Check the bind address as well as the port:
0.0.0.0:80or0.0.0.0:443generally listens on available IPv4 interfaces.- A specific server address indicates that the service is bound to that interface.
127.0.0.1:80or127.0.0.1:443accepts local requests only.
If the application is intentionally private on localhost, confirm that the public-facing reverse proxy is running and forwarding to it. Otherwise, adjust the service configuration to listen on the intended interface during an approved maintenance or deployment change.
4. Check host and cloud firewall rules
Review the server firewall with ufw status, iptables -L, or the equivalent command for the operating system. Then inspect the cloud security group, network ACL, or provider firewall attached to the expected server.
Confirm that inbound traffic is allowed on the required port from the appropriate sources. A public website may need internet access, while an internal service should use a narrower approved range. Check IPv4 and IPv6 rules separately when both record types are published. Do not broaden access more than necessary, and make firewall changes only with authorization.
5. Test locally and externally
From the server, test the local listener and configured hostname separately. Local success confirms only that something responds on the machine; it does not prove that external clients can reach the port.
After correcting DNS, the service, binding, or firewall, run a verbose curl -v request against the affected hostname from a different network or external machine. Confirm that the request reaches the expected address and port and that the refusal has cleared.
6. Compare recent changes
If the failure began after a deployment, restart, server rebuild, DNS update, or firewall change, compare the current configuration with the last known working version. Look specifically for a changed port, failed service startup, localhost-only binding, a rule attached to the wrong server, or an incomplete IPv6 configuration.
Prevention & how to verify the fix
- Use a service manager or process supervisor so the web service can recover from an unexpected failure.
- Make configuration validation, such as
nginx -torapachectl configtest, a required deployment check before a reload or restart. - Document the intended ports, bind addresses, firewall rules, security groups, and DNS records as a known-good baseline.
- Monitor the service from outside the server instead of relying only on local health checks.
- Review IPv4 and IPv6 listeners and firewall rules whenever a domain has both A and AAAA records.
- Record infrastructure changes so a new refusal can be correlated with a deployment, rebuild, DNS update, or firewall change.
When to get outside help
Escalate to your hosting or cloud provider when the service is running, the expected port is listening on the correct interface, DNS points to the intended server, and firewall rules allow the traffic, but external connections are still refused. Provide the affected hostname, approximate start time, recent infrastructure changes, listening-port output, and relevant firewall or service-log findings. Remove private credentials and sensitive configuration before sharing diagnostics.
Frequently asked questions
Is ERR_CONNECTION_REFUSED the same as a timeout?
No. ERR_CONNECTION_REFUSED is normally returned quickly when the destination rejects the connection or no usable listener accepts it. A timeout generally means the request received no response within the expected period.
What should I check first for ERR_CONNECTION_REFUSED?
Check whether the web server or application process is running, then confirm that a process listens on the requested port. These checks quickly distinguish a stopped service from a port, binding, or firewall problem.
Why does the site work on the server but not from my computer?
The service may be bound only to 127.0.0.1, which accepts local connections but not external ones. A host firewall, cloud security group, or network ACL can also permit local traffic while blocking outside requests.
Which ports are commonly involved?
HTTP commonly uses port 80 and HTTPS commonly uses port 443, although a site or reverse proxy may use another configured port. Compare the requested port with the listeners shown by ss -tlnp or the platform equivalent.
Can DNS cause ERR_CONNECTION_REFUSED?
DNS does not itself refuse a TCP connection, but an incorrect A or AAAA record can send the browser to a server with no suitable web listener. Verify both the resolved address and the service configuration on that destination.
Should I restart the web server immediately?
Not before checking its status, logs, and configuration syntax. A restart can interrupt requests, hide the original cause, or fail again because of a syntax error. Validate the configuration first, then restart or reload it only with appropriate authorization.
Further documentation
For authoritative reference material, consult the documentation for the browser’s connection errors, the operating system’s service manager and socket tools, the installed Nginx or Apache version, the host firewall, the cloud provider’s security groups or network ACLs, and the DNS provider’s A and AAAA record management. Use the documentation matching the server operating system, web server, hosting platform, and network design in the affected environment.
LIVE CHECKS
