Windows

Optimize Windows Server 2022 RDP for Chinese Teams Accessing Vietnam VPS

BM BizMaC Team Sep 05, 2026 12 min read

A Chinese colleague connects to your Windows Server 2022 in Hanoi, and the session crawls. Typing lags, the screen repaints in waves, and the team blames the server. It is rarely the server CPU. RDP from China to a Vietnam VPS crosses international transit, and the default Windows Server 2022 RDP stack is not tuned for that path. This guide walks through the settings that actually move the latency needle, in the order you should apply them, with verify commands after each change. It assumes a Windows Server 2022 VPS with a Windows VPS public IPv4 and Administrator access.

Prerequisites

  • A Windows Server 2022 VPS with Administrator access. If you have not deployed one yet, a Windows VPS with RDP from thueVPS provisions in minutes with a dedicated IPv4 located in Vietnam.
  • A test client on the China side. Install the Microsoft Remote Desktop client (Windows, macOS, or iOS all work) before you start.
  • A baseline latency reading. Run ping -t <server-ip> from the Chinese client for 60 seconds and note the average. This is your before number.

Why RDP from China to Vietnam is slow by default

RDP is a remote display protocol. Every mouse move, keystroke, and screen update travels as a packet over the network, and the protocol assumes a reasonably clean path with modest latency. A China-to-Vietnam route crosses international transit, often through Hong Kong or Singapore, and latency lands anywhere from 80 ms to over 200 ms depending on the carrier and the time of day. At that latency, the default Windows Server 2022 settings start to feel unresponsive.

The defaults that hurt you most: Network Level Authentication renegotiation overhead, a TCP stack tuned for LAN conditions, and a desktop experience profile that tries to send full-fidelity graphics over a congested pipe. The good news is each of these has a precise fix. None require third-party software, and all are native Group Policy or registry settings you can apply in a few minutes. Before touching anything, note that Windows Server RDP performance depends as much on the network path as on server settings, so apply the fixes and re-measure rather than assuming one magic switch.

RDP 卡顿通常不是服务器性能问题，而是默认设置未针对跨国网络优化。

RDP lag is usually not a server performance problem, it is the default stack not being tuned for a cross-border network path.

How to measure RDP latency before you start tuning

You need a number to compare against, not a feeling. From the Chinese client, open PowerShell and run a sustained ping to the VPS public IP. Do not use the RDP session itself to measure, the session traffic competes with your test.

ping -t 203.113.xx.xx

Let it run for 60 seconds, then press Ctrl+C. Record the average. A value under 100 ms is workable, 100-150 ms is tolerable with the tuning below, and above 150 ms means the network path itself needs attention before server settings will help much.

You also want to confirm which RDP transport is in use. Windows Server 2022 supports UDP, and UDP is dramatically better for interactive sessions because it avoids TCP retransmission stalls. Check the negotiated transport in the RDP session: open the connection bar, click the info icon, and look for the transport line. It should read UDP. If it reads TCP, the fixes in the next sections will help, but you should also check that UDP port 3389 is not blocked on the path, some firewalls in China drop UDP selectively.

Step 1 - Enable UDP and force the modern transport

RDP over UDP is the single biggest win for interactive feel on a high-latency path. Windows Server 2022 enables it by default, but a Group Policy or a misconfigured client can force TCP. Set the policy to allow both and let the client negotiate UDP.

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 both TCP and UDP". Then open an elevated PowerShell and restart the service:

Restart-Service TermService -Force

Verify: reconnect from the Chinese client, open the connection bar info icon, and confirm the transport line reads UDP. If it still shows TCP, the client itself may be forcing TCP. In the Windows Remote Desktop client, the default is to use UDP when available, so this is rarely the client side.

Step 2 - Tune the TCP stack for long fat networks

Windows Server 2022 default TCP settings assume a low-latency LAN. For a path from China to Vietnam, you want auto-tuning level set to normal (it usually is) and, more importantly, you want to confirm the receive window autotuning is not disabled. Some "optimization" scripts found online disable it, which caps throughput badly on high-latency paths.

