You double-click the RDP shortcut, type in your VPS's IP, and instead of the familiar Windows login screen you get "Remote Desktop can't connect to the remote computer" — or the connection just spins for thirty seconds and times out. If you manage a Windows VPS, this happens eventually, and the annoying part is that RDP is usually the only way in, so when it breaks you're locked out of the one tool you'd normally use to fix it. Here's how to work through it methodically.
Symptom: What "Can't Connect" Actually Looks Like
It's not always the same error. You might see:
- "Remote Desktop can't connect to the remote computer" — a generic client-side timeout
- "An authentication error has occurred... The Network Level Authentication (NLA) is not enabled" or a CredSSP encryption oracle warning
- The connection accepts your password, then immediately drops back to the login box
- A black screen after login that never loads the desktop
- "This computer can't connect to the remote computer" with no further detail at all
Each of these points at a different layer — client, network, firewall, or the RDP service itself — so the fix depends on which one you're actually hitting.
Cause 1: The Remote Desktop Service Isn't Running
If a Windows Update reboot got interrupted, or something crashed the Terminal Services process, RDP itself can be down even though the VPS is up and pingable. You can't check this over RDP obviously, so you'll need your hosting provider's VNC/console access (SkyServer's VPS panel has this under "Console" — use it whenever RDP is the thing that's broken).
From the console, open an elevated PowerShell and check:
Get-Service TermService, UmRdpService, SessionEnv | Select-Object Name, Status
If any show Stopped, start them:
Start-Service TermService
Set-Service TermService -StartupType Automatic
Also confirm RDP is actually enabled at the OS level — it's easy for a group policy push or a hardening script to have quietly disabled it:
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' -Name 'fDenyTSConnections'
A value of 1 means RDP is disabled. Set it back to 0:
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' -Name 'fDenyTSConnections' -Value 0
Cause 2: Windows Firewall Is Blocking Port 3389
A Windows Update, a third-party antivirus install, or someone running "harden this server" scripts can silently reset firewall rules. Check the built-in RDP rule group from the console:
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Select-Object DisplayName, Enabled, Direction
If the inbound TCP rule shows Enabled: False, turn it back on:
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"
If you changed the RDP listening port away from the default 3389 (a common hardening move, since bots hammer 3389 constantly), remember the firewall rule and the registry PortNumber value both need to match — and so does whatever firewall your hosting provider runs in front of the VPS.
Cause 3: The Provider-Level Firewall or Security Group Is in the Way
This one trips people up because it's invisible from inside the VPS entirely. Most VPS platforms — SkyServer included — let you attach a network-level firewall or security group in the control panel, separate from Windows Firewall. If someone tightened that ruleset (or it defaulted to "deny all inbound" after a rebuild) and 3389 isn't explicitly allowed from your IP or "any," Windows will never even see the connection attempt. Check your VPS panel's firewall/security tab first — it's a thirty-second check and rules out an entire category of the problem before you go digging inside the OS.
Cause 4: Network Level Authentication (NLA) Mismatch
NLA requires the client to authenticate before a full session is established — it's more secure, but it breaks compatibility with very old RDP clients (some Linux rdesktop builds, older mobile apps) that don't support it. If your error specifically mentions NLA or CredSSP, you have two options: update the client you're connecting from (almost always the right fix), or, if you genuinely can't, temporarily relax the requirement from the console:
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'UserAuthentication' -Value 0
Turn it back to 1 once you've swapped to a modern client — leaving NLA off is a real reduction in security since it exposes the login screen to unauthenticated network attempts.
Cause 5: You've Hit the Concurrent Session Limit
Standard Windows Server (not Remote Desktop Services) allows two concurrent administrative RDP sessions. If a previous session from you — or a colleague — didn't log off cleanly and is just sitting disconnected, a third connection attempt gets refused or silently dropped. From the console, list active sessions:
query session
Then log off the stale one by its session ID:
logoff
If you frequently need more than two simultaneous admin connections, that's a sign you actually need Remote Desktop Session Host licensing, not a workaround.
Cause 6: DNS or IP Pointing Somewhere Else
If you connect using a hostname rather than a raw IP, and the VPS was recently rebuilt, migrated, or its IP was reassigned, your hostname may simply be resolving to the old address. Confirm with:
nslookup vps.yourdomain.com
and compare it against the IP shown in your SkyServer VPS panel. This is a quick check that's easy to skip because everything else about the troubleshooting looks like a server-side problem.
Quick Diagnostic Table
| What you see | Most likely cause | Where to check |
|---|---|---|
| Connection times out, no error text | Firewall (Windows or provider-level) blocking 3389 | VPS panel firewall, then Get-NetFirewallRule |
| "Can't connect" immediately, every time | TermService stopped or RDP disabled in registry | Console → Get-Service TermService |
| NLA/CredSSP authentication error | Old RDP client vs. modern NLA requirement | Update client software first |
| Password accepted, then dropped back to login | Session limit reached | Console → query session |
| Worked yesterday, dead today, hostname used | DNS/IP mismatch after a rebuild | nslookup vs. VPS panel IP |
Prevention: Don't Let This Lock You Out Again
The real problem with RDP breaking isn't the fix — it's usually quick. It's that RDP is often the only access path people set up, so when it fails they have no way in at all. A few habits fix that:
- Know where your provider's console/VNC access is before you need it. On SkyServer, that's the "Console" tab in the VPS panel — bookmark it.
- If you change the RDP port, update both Windows Firewall and the provider-level firewall in the same maintenance window, and test from a second device before closing the original session.
- Keep RDP client software current, especially if you connect from a Mac, Linux box, or mobile device where NLA support lags behind Windows itself.
- Log off cleanly instead of just closing the RDP window — it avoids piling up stale sessions that eat your two-connection limit.
- If more than one person regularly needs RDP access, plan for RDS licensing rather than fighting the two-session cap indefinitely.
Frequently Asked Questions
My VPS responds to ping but RDP still won't connect — what does that mean?
Ping success only confirms the network path and that the OS is up; it says nothing about port 3389 specifically. This points squarely at either the Remote Desktop service being stopped, or a firewall (Windows or provider-level) blocking that one port while everything else on the server is fine.
Can I fix RDP without console/VNC access?
Only if the problem is purely client-side — an old RDP client, wrong port in your connection settings, or stale DNS. Anything involving the service, the registry, or the in-OS firewall requires getting into the server some other way, since RDP being broken means RDP can't be used to fix RDP.
Is it safe to just disable Windows Firewall entirely to get RDP working again?
No — treat that as a last-resort diagnostic step only, and turn it back on immediately after confirming that's the cause. A Windows Server with no firewall and RDP exposed to the internet gets scanned and attacked within minutes. If firewall rules are the culprit, fix the specific rule rather than turning protection off.
Why did this start happening right after a Windows Update?
Cumulative updates occasionally reset firewall rule groups to their defaults, or leave a pending reboot that never completed, which can leave TermService in a stopped state. It's common enough that "check Windows Firewall rules and TermService status" should be your first move any time RDP breaks shortly after patching.
How do I stop this from happening again on a new VPS?
Set it up right the first time: confirm console access works before you need it, enable NLA and keep it on, allow 3389 (or your custom port) explicitly in both firewalls, and avoid running random "security hardening" scripts against a production server without reading exactly what they change first.
