I can't connect to my server: what to check, in order, for SSH and RDP

When a connection drops, the first instinct is usually to reboot the server. A reboot fixes nothing in most cases, and it deletes the best clue you have — the error message on screen. The order below starts with the cheapest and most likely check and ends at the server console; each step eliminates the next one.

Read the error message first

Before you start guessing, read the text on screen. The messages below look similar but are solved in completely different places.

Message	What it means	Where to look
`Connection timed out`	No packet comes back	Network, firewall or a powered-off server — steps 1-3
`Connection refused`	The machine is up, nothing is listening on that port	Service stopped or port changed — step 4
`Permission denied (publickey)`	The service runs, authentication was rejected	Step 5
`Host key verification failed`	The server fingerprint changed	Normal after a reinstall; if you did not reinstall, do not connect
`Connection closed by ... port 22`	The connection was made and then dropped	A limit on the server side or a full disk — step 6

The RDP equivalents read like this: a timeout points at the network layer, "your credentials did not work" at authentication, "you do not have permission to sign in to this computer" at user rights, and a complaint about the session limit at old sessions that were never logged off.

1. Is the server actually running?

Check the power state and the resource graphs for the service in the customer panel. If the CPU graph turns into a flat line at a certain moment, the machine has shut down or frozen — in which case there is nothing to look for on your own computer.

Check the status page at the same time. If there is planned maintenance or a general outage, the diagnosis ends there.

2. Is the problem on your side?

This step is free and answers the question surprisingly often: try connecting over your phone's mobile data.

If mobile data works, the problem is not the server but the network you are on. Most corporate networks and some hotel networks block outbound traffic to ports 22 and 3389.
If no network works, move on to step 3.

The second very common cause: your own IP address changed. If you allowed SSH or RDP only from your own address in the firewall — which is what the server security basics recommend — you lock yourself out the moment your ISP renews that address. Look up your current address in a browser and update the rule.

3. Do packets reach the server at all?

ping -c 5 185.137.98.29
mtr -r -c 30 185.137.98.29

A silent ping does not on its own mean "the server is down"; many setups disable ICMP deliberately. The real information is in the mtr output: if the intermediate hops progress normally and only the last line shows total loss, the path is open and the target is not answering. If the path breaks in the middle, the problem is in the network and cannot be fixed inside the server.

4. Is the port open from the outside?

This is the step that separates the network layer from authentication.

nc -vz 185.137.98.29 22

On Windows, with PowerShell:

Test-NetConnection 185.137.98.29 -Port 3389

The result is unambiguous. If the connection succeeds, the network and firewall are fine and the fault is in authentication. If it times out, a firewall is silently dropping the packet. If you get "refused", the machine is up but nothing is listening on that port.

5. If authentication is rejected

On SSH, ssh -v shows which key was offered and where the login was refused. The two most common causes are permissions that are too open on ~/.ssh and authorized_keys, and several keys on your machine being tried in turn until the attempt limit is hit; both are covered step by step in the guide to connecting over SSH.

On RDP, check in this order: is the user in the "Remote Desktop Users" group, is the account locked out by the lockout policy, has the password expired. The details are in connecting to a Windows server over RDP; on a VDS running Windows Server all of these settings live in the same place.

6. The console: the path that bypasses both the network and SSH

If nothing so far worked, use the console access in the customer panel. The console works independently of the network path and of the SSH service, so it opens even when both are broken. On virtual server plans the console and the reinstall are handled from the panel.

Once you are on the console, four commands close most cases:

systemctl status ssh
ss -tulpn | grep -E ':22|:3389'
ufw status verbose
df -h

Do not skip the last one: a full disk breaks logins. The session fails silently because no temporary file can be written; the symptom looks like a connectivity problem but is not one. How to fix it is in a separate article: the disk is full

When to open a support ticket

This is as far as working on it yourself makes sense. In the following four cases, open a support ticket from the customer panel directly:

The panel shows the server as running but the console does not open either, or the screen is frozen.
The break in the mtr output is at a hop inside the provider's network.
You cannot reach several of your servers at the same time.
You got in over the console, the service is running and the firewall is open, but the port still looks closed from outside.

Attach the exact text of the error message, the IP and port you tried, the mtr output and the time the problem started. Those four details answer every opening question in advance and close the case in one round. If you are not a customer yet, the contact page is faster.

If you have not bought the server yet and are undecided about the access model, the page that puts the management path and the monthly figure for both templates side by side is here: which one fits your work, with current pricing