ERR_CONNECTION_TIMED_OUT and ERR_CONNECTION_REFUSED: The Fix
Your domain resolves fine, but the browser just sits there and then gives up with "ERR_CONNECTION_TIMED_OUT" or slaps you with "ERR_CONNECTION_REFUSED" straight away. No SSL warning, no 500 page - the request never even reaches your web server. Here's what's actually happening at each stage, and how to fix it without randomly restarting services and hoping.
What these two errors actually mean
Both errors happen after DNS has already done its job. Your browser looked up the domain, got an IP address back, and tried to open a TCP connection to your server on port 80 or 443. What happens next is where the two errors split:
- ERR_CONNECTION_REFUSED - the server actively said no. Something answered at that IP but nothing is listening on the port you asked for, or a firewall rule sent back a hard reset (RST) instead of silently dropping the packet.
- ERR_CONNECTION_TIMED_OUT - nobody answered at all. The browser sent the connection request and waited (usually 20-30 seconds) with total silence, then gave up. This usually means a firewall is dropping the packet rather than rejecting it, or the IP simply isn't reachable from where you are.
If you've ruled out DNS (the domain resolves to the right IP via nslookup yourdomain.com) and you're still stuck here, the problem is on the network path or the server itself - not your zone records.
Symptom checklist
ping yourserveripworks but the browser still times out (ping uses ICMP, not the actual web port - different story)- The site was working, then you resized the VPS, restored a snapshot, or changed hosting and it stopped
- It fails from your office network but loads fine over mobile data, or the reverse
- SSH still connects on port 22 but the site itself is unreachable
- It happens for everyone, everywhere - not just you
Common causes, most likely first
1. Web server or PHP-FPM isn't running
If Nginx, Apache, or LiteSpeed crashed or was never restarted after a server reboot, nothing is listening on port 80/443 at all - that's a textbook ERR_CONNECTION_REFUSED. Check it directly on the VPS:
systemctl status nginx
systemctl status httpd
systemctl status php-fpm
ss -tlnp | grep -E ':80|:443'If ss shows nothing bound to 80 or 443, that confirms it - the service is down or misconfigured. Start it and check the error log (/var/log/nginx/error.log or /usr/local/apache/logs/error_log) for why it died in the first place - a bad config edit is the usual culprit.
2. A firewall is blocking the port
This is the most common cause of ERR_CONNECTION_TIMED_OUT specifically, because most firewalls drop rather than reject by default. Check both layers:
- On the server - UFW, iptables, or CSF/LFD on a cPanel VPS. Run
ufw statusorcsf -land confirm 80 and 443 are open. - Above the server - if you're on a cloud VM (DigitalOcean, AWS, Google Cloud, Azure), the provider's own network firewall (security group / cloud firewall) sits in front of the OS firewall and can silently drop traffic even if UFW looks fine.
Quick way to isolate which layer is blocking: try connecting to the port directly from another machine.
nc -zv yourserverip 443
telnet yourserverip 80If that hangs with no response, it's a network/firewall drop upstream of the OS. If it says "connection refused" immediately, it got to the server but nothing's listening there.
3. CSF has auto-blocked the visitor's IP (or your own)
On cPanel VPS servers running CSF, repeated failed logins, aggressive crawling, or a false-positive from LFD (Login Failure Daemon) can land an IP in /etc/csf/csf.deny. That IP then gets refused or dropped entirely while everyone else loads the site fine - which explains the "works for me, not for them" reports.
grep yourip /etc/csf/csf.deny
csf -g yourip
csf -dr yourip # remove the block4. The IP changed and DNS or a cached record is stale
After a migration, VPS rebuild, or IP reassignment, the domain might still resolve correctly in dig but your own machine, a corporate DNS server, or an ISP resolver is still holding the old IP in cache. You're then trying to connect to a server that no longer exists or belongs to someone else - hence the timeout or refusal.
dig +short yourdomain.com @8.8.8.8
dig +short yourdomain.com @1.1.1.1If public resolvers agree on the new IP but your browser still times out, flush your local DNS cache and, if you're behind a corporate network, ask IT to check theirs.
5. The server is overloaded or genuinely down
Under heavy load, a server can stop accepting new TCP connections even though it's technically "up" - the accept queue fills and new SYN packets get dropped. Check basic health:
uptime
free -h
topIf load average is far above your core count or RAM is exhausted and swapping heavily, that's your answer - the fix is capacity, not configuration.
6. Cloudflare or another proxy is misconfigured
If the domain is proxied through Cloudflare (orange cloud) and your origin server's firewall only allows traffic from certain IPs, make sure Cloudflare's IP ranges are whitelisted. Otherwise Cloudflare's own request to your origin gets refused, and it shows the visitor a connection error or one of the 52x Cloudflare-specific pages instead.
A quick diagnostic order
| Step | Command | Tells you |
|---|---|---|
| 1 | dig +short yourdomain.com | Confirms DNS points where you expect |
| 2 | ping yourserverip | Basic network reachability (ICMP only) |
| 3 | nc -zv yourserverip 443 | Whether the port itself is open |
| 4 | ss -tlnp | grep 443 (on the server) | Whether a service is actually listening |
| 5 | ufw status / csf -l | Whether a local firewall is blocking it |
Prevention
- Enable a monitoring check (uptime monitor hitting your homepage over HTTPS, not just ping) so a downed web server pages you before customers notice
- Whitelist your office/admin IP in CSF before locking down a fresh server, so you don't firewall yourself out
- Keep a note of your cloud provider's security group rules alongside your OS firewall rules - the two drift apart easily after a "quick fix"
- After any VPS migration or IP change, update DNS first and give it time to propagate before decommissioning the old server
- Set systemd to auto-restart critical services:
systemctl edit nginxand addRestart=on-failureunder[Service]
Frequently asked questions
Why does ping work but the website still time out?
Ping only tests ICMP, a different protocol from HTTP/HTTPS. A firewall can easily allow ICMP while blocking or dropping traffic on ports 80 and 443, so a successful ping tells you almost nothing about whether the web server itself is reachable.
Is ERR_CONNECTION_REFUSED always a firewall issue?
No. It just as often means the web server process isn't running at all, or is listening on a different port than expected (for example only on 8080 behind a reverse proxy that isn't forwarding correctly). Check systemctl status and ss -tlnp before touching firewall rules.
I just migrated to a new VPS - could that be the cause?
Yes, this is one of the most common triggers. If DNS still points to the old server, or a resolver somewhere between you and the domain is caching the old IP, you can end up trying to connect to a server that no longer runs your site or has been decommissioned.
How do I tell if Cloudflare or my own server is the problem?
Temporarily pause Cloudflare proxying (grey-cloud the DNS record) and test the origin IP directly. If the error disappears, the issue is between Cloudflare and your origin - usually a firewall rejecting Cloudflare's IP ranges. If it persists, the problem is on your server.
Can a security group on AWS/DigitalOcean cause this even if UFW looks fine?
Yes. Cloud firewalls sit in front of the operating system and are evaluated first. A wide-open UFW config still won't matter if the cloud provider's security group doesn't allow inbound traffic on 80/443 from the internet.