1. 为什么要在两台 Ubuntu 之间折腾远程桌面

先把场景摆出来。手头两台机器，一台是固定在工位的主力机，另一台是放在机房或者家里的算力机、测试机，两边都装着 Ubuntu。平时需求很朴素：在主力机上敲命令、改配置、跑编译，直接操作远端那台。听起来像是 SSH 就能解决的事，但真正干活的时候你会发现，纯命令行不够用——要看编译后的图形界面效果、要点开一个 IDE 拖拽窗口、要远程操作浏览器调试前端页面、要给同事演示一个桌面应用的交互流程，这些都是纯 mate 终端搞不定的场景。于是"远程桌面"就成了刚需，而向日葵这类国产远程工具因为跨平台、安装简单、免费额度够用，成了很多人的第一选择。

但 Ubuntu 上的远程桌面有个绕不开的坎：显示服务器协议。Ubuntu 从 22.04 开始默认使用 Wayland 作为 GNOME 的显示服务器，而目前绝大多数第三方远程桌面软件（包括向日葵）的 Linux 端都是围绕 X11 设计的。这就导致一个非常典型的现象——软件装着、登录着、显示"已就绪"，但对方连上来看到的是一片黑屏或者只有一个光标，鼠标能移动却看不到桌面。我前前后后在三台不同配置的机器上遇到这个问题，表现还不完全一样：有的黑屏、有的闪一下就断、有的直接提示"远程端未开启桌面"。所以这篇内容的核心就是两件事，一是把向日葵在 Ubuntu 上的安装配置流程走通并讲清楚每一步为什么这么做，二是把 Wayland 导致的黑屏问题彻底排查明白，从现象、原理到几种不同的解决路径。

不管你是刚接触 Linux 桌面、想把公司电脑和家里机器连起来的新手，还是已经用过远程桌面但被黑屏卡住的老手，这篇都值得从头看一遍。我尽量不堆术语，能类比的地方就类比，涉及到参数的地方给出计算和取舍逻辑，涉及到踩坑的地方把现场记录原样贴出来。文中涉及的具体机器配置、主机名、账号都做了虚构处理，但操作路径和报错现象是真实的。

2. 开工前的整体设计与方案选型

2.1 先把两台机器的角色定清楚

远程桌面这件事，第一步不是装软件，而是把角色分清楚。两台机器里，一台是控制端（你在它面前敲键盘、看屏幕的那台），一台是被控端（远端的、要被远程操作的那台）。向日葵的安装包在两边都要装，但配置重点完全不同：控制端基本是"装完登录就能用"，被控端才是所有麻烦的来源——它需要正确识别当前的图形会话、需要有可用的显示输出、需要在无人值守的情况下也能建立会话。很多人装完发现连不上，问题八成出在被控端。

我把这次的两台机器这么定：控制端是一台日常用的笔记本，装上向日葵客户端，登录同一个账号；被控端是一台台式机，跑的是 Ubuntu 22.04 LTS，显卡是核显加一张入门独显的混合配置，这也是后面排查黑屏时的一个干扰项。这里先埋个伏笔：混合显卡 + Wayland + 第三方远程桌面这三个条件凑在一起，是黑屏的高发组合，后面第 4 节会详细展开。

2.2 为什么选向日葵，以及它的能力边界

选向日葵的理由很直接：跨平台支持全（Windows、macOS、Linux、移动端都有客户端）、国内网络环境下连接质量相对可控、免费版对个人使用基本够用、操作界面是中文的不用猜。对比一下其他常见方案：系统自带的 GNOME Remote Desktop 配置繁琐且对 Wayland 的支持也不算完善，VNC 系（如 TigerVNC、x11vnc）需要手动起服务、配置 xstartup、处理认证，对新手门槛偏高，而且性能在弱网下体验一般。

