If Remote Desktop throws “Can’t connect to this computer,” the first thing to check isn’t your firewall — it’s whether the target PC is even awake and has Remote Desktop enabled. In real-world support tickets, more than half of these failures come down to the target machine being asleep or Remote Desktop being toggled off after an update. Work through the checklist below in order and most connections come back within five minutes.
The 8-step checklist, in order
- Confirm the target PC is powered on and not asleep. You can’t wake a PC remotely over standard RDP, so if it’s off or sleeping, the connection will always fail.
- Check Settings > System > Remote Desktop is still turned on. Windows updates occasionally reset this setting silently.
- Verify the IP address or computer name hasn’t changed. A router reboot can hand out a new internal IP.
- Determine whether you’re on the same network or need port forwarding/VPN. Connecting from outside the network requires a forwarded port 3389 and the correct public IP.
- Confirm the “Remote Desktop” rule is allowed in Windows Firewall. Check Control Panel > Windows Defender Firewall > Allowed apps.
- Check Network Level Authentication (NLA) settings. Older clients sometimes fail against NLA — temporarily disabling it can confirm this is the cause.
- Make sure the user account is in the Remote Desktop Users group. Non-admin accounts need to be added explicitly.
- If nothing else works, check whether antivirus or security software is blocking the port. Some antivirus suites block RDP traffic by default.
The cause people miss most often: sleep mode
Of everything on this list, sleep mode is the one people overlook most. Firewall rules and account permissions rarely change once you set them, but sleep settings quietly reassert themselves after Windows updates or power management policy changes. If a PC gets accessed remotely on a regular basis, the real fix is disabling sleep entirely or setting power options to keep the machine awake for remote wake requests.
When standard RDP still won’t cooperate
If you’ve checked the firewall, NLA, and account permissions and the connection still fails, the network topology itself is often the culprit — double NAT, corporate firewalls, or asymmetric routing are hard for an average user to diagnose. In these cases, a cloud-relay remote control SaaS sidesteps the problem entirely since it doesn’t need port forwarding or a public IP.
If you’re managing PCs remotely for a distributed team, or running unattended signage displays at multiple locations, every one of these connection failures translates directly into downtime. On an unattended machine especially, something as small as a sleep setting or a firewall rule can force someone to physically drive out to fix it — which is exactly why it’s worth locking down power settings and network policy before problems show up.
If you’re supporting remote work or IT at scale, take a look at Y-Remote, a browser-based remote access service.