Applies to: SSH and other TCP connections to Linux servers; tested with OpenSSH 10.0p2, curl 8.14.1 and netcat-openbsd on Debian 13, firewall rules with nftables 1.1.3
"Connection timed out" means your computer asked the server for a connection and got no answer at all before the time limit ran out. Nothing said yes and nothing said no: the request disappeared on the way. The usual causes, most common first:
- A firewall silently drops the traffic: on the server, at the provider or on your own network.
- Wrong IP address or port, for example SSH was moved to another port, or the domain still points to an old IP.
- The server is switched off, crashed, or its network is down.
- A routing problem somewhere between you and the server.
A typical SSH message looks like this:
ssh: connect to host 192.0.2.10 port 22: Connection timed out
Timed out, refused or no route: what each message tells you
We created each situation in a lab container with nftables rules and connected with ssh. The message tells you how far your request got:
- Connection timed out: no reply. Our firewall rule with
dropproduced this, and so did an address with nothing behind it. - Connection refused: the server answered "nothing is listening on this port", or a firewall rule rejected the request with a TCP reset. The server is reachable. See SSH connection refused.
- No route to host: a firewall rejected the request with an ICMP "prohibited" message (we tested both "host prohibited" and "administratively prohibited"). According to the firewalld documentation, firewalld rejects packets that match no rule unless the zone says otherwise, so on servers with firewalld a closed port often shows this message rather than a timeout.
UFW behaves differently: according to its manual, deny (the default for incoming traffic) ignores the packet, which you see as a timeout, while reject answers.
Step 1: Get a fast, clear error
Without a limit, ssh waits for the operating system's own timeout. On our Debian 13 test machine (Linux default tcp_syn_retries of 6) that took 132 seconds. Set a shorter limit and turn on verbose output:
$ ssh -v -o ConnectTimeout=5 root@192.0.2.10 debug1: Connecting to 192.0.2.10 [192.0.2.10] port 22. debug1: connect to address 192.0.2.10 port 22: Connection timed out ssh: connect to host 192.0.2.10 port 22: Connection timed out
(lab example, other debug lines removed). The "Connecting to" line shows the IP and port ssh really used. Check both: a domain that still resolves to an old server, or a missing -p after you moved SSH to another port, are common reasons. getent hosts example.com shows the IP your system uses for a name; if the name has an IPv6 address that does not work, ssh -4 forces IPv4.
Step 2: Test the port from your side
- Linux or macOS, with netcat:
$ nc -zv -w 5 192.0.2.10 22 nc: connect to 192.0.2.10 port 22 (tcp) timed out: Operation now in progress
An open port prints "succeeded!", a closed one "Connection refused". More in how to test port connectivity with nc. - A web port, with curl:
$ curl -sS --connect-timeout 5 http://192.0.2.10/ -o /dev/null curl: (28) Connection timed out after 5002 milliseconds
- Windows PowerShell, according to Microsoft:
Test-NetConnection -ComputerName 192.0.2.10 -Port 22. The lineTcpTestSucceeded : Falsemeans the port could not be reached. - PuTTY shows "Network error: Connection timed out". The PuTTY manual describes it the same way: the connection received no response at all from the server.
Then repeat the test from another network, for example a phone on mobile data. If it works there, the block is on your side: an office or hotel network that blocks outgoing SSH, or your IP address was blocked by a security tool on the server after failed logins (Fail2Ban, or CSF on cPanel servers, see how to unblock an IP in CSF).
Step 3: Check that the server is up
If every port times out from every network, the server or its network is the likely problem. A failed ping does not prove much, because many servers block ping. Use your provider's tools instead:
- On a Ucartz VPS, check in the client area (Services, My Services, then the VPS) that it is running, and open the VNC console: how to access your VPS via VNC in Virtualizor. The console works even when SSH and the network do not.
- On a dedicated server, use the IPMI console (Supermicro IPMI HTML5 console).
Step 4: Check the firewall and SSH on the server
Log in through the console, then check these in order:
- Is SSH running and on which port?
sshd -T | grep -E '^(port|listenaddress) 'printedport 22,listenaddress [::]:22andlistenaddress 0.0.0.0:22on our default Debian 13 install.ss -tlnplists every port that something is listening on. On Ubuntu 24.04 and 26.04, SSH uses socket activation, so a new port only takes effect aftersystemctl daemon-reload && systemctl restart ssh.socket(see how to change the SSH port safely). - Does the firewall allow the port? Depending on the system:
ufw status verbose,firewall-cmd --list-allornft list ruleset. Open the port with UFW or firewalld. - Test again from outside. If it still times out while the server's own firewall allows the port, the traffic is stopped before it reaches the server; ask your provider.
Step 5: Trace the route
If some networks reach the server and others do not, run mtr or a TCP traceroute to the server's port from an affected network and keep the output for your provider. See how to use mtr and read its report and TCP traceroute on Ubuntu.
"Operation timed out" and timeouts after connecting
Some timeouts happen after the connection is made: the server accepted it but did not answer in time. In our lab, a listener that accepted connections but never replied gave a different curl message:
curl: (28) Operation timed out after 5002 milliseconds with 0 bytes received
That points to a busy or stuck service (web server, PHP, database), not a firewall. For websites behind a proxy, that is often a 504 Gateway Timeout.
On macOS, "Operation timed out" is also simply the system's wording for the same connect timeout (macOS lists error 60, ETIMEDOUT, as "Operation timed out"; Linux calls it "Connection timed out"). So ssh: connect to host ... port 22: Operation timed out on a Mac means the same as the Linux message above.
An SSH session that was working and then drops after some idle time is a different problem: see how to stop SSH session timeouts.
If you are a Ucartz customer and still cannot connect, open a ticket with the output of the commands above. A quick check like this is covered by our Free Basic Managed Support, on a best-effort basis.
Related articles: SSH connection refused: causes and fixes, SSH session timeouts, test port connectivity with nc, default SSH port and how to change it.