一、 现象描述
在多网卡服务器运维中，经常遇到网络路径正常但应用层服务失效的情况。本次故障环境如下：
- 系统配置：Windows Server 2016，安装两块物理网卡
- 网卡 A：IP 为
192.168.40.254，默认网关（0.0.0.0）**指向此段 - 网卡 B：IP 为
10.30.1.140，手动设置了高优先级静态路由
- 网卡 A：IP 为
- 故障现象：
- 客户端 A：通过192段访问服务器，远程桌面正常
- 客户端 B：通过10段访问服务器，能够 Ping 通 10.30.1.140，但尝试远程桌面连接时提示超时或连接失败
二、 核心原因
- RDP 协议双轨制传输 ：
（1）现代 RDP 建立连接时，会并行开启两条路：一条是必选的 TCP (3389)，用于指令控制；一条是可选的 UDP (3389)，用于传输大流量图像
（2）TCP 握手成功后，客户端会立即向服务器发送一个 UDP 探测包。如果服务器回包，协议就“升级”为高效模式；如果服务器没反应，理论上应该“降级”回纯 TCP 模式 - 不同客户端本质区别：
（1）客户端 A 的路径（主链路优势）：A 走的是服务器的 192 段网卡。由于路径属于系统默认主路径，Windows 内核处理请求非常果断。一旦 UDP 探测被拦截，系统能迅速判定从而立即切换回纯 TCP 模式
（2）客户端 B 的路径（协议不匹配）：B 走的是服务器的 10 段网卡。虽然手动设置了路由优先级（Metric），让 TCP 握手 能够正确回包，但由于跨了网卡且路由 Metric 不同，Windows 协议栈在处理“非默认路径”的 UDP 回包时，会进入一种“静默等待”状态 - 连接的逻辑死循环：
（1）服务器收到了 B 的 UDP 请求，但因为防火墙 UDP-In 没开，这个包在进入系统内核前就被无声无息地丢弃了
（2）服务器的 RDP 服务根本不知道有人发过 UDP 请求，因此不会发出“拒绝”指令
（3）客户端 B 则一直在死等服务器的回应。由于 10 段网卡不是默认主路径，Windows 客户端会反复尝试重新发送 UDP 探测包，而不是降级连接
三、 解决方案
- 建议方案：远程桌面 UDP 准入 ：
（1）打开“高级安全 Windows 防火墙”
（2）进入“入站规则”列表，找到 “远程桌面 – 用户模式 (UDP-In)” 项（建议同时开启TCP-In）
（3）右键点击该规则，选择 “启用规则” - 备选方案：强制执行 TCP 传输
（1）若开启 UDP 后仍不稳定，可通过组策略禁用 RDP 的 UDP 插件，强制所有连接只走 TCP
（2）路径：计算机配置->管理模板->Windows 组件->远程桌面服务->远程桌面会话主机->连接
（3）启用 “选择 RDP 传输协议”，并将其设置为 “仅使用 TCP”
四、 经验总结
- 排查逻辑：
（1）Ping 通只能证明网络层（Layer 3）路由通路正常
（2）Telnet 3389 成功只能证明传输层（Layer 4）的 TCP 端口开放
（3）多网卡环境下，必须确保 TCP 和 UDP 的规则在所有网卡接口上均处于一致开启状态 - 运维建议：
（1）在配置 Windows 多网卡服务器时，不能只关注route print里的优先级，必须同步检查防火墙对非默认网段的协议过滤情况
（2）开启 UDP-In 规则是解决跨网段远程桌面“卡顿”或“连不上”的最快手段