ERR_CONNECTION_TIMED_OUT: why it happens and how to fix it

What ERR_CONNECTION_TIMED_OUT means

When a browser opens a connection, it sends a SYN packet and waits for a SYN-ACK. A timeout means no reply arrived, neither a SYN-ACK nor the RST that a closed port would send, so the browser cannot tell whether the packet reached anything. That silence is the difference from ERR_CONNECTION_REFUSED, a fast and definite rejection from the target. Chromium's error list defines the code (-118) as "a connection attempt timed out."

The client's operating system does not give up after one try. It resends the SYN several times with growing gaps, in case the first one was lost to ordinary packet loss. On Linux, net.ipv4.tcp_syn_retries is 6 by default, and the kernel documentation puts the final timeout at 131 seconds. RFC 9293 asks TCP to keep retrying a SYN for at least 3 minutes but lets the application give up sooner, so the wait you see depends on the operating system and the browser together. Either way, a timeout takes far longer to appear than a refusal, which usually comes back in milliseconds.

How the error appears

Chrome shows "This site can't be reached", then "example.com took too long to respond" and ERR_CONNECTION_TIMED_OUT, only after the full wait. Firefox shows "The connection has timed out". From the command line, set a connect timeout so you do not wait minutes:

curl -v --connect-timeout 10 https://example.com/
* Trying 203.0.113.10:443...
* Connection timed out after 10001 milliseconds
curl: (28) Connection timed out after 10001 milliseconds

Exit code 28 means a timeout; newer curl versions word the message differently but return the same code. --connect-timeout limits only the connection phase, so it separates a connect timeout from a slow response. nc -zv -w 5 example.com 443 reports "timed out" the same way, and on Windows Test-NetConnection example.com -Port 443 in PowerShell ends with TcpTestSucceeded : False.

ERR_CONNECTION_TIMED_OUT vs similar errors

Chrome shows all of these under the same "This site can't be reached" heading, so the code underneath is what tells them apart. The rows follow the order in which a page load meets them, from the DNS lookup to the first byte of the response. The numbers are Chromium's internal error codes.

