What the error actually says

Chrome shows “This site can’t be reached. example.com took too long to respond.” with ERR_CONNECTION_TIMED_OUT (net error -118). Firefox says “The connection has timed out”. Programs get ETIMEDOUT.

Your computer sent a SYN, the first packet of a TCP connection, and nothing came back. Not a yes, not a no. It resent the SYN a few times, waiting longer each time, and eventually gave up. How long that takes depends on the operating system: on Linux with default settings the retries span about two minutes, and Windows gives up sooner.

The silence is the clue. A machine with nothing listening on the port would have refused, instantly. Silence means the packet was dropped somewhere, or went to an address where nobody is home:

ErrorWhat happenedHow it feelsWhere to look
ERR_CONNECTION_TIMED_OUTThe SYN got no answerHangs, then failsFirewall that drops, wrong IP, routing, overloaded server
ERR_CONNECTION_REFUSEDThe SYN was answered with a RSTFails immediatelyNo program listening on that port, or a firewall that rejects
ERR_CONNECTION_RESETConnection opened, then a RST arrivedFails after connectingApplication, proxy, filter that inspects traffic

This error is only about opening the connection. If the connection opens and then the page never arrives, you get a long spinner and possibly a different error, such as ERR_TIMED_OUT. That’s a different problem, covered near the end.

First: where does it happen?

Every site, or one site? If every site times out, your own connection is the problem: the router, the Wi-Fi, a VPN that’s stuck, or a proxy setting pointing nowhere. Restart the router and turn off the VPN before reading further.

One network, or every network? Load the URL on your phone with Wi-Fi off. If it works on mobile data, the problem is between your network and the site, or on your computer. If it times out everywhere, the server or its firewall is the place to look.

The HTTP check loads the page from outside your network. If it succeeds there, the site is up and the path from you to it is broken.

If you’re a visitor

Your computer has the wrong address cached. If the site moved recently, your computer or your network’s DNS resolver may still be holding the old IP, where nothing answers any more. Flush the caches: ipconfig /flushdns on Windows, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder on macOS, and in Chrome, chrome://net-internals/#dns → Clear host cache. Also check your hosts file for the site’s name (/etc/hosts, or C:\Windows\System32\drivers\etc\hosts).

A VPN, proxy or firewall on your computer. Turn each off and retry. A VPN that has lost its tunnel without noticing will swallow traffic and produce exactly this error for every site.

Your network blocks the site, or the port. Company networks, schools and some public Wi-Fi drop traffic to sites or ports they don’t allow, and a drop looks like a timeout. Unusual ports are blocked more often than 443: if the URL has :8080 or :8443, try it from another network.

The site blocks your country, or your IP. Some sites only accept visitors from their home country and silently drop everyone else. Some firewalls drop IPs that triggered a rate limit. If it works on another network or from the HTTP check, and only your connection is ignored, this is a likely explanation. Only the site owner can change it.

If you run the site

Reproduce from outside your network with an explicit connect timeout, so you don’t wait two minutes:

curl -v --connect-timeout 10 https://www.example.com/ -o /dev/null
*   Trying 203.0.113.10:443...
* Failed to connect to www.example.com port 443 after 10001 ms: Timeout was reached
curl: (28) Failed to connect to www.example.com port 443 after 10001 ms: Timeout was reached

The wording differs between curl versions, but note the IP it tried. Everything below starts from whether that IP is right.

1. The name points at the wrong address

dig +short www.example.com A
dig +short www.example.com AAAA

Things to look for:

  • An old server’s IP after a migration. Use a propagation check to see whether public resolvers have all moved to the new one.
  • A private address like 10.x.x.x, 172.16–31.x.x or 192.168.x.x. That works inside your office and goes nowhere from the internet. It happens when someone copies an internal record into public DNS.
  • A typo in the IP, or an address that was released back to the cloud provider when an instance was stopped. Elastic and static IPs exist for this reason.

The DNS lookup shows what public resolvers return, which may differ from what your own machine sees.

2. A firewall drops the packets

This is the most common server-side cause. Cloud firewalls drop by default: an AWS security group, a GCP firewall rule or an Azure network security group without an inbound rule for 443 discards the SYN without a word. There are often two layers to check, the cloud firewall and the server’s own:

