Ubuntu双机向日葵远程桌面：Wayland黑屏排查与Xorg切换

两台机器都跑 Ubuntu，想把其中一台当被控端长期放在客厅接电视，另一台当主力机在书房操作它，这个需求听起来简单，真动手装的时候才知道坑有多密。我最初的方案是装向日葵客户端，装完连上去——黑屏。鼠标能滑动，画面一片漆黑，切换编码模式、重装客户端、换端口都试过，最后才定位到是 Wayland 会话把抓屏接口锁住了。这篇就把两台 Ubuntu 机器通过向日葵互联的完整过程，以及 Wayland 黑屏从现象到根因的排查链路摊开讲清楚，包括每一步为什么要这么做、哪些配置是必须的、切回 Xorg 会付出什么代价、不想切的话还有什么替代路线。适合手里有两台 Linux 机器、想搭一套稳定远程桌面环境的人，不管是刚接触 Ubuntu 的新手，还是已经踩过一次坑但没找到根因的老用户，都能从里面找到可以直接抄的部分。

1. 动手之前先把两台机器的角色和链路定清楚

1.1 被控端和控制端装的东西并不一样

很多人第一次接触远程桌面会有一个误解：两台机器装同一个软件、做同一套配置就能互相连。实际不是。远程桌面是典型的 C/S 结构，被控端跑的是"服务进程"，负责抓取屏幕画面、编码、回传，同时接收控制端的鼠标键盘事件并注入到本地输入子系统；控制端跑的是"客户端进程"，负责解码画面、显示窗口、采集本地的输入事件并发送过去。这两端的权限要求、依赖包、配置项完全不同。

向日葵在 Linux 上的分发形态是同一个安装包，里面同时包含客户端和服务端组件，装完之后由你登录账号、选择角色。但理解这个分层很关键，因为后面排查黑屏的时候，你需要判断问题出在"抓屏"这一侧还是"传输"这一侧。如果是抓屏失败，控制端收到的画面就是黑的或者空白；如果是传输或者编码出问题，你通常会看到花屏、色块、画面撕裂，而不是纯黑。这两类症状的处理路径完全不一样，一上来就乱试编码参数是浪费时间。

我当时的角色划分是这样：客厅那台旧笔记本（i5 八代、核显、8G 内存）做被控端，接一台 1080P 显示器，长期开机；书房的主力机做控制端。被控端配置低这一点在后面会变成一个真实的约束——Wayland 加 GNOME 本身就不轻，再叠一个实时编码进程，CPU 占用会明显上去。

1.2 局域网直连和中继转发，走哪条路差别很大

向日葵默认走的是厂商的中继服务器，好处是两台机器不需要在同一个网段、不需要公网 IP、不需要动路由器，坏处是画面质量和延迟受中继节点影响，免费账户还有带宽和画质限制。如果两台机器在同一个局域网里，走直连会好很多，延迟能从几十毫秒降到个位数，画质也能拉满。

判断是否走了直连，最直接的办法是看客户端连接信息里显示的连接类型。如果显示的是"中继"或者延迟明显偏高（比如始终在 30ms 以上），说明没走通局域网直连。局域网直连失败常见的原因有三个：两台机器不在同一个子网（比如一台连的是 2.4G 访客网络，一台连的是 5G 主网络，路由器隔离了）；被控端防火墙挡了 UDP 探测包；路由器的 AP 隔离功能开着。

我实际遇到的是第二种。被控端那台机器装完之后我手动开过 ufw，默认策略是 deny incoming，向日葵的服务进程起不来监听。这里有个细节值得记一下：不要图省事直接ufw disable，正确的做法是先查清楚向日葵用了哪些端口，只放行必要的。查端口可以用sudo ss -tulnp | grep -i sunlogin看进程实际监听在哪些端口上，比翻文档靠谱，因为不同版本的端口号可能会变。

提示：如果两台机器都要长期用，建议在路由器上给被控端做一个 DHCP 静态绑定，避免 IP 变动之后直连失效。这个操作五分钟，但能省掉后面很多"昨天还好好的今天就连不上"的困惑。

1.3 一套最小可用的前置清单

在真正装软件之前，我建议先把下面这几件事确认掉，能避免后面 80% 的无效折腾。

