RDP over UDP vs TCP: check and choose the transport

Remote Desktop always starts over TCP. Modern Windows can then add a UDP channel for the screen data, which copes better with packet loss and delay. Most of the time this is invisible. When a firewall, VPN or flaky network handles UDP badly, though, sessions can freeze or drop. This guide explains how the two work together, how to check what your session uses, and how to choose.

Before you start

• A Windows VPS or Admin RDP server, with its IP address and login from your VPS provider's control panel.
• Administrator rights on the server for the policy steps.
• A way back in if you change settings: the browser console in your VPS provider's control panel.

How RDP uses TCP and UDP

• TCP is always used. It carries the connection setup, login and security negotiation. If nothing else is available, it carries the whole session.
• UDP is optional. After the TCP connection is up, client and server try to open a UDP channel on the same port number. If that works, most screen updates move to UDP.

UDP helps on long-distance or lossy links, because a lost packet does not stall everything behind it as it does with TCP. When UDP is blocked, RDP quietly stays on TCP. That fallback is normal and not an error.

On a server, Remote Desktop listens on port 3389. TCP 3389 is always required. UDP 3389 is only used if the server firewall and every network in between allow it.

See which transport your session uses

From the client: connect with mstsc to 203.0.113.10:3389. On the connection bar at the top of a full-screen session, click the signal-strength icon. The window that opens shows the connection quality and states whether UDP is enabled.

From the server: the RDP core log records each new connection. In PowerShell as Administrator:

Get-WinEvent -LogName 'Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational' -MaxEvents 50 |
  Where-Object { $_.Id -eq 131 -or $_.Message -match 'UDP' } |
  Format-Table TimeCreated, Id, Message -Wrap

Event 131 says the server accepted a new TCP connection. An event mentioning UDP a moment after it means the UDP channel came up as well. Look at the entries around the time of your last connection.

Check what the server is listening on:

Get-NetTCPConnection -LocalPort 3389 -State Listen
Get-NetUDPEndpoint -LocalPort 3389

A result from the second command means the server is ready to accept UDP on 3389.

Firewall rules for each transport

Servers ship with an inbound rule for TCP 3389. Never remove it. To see whether UDP is also allowed:

Get-NetFirewallPortFilter |
  Where-Object LocalPort -eq 3389 |
  Format-Table Protocol, LocalPort, InstanceID

If you want UDP and only TCP is listed, add a UDP rule:

New-NetFirewallRule -DisplayName "Remote Desktop (UDP 3389)" `
  -Direction Inbound -Protocol UDP -LocalPort 3389 -Action Allow

If you have limited the TCP rule to certain source addresses, give the UDP rule the same -RemoteAddress list. See Check the Windows Firewall rule for RDP port 3389.

Force TCP only when UDP misbehaves

Signs that UDP is causing trouble include sessions that freeze for several seconds and recover, black screens after connecting over a VPN, or drops on one network but not another.

On the server (affects every client):

1. Run gpedit.msc.
2. Go to Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Connections.
3. Open Select RDP transport protocols, set it to Enabled, and choose Use only TCP.
4. Run gpupdate /force, then sign out and reconnect.

On one client only (your own computer):

1. Run gpedit.msc on your local PC (Windows Pro or higher).
2. Go to Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Connection Client.
3. Set Turn Off UDP On Client to Enabled.
4. Run gpupdate /force and reconnect.

The client-side change is the safer test, because it only affects you. Try it first, and change the server only if every user has the problem.

Check it works

After your change, reconnect and click the signal icon on the connection bar again. With TCP forced, it should no longer report UDP. Use the session for a while on the network that caused trouble. Freezes that stop after forcing TCP confirm UDP was the cause.

To go back to the default, set the policies to Not configured and run gpupdate /force.

Troubleshooting

• UDP never comes up: the server firewall has no UDP 3389 rule, or a network between you blocks it. RDP over TCP still works.
• Freezes only on VPN or mobile networks: UDP packets are being dropped or fragmented. Force TCP on that client.
• Cannot connect at all: this is not a UDP problem, because TCP comes first. Follow Fix Remote Desktop can't connect.
• Policy change had no effect: you disconnected instead of signing out, or the policy is overridden by a domain policy. Sign out fully and check with gpresult /r.

Next steps

• Tune visual settings for weak links: Speed up Remote Desktop on a slow connection.
• Fix random drops: Fix Remote Desktop that keeps disconnecting.