---
publishDate: 2026-07-06T08:31:00Z
lang: 'zh-cn'
translationKey: 'rustdesk-connected-waiting-for-image'
draft: false
title: 'RustDesk 显示“已连接，等待图像”：完整修复指南'
excerpt: '“已连接，等待图像”意味着远程屏幕未被捕获。本文列出了所有可能的原因——无头主机、休眠、编解码器、驱动程序——并给出相应的修复方法。'
image: '~/assets/images/blog/rustdesk-connected-waiting-for-image-og.webp'
category: '故障排除'
tags: ['RustDesk', '故障排除']
author: 'RustDesk Team'
slug: 'rustdesk-connected-waiting-for-image-zh-cn'
faq:
  - question: '为什么 RustDesk 会显示“已连接，等待图像”？'
    answer: '会话已成功建立，但远程主机没有生成可供发送的屏幕图像。最常见的原因是没有可捕获的活动显示器——例如没有显示器的无头服务器、已休眠或锁定的屏幕，或操作系统不允许 RustDesk 录制的显示器。修复捕获源之后，图像就会出现。'
  - question: '如何修复无头计算机上 RustDesk 卡在“等待图像”的问题？'
    answer: '没有显示器的主机没有可供捕获的帧缓冲区，因此 RustDesk 无内容可发送。可以连接一台真实显示器、插上一个廉价的 HDMI 仿真插头（让 GPU 误以为已连接显示器），或者在 Linux 上使用官方文档中的无头配置方法（github.com/rustdesk/rustdesk/wiki/Headless-Linux-Support）。唤醒显示器或让其保持唤醒状态可解决大多数此类问题。'
  - question: '更换视频编解码器能否解决黑屏问题？'
    answer: '通常可以。在远程会话工具栏或设置中，你可以切换编解码器——VP8、VP9、AV1，或在硬件支持的情况下使用 H.264/H.265。如果远程硬件无法编码某个编解码器，画面就会显示空白或卡死，此时切换回软件编解码器（例如 VP9）通常可以恢复画面。'
  - question: 'RustDesk 在一台电脑上能显示图像，在另一台却不行，这是为什么？'
    answer: '这说明问题出在无法正常显示的那台机器本地——可能是显示器休眠或缺失、macOS 上缺少屏幕录制权限、GPU 驱动过旧、硬件加速冲突，或硬件无法处理某个编解码器。请针对出问题的那台机器，逐一排查本文列出的各原因对应的修复方法，而不是那台正常工作的机器。'
  - question: '自建服务器会导致“等待图像”问题吗？'
    answer: '当你看到这条提示时，会话通常已经连接成功，说明服务器已经完成了自己的工作。但如果公共中继服务器过载，或中继端口被阻断，视频流仍可能卡住。对于标准服务器路径，请放行 TCP 21115-21117 和 UDP 21116；仅在使用 WebSocket 客户端时才需要放行 TCP 21118-21119。若想获得更稳定的吞吐量，可以考虑自建中继服务器。'

metadata:
  description: '“RustDesk 已连接，等待图像”？教你修复黑屏问题：无头显示器、休眠/锁屏、视频编解码器、GPU 驱动、Wayland 以及防火墙端口。'
  keywords: 'RustDesk 已连接等待图像, RustDesk 黑屏, RustDesk 等待图像修复, RustDesk 无图像, RustDesk HDMI 仿真插头, RustDesk 视频编解码器, RustDesk 硬件加速'
---

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

## 简短回答

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

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

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

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

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

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

## 按原因修复

| 原因                  | 表现                 | 修复方法                                                                                        |
| --------------------- | -------------------- | ----------------------------------------------------------------------------------------------- |
| 无头主机 / 无显示器   | 服务器或迷你电脑黑屏 | 连接显示器、加装 HDMI 仿真插头，或使用 Linux 无头方案                                           |
| 屏幕休眠 / 锁定       | 之前正常，闲置后变黑 | 唤醒屏幕；禁用休眠/屏保；macOS 用户在系统设置中禁止显示器休眠                                   |
| 缺少权限（macOS）     | 已连接，但始终黑屏   | 在“隐私与安全性”中授予屏幕录制权限；为登录界面安装辅助程序                                      |
| 编解码器不匹配        | 画面空白或卡死       | 切换编解码器（VP8 / VP9 / AV1 / H.264 / H.265）；回退到软件编解码器                             |
| 硬件加速冲突          | 特定 GPU 上黑屏      | 在会话工具栏或设置中关闭硬件编解码器，或切换编解码器                                            |
| GPU 驱动过旧          | 驱动/系统更新后黑屏  | 更新 GPU 驱动（尤其是 NVIDIA）                                                                  |
| Wayland 会话（Linux） | 无授权提示，画面空白 | 接受 PipeWire/portal 的授权提示，并确认已安装桌面 portal；如发行版仍提供 X11 会话，使用它也可以 |
| 网络 / 中继卡顿       | 卡在“等待图像”       | 放行 TCP 21115-21117 和 UDP 21116；WebSocket 客户端需额外放行 TCP 21118-21119                   |

### 屏幕休眠、锁定与屏保

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

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

### 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](https://github.com/rustdesk/rustdesk/pull/15420)）。如果你在 Wayland 上遇到画面空白，通常的解决办法是接受 portal 的屏幕共享提示，并确认 `xdg-desktop-portal` 和 PipeWire 已安装并正在运行；对于无头主机，请使用文档中给出的[无头配置方法](https://github.com/rustdesk/rustdesk/wiki/Headless-Linux-Support)。如果发行版仍然提供 X11/Xorg 会话，登录该会话也可以绕开 portal 路径——但随着越来越多发行版转向仅支持 Wayland，修复 portal/PipeWire 路径才是更长远的做法。

### 网络与中继

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

## 保持一切最新

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

## 开源的优势

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

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

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