但必须提前说清楚它的边界，避免后面白折腾。第一，向日葵的 Linux 客户端对 Wayland 会话的支持是有限的，官方文档里对支持的系统版本和桌面环境有明确限制，实际使用中 Wayland 下黑屏是高频问题。第二，它做的是"屏幕共享式"的远程控制，也就是把被控端当前登录的物理会话镜像出来，而不是像 RDP 那样给你开一个独立的、可以多用户并行的虚拟会话。这意味着被控端必须处于已登录、桌面已加载的状态，锁屏界面能不能操作要看版本，纯粹的无头服务器（不接显示器）启动后没有图形会话，连上去自然也是黑的。第三，免费版的画质和帧率有限制，做精细的图形操作会卡顿，这个要有心理预期。

注意：如果你的被控端是一台完全没有显示器的服务器，只是想跑图形程序，那向日葵不是最优解，更适合的方案是配一个虚拟显示输出或者用支持无头模式的方案。这一点在选型阶段就要想清楚，别等装完了才发现方向错了。

2.3 整体方案：三条路径并行准备

考虑到 Wayland 的不确定性，我在动手之前就规划了三条路径，按侵入性从低到高排列，实际排查时也是按这个顺序走的：

这个顺序的逻辑是：先排除最简单的原因，再动系统级配置。很多人的黑屏其实不是 Wayland 的锅，而是权限、防火墙、显示输出识别的问题，上来就改 GDM 配置属于杀鸡用牛刀，而且改错了还得回滚。我见过有人直接编辑/etc/gdm3/custom.conf禁用 Wayland，结果机器重启后进不了桌面，又因为没有物理接触而彻底失联——这种事故在远程操作里是致命的，所以每一步改动前都要留好退路。

2.4 一个容易被忽略的前置条件：会话必须是"活的"

这一条单独拎出来讲，因为它是黑屏问题里最冤的一种。向日葵镜像的是当前活动的图形会话，如果被控端处于以下状态，连上去大概率是黑的或者连不上：一是刚开机停在登录界面还没人登录；二是登录后长时间无操作，系统进入了休眠或者关闭了显示器输出；三是笔记本合上了盖子（默认行为是挂起）。这三种情况都跟 Wayland 无关，但表现出来的现象一模一样。

所以排查的第一步永远是：确认被控端此刻真的有一个活着的、已登录的图形桌面。最土但最有效的验证方法是让人在那边看一眼屏幕，或者用 SSH 登进去执行who、loginctl list-sessions看会话状态。我这次就是在这一步先排除了"会话不存在"的可能，才把矛头指向 Wayland 的。

3. 向日葵的安装与基础配置实操

3.1 安装包获取与依赖处理

向日葵 Linux 版的安装包官方提供 deb 格式，也有部分版本提供 rpm 和 tar 包。Ubuntu 系直接用 deb 最省事。下载之前先确认系统架构，现在主流是 x86_64，个别 ARM 设备（比如某些开发板）要单独找 ARM 版本，装错了会报"无法执行二进制文件"。

# 确认架构和系统版本 uname -m lsb_release -a

拿到 deb 包后，标准的安装命令是：

sudo dpkg -i sunloginclient-*.deb

这里有个高频坑：dpkg 不会自动解决依赖。如果系统缺库，它会报一堆 "dependency problems prevent configuration"，此时安装其实是半成品状态，程序图标可能出现但起不来。正确的补救方式是紧接着执行：

sudo apt-get install -f

这条命令会读取 dpkg 记录的破损依赖并尝试补齐，比手动一个个 apt install 靠谱得多。我这次装的版本依赖了 libwebkit2gtk、libgtk-3 等一票图形库，在一台精简安装的机器上确实缺了几个，靠-f一次补齐了。

装完之后可以用dpkg -l | grep sunlogin确认状态是ii（已安装且已配置），iU之类的状态说明还没配置完，得回头处理依赖。启动方式有两种：图形界面里搜"向日葵"点图标，或者命令行执行sunloginclient。第一次启动会在用户目录下生成配置和日志，日志路径通常在~/.sunlogin/sunloginclient/log/下面，后面排查全靠它。

