Connection refused
What “Connection refused” usually means
When PuTTY reports Network error: Connection refused, 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.
A TCP SYN reached a host that actively answered with a RST or refusal on the destination port. That usually means nothing is listening on that port, a local firewall rejected with refuse semantics, or you aimed SSH at a port that serves a different protocol. It is not an authentication failure—the SSH handshake never starts.
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.
- PuTTY shows a network error dialog immediately or within a second of Open, citing connection refused.
- No username prompt and no host-key prompt appear because the SSH layer never begins.
- Plink exits non-zero with the same refusal wording when automating the same Host Name and Port.
- A browser or other TCP client to the same IP:port may also fail if the service is down.
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.
- Wrong port (for example SSH moved to 2222 but the saved session still uses 22).
- sshd not running, crashed, or bound only to an internal interface.
- Host-based firewall (firewalld, ufw, nftables, security groups) refusing the client IP.
- Connecting to a load balancer or NAT address that does not forward the SSH port.
- Accidentally selecting Telnet or a raw protocol while targeting an SSH-only port, or the reverse.
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.
- In Session, confirm Host Name and Port; Connection type must be SSH for encrypted remote shells.
- From the same Windows host, test TCP reachability with PowerShell Test-NetConnection or an equivalent to the destination port.
- Try the numeric IP after verifying DNS to rule out a wrong A/AAAA record pointing at an unrelated host.
- Compare with a known-good network path (phone tether or bastion jump) to separate workstation filtering from server-side refusal.
- Ask the server owner to confirm sshd is listening with ss -tlnp and that your source IP is allowed.
- Only after TCP succeeds should you troubleshoot keys under Connection → SSH → Auth.
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
On the server, verify the SSH daemon is active, listening on the expected address, and not rate-limiting with refuse behaviours. Cloud security groups and network ACLs frequently allow HTTPS while forgetting TCP/22 or a custom SSH port. Container platforms may publish SSH only on a private network namespace that your laptop cannot reach without a VPN.
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.