这张表里最容易被忽略的是第四行和第五行。无头机器的问题尤其隐蔽：你把一台没接显示器的机器当被控端，X11 起来之后找不到输出设备，抓到的画面可能是 1024x768 的默认分辨率，甚至是全黑。这种情况需要用 xrandr 配合虚拟显示适配器解决，跟 Wayland 黑屏是两回事，但症状看起来一模一样，很容易混淆。

2. 向日葵 Linux 端的安装：从 deb 包到能看见识别码

2.1 下载与安装，以及第一次 apt install -f 的意义

向日葵官网提供 deb 和 rpm 两种包，Ubuntu 用 deb。下载下来之后不要直接双击安装，走命令行更可控，因为你能看到依赖报错。

# 进到下载目录，确认包名 ls -lh *.deb # 用 dpkg 安装，这一步大概率会报依赖缺失 sudo dpkg -i sunloginclient_*.deb # 补齐缺失的依赖 sudo apt install -f

dpkg -i和apt install ./xxx.deb的区别值得说一下。前者只做解包和文件放置，不处理依赖关系，缺什么直接报错退出，装到一半的状态；后者会把本地 deb 当成一个软件源条目，自动解析并拉取依赖。我习惯先用dpkg -i跑一遍，看它到底缺哪些包——这个信息有价值，因为你能知道这个版本的客户端依赖了什么，出问题时心里有数。然后再用apt install -f一次性补齐。

向日葵 Linux 客户端依赖里比较常见的是 GTK3 相关库和 WebKit 渲染引擎（登录界面是用 web 技术做的），如果系统是精简安装（比如装的是 Ubuntu Server 后补装的桌面环境），这些依赖缺失的概率很高。补依赖这一步失败，通常是因为软件源列表里没有对应的包，先sudo apt update再重试。

安装完成后，程序一般落在/opt下面，同时会注册一个 systemd 服务。用下面的命令确认服务状态：

systemctl status sunloginclient --no-pager # 如果提示 unit 不存在，换个名字查 systemctl list-unit-files | grep -i sun

服务名在不同版本之间可能略有差异，用list-unit-files加 grep 是最稳的查法，不要死记。

2.2 首次启动登录与设备绑定

装完之后在应用列表里能找到向日葵的图标，点开就是登录界面。这一步看起来平平无奇，但有两个细节会影响后面的使用体验。

第一，登录账号之后，这台机器会出现在你的设备列表里，同时生成一个固定的识别码。识别码是设备身份，验证码是临时访问凭证，两者不要搞混。临时验证码每次连接都可能变，如果你希望无人值守（比如被控端在客厅，你不想每次跑过去看验证码），就要在设置里把它改成固定的访问密码。

第二，客户端的自启动开关。Linux 版本的这个开关有时候不生效，因为它依赖的是桌面环境的自启动机制（XDG autostart），而不是 systemd 服务。判断方法很简单：重启之后不登录桌面，直接用另一台机器连，能连上说明服务是系统级的；连不上、必须登录桌面之后才能连，说明它挂在用户会话里。

这个区别非常关键。如果你的被控端重启之后停在登录界面没人输密码，服务级自启动能让你远程连上去（虽然 Wayland 下画面可能是黑的），用户级自启动则完全连不上。我倾向于同时保证两条路：systemd 服务开着，用户的 autostart 也留着，冗余一点没坏处。

2.3 被控端必须打开的三个开关

向日葵的设置项不少，但对"长期无人值守"这个场景来说，真正必须打开的就三个。

第一个是开机自启动，前面说过了，服务级和用户级都配上。第二个是接受远程控制时不需要本机确认——默认情况下有些版本会在被控端弹一个确认框，需要本地有人点"接受"，无人值守场景下这个必须关掉。第三个是锁屏状态下允许控制，这个跟后面的黑屏问题直接相关，我把它单独拎出来讲。

在 X11 会话下，锁屏界面是独立的窗口，抓屏能抓到，键盘事件也能注入，所以远程输密码解锁是可行的。但在 Wayland 会话下，锁屏界面由 compositor 自己渲染，普通的抓屏接口拿不到这块内容，你会看到"连接成功但画面是锁屏壁纸或者纯黑，输入密码没反应"。很多人误以为是密码错了，其实是画面根本没传过来。

注意：如果你在设置里看到"隐私模式"或者"黑屏模式"之类的选项，先确认它不是默认开启的。这类选项的作用是被控端本地屏幕变黑、只给远程看画面，本意是保护隐私，但如果和 Wayland 的抓屏问题叠在一起，你会很难判断到底是哪个导致的。