Error	What happened at the network or protocol level	Where to look first
ERR_NAME_NOT_RESOLVED (-105)	The DNS lookup returned no usable IP address, so no connection was attempted.	The domain's DNS records and the resolver the device uses.
ERR_ADDRESS_UNREACHABLE (-109)	The operating system or a router reported that there is no route to the IP address.	Routing on the client side: VPN routes, the local network, IPv6 setup.
ERR_CONNECTION_TIMED_OUT (-118)	The SYN went out and nothing came back, neither SYN-ACK nor RST, until the client gave up.	Firewalls and security groups that drop packets, whether the host is up, and the IP address DNS returns.
ERR_CONNECTION_REFUSED (-102)	The SYN reached the host and was rejected right away, usually with an RST.	Whether a process listens on that port and address, and firewall REJECT rules.
ERR_CONNECTION_RESET (-101)	The connection was open, then an RST ended it during the TLS handshake or the transfer.	Proxy, WAF, and application logs at that moment; antivirus, VPN, or filtering on the client's network.
ERR_EMPTY_RESPONSE (-324)	The connection opened and the request went out, but the server closed the connection without sending any data.	Server and proxy error logs for crashed workers or connections closed on purpose (nginx's return 444).

What causes ERR_CONNECTION_TIMED_OUT

• A firewall drops the packets. DROP rules, cloud security groups, and ufw's deny discard the SYN without replying. It is the usual setup for ports that should not be public, and the most common cause when the server itself is up.
• The host is down or cut off. A server that is powered off, hung, or disconnected cannot answer at all. A router that knows the host is gone may send an ICMP error instead, which Chrome reports as ERR_ADDRESS_UNREACHABLE.
• DNS returns the wrong address. A record that still points at an old server after a migration, a cached old IP, or a hosts-file entry sends the browser to an address where nothing answers.
• A routing problem on the path. A broken peering link, a misconfigured route, or an ISP outage strands packets before they reach the destination network, sometimes for only some regions.
• The server is overloaded. When the listen queue is full, Linux drops new connection attempts instead of refusing them, and a full connection-tracking table on a firewall or NAT host does the same.
• Your network blocks the port. Some workplace, school, and public Wi-Fi firewalls allow only common ports such as 80 and 443, so a site on :8080 or :8443 times out there and loads at home.

Server-side causes and configuration

A service that listens only on 127.0.0.1 produces a refusal, not a timeout. If outside clients time out, something discards the packets before they reach the port, and the fastest way to find where is to watch for them on the server while you connect from another network:

sudo tcpdump -ni any 'tcp port 443 and tcp[tcpflags] & tcp-syn != 0'

The filter shows incoming SYNs and the server's SYN-ACK replies. No SYN at all means the drop happens before the server: a cloud firewall, a network firewall, routing, or DNS pointing elsewhere. SYNs arriving with no SYN-ACK going out means a firewall on the host or a full queue is discarding them. SYNs answered with SYN-ACKs means the server is answering, and the replies are lost on the way back or dropped on the client's side.

Cloud security groups and network ACLs

Cloud firewalls typically drop traffic they do not allow, so a missing inbound rule produces a timeout, not a refusal. List the rules that apply to the server:

# AWS: inbound rules of a security group
aws ec2 describe-security-groups --group-ids sg-0123456789abcdef0 --query 'SecurityGroups[].IpPermissions'

# Azure: rules of a network security group
az network nsg rule list --resource-group web-rg --nsg-name web-nsg --output table

# Google Cloud: firewall rules in the current project
gcloud compute firewall-rules list

AWS network ACLs are stateless, so they need an outbound rule for the return traffic on ephemeral ports (1024-65535) as well as the inbound rule. A missing return rule also looks like a timeout.

Host firewalls

# Default policy and DROP rules with packet counters
sudo iptables -L INPUT -n -v --line-numbers

# ufw: "deny" drops without replying; allow the port explicitly
sudo ufw status verbose
sudo ufw allow 443/tcp

# nftables
sudo nft list ruleset | grep -n -E "drop|policy"

A Chain INPUT (policy DROP) header means anything not explicitly allowed is dropped. A DROP rule whose packet counter rises each time you retry is the one dropping your connections.

DNS records

Compare the address the domain's own name servers publish with what public resolvers return and with the server's real IP:

dig +short NS example.com
dig +short A example.com @ns1.example-dns.net
dig +short A example.com @1.1.1.1

If the authoritative answer is right and a resolver still returns the old address, the record's TTL has not expired yet. A low TTL set before a planned move shortens that wait:

example.com.      300  IN  A      203.0.113.10
www.example.com.  300  IN  CNAME  example.com.

A stale AAAA record is harder to spot: Chrome starts an IPv4 attempt in parallel after a short delay, so browsers may load the site while IPv6-only clients and checks time out.

Overloaded Linux servers

When a listening socket's accept queue is full, Linux drops new SYNs instead of resetting them, because tcp_abort_on_overflow is off by default. Clients see slow connects and timeouts. The queue is capped by net.core.somaxconn (4096 by default since Linux 5.4) and by the backlog the application requests; nginx requests 511 unless the listen directive sets backlog=.

# Listen queues: Recv-Q is the current accept queue, Send-Q its limit
ss -ltn

# Counters of overflowed queues and dropped SYNs
nstat -az TcpExtListenOverflows TcpExtListenDrops

# Connection-tracking table full on a firewall or NAT host
sudo journalctl -k | grep -i "nf_conntrack: table full"

Raise the backlog (for example listen 443 ssl backlog=4096;) only together with fixing whatever makes the application slow to accept connections.

Kubernetes

Two settings drop traffic instead of rejecting it. With externalTrafficPolicy: Local, kube-proxy does not forward external traffic on a node that has no ready pod for the Service, so connections to that node's NodePort time out. Cloud load balancers health-check nodes to avoid this, but clients that connect to a NodePort directly do not. A NetworkPolicy that does not allow the traffic usually drops it as well, depending on the network plugin.

How it looks from the outside

• Times out from every location. The host is down, a firewall or security group drops the port for everyone, or DNS points at a dead address everywhere.
• Times out from some regions only. A routing or peering problem between those networks and the host, a firewall rule that drops certain countries or address ranges, or one of several A records pointing at a dead server.
• Ping answers, the port times out. The host is up and a firewall drops that port. A failed ping proves little on its own, because many hosts block ping.
• One port answers, another times out. A firewall rule covers that port only, for example a missing allow rule for 443 after HTTPS was enabled.
• Accepted everywhere, times out only for you. Your network: an outbound firewall, an ISP block, a stale DNS or hosts-file entry, or a VPN.
• Intermittent timeouts under load. Full listen queues or a full connection-tracking table.

The port checker opens a TCP connection from many locations and reports for each one whether it was accepted, refused, or timed out, so a drop on one path stands apart from a host that is down everywhere.

How to fix ERR_CONNECTION_TIMED_OUT

If you are a visitor

1. Try a different network, such as mobile data, to rule out your router, your ISP's route, or a workplace firewall.
2. Flush your DNS cache in case it holds an old, unreachable address. Run the command for your system (Windows, macOS, Linux with systemd-resolved, in that order):

   ipconfig /flushdns
   sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
   resolvectl flush-caches

   In Chrome, also open chrome://net-internals/#dns and click "Clear host cache".
3. Check your hosts file (C:\Windows\System32\drivers\etc\hosts on Windows, /etc/hosts on macOS and Linux) for an old entry that pins the domain to a dead address.
4. Disable a VPN or proxy temporarily. A VPN's exit node can be the thing that is unreachable.
5. Restart your router to clear stuck routing or connection state.

If you run the site

1. Confirm the host is up from the provider's console or another machine, not from a shell on the server itself.
2. Watch for SYNs with tcpdump while connecting from outside, as shown above, to learn whether packets reach the server.
3. Check security groups, network ACLs, and host firewalls for a missing allow rule or a DROP rule on the port.
4. Compare DNS answers with the server's real address, including AAAA records.
5. Trace the path over TCP:

   mtr --tcp --port 443 example.com
   sudo traceroute -T -p 443 example.com

   A TCP trace can get past firewalls that block ICMP or UDP trace probes. Where it stops is a hint, not proof, because many routers do not answer trace probes at all.
6. Check queue and conntrack counters if timeouts appear only under load.

How to prevent ERR_CONNECTION_TIMED_OUT

A dropped packet leaves no error in the server's logs, because nothing on the server ever received the request. Port and HTTP checks from outside the network catch an unreachable host or a dropped port when it starts; HostTracker runs them from 300+ checkpoints in 158 cities and alerts by email, SMS, voice call, Slack, Telegram and more before visitors report it. Adding ping monitoring next to a port check shows at once whether the whole host or only the port went silent.

Frequently asked questions

How long does Chrome wait before showing ERR_CONNECTION_TIMED_OUT?

It depends mostly on the operating system's TCP settings, not on a fixed browser timer. On Linux the kernel resends the SYN 6 times by default and gives up after about two minutes; other systems use different retry counts. A failure that appears within a second or two is almost never a timeout.

Why does the site load on my phone but time out on my laptop?

This usually points at something specific to the laptop's network path: a workplace firewall, a VPN client, or a cached DNS or hosts-file entry pointing at an unreachable address.

Why does ping work but the site times out?

Ping uses ICMP, while the site needs a TCP connection to port 80 or 443. A firewall can allow one and drop the other, so a working ping only proves the host is up.

Why does it time out only on a port like 8080 or 8443?

The network you are on probably allows only common ports. Many workplace and public networks drop outbound connections to anything other than 80 and 443, so the same URL works from home or mobile data.

Can a DNS problem cause ERR_CONNECTION_TIMED_OUT instead of a DNS error?

Yes, if DNS resolves successfully but returns an address where nothing answers, such as an old server that has since been shut down. The lookup succeeds, and the connection attempt to that address times out.

Can a website block my IP with a timeout?

Yes. A server or its firewall can drop traffic from banned addresses or whole countries, and dropped packets look exactly like a dead server to you. If the site loads over mobile data but not from your home connection, ask the site owner whether your address was blocked.

Is ERR_CONNECTION_TIMED_OUT the same on every browser?

The cause is the same, but the wording differs. Microsoft Edge is built on Chromium and shows the same code, while Firefox shows "The connection has timed out".

Does a timeout always mean the server is down?

No. It means nothing answered the connection attempt, which can also mean a firewall dropped it, a route is broken somewhere in between, or DNS points at the wrong address while the real server is fine.

Why does the site time out for me but load for a coworker on the same network?

Look for a per-device VPN client, a cached DNS entry, a hosts-file line, or a browser proxy setting that only your machine has. A shared network problem usually affects everyone on it, so a difference between two devices points at one of them.

Sources and further reading

• Chromium net error list: the definitions of CONNECTION_TIMED_OUT (-118) and the other codes in the table above.
• RFC 9293, Transmission Control Protocol: section 3.8.3 on connection failures and how long a SYN is retried.
• Linux kernel IP sysctl documentation: tcp_syn_retries, tcp_abort_on_overflow, and somaxconn.
• Kubernetes: virtual IPs and service proxies: how traffic policies route or drop Service traffic.