提示：安装过程中如果提示"软件包架构不匹配"或者"无法定位软件包"，先别急着换安装包，回到uname -m那一步确认架构，再看系统版本是否在官方支持列表里。Ubuntu 的 LTS 版本支持较好，非 LTS 或者过新的版本可能遇到库版本对不上的问题。

3.2 账号登录与被控端授权

向日葵的工作模型是"账号 + 设备"：控制端和被控端登录同一个账号后，设备会出现在设备列表里，控制端直接点"远程协助"就能连。这种模式比"输入识别码"的方式方便，适合自己两台机器互连的固定场景。被控端登录后建议做几件事：

一是设置独立的本机访问密码。即使走账号体系，很多版本在建立连接时仍会要求输入被控端的访问密码，这个密码和账号密码是两回事，在"设置—安全"里可以改。设一个自己记得住的，别用默认的。

二是开启"无人值守"相关的选项（不同版本叫法不一，有的叫"允许远程控制本机"、"开机自启"）。如果被控端需要长期可连，把客户端设成开机自启并允许后台运行，否则重启后软件没起来，你在控制端只能看到设备离线。

三是确认设备在线状态。客户端界面上会显示"本机识别码"和一串在线状态，控制端的设备列表里能看到对方是绿色在线还是灰色离线。离线的原因通常是：被控端软件没启动、被控端断网、或者登录的账号不一致。这一步看着傻，但我确实遇到过登录错账号（一个手机号注册了两个账号）折腾半小时的情况。

3.3 防火墙与端口：不是每次都要开放，但要知道卡在哪

Ubuntu 默认的 ufw 通常是关闭状态，用sudo ufw status看一眼。如果是 active，那远程桌面很可能被拦。向日葵建立连接的方式是客户端主动向外连接服务器做穿透，理论上不需要在被控端开放入站端口，但在某些网络环境下（比如公司内网有严格的出站策略），可能需要放行特定端口。

我的处理原则是：先不动防火墙，连不上再排查。判断方法很简单，如果控制端能看到设备在线但点连接没反应或者超时，可以先临时把 ufw 关掉（sudo ufw disable）测试一次，能连上了就说明是防火墙问题，再针对性地放行而不是长期关闭。测完记得按原状态恢复，sudo ufw enable重新打开。

# 查看防火墙状态 sudo ufw status verbose # 临时关闭做对比测试（测完务必恢复） sudo ufw disable # ... 测试连接 ... sudo ufw enable

另外提一个网络层面的因素：两台机器如果不在同一个局域网，连接质量取决于双方的网络环境。免费版在有公网环境下的画质压缩比较明显，做文字类工作时可以手动把画质调成"清晰优先"或者降低分辨率来换取流畅度，这个在客户端的画质设置里能调。

3.4 完成基础配置后的第一次连接测试

到这一步，理论上的配置已经齐了：两端都装好、登录同一账号、被控端处于已登录的图形桌面、防火墙不拦。此时做第一次连接测试，重点观察三件事：

第一，连接能不能建立。控制端点击连接后，如果几秒内出画面（哪怕模糊、卡顿），说明链路是通的，剩下的只是优化问题；如果长时间黑屏、转圈、或者提示连接失败，那就是另一类问题。

第二，画面是不是真的"桌面"。这里的关键区分是：黑屏分两种，一种是纯黑什么都没有，一种是有鼠标指针但背景全黑，还有一种是有桌面背景但没有窗口/面板。这三种现象指向的原因不同，第 4 节会做对照表。

第三，被控端本地的屏幕有没有反应。连接成功时，被控端的物理显示器上应该能看到鼠标在动（因为远程操作就是操作同一个会话）。如果本地屏幕完全没反应，说明远程端根本没有拿到输入控制权，问题在会话层面；如果本地屏幕有反应但远程看不到画面，问题在画面捕获层面。这个对比能帮你快速定位问题方向。

我这次的第一次测试结果是：连接能建立，控制端出现鼠标指针，能移动，但背景全黑，看不到任何窗口和面板。被控端本地屏幕一切正常。这个现象基本就把范围锁定在"画面捕获"环节，而最常见的原因就是 Wayland 下第三方工具抓不到画面。带着这个结论，进入下一节的排查。