sudo ufw status verbose
sudo iptables -S
sudo nft list ruleset

ufw’s default incoming policy of deny drops packets, so a missing ufw allow 443/tcp produces a timeout, not a refusal. Some cloud images also ship their own host firewall rules on top of the provider’s firewall (Oracle Cloud’s images are a well-known example), so opening the port in the web console alone isn’t enough.

To confirm the packets arrive at all, capture on the server while you retry from outside:

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

No SYN arriving: it’s dropped before the server (cloud firewall, wrong IP, routing). SYN arriving and no SYN-ACK going out: the server’s own firewall, or the server is overwhelmed. SYN-ACK going out and the client still timing out: the reply is lost on the way back, which points at routing or a firewall on the return path.

3. A server at home, behind a router

If you host on a home connection, three things commonly cause timeouts from outside:

  • No port forwarding. The router receives the SYN and has nowhere to send it. Forward 443 to the server’s LAN address.
  • Carrier-grade NAT. If the WAN address in your router’s status page differs from your public address (the IP check shows it), or falls in 100.64.0.0/10, your ISP shares one public IP among many customers. Port forwarding can’t work; you need a public IP from the ISP or a tunnel service.
  • The ISP blocks inbound ports. Some residential plans block incoming connections on 80, 443 or 25. Check the plan’s terms.

The reverse problem also exists: the site works from outside but times out from inside your own network, because the router doesn’t support hairpin NAT (reaching your public IP from inside). Use local DNS, or test from outside.

4. The server is too busy to answer

When the listen queue overflows, Linux drops new connection attempts instead of answering them, which looks like a timeout to the client. Look for overflows and for a full connection-tracking table:

nstat -az TcpExtListenOverflows TcpExtListenDrops
ss -ltn 'sport = :443'
dmesg -T | grep -i conntrack

For a LISTEN socket, ss shows the current accept queue in Recv-Q and its limit in Send-Q. A Recv-Q pinned at the limit means the application isn’t accepting fast enough. A nf_conntrack: table full, dropping packet message means the firewall’s state table is full; raise nf_conntrack_max or reduce what’s tracked.

5. A routing problem on one path

If one ISP’s customers time out and everyone else is fine, the problem is in the routing between them. A TCP traceroute shows where packets stop:

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

Ordinary ICMP traceroute is often filtered and misleading; the TCP mode uses the same port as the browser. A trace that stops at the same hop every time, from affected networks only, is something to send to the hosting provider or the ISP with the trace attached.

Behind Cloudflare or another CDN

When a hostname is proxied through Cloudflare, the browser connects to Cloudflare, not to your server. If your origin doesn’t answer, visitors see Cloudflare’s 522 error page, not ERR_CONNECTION_TIMED_OUT. A browser timeout on a proxied hostname therefore means the visitor couldn’t reach Cloudflare’s edge, which points at their network, or the record isn’t actually proxied and the visitor is going straight to an origin that drops them.

Connects, then hangs: a different problem

If curl gets past Connected to and then stalls during the TLS handshake or while waiting for the response, the connection did open. Two common causes:

  • A path MTU problem. Small packets get through, large ones (the server’s certificate during TLS) silently disappear. Common with VPNs, PPPoE links and tunnels. Test with a don’t-fragment ping: ping -M do -s 1472 example.com on Linux, ping -f -l 1472 example.com on Windows. If it fails while smaller sizes work, lower the MTU or enable MSS clamping on the tunnel.
  • The application is slow. The server accepted the connection but takes too long to answer. Behind a proxy this becomes 504 Gateway Timeout.

Checking from outside with DechoNet

  • The port check tries a TCP connection from DechoNet’s servers. Open means the handshake completed within 3 seconds. Closed covers refused, reset and no answer alike, so it won’t tell you which; curl -v from outside will. The check runs from outside your network and, in most cases, from outside Korea, so a server that only accepts domestic traffic will look closed. Hosts on Cloudflare IP addresses can’t be checked from our side at all, and the tool says so.
  • The HTTP check loads the page from outside. When DechoNet’s overseas egress gets no answer, it retries from an observation point in Seoul, which separates “down” from “blocks foreign IPs”.
  • The DNS lookup shows the A and AAAA records the public sees.

Check your own domain now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.