Optimize Windows Server 2022 RDP Stability from China to Vietnam VPS

You connect to your Windows Server 2022 VPS in Vietnam from China, and the session dies every few minutes. Typing lags, the screen freezes, then "Connection was lost". You reconnect, lose your work, and repeat. This is not a broken VPS. It is a protocol problem: RDP was built for a LAN, and your traffic is crossing international transit with higher latency and real packet loss. This guide fixes the Windows Server 2022 RDP stability from China to Vietnam VPS by tuning the server, not by blaming the network.

Why RDP is unstable on a China to Vietnam path

RDP assumes a low-latency, low-loss link. A session inside a datacenter feels instant. From China to Vietnam, your packets cross international gateways, and latency sits far higher than the 20-30 ms RDP expects. When packets drop, RDP's congestion behavior kicks in, it backs off, and your session stutters or dies.

The bigger trap is MTU. The default Ethernet MTU is 1500 bytes, but the tunnel between China and Vietnam often carries an extra header (PPPoE, GRE, or a VPN wrapper). When a 1500-byte frame hits that tunnel, it fragments or drops silently. The server keeps sending big frames, they die in the middle, and the session hangs. This is the single most common cause of "RDP connects but then freezes".

There is also a version gap. Windows Server 2022 defaults to the newer RDP protocol stack which aggressively uses UDP for graphics. UDP has no retransmission. On a lossy international path, that means visual corruption and freezes. You need to decide: keep UDP and tune it, or pin the session to TCP and lose some smoothness but gain reliability.

Step 1 - Set the MTU to 1400 on the Windows Server 2022 VPS

Lowering the MTU is the highest-impact fix for RDP stability from China. A smaller MTU means no fragmentation on the international path, which removes the silent packet drops that kill sessions. Open PowerShell as Administrator and run:

netsh interface ipv4 show subinterfaces

Find the interface name (usually "Ethernet" or "Ethernet Instance 0"). Then set the MTU to 1400:

netsh interface ipv4 set subinterface "Ethernet" mtu=1400 store=persistent

Why 1400? It leaves headroom for a GRE or PPPoE header while staying large enough for efficient throughput. Some guides say 1350, and that also works. The point is to eliminate fragmentation on the international leg.

Verify: run netsh interface ipv4 show subinterfaces again and confirm the MTU column shows 1400. Then reboot the VPS or at least restart the interface so the new value applies to the TCP stack.

Step 2 - Tune TCP timers for a high-latency link

Windows default TCP settings assume a low-latency LAN or a well-behaved domestic link. From China to Vietnam, the default retransmission timeout is too aggressive. When one packet is lost, Windows waits too long before retransmitting, and the RDP session appears frozen. You can shorten that wait with an autotuning-level change and a registry tweak on the Windows Server 2022 VPS.

First, set the TCP autotuning level to normal, which is the default anyway, and confirm it is not disabled:

netsh interface tcp set global autotuninglevel=normal

Then open the registry for the TCP timestamps and initial RTO. In PowerShell:

New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces" -ErrorAction SilentlyContinue
# Find your interface GUID first with:
Get-NetAdapter | Format-Table Name, ifIndex, InterfaceGuid

Then set the initial RTO (retransmission timeout) to a lower value. The default is 3000 ms. For a cross-border path, 1000-1500 ms recovers faster from loss without spamming retransmits. Set it in the registry under the matching interface GUID:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{YOUR-GUID}" -Name "InitialRTT" -Value 1000 -Type DWord
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{YOUR-GUID}" -Name "TcpAckFrequency" -Value 1 -Type DWord

TcpAckFrequency=1 forces an immediate ACK for every packet, which helps on high-latency links where delayed ACKs double the round-trip time. Replace {YOUR-GUID} with the GUID from the command above.

Verify: reboot the VPS, reconnect RDP, and watch a file transfer or a scrolling window for 5 minutes. If it stays alive, the timers are behaving.

Step 3 - Choose TCP-only or tuned UDP for RemoteFX

Windows Server 2022 RDP uses UDP for the graphics channel by default. On a clean low-latency link, that is smooth. From China, UDP loss means visual corruption that does not self-heal the way TCP retransmission does. You have two options.

Option A, force TCP-only for maximum stability. In the Group Policy editor on the Windows Server 2022 VPS:

gpedit.msc

Navigate to: Computer Configuration, Administrative Templates, Windows Components, Remote Desktop Services, Remote Desktop Session Host, Connections. Set "Select RDP transport protocols" to "Use only TCP". This removes UDP entirely. The session survives packet loss because TCP retransmits. Slight input lag is the trade-off.

Option B, keep UDP but raise the Network Level Authentication (NLA) timeout and the session idle limits so a brief network blip does not kill the session. Open the registry:

New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" -Force
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" -Name "fPolicyEncryptRPCTraffic" -Value 1 -Type DWord

I recommend Option A for users in China. A slightly less smooth cursor is far better than a session that dies every 10 minutes. You can keep UDP enabled on a domestic Vietnam connection, where loss is near zero, and switch to TCP-only only for the China route.