4. Wayland 黑屏的深度排查与解决

4.1 先确认你到底在跑哪个显示协议

排查 Wayland 相关的任何问题，第一步永远是确认当前会话用的是 X11 还是 Wayland。很多教程默认你在 Wayland，但有些机器（尤其是装过显卡驱动的）可能已经回落到 X11 了，方向搞反就白忙活。

# 方法一：查会话类型，最直接 echo $XDG_SESSION_TYPE # 输出 wayland 或 x11 # 方法二：查登录会话详情 loginctl show-session $(loginctl | grep $(whoami) | awk '{print $1}') -p Type # 方法三：看进程，有 Xwayland 相关进程通常说明在 Wayland 下 ps aux | grep -i wayland

这三个方法里，echo $XDG_SESSION_TYPE最快，但要注意它必须在图形终端里执行，通过 SSH 登进去执行可能是空的或者不准，因为 SSH 会话没有继承图形会话的环境变量。如果 SSH 里要看，用loginctl那条更可靠。

我这次在图形终端里执行，输出是wayland，确认了方向。顺带说一下，Ubuntu 22.04 的登录界面（GDM）上，密码输入框右下角有个小齿轮图标，点开能看到"Ubuntu"和"Ubuntu on Xorg"两个选项，这就是切换会话类型的入口，后面路径 B 会用到。

4.2 Wayland 为什么会导致第三方工具黑屏

这块原理值得花点篇幅讲清楚，理解了就不会再被各种"玄学"说法带偏。

传统的 X11 架构里，有一个叫 X Server 的中心角色，所有应用都通过它来画图、接收输入。这个架构的问题是把所有东西都集中在一个进程里，安全和性能都有隐患。Wayland 换了个思路：合成器（compositor）直接管一切，应用不再直接访问显示设备，而是把绘制好的缓冲区交给合成器，合成器负责合成、显示、分发输入事件。GNOME 的 Mutter、KDE 的 KWin 都是合成器。

这个设计带来的直接后果是：应用不能再随便"偷看"整个屏幕。在 X11 时代，一个程序只要连上 X Server，就能拿到整个屏幕的画面，第三方远程桌面正是这么工作的——它截取 X Server 的输出，把画面编码后传走。到了 Wayland，合成器出于安全和隔离的考虑，默认不允许这种全屏截取，除非应用走了合成器提供的专门接口（比如 GNOME 的 ScreenCast 接口，基于 PipeWire）。

于是黑屏的机理就清楚了：向日葵的 Linux 客户端在 Wayland 会话下拿不到全屏画面数据，只能拿到一个空的或者只有光标的图层。这也是为什么现象往往是"有鼠标、无桌面"——输入事件的转发在某些实现里是通的，画面捕获是断的。这不是软件"坏了"，而是协议层面的限制，靠改软件配置基本无解，只能换协议或者等软件适配。

4.3 三种方案的实际操作与取舍

路径 A：在 Wayland 下尝试权限与配置层面的微调。

这条路径的期待值要放低，但成本最低，值得先试。核心是检查向日葵是否具备屏幕捕获相关的权限。Ubuntu 22.04 的 GNOME 有屏幕共享的开关，在"设置—共享"里，确认共享是开的。另外 Wayland 下的屏幕捕获走 PipeWire，可以检查相关组件是否齐全：

# 检查 PipeWire 和 xdg-desktop-portal 相关包 dpkg -l | grep -E "pipewire|xdg-desktop-portal"

如果缺少xdg-desktop-portal-gnome，Wayland 下的捕获接口就不完整，装上它再重启会话试试。我在一台机器上补了这个包，配合新版客户端，确实有一台机器从"纯黑"变成了"能出画面但偶尔闪断"，虽然不完美但可用。这条路径能不能成，很大程度上取决于客户端版本，所以先把向日葵升级到官网最新版是免不了的一步。

