Linux 远程桌面服务器：X11VNC 与 RustDesk 守护进程部署

你希望让他人（或你自己）可靠、安全地连接到 Linux 桌面，并且不通过昂贵的专有服务 —— 但你找到的手册要么太空泛，要么是为图形界面专家写的。本指南展示两种实用的服务器端方法：一个成熟可靠的 X11VNC 配置用于直接暴露 X 会话，另一个是自托管的 RustDesk 守护进程（hbbs/hbbr）用于现代 NAT 穿透与中继 — 包含真实命令、systemd 单元、Docker 示例以及具体的加固步骤。

为什么要运行 linux 远程桌面服务器？快速决策树

在进入命令之前：选择一个符合你需求的模型。

• 如果你需要直接访问机器上的物理 X 会话（支持已登录用户、本地会话状态和多显示器），X11VNC 是最简单的服务器端工具。
• 如果你需要客户端/服务器模型，支持 NAT 穿透、ID 服务器、中继和更容易的跨平台客户端 —— 并且你想自托管这些服务器组件，请运行 RustDesk 的 hbbs/hbbr 守护进程。
• 如果你只是想为一次性支持快速建立单机隧道，SSH 隧道或使用托管服务可能更快。另见我们的自托管远程桌面指南，了解策略与权衡。

注意：像 TeamViewer 和 AnyDesk 这样的商业产品在纯便捷性上通常占优（开箱即可自动 NAT 穿透和优化的编解码器）。如果你需要即插即用的可靠性和商业支持，它们是合理的选择；参见 rustdesk-vs-anydesk 的功能权衡比较。

1) X11VNC：将物理 X 会话暴露出来的最小 linux 远程桌面服务器

X11VNC 连接到已有的 X 服务器并提供当前桌面。它不是独立的虚拟桌面 —— 而是镜像本地已登录的 GUI。对于希望与本地用户看到的同一会话交互的远程支持和运维场景，这非常合适。

先决条件与推荐版本

• 适用于基于 X11 的桌面。对于 Wayland，请使用合成器特定的远程 API 或采取不同的方法。
• 安装 x11vnc >= 0.9.16（0.9.16+ 提供现代特性与稳定性改进）。
• 确保有显示管理器（gdm/lightdm/sddm）或在 :0 上运行的 X 会话。

在 Debian/Ubuntu 上安装（示例）：

sudo apt update
sudo apt install -y x11vnc xauth

创建密码文件（请安全存储）：

sudo x11vnc -storepasswd /etc/x11vnc.pass
sudo chown root:root /etc/x11vnc.pass
sudo chmod 600 /etc/x11vnc.pass

用于在显示 :0 上自动启动的简单 systemd 单元（放到 /etc/systemd/system/x11vnc.service）：

[Unit]
Description=x11vnc - VNC server for :0
After=display-manager.service

[Service]
Type=simple
ExecStart=/usr/bin/x11vnc -auth guess -forever -loop -noxdamage -repeat -rfbauth /etc/x11vnc.pass -rfbport 5900 -shared -ncache 10
User=root
Restart=on-failure

[Install]
WantedBy=graphical.target

启用并启动：

sudo systemctl daemon-reload
sudo systemctl enable --now x11vnc.service
sudo systemctl status x11vnc.service

X11VNC 的安全注意事项

• 不要在没有额外保护的情况下直接将 TCP/5900 暴露到互联网。VNC 验证在局域网使用可以，但在公共网络上应视为弱认证。
• 优先使用 SSH 隧道进行远程访问：ssh -L 5900:localhost:5900 user@your-server，然后在本地连接 VNC 客户端到 localhost:5900。
• 如果需要直接的 TLS，请使用 stunnel 或 VPN。或者把 VNC 放在恰当的防火墙之后，并要求 VPN 访问。

性能建议

• 使用 -ncache 10 以减少桌面内容快速变化时的带宽突发。
• 在 1–2 Mbps 链路上看到高 CPU 时，降低色深或使用压缩标志（x11vnc 支持 -compresslevel 和 -quality）。多试验 —— 降低质量通常能显著提升感知响应速度。

2) RustDesk 守护进程：用于现代远程访问的自托管中继与 ID 服务器

RustDesk 客户端可以使用一个中央 ID 服务器（hbbs）和一个中继（hbbr）在 NAT 后面连接对等端。自托管 hbbs/hbbr 可让你完全控制 ID 和中继 —— 如果你想避免第三方服务器，这很重要。在自托管模型下，大多数人所说的 linux 远程桌面服务器即指这种服务器端部署。

为什么要把 hbbs/hbbr 分成两个服务而不是单个二进制？hbbs 是 ID 服务器（认证、分配），hbbr 是中继服务器（当直接 P2P 失败时做 TCP/UDP 中继）。两者都很轻量，通常在 Docker 中运行。

推荐版本：部署时请使用 rustdesk 服务组件 1.1.9+（或部署时的最新稳定标签）。在生产上线前查看 RustDesk 项目的发行说明。

hbbs + hbbr 的示例 Docker Compose（精简）：