Verify: reconnect and run qwinsta in an elevated command prompt. If the session shows "Active" and stays that way for 15 minutes, the transport change worked.

Step 4 - Open the right ports and disable network-level auth timeouts

RDP needs TCP 3389 and, if you kept UDP, UDP 3389. The Windows Firewall on your Windows Server 2022 VPS must allow both, or the UDP path will silently fail and the session will keep dropping back to TCP. Check it with:

netsh advfirewall firewall show rule name="Remote Desktop"

The standard "Remote Desktop" rule opens both TCP and UDP 3389. If it only shows TCP, add the UDP rule:

netsh advfirewall firewall add rule name="RDP UDP" dir=in action=allow protocol=UDP localport=3389

Next, the NLA timeout. When you connect from China, the TLS handshake and credential validation can take longer than the local default. The server gives up and the client shows "Connection was denied". Extend the session timeout in the registry:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" -Name "MaxIdleTime" -Value 0 -Type DWord
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" -Name "MaxConnectionTime" -Value 0 -Type DWord

Setting both to 0 disables the idle and connection time limits. A user in China who drops for 30 seconds will reconnect to a live session instead of a dead one.

Verify: connect, let the session idle for 5 minutes, then briefly disconnect your local network for 10 seconds and reconnect. You should resume the same session instead of getting a new login screen.

RDP over public internet vs the alternatives

Even with all the tuning above, RDP over the public internet from China to Vietnam is a best-effort ride. The path can hit congestion during peak hours, and no registry tweak fixes a saturated international gateway. For critical work, consider layering a VPN tunnel or a dedicated access path on top of the RDP port.

WireGuard or OpenVPN over the same VPS gives you two benefits: you control the MTU end to end, and you mask the RDP port from scanners. When you run RDP inside a WireGuard tunnel, the MTU of the tunnel interface (typically 1420) already prevents fragmentation, and the packet loss inside the tunnel behaves like a normal TCP stream. This is why many teams in China run RDP through a VPN even when they are not hiding anything.

That said, a VPN adds its own overhead. If latency from China to your Vietnam VPS is already above 100 ms, a WireGuard tunnel adds maybe 5-10 ms, which is acceptable. The stability gain from a consistent MTU and no port scanning noise usually outweighs the small latency increase. A Windows VPS with a dedicated IPv4 in Vietnam is the right foundation for this, since you need a stable public address to build either a direct RDP rule or a VPN tunnel on top.

What actually matters for China to Vietnam RDP: a summary table

Why a Vietnam VPS for users in China

Latency from China to Vietnam is physically lower than China to the US or Europe. A session to a US server at 180-220 ms is nearly unusable, while a Vietnam route often sits in the 60-120 ms band depending on the carrier. That is still above RDP's comfort zone, which is why the MTU and timer tuning above matter. But the starting point is far better.

A Vietnam VPS with a local IPv4 also gives you a consistent routing path. The international pool is shared, so you should not expect a dedicated international circuit, but the domestic leg inside Vietnam is on a 100 Mbps port with no data cap. Your bottleneck is the international transit, not the VPS itself. If you need a fixed, clean address for your RDP gateway or a VPN endpoint, a monthly-billing Linux VPS or a Windows VPS with a dedicated IPv4 is the practical choice.

Before you blame your VPS provider, run a 10-minute ping test from your China machine to the server IP. If packet loss stays under 1% and latency is stable, the network is fine and the issue is the RDP stack. If loss is high, the problem is the international path, and no server-side setting fixes it entirely. That is the moment to consider a tunnel or a different transit provider.

Troubleshooting common RDP failures on a Windows Server 2022 VPS

The connection is denied immediately, before any login prompt

This is usually NLA, not a network issue. The server tries to validate credentials before showing the desktop, and a slow international handshake times out. Check the event log on the Windows Server 2022 VPS:

Get-WinEvent -LogName "Microsoft-Windows-TerminalServices-LocalSessionManager/Operational" | Select-Object -First 5

If you see Event ID 21 or 39, NLA is failing. Extend the registry timeout as in Step 4, or temporarily disable NLA (not recommended for security) to confirm the diagnosis.

The screen freezes but the session does not disconnect

That is packet loss on the UDP graphics channel. The TCP control channel is alive, so the session stays, but the visual stream is corrupt. Force TCP-only as in Step 3 and the freeze turns into a slight lag instead of a frozen frame.

Typing registers 2-3 seconds late, constantly

This is pure latency plus the default Nagle-like delayed ACK behavior. Set TcpAckFrequency to 1 as in Step 2, and consider lowering the display resolution and color depth in the RDP client. A 1920x1080 32-bit session generates far more graphics traffic than 1366x768 16-bit, and that traffic competes with your typing input on the same international link.

FAQ

Related articles

• Windows Server vs Linux for a small business VPS
• Sizing RAM for a Windows Server VPS
• Set up a WireGuard VPN on your VPS in 10 minutes