路径 B：登录时手动选择 Xorg 会话。

这是最稳妥、最推荐个人用户采用的方案，因为它不修改任何系统文件，只是改变了本次登录的会话类型。操作步骤：注销当前会话回到登录界面，点击用户名后，在密码框下方（或右下角）找到齿轮图标，选择"Ubuntu on Xorg"，然后输入密码登录。登录后再执行echo $XDG_SESSION_TYPE，输出x11就对了。

这一步的原理是：Xorg 是传统的 X11 显示服务器，第三方工具对它的支持是成熟的，画面捕获天然没问题。缺点是 X11 在安全隔离和某些高刷新率、多屏缩放场景下不如 Wayland 现代，另外这个选择只对本次登录有效，重启或注销后要重新选（如果没把它设成默认）。对于"需要远程桌面时选 Xorg、平常本地用 Wayland"的思路来说，这反而正好，灵活切换。

路径 C：全局禁用 Wayland，把 Xorg 设为默认。

如果这台机器长期需要远程桌面，每次登录手动选太麻烦，那就直接改配置。Ubuntu 的 GDM 配置文件在/etc/gdm3/custom.conf，把 Wayland 相关的开关打开（注释掉或者设成 false）：

# /etc/gdm3/custom.conf [daemon] # 取消下面这行的注释，禁用 Wayland WaylandEnable=false

改完执行sudo systemctl restart gdm3或者直接重启。注意：重启 GDM 会把你当前的图形会话干掉，如果你是通过远程连接的方式改这个文件，改完重启就等于自断退路，因为新会话还没起来你就失联了。所以这条操作必须在物理接触或者有可靠的带外管理手段的前提下做。

注意：路径 C 是一个"改了就回不去"的风险操作。改完如果 GDM 起不来（配置文件写错、驱动不兼容），远程就彻底进不去了。我的做法是改之前先备份原文件（sudo cp /etc/gdm3/custom.conf /etc/gdm3/custom.conf.bak），并且确保有一台能 SSH 进去的通道作为兜底，SSH 能进就还有救，改回来重启就行。

4.4 现场记录：从黑屏到可用的完整过程

把这次的排查过程原样记一遍，你能看到每一步的判断依据：

第一步，首次连接，现象是"有光标、无桌面"。此时先用echo $XDG_SESSION_TYPE确认是wayland，锁定大方向。

第二步，检查 PipeWire 和 portal 组件，发现xdg-desktop-portal-gnome缺失，装上、重启会话后再连——现象变成"偶尔能出画面，但很快黑掉或闪断"。这说明链路是通的，是画面捕获的稳定性问题，Wayland 的嫌疑坐实。

第三步，不做任何系统修改，只用路径 B：注销，在登录界面选 "Ubuntu on Xorg"，重新登录，再连。这次画面正常出来了，操作延迟可以接受，连续用了二十分钟没断。至此问题定性完成。

第四步，为了长期方便，我在这台机器上采用了路径 C，把 Wayland 关了，代价是这台机器以后都跑 X11。因为它的角色就是被远程的算力机，本地很少用，这个取舍是划算的。如果它是我的日常主力机，我会更倾向于保留 Wayland、需要时手动切 Xorg。

这个过程中有个细节值得记下来：在 Wayland 下，即使客户端显示"已连接"，被控端的本地屏幕也完全不受远程操作影响，因为画面和输入都没走通；切到 Xorg 后，远程一操作，本地屏幕的鼠标同步在动。这个"本地屏幕是否跟随"的现象，是判断问题出在会话层还是捕获层的一个很实用的土办法。

5. 常见问题速查与避坑清单

5.1 现象对照速查表

下面这张表是这次排查和以往经验的总汇，按现象查原因和动作，能省掉大量瞎试的时间：

这张表的使用方法是从上往下对号入座，别跳步。我见过有人一上来就怀疑显卡驱动，重装驱动折腾半天，最后发现是笔记本合盖挂起了，非常典型。

5.2 几个必须提前处理的系统设置

