Connection Timed Out

The short version: Load another website first. If everything times out, the trouble is your network, not the destination. A connection timed out means no reply arrived in time, usually from a down or overloaded server, a firewall quietly dropping packets, or a local network or DNS issue. Retry, then switch networks, before you dig any deeper.

Key takeaways

• Connection timed out is a generic networking error. The client opened a connection, a timer expired with no reply, and it quit waiting. The same event turns up in browsers, SSH, database clients, ping, and API calls alike.
• Timeouts are ambiguous on purpose. All one tells you is that nobody answered in time, never whose fault it was. So the request path itself (your network, the route, the server) decides where you look next.
• Test the exact port the service uses, not the homepage. Reach for nc -zv host port or telnet host port. When it hangs all the way to a timeout, traffic is being dropped rather than refused.
• On the command line, a timeout shows as curl exit code 28; a flat refusal is exit code 7. That single number tells you which failure you actually hit, before you start guessing.
• Firewalls that DROP packets give you timeouts. Firewalls that REJECT them give you instant refusals. A silent drop on a security group or office network is the usual hidden culprit.

Error type

Network / connection error

Whose side

Either: your network or the server

Fix difficulty

Easy to moderate

Common cause

Server unreachable or firewall dropping traffic

What does Connection Timed Out mean?

Connection timed out is a generic networking error that reaches well past the web browser. The same message greets you when a browser cannot load a page, when an SSH session refuses to open, when a database client cannot reach its server, or when an API request gets no response. The pattern never changes: the client opens a connection and waits, a timer counts down, and once the deadline passes with no answer the client reports a timeout instead of hanging forever. Browsers wrap it in their own labels, ERR_CONNECTION_TIMED_OUT in Chrome or a plain timeout notice in Firefox and Safari, but the event underneath is identical.

What a timeout will not tell you is whose fault it is, only that nobody answered in time. The blame can rest on your side, where your network, Wi-Fi, VPN, or proxy gets in the way, or on the far side, where a server is down, overloaded, or hiding behind a firewall that quietly throws packets away. That is what sets it apart from a flat refusal: a refused connection means something actively said no, whereas a timeout means the request simply vanished into silence. Run the visitor checks first, then the server checks, and you find out which side owns the problem fastest.

~30s

Typical client timeout

cURL 28

curl timeout error code

Port 22

SSH default port

How the Connection Timed Out error appears

The wording changes depending on your browser, device, or server. Here is how this error commonly shows up:

example.com

This site can't be reached

example.com took too long to respond.

ERR_CONNECTION_TIMED_OUT

• Browser: ERR_CONNECTION_TIMED_OUT / The connection has timed out
• SSH: ssh: connect to host … port 22: Connection timed out
• MySQL: Can't connect to MySQL server (error 2002 / 2003)
• WordPress: connection timed out (PHP max_execution_time exceeded)
• ping: Request timed out (packet loss)
• curl / API: Connection timed out after N ms (cURL error 28)

Connection timed out vs refused vs reset vs unreachable

All four mean a connection failed, but each points at a different cause and a different place to look.

curl exit codes for connection failures

The exit code curl prints names the exact failure, which narrows the cause before you change anything.

Timeouts across protocols, and the first thing to check

The same timeout shows up in many tools, and each has a port and a setting worth checking before assuming the host is down.

What causes Connection Timed Out?

• The server is down, overloaded, or just too slow to accept the connection before the client's timer runs out.
• A firewall or security group is silently dropping packets. The request is neither answered nor refused, only ignored, until it eventually times out.
• High latency or packet loss on the network path stops the handshake from completing in time across the route.
• Something on your local network is interfering: a shaky Wi-Fi link, a router due for a restart, or a captive portal you have not passed yet.
• A VPN or proxy is sending traffic through a slow or broken hop, and the added delay is enough to trip the timeout.
• DNS resolves slowly or only intermittently, so the connection cannot even start until the lookup finally fails.
• A timeout value is set too low, either on the client or on an intermediate proxy or load balancer, cutting off a connection that would otherwise have gone through.

How to find the cause fast

1. Open the same address from another device, or over mobile data, to tell a local problem apart from a server one.
2. Ping the host, then run traceroute (or tracert): this shows whether DNS resolves and exactly where the packets stop.
3. Test the exact port using telnet host 443 or nc -zv host 22. That distinguishes a blocked port from a full outage.
4. Turn off any VPN or proxy, pause your firewall or antivirus, then try again.

Terminal

curl -I --connect-timeout 10 https://example.comcurl: (28) Connection timed out after 10001 ms# the host never completed the TCP handshake

How Connection Timed Out looks from the outside

