Fix Unstable Windows Server 2022 RDP connections from Vietnam

You are in Singapore, the US, or Europe, and the RDP session to your Windows Server 2022 VPS in Vietnam keeps freezing then dropping after a few minutes. The server itself is fine, monitoring shows no crash, but the session dies exactly when you need it. This is one of the most common tickets for anyone running a Windows VPS in Vietnam from abroad, and it is rarely the server. This guide walks through the actual causes and the fixes that work in 2026.

Why RDP is unstable over long distance

RDP was designed for LANs. The protocol is chatty, and Windows Server 2022 defaults make some assumptions about latency and packet loss that simply do not hold when your client sits on the other side of the planet from a Vietnam datacenter. The symptom set is consistent: session connects, works for a while, then freezes for 10-30 seconds and drops, or you get the grey "Connection was interrupted" screen.

The three dominant causes are MTU issues on the path, UDP being blocked or throttled somewhere between you and the server, and Network Level Authentication (NLA) behaving badly under latency. A fourth cause is an aggressive network timeout on the provider side, but that is rarer with KVM virtualization. Let us test each one in order.

Step 1: Diagnose the network path first

Before touching anything on the Windows side, confirm whether the problem is the path or the server. Run a continuous ping with timestamps from your local machine to the VPS public IPv4.

ping -t YOUR_VPS_IP   (Windows client)
ping YOUR_VPS_IP      (Linux/macOS client, press Ctrl+C to stop)

Watch for three patterns: timeouts, high jitter (round-trip times jumping between 50 ms and 300 ms), and packet loss above 1-2%. Any of these explains the RDP drops. Vietnam domestic bandwidth is 100 Mbps by default on a 1 Gbps port, but traffic from abroad crosses international transit, and the far-end network matters just as much. If ping shows 5%+ loss, no Windows setting will fix it.

Next, test with a larger packet to reveal MTU clamping problems. This is a frequent culprit on international routes into Vietnam.

ping -f -l 1400 YOUR_VPS_IP   (Windows: no-fragment, 1400 byte payload)
ping -M do -s 1400 YOUR_VPS_IP (Linux/macOS)

If 1400 bytes works but 1472 fails, the path has a lower MTU and the server is not clamping ICMP or TCP MSS properly. The fix is usually on the router or firewall in front of the VPS, not on Windows itself.

VERIFY: a stable ping under 2% loss and RTT within 20% of the average for your route

Step 2: Check the RDP service state and logs

Log into the server through the provider control panel (thueVPS offers KVM console access, use it if RDP is completely dead) and confirm the RDP service is running and listening.

Get-Service TermService | Format-List Status, StartType
Get-NetTCPConnection -LocalPort 3389 -State Listen

Both should show Running and a listening socket. Then pull the RDP-specific event log entries around the time of a disconnect.

Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-TerminalServices-LocalSessionManager/Operational'; StartTime=(Get-Date).AddHours(-2)} | Select-Object TimeCreated, Id, LevelDisplayName, Message | Format-List

Event ID 40 is a benign disconnect. Event ID 65 or 39 with an error code points to a real failure. A recurring pattern of timeouts in the logs combined with clean ping results means the issue is the RDP stack configuration, not the wire.

Step 3: Fix MTU and TCP settings on Windows Server 2022

If the ping test in Step 1 showed fragmentation issues, set a sane MTU on the Windows side and enable TCP auto-tuning which handles most long-distance paths well on Server 2022.

netsh interface ipv4 show subinterfaces
netsh interface ipv4 set subinterface "Ethernet" mtu=1400 store=persistent
netsh interface tcp set global autotuninglevel=normal

Replace "Ethernet" with the actual interface name from the first command. An MTU of 1400 is conservative but safe for international routes; 1450 works on most VPN and datacenter paths. Do not go below 1300 without reason, small packets add overhead on every transfer.

The auto-tuning setting is the one that matters most. Server 2022 defaults to normal, but some provider templates or earlier hardening guides set it to disabled or highlyrestricted, which destroys throughput on high-latency links.

VERIFY:

netsh interface tcp show global

Look for Receive Window Auto-Tuning Level : normal.

Step 4: Enable or disable UDP for RDP, depending on your path

Windows Server 2022 supports RDP over UDP (port 3389), which is meant to improve performance. In practice, over international routes into Vietnam, UDP is frequently throttled or blocked by intermediate firewalls, and Windows does not fall back cleanly. The result is the session hanging until the TCP fallback kicks in.

If you already have UDP enabled and see freezes, disable it:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations" /v DWMFRAMEINTERVAL /t REG_DWORD /d 15 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations" /v fUseUdp /t REG_DWORD /d 0 /f
Restart-Service TermService -Force

Setting fUseUdp to 0 forces pure TCP RDP. This is the single most effective change for unstable connections from overseas. UDP gives you a smoother experience on clean low-latency links, but on a path with packet loss it makes things worse, and the protocol's UDP loss-recovery is weak compared to TCP.