version: '3.3'
services:
  hbbs:
    image: rustdesk/rustdesk-server:1.1.9
    container_name: rustdesk_hbbs
    restart: unless-stopped
    ports:
      - "21115:21115/tcp"  # hbbs TCP (ID server)
    environment:
      - RUST_LOG=info
    volumes:
      - ./data/hbbs:/data

  hbbr:
    image: rustdesk/rustdesk-server:1.1.9
    container_name: rustdesk_hbbr
    restart: unless-stopped
    ports:
      - "21116:21116/tcp"  # hbbr TCP (relay)
      - "21116:21116/udp"  # hbbr UDP for hole punching/relay
    environment:
      - RUST_LOG=info
    volumes:
      - ./data/hbbr:/data

关于端口与 NAT 的说明

• 常见的 RustDesk 端口映射是 21115（hbbs ID 服务器）和 21116（hbbr 中继）。UDP 对 NAT 穿透有帮助；尽可能同时打开 TCP 与 UDP。
• 让服务器位于公网 IP 或有静态 IP/DNS 的主机上。为客户端配置的主机名使用 A/AAAA 记录。

客户端侧配置

将 RustDesk 客户端指向你的 hbbs 主机名并按需启用中继。你可以强制使用中继以保护隐私，或在双方都能穿透 NAT 时允许点对点。客户端配置界面接受服务器主机名和端口（例如 server.example.com:21115）。

为自托管 RustDesk 守护进程部署加固

RustDesk 的默认对等流量是加密的，但服务器组件负责认证与协调。请考虑以下加固步骤：

• 将 hbbs/hbbr 放在防火墙之后，仅开放必要端口（21115 TCP，21116 TCP/UDP）。使用 UFW 或 firewall-cmd；示例：sudo ufw allow 21115/tcp; sudo ufw allow 21116/tcp; sudo ufw allow 21116/udp。
• 对任何面向 Web 的管理 UI 使用 TLS/HTTPS。如果你在反向代理（nginx/caddy）处终止 TLS，请保持后端隔离。
• 监控日志与资源使用情况。RustDesk 组件轻量，但你需要关注连接数与中继带宽。
• 如果在 hbbs 端发现暴力破解尝试，考虑在主机上使用速率限制和 fail2ban。

什么时候选择 RustDesk 或 X11VNC

• 需要跨平台客户端支持（Windows/Mac/Linux/Android/iOS）、NAT 穿透以及针对大量端点的单一自托管 ID/中继时，选择 RustDesk。它是面向分布式设备队列的现代解决方案。
• 需要针对特定桌面机器并与本地 X 会话交互（例如排查已登录用户问题或图形启动问题）时，选择 X11VNC。

实用的生产注意事项与性能调优

带宽与 CPU：对典型办公任务（使用压缩编解码器）来说，直接远程桌面会话通常消耗约 1–5 Mbps；对视频或游戏的屏幕共享会产生更高峰值。如果你自托管中继（hbbr），请为中继带宽做预算：100 个并发会话以 2 Mbps 计 = 约 200 Mbps 的持续带宽需求。

监控与自动扩缩：对于较大组织，在 hbbs 之前运行一个小型 HA 代理或负载均衡器，并在不同区域部署多个 hbbr 中继。需要自动扩缩时使用标准容器编排（Docker Swarm 或 Kubernetes）；否则对于小团队，一台配置较高的中继 VM 就足够。

日志与故障排查

• x11vnc 的日志出现在 systemd 日志中：sudo journalctl -u x11vnc.service
• RustDesk 容器：docker logs rustdesk_hbbs 和 docker logs rustdesk_hbbr 查看启动错误。使用 ss 或 netstat 检查端口可达性，并从远程客户端测试 UDP/TCP。
• 如果直接连接失败，确认中间的 NAT 或防火墙没有阻塞 UDP；许多运营商会阻止非常规的 UDP 端口范围。

安全比较与对厂商的坦率看法

如果安全与隐私是首要关注点，自托管 hbbs/hbbr 可让你掌控元数据和中继端点。然而，像 TeamViewer 或 AnyDesk 这样的专有厂商在开箱时可能提供更强的 NAT 穿透、在差链路下带宽更低的专有编解码器，以及企业级支持/服务等级协议。如果你需要保证的 24/7 商业支持并希望为非技术用户更容易上手，它们可能更合适——但这种便捷是有成本的。参见 anydesk-pricing-explained 了解定价差异与权衡。

上线前的实用检查清单

1. 确定适合你的模型（X11VNC 用于物理会话；RustDesk 用于基于 ID/中继的远程访问）。
2. 加固服务器：防火墙、仅允许 SSH 密钥登录、fail2ban 速率限制，以及在适用处启用 TLS。
3. 从外网测试：验证中继行为、延迟和故障切换情况。
4. 设置监控（日志、带宽、进程重启）和故障告警策略。

进一步阅读与内部资源

如果你在评估更广泛的自托管选项与权衡，请阅读我们的自托管指南，地址为 /self-hosted-remote-desktop。若要对 RustDesk 与商业选项做专门的功能比较，请参见 /rustdesk-vs-anydesk。

结语与实务提示

两种方法都可维护，但解决的问题略有不同。X11VNC 对单机桌面来说简单且可预测；RustDesk 守护进程在规模化队列时更具伸缩性，并在正确配置时优雅地处理 NAT 穿透。无论哪种情况，切勿直接将未加密的 VNC 暴露到互联网 —— 始终使用 SSH 隧道、VPN 或经过适当加固的中继。

准备好自行尝试了吗？下载 Tenvo （godeskflow）客户端或查看我们的服务器文档 /download —— 如果需要定价或企业选项，请查看 /pricing。部署测试实例，验证防火墙规则，并在向用户推广前确认客户端行为。