3. Wayland 黑屏的根因：抓屏协议从一开始就没对上

3.1 X11 时代截屏是一句 XGetImage 的事

要理解为什么黑屏，得先知道 X11 和 Wayland 在架构上的根本差别。

X11 的设计哲学是"客户端-服务器"，但这个服务器是全局的。所有窗口的内容最终都绘制到一块由 X Server 管理的帧缓冲区里，任何客户端只要拿到这块缓冲区的句柄，就能通过XGetImage或者共享内存扩展（XShm）把整屏内容读出来。这个设计在安全上是很松的——任何本地程序都能悄悄截你的屏，但正因为它松，远程桌面软件实现起来极其简单：定时读帧缓冲、差分、编码、发走。

向日葵的 Linux 客户端就是基于这套机制做的。它启动后会去连接 DISPLAY 环境变量指向的 X Server，注册抓屏，拿到的就是完整的桌面画面，包括所有窗口、鼠标指针、甚至锁屏界面。这也解释了为什么在 X11 下它几乎不需要额外配置就能工作。

3.2 Wayland 把屏幕画面锁进了 compositor 里

Wayland 的架构完全不同。它取消了全局的帧缓冲区概念，每个客户端只知道自己窗口的内容，窗口怎么合成、最终画成什么样，由 compositor（在 GNOME 里是 Mutter）全权负责。客户端之间是相互隔离的，A 程序没有任何办法去读 B 程序的画面，更没办法读到整个屏幕。

这个设计在安全和流畅度上是巨大进步，但对远程桌面来说是釜底抽薪。想在 Wayland 下抓屏，唯一的正规途径是走xdg-desktop-portal这一套接口：程序先通过 D-Bus 向 portal 服务发起请求，portal 再弹一个系统对话框问用户"是否允许某某应用共享你的屏幕"，用户点了允许，portal 才通过 PipeWire 把一路视频流交给请求方。

注意这里的关键点：这个流程需要用户交互授权。无人值守的远程桌面场景最怕的就是这个——被控端没人，弹窗没人点，抓屏请求永远挂着，控制端收到的就是一片黑。而且不同发行版、不同 GNOME 版本对这套 portal 接口的支持程度还不一样，就算授权了，帧率和分辨率也可能被限制。

向日葵目前的 Linux 客户端并没有完整走通这套 portal 流程，官方文档里其实也提过 Linux 版对 Wayland 的支持有限。这就解释了为什么"装完能连上、就是黑的"——连接建立、鉴权、心跳全都正常，唯独抓屏这一环拿不到数据。

3.3 黑屏、卡登录界面、只有鼠标能动，其实是三种不同症状

排查的时候最忌讳把所有"看不到画面"都归成一类。我按实际遇到过的情况拆成三类，处理方式完全不同。

第一类和第三类本质上是同一个根因（Wayland 抓屏受限），只是表现位置不同。第二类是另一个问题，通常和被控端的输入设备权限有关——X11 下注入事件需要访问/dev/uinput或者 XTEST 扩展，Wayland 下则完全不允许外部程序注入输入事件，除非通过 portal 的 RemoteDesktop 接口。所以如果在 Wayland 下你发现鼠标能动但点击无效，别怀疑是客户端 bug，这是架构层面的限制。

第四类容易被误判成黑屏问题。我一开始就混淆过：调了半天 Wayland 配置，最后发现是编码器的问题，把硬件编码关掉就正常了。判断方法是看画面有没有"内容但糊了"，纯黑和花屏的区分看一眼就知道。

4. 切回 Xorg：最快见效的做法和它的代价

4.1 登录界面的齿轮图标，是最轻量的切换方式

在动配置文件之前，先试一个很多人不知道的办法：注销回到 GDM 登录界面，点自己的用户名，右下角（或者密码框下方）会出现一个齿轮图标，点开能看到 "Ubuntu" 和 "Ubuntu on Xorg" 两个选项，选后者再登录。

这个操作只对当前这次登录生效，重启之后会回到默认的 Wayland 会话。它的好处是零风险、随时可以切回来，适合用来做验证——如果切到 Xorg 之后远程画面立马正常了，那 Wayland 就是唯一根因，你可以放心地去改配置文件做永久切换；如果切过去还是黑的，说明还有别的问题叠加，别急着改配置。

