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 的不确定性我在动手之前就规划了三条路径按侵入性从低到高排列实际排查时也是按这个顺序走的路径做法侵入性适用情况路径 A保持 Wayland调整向日葵配置与权限最低新版客户端已适配或问题出在权限而非协议路径 B登录时切换为 Xorg 会话中等确认是 Wayland 兼容性问题且可接受每次登录选会话路径 C全局禁用 Wayland固定使用 Xorg最高长期需要远程桌面不想每次手动切这个顺序的逻辑是先排除最简单的原因再动系统级配置。很多人的黑屏其实不是 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-gnomeWayland 下的捕获接口就不完整装上它再重启会话试试。我在一台机器上补了这个包配合新版客户端确实有一台机器从纯黑变成了能出画面但偶尔闪断虽然不完美但可用。这条路径能不能成很大程度上取决于客户端版本所以先把向日葵升级到官网最新版是免不了的一步。路径 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 WaylandEnablefalse改完执行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 现象对照速查表下面这张表是这次排查和以往经验的总汇按现象查原因和动作能省掉大量瞎试的时间现象最可能的原因优先动作连上了纯黑无光标无活动图形会话 / 被控端锁屏 / 休眠SSH 查会话状态唤醒并登录桌面连上了有光标无桌面Wayland 下画面捕获受限切 Xorg 会话验证连接直接失败/超时被控端离线、账号不一致、防火墙看设备在线状态临时关 ufw 对比装完图标在但打不开dpkg 依赖未配置完sudo apt-get install -f补依赖画面能出但严重卡顿带宽/画质设置过高降分辨率、调流畅优先用一会儿自动断被控端息屏/挂起/网络切换关闭息屏与自动挂起检查电源设置重启后设备离线客户端未设开机自启开启自启并确认后台运行这张表的使用方法是从上往下对号入座别跳步。我见过有人一上来就怀疑显卡驱动重装驱动折腾半天最后发现是笔记本合盖挂起了非常典型。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 切回去也不迟。
阅读完成 · 觉得有帮助?