xrdp开启虚拟机后无法连接？先查这三件事
xrdp开启虚拟机后无法连接，绝大多数情况下是服务没起来、端口被防火墙拦住或者桌面会话残留导致的，按下面顺序排查，五分钟内能解决八成以上故障。这个问题我自己在本地虚拟机和云服务器上都踩过坑，先是折腾半天发现xrdp服务压根没启动，后来又遇到防火墙默认拦了3389端口，如果你也懒得每次反复试错,直接从服务状态开始查。
第一步：确认xrdp服务真的在运行
不少用户以为装完xrdp就能用，其实安装后服务不会自动启动，打开虚拟机里的终端,执行：
systemctl status xrdp
如果输出显示 active (running)，说明服务正常，如果显示 inactive (dead) 或 failed,手动启动并设置开机自启：
systemctl start xrdp systemctl enable xrdp
有些系统还需要同时启动xrdp-sesman进程，这个进程负责管理远程登录会话,检查命令：
systemctl status xrdp-sesman
行业共识认为，xrdp-sesman状态异常导致的连接失败，占日常故障的较大比例，如果两个服务都显示在运行，但客户端还是连不上,接着查端口。
第二步：端口和服务监听状态
xrdp默认监听 3389端口,在虚拟机里用下面命令看端口是否处于监听状态：
ss -tlnp | grep 3389
有输出说明端口正常监听中，如果没有任何输出,打开xrdp配置文件检查端口设置：
sudo nano /etc/xrdp/xrdp.ini
文件里找到 port=3389 这一行，确认没有被改过，如果改成别的端口,Windows远程桌面客户端连接时要填写对应端口。
部分系统自带VNC服务或远程桌面服务会和其他程序抢占端口，比如较早版本的xrdp默认监听 5900端口用于内部VNC转发，如果需要和VNC共存，配置不当就会出现 虚拟机xrdp连接失败原因 中的端口冲突问题。
第三步：防火墙规则检查
Linux虚拟机默认开启防火墙时，不会放行3389端口，基于Debian/Ubuntu系统用ufw管理防火墙的,执行：
sudo ufw allow 3389/tcp sudo ufw reload
CentOS/RHEL系要用firewalld：
sudo firewall-cmd --permanent --add-port=3389/tcp sudo firewall-cmd --reload
这里有个容易忽略的坑：你改了虚拟机的防火墙，但宿主机层面还有一层防火墙，比如使用国内云服务器时，安全组规则也得放行3389端口，这个在云平台控制台里操作，廉价云服务器和物理机装虚拟机的排查路径差异不大,但云平台安全组忘了配的情况很常见。
虚拟机xrdp连接失败原因排查：网络、桌面环境与会话残留
服务、端口、防火墙都检查过还是连接不上，问题大概率出在网络连通性、桌面环境缺失或残留会话锁死这三个方向。
网络连通性测试
从Windows宿主机打开命令行,执行：
ping 虚拟机IP
能ping通说明二层三层网络没问题,接着测TCP端口连通性：
telnet 虚拟机IP 3389
光标停留在一个黑窗口或者提示连接成功，说明Windows到虚拟机的3389端口链路是通的，如果ping不通，检查虚拟机的网络模式，NAT模式下宿主机要访问虚拟机得配置端口转发,桥接模式则直接分配局域网IP。
桌面环境不完整导致的黑屏
xrdp连接成功但登录后只有背景图和鼠标，没有任务栏和桌面图标，这是因为系统缺少完整的桌面会话组件，Ubuntu Server默认没有安装桌面环境,需要手动补装：
sudo apt install xfce4 xfce4-terminal
装好之后配置xrdp启动会话文件：
echo "xfce4-session" > ~/.xsession
同时编辑startwm.sh,确保xrdp调用正确的桌面启动器：
sudo nano /etc/xrdp/startwm.sh
文件末尾加上：
xfce4-session
保存后重启xrdp服务。记住执行 sudo systemctl restart xrdp，否则新配置不生效,这个步骤能解决相当一部分黑屏问题。
会话残留导致无法重新登录
反复连接、断开、再连接，旧会话没被正确清理，新会话起不来，状况表现为输入用户名密码后闪退回登录界面,或者提示连接被拒绝。
清理残留会话用：
pkill -u 用户名
杀光该用户所有进程后，重启xrdp服务，如果问题经常出现，建议在xrdp.ini里把 MaxSession 数值调小,限制单人同时建立的会话数。
xrdp黑屏和闪断的具体修复命令
前面提到黑屏，这是用户反馈最多的故障场景，单独拆开细说，xrdp在Ubuntu 22.04以上的GNOME桌面环境下，经常会因为 GNOME会话优化冲突 导致黑屏或卡死,兼容性最稳的方案是改装Xfce桌面。
完整操作路径：
sudo apt update sudo apt install xrdp xfce4 xfce4-goodies sudo apt install tigervnc-standalone-server
为了不跟系统自带远程功能冲突,把组件做一次统一重启：
sudo systemctl restart xrdp sudo systemctl status xrdp
Windows端远程桌面连接时，在“显示选项”里把体验调整为“LAN（10Mbps以上）”，能减少因为色彩深度和桌面特效导致的花屏和延迟，在同一局域网内，xrdp连接不上时多数情况下调整这个选项就能改善。
还有一种情况是连接后立即断开，查 /var/log/xrdp.log 日志，里面明确了断开原因，遇到权限相关错误，把用户加入 ssl-cert 组：
sudo adduser 用户名 ssl-cert
这个操作在证书权限异常时非常关键。
xrdp和vnc哪个更好用？建议两个都装
经常有人问xrdp和vnc该选哪个，这个问题的答案不是二选一，而是组合使用，xrdp走3389端口，配合Windows自带远程桌面客户端，零额外软件，对公网带宽消耗小，VNC灵活性强，跨平台兼容性好，但传输效率略低于xrdp,尤其是在弱网环境下。
组合使用方案
xrdp内部本身可以转发给VNC服务，配置得当就同时拥有了两种通道，编辑 /etc/xrdp/xrdp.ini，在 [xrdp1] 段配置VNC转发参数：
lib=libvnc.so port=5900 username=用户 password=密码
保存后重启服务，你在客户端连接3389时,xrdp自动桥接到本机5900端口的VNC服务。
哪些场景不推荐用xrdp
如果你需要远程操作图形化安装程序、3D渲染界面，或者调试显卡直通，这类场景下xrdp支持不好，VNC同样表现有限，行业专家指出，真正流畅跑3D图形远程方案还是要靠专业远程软件或专门的渲染协议，而日常运维、文件操作、轻量办公,xrdp完全够用。
免费开源是xrdp最大的卖点，相比TeamViewer商业版按年付费，xrdp不产生任何额外费用，国内云服务器带宽按M计费，xrdp传输的协议数据包本身就比VNC精简,长期运行成本更低。
哪些情况必须重装xrdp
配置文件改乱了又不想逐个排查，直接重装最省事,卸载干净后重新安装：
sudo apt remove xrdp sudo apt autoremove sudo apt install xrdp
重装不影响虚拟机的文件和应用，只是重置远程连接相关的配置，这个操作结束后记得把用户加入ssl-cert组、确认startwm.sh里的桌面环境启动器、重新放行防火墙端口。重装完这三步不做，大概率还是连不上。
另一个偏门的排查点：虚拟机系统时间异常导致SSL证书验证失败，xrdp也会拒绝连接,同步时间：
sudo timedatectl set-ntp true
时间校准后证书校验通过,连接就恢复正常。
关于xrdp连接失败的常见问答
问：xrdp开启虚拟机后无法连接，但ping虚拟机IP能通，是什么原因？
问题通常出在端口层，主机到虚拟机的ICMP通，只代表网络层可达，3389端口没监听或防火墙拦截，TCP层就不通，用 telnet 虚拟机IP 3389 进一步判断，连接失败就回到上面的排查流程：先确认xrdp服务运行，再核对防火墙规则,最后检查是否改过默认端口。
问：xrdp连上后黑屏，只显示鼠标光标，怎么办？
这是桌面会话调用错误，Ubuntu的GNOME桌面与xrdp兼容性差，改装Xfce桌面并设置 xfce4-session 为默认启动器，能解决绝大多数黑屏状况，操作顺序：安装xfce4、编写 ~/.xsession 文件、修改 /etc/xrdp/startwm.sh、重启xrdp服务。
问：云服务器上的虚拟机用xrdp连接为什么比本地虚拟机更卡，价格更贵的带宽还是不稳定？
远程桌面的卡顿取决于两个环节的带宽和时延，云场景下xrdp数据要经过公网传输，公网质量决定体验上限，本地虚拟机走虚拟交换机和宿主机内存交换，延迟极低，想改善云服务器xrdp体验，优先压缩桌面分辨率和色彩深度，在xrdp.ini中设置 max_bpp=24 并降低默认分辨率,同时避免在远程会话里播放视频等高码率内容。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/744387.html