针对"用一会儿就断"这类问题，有几个系统设置必须在被控端提前改掉，否则你会在远程操作中莫名其妙地掉线：

关闭自动息屏和自动挂起。在"设置—电源"里，把"空白屏幕"设为"从不"，"自动挂起"关掉。命令行方式可以用gsettings：

# 关闭息屏（AC 供电时） gsettings set org.gnome.desktop.session idle-delay 0 # 禁止自动挂起 gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type 'nothing'

处理笔记本合盖挂起。如果被控端是笔记本且合着盖子放着，默认行为是挂起，远程立刻失联。改/etc/systemd/logind.conf里的HandleLidSwitch为ignore，然后重启 logind 服务。这个改动要谨慎，合盖不挂起意味着散热要注意。

确认无人值守时的锁屏策略。锁屏本身不一定是问题（有些版本能在锁屏界面接受远程输入），但如果你的版本不行，锁屏就等于黑屏。可以在"设置—隐私—锁屏"里调整自动锁屏时间，或者评估是否需要一个专门用于远程的会话。这里要权衡安全性和可用性，别为了远程方便把锁屏彻底关了，机器放在公共环境里是有风险的。

5.3 我踩过的三个真实坑

第一个坑是装完没重启会话就测试。补装xdg-desktop-portal-gnome之后我直接在原会话里又连了一次，还是黑屏，差点以为没用。实际上 portal 组件需要重新登录会话才能生效。这类"改了配置要重进会话"的规律在图形栈相关的改动里非常普遍，记住一条：凡涉及显示服务、portal、输入法的改动，测之前先注销重登。

第二个坑是混合显卡的干扰。那台被控端是核显加独显，我一度怀疑是独显驱动导致画面捕获异常，花时间去查nvidia-smi、切 prime 模式，结果发现跟显卡没关系，就是 Wayland。这个教训是：排查要有优先级，先查高概率的共性问题（协议、会话、权限），再查低概率的个性问题（驱动、硬件），否则很容易陷进细节里出不来。判断方法也简单，用路径 B 切一次 Xorg，如果立刻好了，就跟显卡无关。

第三个坑是在远程连接的状态下改 GDM 配置。这个前面提过，但我确实干过一次：SSH 进去改了custom.conf，然后systemctl restart gdm3，结果新会话起来后向日葵客户端没自动启动，加上当时没配好自启，直接失联了二十分钟，最后靠物理接触才恢复。从那以后我立了个规矩：任何可能导致图形会话中断的操作，先确认三条退路——物理接触、SSH 可用、客户端开机自启已配好，三条齐了再动手。

5.4 关于版本与长期维护的建议

最后一组实操建议，跟版本管理有关。向日葵的 Linux 客户端更新不算频繁，但每次大版本对 Wayland 的支持情况可能有变化，所以遇到黑屏先看版本、先升级，这是成本最低的一步。升级的方式是去官网下新的 deb 覆盖安装，dpkg -i覆盖即可，配置一般会保留。

另外一个习惯是把被控端的关键配置写成脚本存档。比如关闭息屏、禁止挂起、检查会话类型这几条命令，我整理成了一个小脚本放在被控端，换机器或者重装系统时直接跑一遍，比凭记忆敲命令靠谱。这不是什么高深技巧，但在需要反复折腾同类环境的时候，能省掉大量重复劳动和"上次那条命令是怎么写的来着"的抓狂。

如果后面有更彻底的需求，比如被控端是纯无头服务器还想跑图形程序，那就得考虑虚拟显示输出（给系统配一个虚拟显示器让它以为有屏幕）或者转向原生支持无头的方案，那是另一个话题了，跟本文这套"两台有桌面的 Ubuntu 互连"的路径是分开的。眼下这套组合——向日葵客户端 + Xorg 会话 + 电源策略调整——在我这边已经稳定跑了几个月，日常改配置、看界面、演示操作都够用，剩下的就是等客户端对 Wayland 的支持真正成熟，到时候再把 Xorg 切回去也不迟。