我当时就是用这个方法确认的。切换后重新连，画面立刻出来了，鼠标键盘也正常响应，延迟在局域网内大概 15ms 左右，1080P 下基本感觉不到卡顿。这一下就把问题锁死了。

4.2 永久关闭 Wayland 的三行配置

确认根因之后，改配置文件做持久化。Ubuntu 用的是 GDM3，配置文件在/etc/gdm3/custom.conf。

sudo nano /etc/gdm3/custom.conf

找到[daemon]这一段，把下面这行的注释去掉：

[daemon] WaylandEnable=false

保存退出，然后重启显示管理器：

sudo systemctl restart gdm3

注意，systemctl restart gdm3会直接把你当前的图形会话杀掉，所有开着的窗口都会关掉，先保存工作。如果想避免这个，直接sudo reboot也一样，反正都要重启。

Ubuntu 24.04 之后这个路径和写法依然有效，但我建议改之前先备份一份：

sudo cp /etc/gdm3/custom.conf /etc/gdm3/custom.conf.bak

出问题的时候把备份拷回去，重启，就回到原状了。这一步看起来多余，但我在折腾显示相关配置的时候被坑过不止一次——有一次改错了缩进导致 GDM 起不来，只能进 recovery mode 用命令行恢复。有备份能省掉半小时。

另外，有些教程会让你改/etc/gdm3/daemon.conf，那是旧版本的路径，现在统一在custom.conf里。如果你的系统里两个文件都存在，以custom.conf为准，daemon.conf里改了不生效。

4.3 切换之后会丢掉什么，这笔账要算清楚

关掉 Wayland 不是没有代价的，我列一下实际感受到的损失，方便你判断值不值。

触控板手势。GNOME 在 Wayland 下的三指、四指手势非常顺滑，切到 Xorg 之后手势支持会退化，部分手势直接失效。如果你用的是笔记本自带触控板且依赖手势操作，这个体验落差很明显。

混合缩放（fractional scaling）。Wayland 支持 125%、150% 这种非整数倍缩放，Xorg 基本只支持整数倍。如果你用的是高分屏（比如 2K、4K），在 Xorg 下要么字太小要么整体放大得很难看。这一点对有外接高分屏的用户是硬伤。

多显示器不同刷新率。Wayland 下每台显示器可以独立设置刷新率，Xorg 下多屏通常要统一到最低的那个，或者手动配 xrandr 参数折腾。

部分应用的渲染问题。少数基于 GTK4 或者较新框架的应用在 Xorg 下会有渲染瑕疵，概率不高但存在。

反过来说，Xorg 的优势也很明确：远程桌面、屏幕录制、自动化测试、截图工具这一整类"需要抓屏"的软件，在 Xorg 下都是一条命令的事，兼容性极好。对一台长期当被控端、主要用途就是被远程操作的机器来说，Xorg 显然是更合适的选择。我最后就是把这个决策做成了分工：被控端那台固定跑 Xorg，主力机继续用 Wayland 享受手势和缩放。

4.4 多用户和多会话环境下容易翻车的地方

如果你的被控端不止一个用户账号，或者开启了自动登录，切换 Wayland 之后有几个地方要注意。

自动登录的情况下，GDM 会自动用默认会话登录，WaylandEnable=false生效之后默认会话就变成 Xorg 了，这个没问题。但如果你的系统里有多个用户，A 用户登录用的是 Xorg，切到 B 用户之后可能又回到 Wayland——因为 GDM 的会话选择是按用户记住的，WaylandEnable=false只影响"没有明确选择时用什么"。

解决方法是确保每个用户登录时都手动选一次 "Ubuntu on Xorg"，或者干脆在/var/lib/AccountsService/users/<用户名>里检查XSession=这个字段的值，把它设成ubuntu-xorg。这个文件是 AccountsService 存用户偏好的地方，比 GDM 的配置优先级更高，值得查一眼。

还有一个坑：WaylandEnable=false之后，某些依赖 Wayland 的应用（比如某些版本的截图工具、屏幕录制工具）会切换到 X11 后端，功能可能不全。如果你在被控端上还跑着其他需要图形界面的服务，切换前先确认一下它们的兼容性。

5. 不想动 Wayland 的话，还有几条路可走

5.1 用系统自带的 RDP 远程桌面

GNOME 从 42 版本开始内置了远程桌面功能，走的是 RDP 协议，底层用的正是 xdg-desktop-portal 和 PipeWire 那套接口。因为它是由 compositor 自己提供的实现，Wayland 下能正常工作。

