Remote desktop connection error code 0x204 usually means the client cannot reach a usable RDP endpoint, not that your password is wrong. Check the server, RDP service, firewall, port, IP address, and local network in that order to find the failed link quickly.
What error 0x204 means
The 0x204 message is a connection error shown by Remote Desktop clients, including clients on Windows, macOS, and Android. It is a broad symptom: the host may be offline, Remote Desktop may be disabled, the RDP listener may not be running, a firewall may block the port, or the client may be using an old address or wrong port.
It does not identify one exact fault by itself. That is why repeatedly changing the password or reinstalling the client rarely helps when the request is not reaching the Windows machine. Microsoft’s general Remote Desktop troubleshooting procedure follows the same basic path: verify the listener, check the port, and investigate firewalls between the client and server.
Before you start
Have these details ready:
- The server’s current public IP address or hostname.
- The RDP port. The default is TCP 3389, but a server can use another port.
- A Windows administrator account or another account allowed to use Remote Desktop.
- Console or out-of-band access if RDP is your only way into the server.
If the server is new, first check the connection details in this Windows VPS RDP connection walkthrough. Do not assume that a saved connection profile still contains the server’s current IP or port.
Step 1: Run the two-minute checks
Why this helps: simple address and power mistakes are faster to eliminate than server changes.
- Sign in to your hosting client area and confirm that the server is running.
- Copy the current public IPv4 address exactly. Do not use an old IP from a previous order or reinstall.
- Check the client’s PC or computer field. For the default port, enter only the IP address. For a custom port, use
IP-address:port, such as203.0.113.20:3390. - Temporarily turn off a VPN or corporate proxy on the device you are using to connect. Keep Windows Firewall enabled on the server.
- Try once from a second network, such as a phone hotspot. If it works there, the original Wi-Fi, VPN, proxy, or ISP path is the likely cause.
If the same error appears from two unrelated networks and two clients, investigate the server and port before spending time on client settings.
Step 2: Re-enable RDP and the Windows Firewall rules
Why this helps: a disabled RDP setting, stopped TermService service, or disabled inbound rule prevents a connection even when the server itself is online.
Open the server’s console, or ask someone with console access to open PowerShell as Administrator. Run:
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnections -Value 0
Set-Service -Name TermService -StartupType Automatic
Start-Service -Name TermService
Get-NetFirewallRule -DisplayGroup 'Remote Desktop' | Set-NetFirewallRule -Enabled TrueThe first command allows incoming Remote Desktop connections. The next two make sure the Remote Desktop Services service starts and is running. The last command enables the built-in Remote Desktop firewall rules without disabling the whole Windows Firewall.
Check the result:
Get-Service -Name TermService
Get-NetFirewallRule -DisplayGroup 'Remote Desktop' | Select-Object DisplayName, Enabled, ProfileSuccess looks like TermService with a Running status and enabled Remote Desktop rules. Microsoft’s Remote Desktop access instructions also require the host to be on, network-accessible, configured for Remote Desktop, and allowed through its firewall.
Step 3: Confirm the RDP listener and port
Why this helps: a client pointed at port 3389 cannot connect if the server listens on a different port, or if another configuration change stopped the listener.
On the server, check the configured port and the listening socket:
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name PortNumber
Get-NetTCPConnection -State Listen | Where-Object LocalPort -eq 3389
Test-NetConnection -ComputerName 127.0.0.1 -Port 3389For the normal configuration, PortNumber is 3389, a listening entry is present, and the local test reports TcpTestSucceeded : True. If the registry command shows another port, use that port in the client instead of changing the server blindly.
If you intentionally changed the port, confirm that the matching TCP firewall rule exists and that the client uses the same value. Microsoft documents the full process in Change the Remote Desktop listening port. Changing the port alone does not open it through every firewall.
You can also review the related firewall rules with:
Get-NetFirewallRule -DisplayGroup 'Remote Desktop' |
Get-NetFirewallPortFilter |
Select-Object Protocol, LocalPortIf the local test fails, stay on the server: the problem is the service, listener, or local firewall. If the local test succeeds but an outside test fails, check the path between the client and server.
Step 4: Test the connection from the client network
Why this helps: it separates a server-side listener problem from a blocked route, wrong IP, or local network restriction.
From a Windows client, run PowerShell and replace the placeholders:
Test-NetConnection -ComputerName <server-ip> -Port <rdp-port> -InformationLevel DetailedFor a default setup, <rdp-port> is 3389. Read the TcpTestSucceeded result:
| Result | What it tells you | Next action |
|---|---|---|
True | The client can reach that IP and port. | Recheck the client profile, saved credentials, VPN, and app version. |
False | The TCP connection is not completing. | Recheck the IP, port, server firewall, and any provider or network firewall. |
| Wrong IP or DNS address | The name resolves somewhere else or is stale. | Connect directly with the current public IP. |
On macOS or Android, enter the same IP:port value in the Microsoft client. Remove the old saved PC entry, create it again, and confirm that the username is attached to the correct connection. If the IP works but the hostname does not, the issue is name resolution rather than RDP itself.
If a mobile hotspot works but home or office Wi-Fi does not, check that network for a VPN, proxy, outbound RDP restriction, or DNS filtering. If both networks fail, ask the host or network administrator to verify that the server is reachable on the selected port. Do not permanently disable a firewall as a diagnosis; use a controlled port test instead.
Step 5: Use the browser console when RDP is unavailable
Why this helps: a browser console gives you a second path into a VPS so you can repair RDP without an existing RDP session.
For a VPSLake server, sign in at the VPSLake client area and open the server’s browser console. From there, check the service and listener using the commands from Steps 2 and 3. Confirm that:
TermServiceis running.fDenyTSConnectionsis set to0.- The Remote Desktop firewall rules are enabled.
- The configured port matches the port in your client.
The console is especially useful after a firewall change, reinstall, port change, or accidental service stop. If the console works but RDP still returns 0x204, the Windows machine is reachable through the management path and the remaining issue is usually the RDP configuration or network path.
Verify the fix
Run one final test from the device that originally failed:
Test-NetConnection -ComputerName <server-ip> -Port <rdp-port>Then open the RDP client and create a fresh connection using the same IP and port. A successful test should show TcpTestSucceeded : True, followed by the normal username and password prompt. After signing in, save the working address only after confirming that it is the current server IP.
If Windows connects but macOS or Android still shows 0x204, update that client, delete its saved connection, and add the PC again with the explicit IP and port. If every client fails, return to the server listener and firewall checks rather than changing account passwords.
Common mistakes that keep 0x204 coming back
- Using a private IP:
192.168.x.x,10.x.x.x, and similar addresses are normally internal addresses. Use the public address when connecting over the Internet. - Forgetting a custom port: a port change must be reflected in the client and the firewall rule. See how to open a port on Windows Server for the firewall side.
- Testing only one network: a blocked office or home network can look like a dead server. Test from a different connection.
- Disabling the entire firewall: this removes protection and does not prove which rule is wrong. Enable the specific Remote Desktop rules instead.
- Changing several things at once: change one item, rerun the port test, and record whether the result changes. This makes the cause easier to identify.
FAQ
What is Remote Desktop error code 0x204?
It is a client-side connection error that commonly appears when the RDP host, listener, port, firewall, or network path cannot be reached. Check reachability and the RDP service before changing credentials.
How do I fix Microsoft Remote Desktop 0x204 on a Mac?
Confirm the current public IP and port, then create a fresh connection using IP:port. Test from another network, disable any VPN or proxy temporarily, and verify the Windows server’s RDP service and firewall rules through its console.
What port does Remote Desktop use?
RDP uses TCP 3389 by default, and Windows can also use UDP 3389. A server configured with a custom port requires that port in the client and an inbound firewall rule for the same value.
Can I fix 0x204 without an RDP session?
Yes. Use the server’s browser console or another management path to start TermService, enable the Remote Desktop rules, and check the listening port. Once the external port test succeeds, reconnect with a new client profile.
Why does RDP work on one network but not another?
The failing network may use a VPN, proxy, DNS filter, or outbound firewall rule that blocks the selected RDP port. Compare both networks with the same IP and port, then ask the network administrator to allow the connection if the server passes local and external tests.