netsh interface tcp show global

Look at the "Receive Window Auto-Tuning Level" line. It must read "normal". If it reads "disabled", enable it:

netsh interface tcp set global autotuninglevel=normal

Next, enable the experimental TCP congestion provider that helps on lossy international links. Windows Server 2022 includes CUBIC, and it works well on paths with some packet loss. Set it explicitly:

netsh interface tcp set global congestionprovider=cubic

Verify: rerun netsh interface tcp show global and confirm both lines. Then repeat the ping test from the client. A small improvement here is normal, the big win comes from the combination of UDP plus the session settings below.

Step 3 - Apply the RDP experience profile for low bandwidth

This is where most of the perceived smoothness comes from. Open Group Policy and set the session experience to prioritize responsiveness over visual fidelity. These settings reduce the graphics data sent over the wire, which matters far more than server CPU on a 100-200 ms path.

gpedit.msc

Navigate to Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Remote Session Environment. Set these three policies:

  • "Use compression" to "Optimize use of memory" (this balances CPU and bandwidth).
  • "Limit maximum color depth" to "16 bits per pixel" (24-bit color over a high-latency link wastes bandwidth for little visible gain).
  • "Remove wallpaper" to "Enabled" (wallpaper is pure waste on a remote session).

Apply with gpupdate /force in an elevated prompt, then restart the session for the changes to take effect. Do not restart the whole server for this, a logoff and reconnect is enough.

gpupdate /force

Verify: reconnect and feel the difference during a scroll test. Open a long document and scroll continuously. With 16-bit color and compression tuned for memory, the repaint should track your input instead of trailing it.

Step 4 - Cap session idle timeouts and keepalives

Chinese teams often leave RDP sessions open for hours. Disconnected sessions keep consuming memory and, worse, an idle TCP connection through a stateful firewall can be silently dropped, which causes the infamous "reconnecting" loop. Set active session limits and a keepalive interval so the server reclaims dead sessions and the connection stays alive when idle.

gpedit.msc

Navigate to Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Session Time Limits. Set:

  • "Set time limit for active but idle Remote Desktop Services sessions" to "15 minutes" (or your team preference, pick a value that does not kill active work).
  • "Set time limit for disconnected sessions" to "10 minutes".

Then set the keepalive interval in the registry. Open an elevated PowerShell:

Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" -Name "KeepAliveEnable" -Value 1 -Type DWord
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" -Name "KeepAliveInterval" -Value 1 -Type DWord

The keepalive interval of 1 minute sends a probe that keeps the NAT mapping alive on the Chinese side. Without it, the connection drops after a few minutes of inactivity and the client hangs on "Reconnecting".

Verify: gpupdate /force, then from the client, stay idle in the session for 10 minutes. The session should remain connected and responsive, not drop to a reconnecting state.

Step 5 - Reduce NLA renegotiation friction

Network Level Authentication is a security feature you should keep, it pre-authenticates before the full session loads and blocks most brute-force attacks. But on a high-latency path, the initial NLA handshake adds a few extra round trips, which feels like a long pause before the login screen appears. Keep NLA on, it is worth the extra second for the security it provides, especially on a public-facing RDP port. If you want that port less exposed, an Linux VPS as a jump host with SSH tunneling to the Windows RDP port is a solid pattern, but for most teams the direct connection with NLA is fine.

What you can reduce is the credential prompt round trips. On the client side, save the credentials in the RDP file or let Windows Credential Manager store them. The client then sends the credentials in the first round trip instead of waiting for a challenge. This is a client setting, not a server one, but it directly cuts the perceived login delay from China.

Verify: reconnect and count the seconds from double-click to desktop. With saved credentials over UDP, this should drop to under 10 seconds even at 120 ms latency, versus 20-30 seconds with the full NLA challenge over TCP.

Troubleshooting common RDP issues from China

You applied everything and the session is still bad. Work through these in order.

