RustDesk 显示“已连接，等待图像”：完整修复指南

如果 RustDesk 显示**“已连接，等待图像”**，随后出现黑屏，好消息是最难的部分已经完成：两端已经找到彼此，会话也已建立。缺少的只是画面。远程主机上的某个环节没有生成可供发送的屏幕图像。本文将逐一梳理所有已知原因，从最常见的情况到各种边缘案例，并为每种情况给出具体的修复方法。

简短回答

会话已经连接，但没有可供捕获的帧缓冲区。如果远程主机没有显示器、显示器处于休眠或锁定状态，或操作系统不允许 RustDesk 录制该显示器，视频流就没有内容可编码。只要给 RustDesk 提供一个真实且处于唤醒状态的显示器可供捕获——无论是实体显示器、HDMI 仿真插头、正确的权限，还是兼容的编解码器——图像就会出现。

从这里开始：有没有可以捕获的画面？

迄今为止报告最多的原因是无头主机——即在没有连接显示器的情况下运行的服务器、迷你电脑或工作站，又或者显示器处于休眠状态。由于没有活动显示器，GPU 不会生成帧缓冲区，因此 RustDesk 虽能连接，却无内容可发送。这种情况在 RustDesk 的问题跟踪系统中反复出现，包括目标设备显示器关闭时出现黑屏的报告，以及长期存在的“已连接，等待图像”讨论帖。

以下三种方法可以让它有内容可捕获：

• 连接一台显示器，并确保它已通电且处于唤醒状态。
• 使用 HDMI（或 DisplayPort）仿真插头。 这类廉价适配器可以让 GPU 误以为已连接显示器，从而持续渲染帧缓冲区供 RustDesk 抓取。这是解决无头台式机和家庭服务器问题的标准方法。
• 在 Linux 上，使用官方文档中的无头方案。 RustDesk 支持无头 Linux 配置，但其设置方式与普通桌面会话不同——详见无头 Linux 支持 wiki。

如果显示器确实连接着，那么下一个疑点就是它进入了休眠状态。

按原因修复

屏幕休眠、锁定与屏保

如果之前一直正常，机器闲置一段时间后才变黑，那就是显示器进入了休眠状态。

• Windows： 设置电源计划，确保在你需要远程访问的时间段内，显示器和主机都不会休眠，并禁用屏保（或将其设置为会话期间不要求密码）。
• macOS： 在你需要远程访问的时间段内阻止显示器休眠——在系统设置 → 显示器（或“锁定屏幕”/“电池”设置）中进行配置，并让 Mac 保持接通电源，因为使用电池供电时的休眠行为有所不同。
• Android： 屏幕必须处于点亮状态才能被共享，因此连接前请先触摸屏幕将其唤醒。从 iOS 连接到屏幕已关闭、处于休眠状态的 Android 设备，是一种已知的“等待图像”案例——请先唤醒目标设备。

macOS 权限

macOS 规定，任何应用未经明确许可都无法录制屏幕。如果 RustDesk 在 Mac 上已连接却始终黑屏，请打开系统设置 → 隐私与安全性 → 屏幕录制，启用 RustDesk，然后重启应用。如果黑屏恰好出现在登录界面，则说明 RustDesk 的服务/辅助程序未被安装为在用户登录前运行——请安装该组件以支持登录前捕获。

视频编解码器不匹配

RustDesk 可以用多种方式对视频流进行编码，默认选项并不总是适合远程硬件。在会话工具栏（或设置）中切换编解码器——VP8、VP9、AV1，或在硬件支持时使用 H.264/H.265——观察画面是否出现。如果某个硬件编解码器在特定 GPU 上导致画面空白，回退到软件编解码器（例如 VP9）是可靠的解决办法。

硬件加速与 GPU 驱动

部分 GPU——尤其常见于 NVIDIA 配置——会与 RustDesk 的硬件加速捕获和渲染路径产生冲突。以下两种手段可以帮上忙：

• 关闭硬件编解码器。 在会话工具栏（或设置）中，禁用使用硬件编解码器，让编码回退到软件路径——这能解决许多问题 GPU 上的黑屏现象。
• 更新 GPU 驱动。 如果黑屏是在驱动或系统更新后才出现的，升级到最新驱动通常能解决问题，在 NVIDIA 硬件上尤其如此。

Linux 与 Wayland

在 Linux 上，Wayland 屏幕捕获需要经过 PipeWire 和 xdg-desktop-portal：它会在首次使用时弹出授权提示，让你选择要捕获的显示器——大多数情况下这个选择会被记住，因此之后不会再次提示——并且只在活动的登录会话内生效。这是 Wayland 的安全设计，因此它本身无法覆盖登录管理器（greeter）界面或真正的无头主机——不过无人值守的 Wayland 捕获功能正在积极开发中（PR #15420）。如果你在 Wayland 上遇到画面空白，通常的解决办法是接受 portal 的屏幕共享提示，并确认 xdg-desktop-portal 和 PipeWire 已安装并正在运行；对于无头主机，请使用文档中给出的无头配置方法。如果发行版仍然提供 X11/Xorg 会话，登录该会话也可以绕开 portal 路径——但随着越来越多发行版转向仅支持 Wayland，修复 portal/PipeWire 路径才是更长远的做法。

网络与中继

由于提示信息中包含“已连接”字样，此时会话通常已经建立——但如果中继服务器过载，或中继端口被阻断，视频仍可能卡住。对于标准服务器路径，请确保 TCP 21115-21117 和 UDP 21116 端到端可达。仅在使用 WebSocket 客户端时才需要开放 TCP 21118-21119。公共演示服务器为共享资源，其吞吐量无法保证，因此如果你每天都依赖 RustDesk，自建专属中继服务器能带来远为稳定的表现。如果会话本身持续掉线或始终无法建立，那是另一个问题——请参阅 RustDesk Server Pro 常见问题。

保持一切最新

旧版本会带有旧版本的捕获缺陷。请同时将主控端和被控端客户端更新到最新版本，如果你是自建服务器，也请一并更新服务器。不少黑屏报告仅仅是在双端都更新之后就自行消失了。

开源的优势

当黑屏问题超出上述排查清单的范围时，RustDesk 能提供闭源工具无法提供的东西：采用 AGPL 许可证发布的真实捕获代码。你（或你聘请的技术人员）可以准确读懂捕获功能在你所用平台上的实现方式、复现问题，并针对公开仓库提交精准的报告——而不必在厂商的支持队列中苦苦等待。

服务器掌握在自己手中，变数更少

运行属于你自己的中继与 ID 服务器，共享的公共基础设施就不再是变量之一——在排查捕获问题时少一个未知因素，同时对可调节的部分拥有完全的控制权。这是在保有数据掌控权之外的又一项低调优势。