After restarting the service, reconnect and run a longer session. If the drops stop, you found the culprit.

VERIFY: session stays connected for 30+ minutes of active use without the grey screen.

Step 5: Review NLA and keep-alive settings

Network Level Authentication adds a security layer and is on by default, and you should keep it on. But under high latency NLA can cause the session to appear frozen during the initial handshake or when the server re-validates the session. The practical fix is a keep-alive so the server does not drop idle or half-open sessions.

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v KeepAliveEnable /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v KeepAliveInterval /t REG_DWORD /d 60000 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v MaxIdleTime /t REG_DWORD /d 0 /f

KeepAliveInterval of 60000 ms (60 seconds) tells the server to send a keep-alive every minute, which prevents NAT and firewall timeouts on the return path from killing the session. MaxIdleTime of 0 disables the idle session limit, so you do not get kicked for inactivity while reading a long document.

Do not disable NLA. The security benefit is real, and with UDP off and keep-alives on, NLA latency is a non-issue.

Step 6: Confirm Windows Firewall allows both TCP and UDP 3389

A common mistake is opening only one protocol in the Windows Firewall. If you leave UDP enabled on the server (you should disable it per Step 4, but if you keep it), both must be open. Even with UDP off, confirm the built-in rule covers TCP.

Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Select-Object DisplayName, Enabled, Direction, Action

Then check the actual port binding:

Get-NetFirewallPortFilter -Protocol TCP | Where-Object {$_.LocalPort -eq 3389}

If the rule is missing, create it explicitly:

New-NetFirewallRule -DisplayName "RDP-TCP" -Direction Inbound -Protocol TCP -LocalPort 3389 -Action Allow -Profile Any

VERIFY:

Test-NetConnection YOUR_VPS_IP -Port 3389

Run this from your local machine. Ensure it reports TcpTestSucceeded : True.

Step 7: Change the RDP port (optional but recommended)

Scanning bots hammer port 3389 constantly, and on a public IPv4 in Vietnam the RDP brute-force traffic starts within minutes of the OS install. An unstable session is not caused by scanners directly, but connection attempts consume resources and can interfere with active sessions on weak VPS plans.

Change the port and block the old one in the firewall:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v PortNumber /t REG_DWORD /d 3390 /f
New-NetFirewallRule -DisplayName "RDP-TCP-3390" -Direction Inbound -Protocol TCP -LocalPort 3390 -Action Allow -Profile Any
Restart-Service TermService -Force

Pick a port above 1024, avoid obvious ones like 3389, 3390, 8080. Then connect with mstsc /v:YOUR_VPS_IP:3390. Update your client shortcut and any monitoring tool that checks port 3389.

Troubleshooting common failures

Session connects then drops after exactly 5 minutes. This is almost always an intermediate NAT or firewall timeout, not the server. The keep-alive settings in Step 5 fix it. If they do not, check your local router for an idle timeout on the outbound connection.

RDP connects but is extremely slow, unusable. This points to low bandwidth or high latency on the path, not the RDP stack. Run the ping test again. If RTT is above 250-300 ms or loss is above 3%, no setting on the server helps. Consider a relay or a VPS located closer to you that forwards RDP.

Cannot connect at all after changing the port. You blocked 3389 before testing the new port, or the firewall rule for the new port did not apply. Log in via the KVM console from the provider panel, verify the rule exists, and confirm the service restarted. This is why you always change the port while you still have a console path.

Everything checks out but it still drops. Check for a VPN or tunneling layer between you and the server. Any encapsulation (WireGuard, OpenVPN, IPSec) reduces the effective MTU and adds latency, which can trigger RDP instability even when the direct path is clean. Lower the MTU on the tunnel interface to 1420 or lower.

Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational'; StartTime=(Get-Date).AddHours(-4)} | Format-Table TimeCreated, Id, Message -Wrap

When to consider a different approach

You can chase RDP settings only so far. If the path itself is bad, the cleanest fix is to not run RDP across the ocean at all. Options that work well in production: an SSH tunnel to the Windows VPS if you have OpenSSH Server installed, or a VPN you control (WireGuard on a small Linux jump box in the same Vietnam datacenter, then RDP over the encrypted tunnel). This avoids the international UDP path entirely and gives you a stable session on TCP.

For a quick remote-admin need, the KVM console from your VPS provider control panel is always available and does not depend on the RDP stack. thueVPS includes that with every Windows VPS, and a dedicated server gives you the same console via IPKVM for hardware-level access.

If you run the fix and the disconnects persist while ping stays clean, the bottleneck is almost certainly the segment between your location and Vietnam, and you should measure it over a full day before blaming the server. That measurement, not guesswork, tells you whether a setting change or a topology change is the right answer.

FAQ

Related articles

• Secure RDP configuration for a Windows VPS
• Securing RDP on a public IP: the four settings that matter
• Sizing RAM for a Windows Server VPS: why 2 GB is never enough
• Windows Server vs Linux for a small business VPS