PuTTY Network Error: Connection Refused (How to Fix It)

What you're seeing

A "PuTTY Fatal Error" dialog the moment you try to connect:

Network error: Connection refused

The wording is identical on Windows 10, Windows 11, and the Linux build of PuTTY, and it appears whether the connection type is SSH, Telnet, or anything else TCP-based.

Two neighbouring errors are easy to confuse with this one:

• Network error: Connection timed out means your packets got no answer at all, usually a firewall silently dropping them or a dead host. Different error, different fix.
• Network error: Software caused connection abort means the session connected fine and died later, usually an idle timeout.

"Connection refused" is more specific than either: the machine at that IP answered, and it answered no. If you get the same rejection from the OpenSSH command line (ssh: connect to host ... port 22: Connection refused), that's the same underlying problem; see SSH Connection Refused for the client-agnostic walkthrough.

What's causing this error

At the TCP level, "Connection refused" means your connection attempt was answered with a reset: the server's kernel (or a firewall in front of it) said "nothing here accepts connections on that port." The real causes, in rough order of frequency:

1. sshd isn't running on the server. It crashed, failed to restart after a config change, or was never installed.
2. The saved PuTTY session has the wrong port. The server was hardened to listen on 2222 but the session still says 22, or the other way round. Saved sessions outlive server changes.
3. Wrong host name or IP. A typo, stale DNS, or a device (Raspberry Pi, VM) that got a new address from DHCP.
4. The server firewall is rejecting the port. ufw, firewalld, or iptables with a REJECT rule, or Windows Defender Firewall on a Windows target.
5. fail2ban banned your IP after a few failed login attempts. The ban rejects new connections before sshd ever sees them.
6. The target has no SSH server at all. A Windows machine without the optional OpenSSH Server feature, or a NAS/appliance that ships with SSH disabled.

How to fix it

Step 1: Check the saved session

Open PuTTY, load the session, and look at the Session panel before blaming the server:

• Host Name (or IP address): is it the current address? If the target is a Pi or a VM on DHCP, its IP may have changed. Ping it or check your router's client list.
• Port: must match what the server listens on. 22 is the default, but hardened servers often use 2222 or similar.
• Connection type: must be SSH. If it's set to Telnet (port 23), you'll get refused by any server that doesn't run a telnet daemon, which today is nearly all of them.

If you fixed anything, click Save before Open, or the session will keep the old values.

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, so it also tells you whether the problem is between you and the server or on the server itself.

For devices on your local network (a Raspberry Pi at 192.168.x.x, a VM), the web checker can't reach them; test from your own machine instead:

PS> Test-NetConnection 192.168.1.50 -Port 22
# TcpTestSucceeded : False  ->  nothing is accepting connections on that port

If the port test succeeds but PuTTY still says refused, you're testing a different host or port than the session actually uses. Go back to step 1.

Step 3: Make sure the SSH service is running

Get onto the server some other way: physical console, your hosting provider's web console (DigitalOcean Console, AWS EC2 Serial Console, Hetzner Rescue), or a monitor and keyboard on a Pi. Then check the service for the server's OS:

$ sudo systemctl status ssh    # Debian/Ubuntu/Raspberry Pi OS
$ sudo systemctl status sshd   # RHEL/CentOS/Fedora
# If inactive or failed:
$ sudo systemctl start ssh
$ sudo systemctl enable ssh    # start on every boot
# If it refuses to start, find the config error:
$ sudo sshd -t
$ sudo journalctl -u ssh -n 50 --no-pager

On Linux, the most common reason sshd fails to start is a syntax error in /etc/ssh/sshd_config; sshd -t prints the exact line.

Step 4: Confirm which port sshd is listening on

Still on the server:

sudo ss -tlnp | grep ssh

You want a line ending in :22 (or your custom port). If it shows :2222 while PuTTY dials 22, either update the Port field in the session or change Port in /etc/ssh/sshd_config back to 22 and restart sshd.

If ss shows sshd bound to a specific address like 192.168.1.5:22 instead of 0.0.0.0:22, a ListenAddress line in sshd_config is restricting it to one interface. Remove or correct it if you're connecting via a different one.

Step 5: Open the firewall

A REJECT rule produces exactly this error even with sshd running. On the server:

# Ubuntu/Debian
$ sudo ufw status
$ sudo ufw allow 22/tcp

# RHEL/CentOS/Fedora
$ sudo firewall-cmd --list-all
$ sudo firewall-cmd --permanent --add-service=ssh
$ sudo firewall-cmd --reload

# Raw iptables (any distro): look for REJECT rules covering port 22
$ sudo iptables -L INPUT -n -v | grep -E "22|ssh"

If you're behind a cloud provider, also check the firewall above the OS (AWS Security Group, DigitalOcean Cloud Firewall, Hetzner firewall): the instance needs an inbound rule for TCP 22. Our firewall rule generator builds the ufw/iptables/firewalld commands if you need a custom port.

Step 6: Check whether fail2ban banned you

A few mistyped passwords earlier in the day are enough. From the server console:

sudo fail2ban-client status sshd
# If your IP is in "Banned IP list":
sudo fail2ban-client set sshd unbanip YOUR.CLIENT.IP

Not sure what your public IP is? It's shown by the SSH port checker, or run curl ifconfig.me from your machine.

Common edge cases