在 Ubuntu 的设置里找"共享"或者"系统"下的"远程桌面"，打开开关，设置用户名和密码，端口默认 3389。然后在控制端用一个 RDP 客户端连过去就行，Ubuntu 自带的 Remmina 就够用，Windows 和 macOS 也有原生或免费的客户端。

这条路线的优点是：不需要切会话类型，Wayland 的所有特性都能保留；画面质量和延迟在局域网内相当不错；协议是标准的，控制端选择多。缺点是配置项少，可调空间小；某些版本上需要开启"远程登录"（headless 模式）才能在无人登录的情况下连进去，而这个模式的稳定性在不同版本之间差异比较大；另外它的多显示器支持比较弱。

我实测过这个方案，在同一个局域网里，延迟和向日葵直连差不多，画质甚至更清晰一些，因为没走中继。但它对"被控端重启之后停在登录界面"这个场景的处理不如向日葵稳，有时候需要本地先登录一次才能连上。

5.2 xrdp 适合什么场景

xrdp 是另一条老牌路线。它的工作方式是启动一个独立的 X 会话（不是接管当前物理会话），然后通过 RDP 协议把画面传出去。这意味着：

• 它不依赖物理显示器的当前状态，无头机器也能用；
• 它创建的会话和你本地登录的会话是两个独立的桌面，互不干扰；
• 它天然跑在 Xorg 上，所以抓屏、输入注入全都没问题。

这个特性对"多人同时使用一台机器"或者"本地和远程各干各的"场景非常合适。但它也有明显的短板：你连上去看到的不是本地屏幕上正在显示的内容，而是一个全新的空桌面。如果你的需求是"看到客厅电视上正在播放的东西"，xrdp 就不合适。

安装方式是sudo apt install xrdp，装完之后它会自己注册服务。默认配置下它可能和 GDM 抢 3389 端口（如果同时开了 GNOME 的远程桌面），先确认端口没冲突。另外 xrdp 的默认会话可能缺少窗口管理器，连上去只有一个空桌面加一个终端，需要额外配置 startwm.sh 来启动 GNOME 会话，这一步在中文环境下的输入法和字体渲染上容易出问题，需要额外调。

5.3 只传文件或只跑命令，根本不需要远程桌面

说句实在话，很多人的"远程桌面需求"其实被高估了。如果你 90% 的操作是跑命令、改配置、传文件，那 SSH 加 SFTP 已经完全够用，而且开销小得多——被控端不需要跑编码进程，控制端也不需要解码，8G 内存的老机器上这个差别很明显。

# 被控端装 openssh-server sudo apt install openssh-server sudo systemctl enable --now ssh # 控制端直接连 ssh 用户名@被控端IP # 传文件用 sftp 或者 rsync rsync -avz --progress ./本地目录/ 用户名@被控端IP:/目标路径/

如果偶尔需要看图形界面，可以用 SSH 的 X11 转发，只把单个应用的窗口转发过来，而不是整个桌面：

ssh -X 用户名@被控端IP # 登录后直接运行图形程序，比如 gedit

这种方式传输的只是单个窗口的绘制指令，带宽占用极低，在局域网里几乎感觉不到延迟。缺点是每个程序都要单独启动，而且不支持把整个桌面搬过来。配合 tmux 使用体验很好——连接断了之后重连，会话还在。

我的实际做法是组合使用：日常运维走 SSH，需要完整桌面的时候才开向日葵，两者互补，谁也不替代谁。

6. 完整排错链路复盘：从"连不上"到"能稳定用"

6.1 分层定位，别一上来就改配置

把整个链路拆成五层，从下往上排查，每一层都有一个明确的判断标准，这样能避免在错误的方向上浪费时间。

第一层：网络可达。控制端ping被控端 IP，通不通。不通的话查子网、查路由器 AP 隔离、查防火墙。这一层不过，后面全白搭。

第二层：服务在跑。被控端systemctl status看向日葵服务是不是 active，ss -tulnp看端口有没有在监听。服务没起来，先看日志journalctl -u sunloginclient -n 50。

第三层：鉴权通过。控制端能输入识别码和验证码，并且不报"设备离线"或者"密码错误"。这一层过了说明连接已经建立，问题一定在画面传输上。