Session drops at random intervals. This is almost always a NAT or firewall timeout, not Windows. Confirm your keepalive settings from Step 4 applied: Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" | Select-Object KeepAliveEnable, KeepAliveInterval and check the transport is UDP. If the Chinese office firewall is aggressive, you may need the client to use TCP instead, which trades a bit of responsiveness for stability.

UDP is blocked but TCP works. Run Test-NetConnection <server-ip> -Port 3389 -InformationLevel Detailed from the Chinese client. This tests TCP only. For UDP, there is no simple PowerShell test, so check the session info icon, it tells you the actual transport. If UDP fails and the network path is the cause, the RDP experience over TCP with the compression settings in Step 3 is still acceptable.

Login is slow but the session is fine once connected. That is NLA round trips over high latency. Save credentials on the client as described in Step 5. If you cannot save credentials for policy reasons, accept the extra seconds, do not disable NLA.

What to do when the path itself is the bottleneck

Server tuning gets you only so far. If your baseline ping from the Chinese city to the Vietnam VPS is above 180 ms, no setting in Windows fixes that. The route is the constraint. In that case, check whether the server is on a domestic-optimized network path in Vietnam. A Windows VPS located in a Vietnam datacenter with good regional peering will give Chinese clients a shorter hop than one that routes through the US or Europe. Re-run the ping test from the same client to a fresh test VPS before you commit to a long-term setup.

Also consider the client side. A Chinese user on a residential ISP at peak evening hours will see worse latency than the same user on a business line, because international capacity is congested at night. Test at the time of day your team actually works, not at 9 AM when the path is clear.

FAQ

Does UDP really make RDP from China to Vietnam faster?

Yes, in most cases. UDP avoids TCP retransmission stalls on lossy international paths, so the session feels smoother during screen updates and scrolling. The transport is negotiated automatically when both server and client allow it. Verify the session info shows UDP after connecting.

Should I disable Network Level Authentication to speed up login?

No. NLA adds one or two round trips at login, which is a few seconds on a high-latency path. Disabling it exposes the server to brute-force attacks on a public port. Save credentials on the client instead, it cuts the same round trips without the security loss.

What color depth should I use for RDP over a long distance?

Set 16 bits per pixel. The difference between 16-bit and 24-bit is barely visible for most office work, remote desktop, code, and browser content, but it reduces the graphics data sent over the wire noticeably at 100+ ms latency.

Why does my RDP session keep disconnecting after a few idle minutes?

A stateful firewall or NAT device on the China side is dropping the idle connection. Enable the keepalive interval in the registry (KeepAliveEnable=1, KeepAliveInterval=1) so the server sends a probe every minute, keeping the NAT mapping alive.

Is a Vietnam VPS the right choice for a team inside China?

If your workloads are in Vietnam, yes, the VPS gives you a local IPv4 and domestic routing. For a team in China accessing a Vietnam server, expect 80-200 ms latency depending on the route. Apply the tuning in this guide, then measure. If latency stays above 180 ms, consider the network path before adding more server resources.

Do I need more RAM or CPU on the server for better RDP performance?

Rarely. RDP performance on a high-latency path is dominated by network round trips and graphics bandwidth, not server compute. A Windows VPS with 2 GB of RAM handles several interactive RDP sessions fine. Upgrade only if the server runs heavy applications inside the session, not for the remote display itself.

Related articles

Windows Server RDP 延迟优化要点

中国团队访问越南 Windows VPS 时，RDP 卡顿通常是网络路径和默认配置问题，而非服务器性能不足。启用 UDP 传输、将 TCP 拥塞控制设为 CUBIC、把颜色深度降到 16 位并关闭壁纸，能明显改善交互流畅度。设置 KeepAlive 探活间隔可防止空闲会话被防火墙断开。建议先测量基线延迟，再逐项应用设置并用会话信息确认实际传输协议。

Note: This guide is for general reference. Every system and infrastructure has its own specifics, so test each step in a safe environment and consult a qualified engineer before applying it in production.