如果您管理 Linux 机器，就知道远程访问不是一刀切。
如果您管理 Linux 机器，就知道远程访问不是一刀切。为 Linux 机群选择远程工具时，界面美观并不是主要决定因素，关键在于三个平台差异：X11 与 Wayland、是否需要持久（虚拟）会话还是附着到用户的本地会话，以及无头服务器或带 GPU 的机器如何呈现显示。本文逐项讨论这些 Linux 特有的权衡，并推荐在实际部署中可用的 NoMachine 替代方案。
为什么 X11 与 Wayland 改变了局面
X11 (Xorg) 与 Wayland 并非可互换的远程访问后端。X11 采用单一的全局显示服务器模型：进程可以创建虚拟显示（Xvfb/Xdummy/Xvnc）或附着到现有的 :0 屏幕。正是这种灵活性使得许多传统远程工具（如 TigerVNC、x11vnc、Xvnc、xrdp）围绕 X11 构建。
Wayland（现代 GNOME、KDE Plasma，及 基于 wlroots 的合成器如 Sway 使用的协议）刻意更安全：屏幕捕获和输入注入由合成器（compositor）仲裁。Wayland 没有通用的标准“虚拟显示”API。相反，远程控制依赖于合成器的明确支持（用于屏幕录制的 PipeWire、合成器提供的远程控制协议，或针对特定合成器的服务器，如用于 wlroots 的 wayvnc）。
| 特性 | X11 | Wayland |
|---|---|---|
| 虚拟显示（服务器端） | 有：Xvfb / Xvnc / dummy 驱动 | 无统一标准虚拟显示；依赖合成器 |
| 连接到物理会话 | 通过 x11vnc 简单实现 | 需要合成器支持 / PipeWire |
| 屏幕捕获模型 | 全局、可编程 | 按合成器，各合成器不同，PipeWire 用于屏幕录制 |
| 可用的远程控制工具 | TigerVNC、xrdp、x11vnc | GNOME RDP backend、wayvnc、合成器插件 |
会话持久性：虚拟桌面与附着到会话
NoMachine 的一个便捷特性是会话持久性：可以创建一个虚拟的、长期运行的桌面，断开后可再次连接。在 Linux 上可以通过几种模式实现相同行为：
- Xvnc / TigerVNC / TightVNC：这些会创建持久的 X 服务器（显示 :1、:2 等）并运行桌面环境。您可以在引导时启动 VNC 桌面，并保持运行直到关闭。命令：
vncserver :1 -geometry 1920x1080 -depth 24。 - Xvfb + x11vnc：Xvfb 提供虚拟 X 帧缓存，x11vnc 将该帧缓存通过 VNC 暴露出来。当您需要无头、可脚本化的 X 显示且不需要真实 GPU 时非常有用。
- xrdp：默认情况下会创建独立的 X 会话（视配置而定），可配置为提供持久会话；不同发行版和桌面环境下行为有所不同。
- 附着到物理会话：像 x11vnc、GNOME Remote Desktop（RDP backend）或其它屏幕共享实现会附着到已登录用户的 :0 会话。这是最终用户在“接管”桌面时的预期行为——但前提是合成器允许捕获与注入。
Example: lightweight persistent VNC session using TigerVNC # install tigervnc-server (package names vary by distro) # start a persistent desktop vncserver :1 -geometry 1920x1080 -depth 24 # connect with a VNC client to user@host:5901 Example: virtual X + expose via x11vnc Xvfb :1 -screen 0 1920x1080x24 & export DISPLAY=:1 # start your desktop environment, e.g. startxfce4 & x11vnc -display :1 -nopw -forever -shared
无头服务器与 GPU 机器：实用修复方案
无头服务器（未连接显示器）和带独立 GPU 的机器带来两个常见问题：可能没有活动的帧缓存，且现代 GPU 或专有驱动（NVIDIA）可能不会创建可用的虚拟输出。可选方案：
- 假 HDMI / dummy 插头：廉价的 HDMI 虚拟插头会使 GPU 与 X 创建真实的 EDID/显示模式。对于物理机且希望使用真实 GPU 桌面，这是最简单的解决办法。
- Xorg dummy 驱动：若不需要 GPU 加速，可安装并配置 xorg 的“dummy”驱动或使用虚拟帧缓存（Xvfb）。示例：
apt install xserver-xorg-video-dummy并放置最小的 xorg.conf 来创建 :1。 - 使用虚拟化 GPU / 直通：在虚拟化环境中，配置虚拟显示适配器或直通 GPU，使来宾暴露显示输出。
- 在 Wayland 上：无头部署更困难。部分合成器（GNOME）可以通过 systemd 用户服务和 GNOME remote-desktop 堆栈创建无头会话；其他合成器（如 Sway）依赖 wayvnc 或 基于 wlroots 的工具链。如果必须可靠地在 Wayland 上无头运行，请查阅合成器文档并测试具体堆栈。
连接路径与中继（relay）对比自托管的权衡
客户端如何到达服务端与 X11/Wayland 无关，但在运维上很重要。选项包括直接（P2P）并带 NAT 穿透，或通过中继服务器。运行自建中继或 broker 是可行的，但在运维上代价高昂：需要 TLS 证书续期、可靠的多区域故障转移、防火墙规则和随叫随到的补丁。对多数团队而言，当把工程时间和可用性成本算入后，使用托管中继在总体拥有成本上更划算。
Tenvo 的托管中继是本文的默认建议：原生客户端覆盖 macOS/Windows/Linux，浏览器客户端处于公测，同时提供多区域托管中继，让您无需自建 broker。当前方案：Free $0、Lite $2.99/mo、Pro $7.99/mo——这些价格点可用于与自建高可用中继的成本进行比较。如果您有书面要求（数据驻留、禁止第三方基础设施的合规要求、隔离的管控网络），自托管才是正确选择；参见我们的 Self-Hosted Remote Desktop: Why, How, and What Breaks 获取运维清单。
安全提示：Tenvo（以及大多数厂商）使用 TLS 配合每设备证书。直接 P2P 连接在两个设备间保持端到端；当流量回落到中继时，TLS 在中继处终止，中继因此有可能看到会话流量。将中继视为受信任的操作方，并据此选择提供商或托管模型。关于隧道与防火墙选择的背景说明，请参阅 Remote Desktop Without Port Forwarding Explained。
哪些 NoMachine 替代方案适合哪些 Linux 场景
- 需要持久虚拟会话（X11，上面运行 GUI 应用的服务器）：TigerVNC (Xvnc) 或 Xvfb + x11vnc 是稳妥之选。它们提供长期运行的桌面，可脚本化且可快照。适用于构建服务器或在无头机器上运行的长期 GUI 会话。
- 在 X11 的 :0 会话上附着到已登录用户：x11vnc 或 VNC 屏幕共享能做到；在 Xorg 下可以轻松实现类似 NoMachine 的对 :0 的控制。
- Wayland 合成器与新版 GNOME/KDE：优先使用合成器感知的解决方案——GNOME 的远程桌面（RDP backend）使用 PipeWire 做屏幕捕获，适合在 GNOME 42+ 上附着到用户会话。Sway 与其它 wlroots 合成器可使用 wayvnc。若需在多种 Wayland 变体上广泛兼容，请对每个目标逐一测试。
- 以浏览器为主的访问 / Web 托管队列：Apache Guacamole 是一个面向 RDP/VNC/SSH 的 Web 网关。需要浏览器客户端且仅想通过浏览器访问时它很可靠，但这是需要您管理或托管的 Web 基础设施。
- 自托管友好的网状（mesh）方案且易于 NAT 穿透：RustDesk 提供自托管服务器选项。当您有合规理由必须自托管 broker 时它是合适的选择；否则托管中继（Tenvo）能减少运维负担。
- 企业级支持、Windows 与 macOS 的一致性：Tenvo 提供跨主流操作系统的原生客户端与可用的托管中继；当您想要集中管理而不想自建 broker 堆栈时，这是较为务实的选择。
简短参考：对 X11 服务器，使用 TigerVNC/xrdp 提供持久会话，使用 x11vnc 附着到本地会话。对 Wayland，优先合成器支持的工具（GNOME RDP、wayvnc），或选择明确支持 Wayland 并在您的发行版/桌面环境中进行测试的托管方案。
示例决策流程 —— 按工作负载选择
- 如果您管理的是面向用户的桌面（用户有实体登录）且需要支持访问：使用合成器支持的附着工具（GNOME 上使用 GNOME Remote Desktop，Sway 上使用 wayvnc），或使用 Tenvo 加托管中继以实现 NAT 穿透和集中管理。
- 如果您运行无头的构建或 CI 机器且需要持久 GUI：在引导时创建 TigerVNC/Xvnc 桌面，并在必须避开中继时通过本地防火墙规则和 SSH 隧道进行保护。
- 如果您需要审计能力和跨混合 Linux 资产的集中控制：除非合规强制自托管，否则优先考虑具有会话记录和多区域中继的托管产品；在决定前请阅读 Self-Hosted Remote Desktop: Why, How, and What Breaks。
有关针对 Linux 目标的详细设置示例和实操脚本，请参阅我们的 Linux Remote Desktop Server: X11VNC & RustDesk Setup 教程，涵盖 Xvfb、x11vnc 以及 RustDesk 的自托管服务器安装。
最终建议：务实的以 Linux 为先的建议
不存在一个通用的“替代 NoMachine”的 Linux 方案，因为桌面后端（X11 或 Wayland）和部署模型（无头虚拟机、用户桌面、受集中管理的机群）会决定不同的技术需求。通过回答三个问题来缩小选择范围：
- 我需要附着到已登录用户的本地会话，还是持久的虚拟桌面即可？
- 目标运行的是 Xorg 还是 Wayland，使用的是哪个合成器/版本（GNOME、KDE、Sway 等）？
- 我能否依赖第三方托管中继，还是合规/法规要求我必须自托管？
在运维层面上，除非您有明确的书面要求必须自托管，否则优先选择托管中继。托管中继可以避免可用性、证书管理、多区域故障转移和应急补丁等隐藏成本。Tenvo 的托管中继、原生 Linux 客户端与处于公测的浏览器客户端即面向该用例；方案包括 Free $0、Lite $2.99/mo、Pro $7.99/mo，视规模与功能而定。
想要一份厂商比较并权衡自托管的利弊？参见我们的更广泛报道：NoMachine Alternative: Linux-First Open-Source Options 和运维深度解析 Self-Hosted Remote Desktop: Why, How, and What Breaks。
准备试用一个理解 X11、Wayland 与无头机器的以 Linux 为先的托管中继与原生客户端？在 下载 页面获取原生客户端或测试浏览器公测。