第四层：抓屏成功。这里就是本文的核心。判断方法：在被控端本地截一张图（用系统自带的截图工具），如果本地截图正常而远程是黑的，说明抓屏接口对远程软件不可用；如果本地截图也是黑的，那是显示驱动或者 compositor 的问题，跟远程软件无关。

第五层：编码和传输。画面出来了但卡顿、花屏、颜色不对，问题在这一层。调编码方式、降分辨率、关硬件加速，逐步试。

这个分层最大的价值是让你在每一步都有"过/不过"的判断，而不是凭感觉乱试。我第一次排查的时候就是跳过了第四层，直接去调第五层的编码参数，折腾了一个多小时毫无进展。

6.2 我实际踩过的五个坑

坑一：以为装了就能用，没看会话类型。这是最根本的一个。Ubuntu 22.04 之后默认就是 Wayland，装完向日葵连上去黑屏是必然的，不是偶发。养成习惯，装任何抓屏类软件之前先echo $XDG_SESSION_TYPE。

坑二：改了 custom.conf 但没重启 GDM。改完配置文件之后我直接重新连，还是黑的，以为配置没生效。实际上 GDM 需要重启才会重新读取配置，而当前会话不会自动切换。改完必须systemctl restart gdm3或者重启系统，然后用echo $XDG_SESSION_TYPE确认返回值变成了x11，光看配置文件改了不算数。

坑三：锁屏之后远程连不上，以为是掉线。被控端设了 10 分钟自动锁屏，锁了之后远程连上去是黑屏，鼠标能动但点不了。这个问题在 Xorg 下也存在，只是表现不同。解决办法是在设置里把自动锁屏关掉，或者把锁屏延迟设得很长。无人值守的机器本来就不该自动锁屏——它放在客厅，物理安全靠的是门锁，不是屏保。

坑四：分辨率不对，画面被拉伸。被控端接的是 1080P 显示器，但远程连上去画面是 4:3 的，两边有黑边。原因是被控端在无显示器状态下（比如显示器关了）启动了 Xorg，拿到的默认分辨率不对。解决办法是用xrandr手动指定，或者装一个虚拟显示适配器让 Xorg 始终有一个固定的输出。

# 查看当前输出和支持的分辨率 xrandr # 强制设置为 1920x1080 xrandr --output HDMI-1 --mode 1920x1080

坑五：系统更新之后又被切回 Wayland。这个最气人。有一次升级了 GNOME 相关的包，重启之后发现 GDM 的配置被覆盖了，WaylandEnable=false那行没了，远程又黑屏。所以改完配置之后，我建议在别的地方留个记录（比如自己维护一个部署脚本），升级大版本之后主动检查一遍。

6.3 长期使用的稳定性调优

跑通只是开始，长期稳定是另一回事。下面这几项是我用下来觉得值得调整的。

表格里最后一项经常被忽略，但它对稳定性的影响其实很大。我最初没做绑定，路由器重启之后被控端拿到了新 IP，控制端那边显示的设备一直"离线"，我以为是软件问题，查了半天才发现是 IP 变了。

另外还有一个实践中的小技巧：给被控端配一个简单的健康检查，比如用一个定时任务每分钟 ping 一次控制端，或者监控向日葵服务进程是否存活，挂了就自动重启。这个脚本可以写得极简：

#!/bin/bash # 检查服务是否存活，不存活则重启 if ! systemctl is-active --quiet sunloginclient; then systemctl restart sunloginclient echo "$(date): restarted" >> /var/log/sunlogin-watchdog.log fi

配合 crontab 每分钟跑一次，就能挡住大部分偶发的服务挂掉。这个方案很土，但在无人值守的场景下非常有效。

最后分享一个我在实际操作中的体会：远程桌面这类工具，真正的难点从来不在安装，而在于"你不在现场的时候它能不能自己活过来"。所以配置的时候要多想一步——断电重启之后能自动恢复吗？网络闪断之后能自动重连吗？服务崩了有人拉起吗？把这些边界情况都考虑到，一套远程桌面环境才算真正可用，否则你只是搭了一个"今天能用"的玩具。

如果后面还想继续扩展，我的建议是往"不依赖单一工具"的方向走：向日葵负责完整桌面，SSH 负责命令行，rsync 负责文件同步，三者各管一段。任何一条路断了，另外两条还能让你摸到那台机器。这种冗余带来的安心感，比任何单一工具的功能都值钱。