Connection timed out
What “Connection timed out” usually means
When PuTTY reports Network error: Connection timed out, the client has already attempted a network or protocol step and failed before a normal interactive shell is available. This guide explains what the message usually means on Windows clients, which local settings to verify first, and when the problem is almost certainly on the server, firewall, or DNS path rather than inside the PuTTY GUI.
PuTTY sent traffic toward the host and port but received no useful TCP response before the timeout. Unlike refusal, timeouts often indicate filtering that drops packets, an unroutable address, or a middlebox silently discarding SSH.
Independent resource: Putty.info is educational only and is not affiliated with the official PuTTY project. Compare symptoms against the official documentation for your installed version.
Symptoms you will see
Operators usually notice this failure in one of a few repeatable ways. Capture the exact dialog text, the hostname and port from the Session panel, and whether the failure happens before or after a username prompt—those details decide which checklist below applies.
- The client sits for many seconds before showing a timed out network error.
- No SSH banner appears; authentication settings are irrelevant until TCP completes.
- Intermittent timeouts can correlate with flaky VPN or captive portal states.
Likely causes ranked by frequency
Several independent conditions can produce the same client-facing wording. Work from the outside in: reachability first, protocol selection second, authentication third. Changing key files will not fix a TCP refusal, and opening a wider firewall will not fix a rejected public key.
- Security group or firewall DROP rules (not REJECT) on the SSH port.
- Wrong VPN context—corporate routes missing for the destination prefix.
- Dead IP that still resolves in DNS, or pointing at a powered-off VM.
- ISP or hotel networks blocking outbound TCP/22.
- Asymmetric routing after a cloud elastic IP change.
Step-by-step client checks
Use this ordered checklist on a workstation you control. Prefer saved sessions so Host Name, Port, and Connection type stay consistent while you isolate one variable at a time.
- Confirm Host Name/Port and that you are not still targeting a decommissioned bastion IP.
- Test DNS resolution and compare A/AAAA records to the inventory system of record.
- Run Test-NetConnection or traceroute/path diagnostics; note where packets stop.
- Retry on another network to detect outbound blocking of port 22.
- If only IPv6 times out, try an IPv4 literal or fix AAAA records.
- Escalate to network/cloud teams with source IP, destination IP, port, and UTC timestamps.
Do not paste private keys, passphrases, or production passwords into Putty.info tools or contact forms. Diagnose locally with PuTTY, Plink, PSCP, or PSFTP from an official install.
When it is a server or network issue
Server admins should check whether sshd listens on 0.0.0.0/::, whether cloud firewalls allow the client prefix, and whether fail2ban or similar temporarily blackholes the client. Packet captures on both ends settle DROP-versus-routing debates faster than more PuTTY retries.
If TCP connects from another network path but fails from yours, involve the network team with traceroute/path evidence rather than repeatedly regenerating keys. If authentication fails after a banner appears, collect the server sshd logs for the same timestamp and username—client-side retries alone rarely reveal AccountLocked, Match blocks, or AllowUsers denials.