PuTTY Network Error: Connection Timed Out (How to Fix It)

What you're seeing

You click Open, PuTTY sits on a blank window for 20 seconds or so, then a "PuTTY Fatal Error" dialog appears:

Network error: Connection timed out

The wording is identical on Windows 10, Windows 11, and for SSH and Telnet sessions alike. The wait before the dialog is the giveaway: PuTTY kept retrying and never heard anything back.

That silence is what separates this from the neighbouring error:

• Connection timed out (this page): your packets got no answer. Either they never arrived, or a firewall DROPped them without replying. PuTTY can't tell which.
• Connection refused: the machine answered and actively said no; it's reachable, but nothing accepts connections on that port. Different causes, different fixes: see PuTTY Network Error: Connection Refused.

Refused means you reached the machine. Timed out means, as far as you can prove, you didn't. And no, there's no PuTTY setting to raise the timeout that fixes this: waiting longer for packets that are being dropped just delays the same dialog.

What's causing this error

Somewhere between your PC and the server, packets to that address and port go into a black hole. The real causes, in rough order of frequency:

1. Wrong IP or hostname. A typo, stale DNS, a DHCP device (Raspberry Pi, VM) that moved, or a cloud instance whose public IP changed after a stop/start.
2. The host is down. Powered off, crashed, or a stopped cloud instance.
3. A firewall silently dropping inbound port 22. On cloud servers this is overwhelmingly the platform firewall: an AWS Security Group, Azure NSG, or GCP firewall with no inbound SSH rule. DROP is the default posture, and DROP produces exactly this error.
4. Your own network blocking outbound port 22. Corporate networks, hotel and public Wi-Fi, and some ISPs block or filter outbound SSH.
5. The host isn't reachable from where you are. It needs the company VPN, or it's a machine on a home network behind NAT with no port forward, so its 192.168.x.x address means nothing from outside.

How to fix it

Step 1: Verify the address

Load the session in PuTTY and check the Host Name field before anything else:

• Cloud instance: compare against the console. On AWS EC2, the public IP changes every stop/start unless you attached an Elastic IP; a saved PuTTY session pointing at last week's IP times out forever. Also confirm the instance is running at all.
• Raspberry Pi or VM on DHCP: it may have a new address. Check your router's client list, or from another machine on the LAN run ping raspberrypi.local.
• Hostname: make sure it resolves, and to the address you expect: nslookup your-server.com in PowerShell.
• Private addresses (10.x.x.x, 172.16-31.x.x, 192.168.x.x) only work from inside that network or over its VPN. From anywhere else they time out by definition.

If you fix the field, click Save in the Session panel or the old value comes back next time.

Step 2: Test whether the port is reachable

For a server with a public IP, the fastest check is our SSH port checker. It probes the port from the internet, which splits the problem in two: if the checker reaches port 22 but PuTTY doesn't, the block is on your side (step 4); if the checker can't reach it either, the block is on the server side (step 3).

For hosts on your local network, test from your own machine:

PS> Test-NetConnection 192.168.1.50 -Port 22
# TcpTestSucceeded : False  ->  same silence PuTTY is seeing

Step 3: Open the firewall in front of the server

On a cloud server, the platform firewall sits above the OS and silently drops anything without an inbound rule. Add one for SSH:

• AWS EC2: EC2 console → the instance → Security tab → its Security Group → Edit inbound rules → Add rule: type SSH, port 22, source My IP (preferred) or 0.0.0.0/0.
• Azure: the VM → Networking → Add inbound port rule: destination port 22, protocol TCP, action Allow.
• Google Cloud: VPC network → Firewall → check that a rule allows tcp:22 to your instance (the default-allow-ssh rule exists in default networks but not in custom ones).

Changes take effect in seconds; no reboot needed.

If the server is in your house (a Pi, a NAS, a home server) and you're connecting from outside, the router needs a port-forwarding rule sending an external port to the machine's LAN IP, port 22. Without it, the connection dies at your router. Forwarding a non-standard external port like 2222 keeps drive-by scanners away; put that port in PuTTY's Port field.

An OS-level firewall on the server can also DROP (as opposed to REJECT, which produces Connection refused). From the server's console: sudo ufw status or sudo iptables -L INPUT -n and allow port 22 if it's blocked. Our firewall rule generator builds the commands.

Step 4: Rule out your own network

If the port checker says the server is reachable but PuTTY still times out, something between you and the internet is filtering:

• Try another network. Tether to your phone's hotspot and connect again. If it works over the hotspot, your office, hotel, or ISP network blocks outbound port 22. Ask IT to open it, or run the server's SSH on port 443, which almost nothing blocks.
• VPN. If the server is only reachable through a company VPN, connect the VPN first, then PuTTY. If the VPN routes all your traffic, the reverse can also happen: a personal server that works without the VPN times out with it up.
• Windows firewall or antivirus on your own PC occasionally filters outbound connections from specific programs. Temporarily disable to test, then add an exception for PuTTY.

Common edge cases