A timeout is silence, and silence tells you nothing on its own. From the outside, an overloaded server, a firewall dropping packets, and a broken route are indistinguishable: no answer comes back from any of them. You separate them by checking the same host from more than one network, on the exact port the service uses rather than just the homepage. A single ping from your own machine will never give you that.

How to fix Connection Timed Out

If you are a visitor

1. Retry once or twice. A lone timeout is often nothing more than a passing network blip or a server that was busy for a moment.
2. See whether the rest of your internet is working. Open another website or service; if every one of them times out, your connection is the problem, not the destination.
3. Power-cycle your router or modem: unplug it, wait roughly 30 seconds, then plug it back in to clear a stalled network state.
4. Switch networks to narrow things down. Jump from Wi-Fi to a mobile hotspot or a wired connection and try the address again.
5. Drop any VPN or proxy for a moment. Each adds an extra hop, and that hop can be the source of the delay tripping the timeout.
6. Flush your DNS cache, then retry. A stale or sluggish DNS entry can stall the connection before it even begins.
7. Find out whether the website is down for everyone before you go further, using Is Website Down? If it is down globally, the fix belongs on the server side and there is nothing left to do from your end.

If you run the website or server

1. Make sure the server is up and accepting connections on the port you expect. Test reachability with telnet host 443, or run curl -v https://yourdomain.com to see exactly where the connection stalls.
2. Go through the firewall and security group rules. A rule that drops traffic instead of rejecting it hands the client a timeout with no error, so confirm the relevant port is open to the right sources.
3. Read the server and application logs for signs of strain: a full connection queue, worker processes exhausted, backends refusing connections. Each of these slows acceptance until clients time out.
4. Look over the timeout settings on any reverse proxy, load balancer, or web server fronting the application. Set one too low, say a short proxy_read_timeout in nginx, and it will cut off slow but valid requests.
5. Check that DNS for the hostname resolves quickly and points at the right address. A slow or incorrect record delays every new connection.
6. After the connection is back, watch it from outside your own network. Timeouts can be intermittent or limited to certain regions, and external checks surface problems an on-server test never sees.

On Linux

1. Confirm the client can reach the port with nc -zv host port. A hang that runs to a timeout means traffic is being dropped, not refused.
2. Inspect the local firewall using sudo ufw status (or iptables -L), and open the port if it is closed, for example sudo ufw allow 443.
3. For a server that is valid but just slow, raise the client timeout rather than living with the short default: curl --connect-timeout 60 https://host.

SSH connection timeouts

1. Before you write the server off as down, check that port 22 (or your custom SSH port) is open and listening with nc -zv host 22.
2. Where the security group or firewall allowlists by source IP, make sure your current IP is on the list, because a dropped packet there reads as a timeout.
3. Long idle sessions timing out? Add ServerAliveInterval 60 to your ~/.ssh/config and the client will send keepalives.

Database connection timeouts

1. Add the client IP to the database firewall or cloud security group. A blocked source gives you a timeout with no error rather than a clean refusal.
2. Make sure the server is not bound to localhost only: review bind-address in the config and point it at the right interface for remote access.
3. When the database is reachable but slow to accept connections, raise the client setting, MySQL connect_timeout for example, so valid connections do not get cut off early.

Still not fixed? Next steps

• When one port hangs to a timeout under nc -zv but the host answers on its other ports, you are looking at a dropped-packet block on that one port, not a dead server. Go check the firewall or security group rules for that source.
• Seeing the timeout only from an office or corporate network? Ask IT to allowlist the host and port. A content filter or proxy that drops traffic is indistinguishable from a timeout, and those rules are rarely yours to change.
• If you run the service and connections time out only under load, the network is probably innocent: look at the connection backlog and the worker pool instead. A full accept queue holds new connections until clients give up on them.
• Intermittent timeouts call for repeated port tests, or continuous monitoring of the host from outside. One check that happens to pass proves nothing about a connection that fails one time in ten.

Code & configuration

Copy-paste starting points. Replace example.com and the paths with your own, and test changes on staging before production.

Test whether the port is actually open

# is the port reachable?
telnet example.com 443
nc -zv example.com 22

# watch exactly where the request stalls
curl -v https://example.com

How to prevent Connection Timed Out

Users usually spot a timeout before you do. Pulsetic watches your website or endpoint from several locations every 30 seconds with HTTP, TCP, ICMP, and port checks, so the moment a server stops answering or starts timing out, you know within seconds: email, SMS, voice call, Slack, Discord, Telegram, or webhook. It cannot tell you why the box is slow, because it does not read CPU, memory, or disk. What it does tell you is the instant connections stop completing, which tends to be the alert you wanted first.

Learn how Pulsetic's uptime monitoring detects this from the outside, across 15+ locations.