How to solve the problem of Network error: Connection refused when connecting with putty?

The "Connection refused" error in PuTTY is a definitive indication that the target server's SSH daemon is actively rejecting the TCP connection attempt on the specified port, typically port 22. This is a transport-layer failure distinct from a timeout, meaning the client's SYN packet reached a live host, but that host has no service listening for SSH connections. The immediate resolution path requires methodical verification of three core components: the network path to the host, the host's operational status and firewall configuration, and the state of the SSH service itself. Begin by confirming the target's IP address or hostname is correct and that you can establish basic network reachability, for instance, via a `ping` command, though note that ICMP may be filtered. Crucially, use a tool like `telnet` or PuTTY's own raw connection mode to the SSH port; a "Connection refused" message from these tools confirms the diagnosis, while a timeout suggests a blocking firewall.

The primary technical mechanisms behind this refusal are typically local to the server. First, the SSH daemon (`sshd`) may not be running. On the server, checking its status via system commands (e.g., `systemctl status sshd` on Linux) is essential. Second, the daemon might be configured to listen on a non-standard port or only on specific network interfaces, necessitating a check of its configuration file (`sshd_config`) for the `Port` and `ListenAddress` directives. Third, a host-based firewall—such as `iptables`, `nftables`, or `firewalld` on Linux, or the Windows Defender Firewall—is often the culprit, having rules that drop or reject incoming connections to the SSH port. A temporary diagnostic step is to cautiously disable the firewall for a brief moment to test connectivity, though this should be done with an understanding of the security implications and only as a test.

Beyond local service configuration, network-level intermediaries can induce this error. An intermediary firewall or security group (especially in cloud environments like AWS, GCP, or Azure) may be configured to reject the connection. In these scenarios, the refusal is functionally identical from the client's perspective. You must verify that the cloud security group or network ACL associated with the server instance explicitly allows inbound traffic from your source IP address to the correct SSH port. For on-premises networks, a network firewall or even an intrusion prevention system (IPS) configured to block the connection could be responsible. Furthermore, if the server is behind a NAT gateway or load balancer, the port forwarding rules must be correctly mapped to the internal server's IP and port.

The implications of this error are fundamentally about access control and service state visibility. A "Connection refused" is often a security feature in action, preventing unauthorized access. The systematic troubleshooting process—verifying service status, reviewing local and network firewall policies, and confirming listener configuration—not only resolves the immediate issue but also reinforces proper operational hygiene. Successfully establishing a connection after this error typically involves starting the `sshd` service, adjusting a firewall rule, or correcting a port number, each action requiring appropriate administrative privileges on the server or its governing cloud console. Persistent issues may indicate deeper problems such as port conflicts or kernel-level filtering, but the initial triage outlined here resolves the vast majority of cases.