远程桌面这件事，做过一次就知道它不像想象中那么"一键"。我在几台 Ubuntu 24.04 的机器上折腾过 x11vnc，前后踩的坑基本集中在两处：一是系统默认跑的是 Wayland 会话，x11vnc 在那种环境下压根没有东西可抓；二是服务托管起来之后，注销重登、分辨率变化、授权文件路径搬家，随便一个都能让画面直接黑掉。x11vnc 的定位很明确——它把一台机器上已经存在的 X11 桌面原样镜像出去，而不是给你新开一个会话。这个特性决定了它特别适合远程看住一台正在跑图形程序的机器、远程协助同事操作、或者在家里接着那台已经登录好各种账号的工作站继续干活。但它不适合当"多用户各开各桌面"的服务器方案用，那种需求得换别的工具。下面我按实际动手顺序，把这套东西从零到能稳定日常用完整讲一遍，包括每一步为什么要这么做的理由，以及那些文档里不会写、但真会绊人的细节。

1. 先搞清楚 x11vnc 到底"抓"的是什么

1.1 镜像现有会话与新建会话的本质差别

理解这一点，后面所有配置和故障排查才有落脚点。x11vnc 的工作方式是从 X 服务器的帧缓冲里读像素，再把键盘鼠标事件通过 XTEST 扩展注入回去。它自己不创建桌面，也不管理登录，本质上是一个"旁路观察者加操作手柄"。所以它能看到的东西，完全取决于当前有没有一个活着的 X 服务器，以及它能不能通过 X 的授权检查读到那个服务器。

这就带来两个直接后果。第一，机器上必须已经有人登录并且图形会话处于运行状态，你连上去看到的就是那个人正在看的屏幕，包括他打开的所有窗口和未保存的文档。第二，如果没有任何人登录、停在登录界面，x11vnc 抓到的是登录管理器自己的那个 X 会话，能看能点，但那是登录界面，不是某个用户的桌面。很多人在这一步产生误解，以为连不上是因为配置错了，其实是机器刚重启完还停在 greeter 上。

与之相对的是 xrdp 那一类方案：它自己起一个 X 会话，用户远程登录后得到一个全新的、独立的桌面，本地屏幕不受影响，两个人可以同时各干各的。这两类工具的适用场景完全不同，选错了再怎么调参数都不顺。

1.2 Ubuntu 24.04 的 Wayland 默认值是第一道坎

Ubuntu 24.04 桌面版默认使用 GNOME 46 加 Wayland 会话。Wayland 下没有传统意义上那个可以被外部进程读帧缓冲的 X 服务器，x11vnc 启动时会直接报XOpenDisplay failed或者Cannot open display ":0"。这不是权限问题，是根本不存在那个显示。

所以整套流程的第一步不是装软件，而是确认并切换会话类型。这一点必须放在最前面，否则后面所有步骤都会在一个错误的前提上打转。我见过不少人在 Wayland 环境下反复检查密码、检查端口、检查防火墙，最后才发现方向从一开始就偏了。

切换的方式是关掉 GDM 的 Wayland 模式，让它以 Xorg 启动图形会话。代价是失去 Wayland 的一些特性，比如更好的分数缩放支持、更严格的客户端隔离，以及某些触控板手势的顺滑度。如果你日常还要用这台机器做本地办公，需要自己权衡一下；如果它是一台放在角落里专门跑任务的机器，那基本没有心理负担。

1.3 什么时候该选 x11vnc，什么时候别硬上

我把常见需求和大致的对应关系整理成了一张表，选型阶段花两分钟对照一下，比后面折腾两小时划算。

还有一类情况我要提醒：如果这台机器上有多个用户会同时使用图形界面，x11vnc 会把当前屏幕完整暴露给连接方，包括通知弹窗、聊天窗口、剪贴板内容。这不是技术缺陷，是"镜像"这个模式的固有属性。在共享办公环境里部署前，最好先跟使用者说清楚这件事，比事后解释要容易得多。

2. 把图形会话切回 Xorg，并且确认它真的切过去了

2.1 用三条命令确认当前会话类型

登录到桌面后打开终端，或者干脆从 SSH 进去操作，先做基础体检。第一条看会话协议：

echo $XDG_SESSION_TYPE

输出wayland就说明还在 Wayland 下，输出x11说明已经是 Xorg。注意这条命令要在图形会话内的终端里执行，SSH 进去执行通常会得到空值或者tty，因为没有关联的图形会话。

第二条看系统里到底装了哪些可选的桌面会话：

ls /usr/share/xsessions/

正常情况下应该能看到类似ubuntu-xorg.desktop或者gnome-xorg.desktop的条目。如果这个目录是空的，说明 Xorg 会话组件没装全，需要把桌面元包补回来，比如重新安装ubuntu-desktop。这一步经常被忽略，结果关掉 Wayland 之后登录界面直接没有可选项。

第三条确认显示管理器是谁：

systemctl status display-manager --no-pager

Ubuntu 24.04 桌面版一般是gdm3。如果是lightdm或者sddm，后面的配置文件路径要相应调整，别照抄。

2.2 改 GDM 配置关掉 Wayland

GDM 的主配置在/etc/gdm3/custom.conf。用编辑器打开，找到[daemon]段，把这一行的注释去掉：

[daemon] WaylandEnable=false

改完之后保存，重启显示管理器：

sudo systemctl restart gdm3

这条命令会立刻终止当前图形会话，桌面上所有没保存的东西都会丢。所以我一般建议从 SSH 连进去执行，或者在本地先把工作保存好、关掉所有程序再操作。远程操作时如果只有图形界面这一条通路，重启 gdm3 等于自断后路，务必先确认 SSH 可用。

还有一个细节值得说：部分机型上，即使写了WaylandEnable=false，GDM 仍然可能因为显卡驱动规则文件而回退到 Wayland。判断方法是重启后再跑一次echo $XDG_SESSION_TYPE，如果还是wayland，就去/usr/lib/udev/rules.d/下面找和显示相关的规则文件看看有没有强制启用的逻辑。这种情况不算常见，但确实存在，尤其在带独立显卡的机器上。

2.3 切换后的验证与几个容易误判的现象

重启显示管理器并重新登录后，做三项验证。第一项还是echo $XDG_SESSION_TYPE，必须是x11。第二项看 X 服务器的套接字在不在：

ls -l /tmp/.X11-unix/

正常应该能看到X0这个套接字文件。有它才说明 X 服务器真的起来了，后面的-display :0才有意义。

第三项看 Xorg 进程：

ps aux | grep -i xorg | grep -v grep

能看到带:0参数的进程就对了。

这里有两个常见误判。一个是登录界面顶部的齿轮菜单里手动选了 "Ubuntu on Xorg"，但 GDM 本身还是 Wayland 模式，这种情况下用户会话是 X11，但登录界面的 greeter 仍然是 Wayland，x11vnc 在没人登录的阶段抓不到东西。如果只需要用户登录后能连，这样也够用；如果要求开机就能连、停在登录界面也能连，那必须改custom.conf。另一个误判是把DISPLAY环境变量当成万能钥匙，实际上在 Wayland 下设DISPLAY=:0只会骗过一部分程序，x11vnc 依然连不上，因为那个显示根本不存在。

3. 安装 x11vnc 与第一次手动跑通

3.1 装包与密码文件：权限比密码本身更容易出事

确认在 X11 会话下之后，安装就很直接：

sudo apt update sudo apt install -y x11vnc

x11vnc 在 universe 仓库里，Ubuntu 24.04 默认启用了这个仓库，一般不会出问题。如果提示找不到包，检查/etc/apt/sources.list.d/下有没有把 universe 注释掉。

接下来设置访问密码。推荐把密码文件放在系统级位置，因为后面要用 root 身份的服务去读它：

sudo x11vnc -storepasswd /etc/x11vnc.pass

命令会交互式提示输入密码，输入时屏幕不显示字符，这是正常的。密码长度建议不少于 8 位，VNC 协议本身的认证强度有限，密码太短等于没设。

关键的一步是权限。密码文件如果权限过宽，x11vnc 启动时会直接拒绝使用，日志里报password file has wrong permissions。手动收紧：

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

600意味着只有属主可读写。这个限制是 x11vnc 自己做的安全检查，不是可选项，绕不过去。我见过有人图省事改成644，结果服务起不来，日志翻半天才看到那一行。

3.2 那条启动命令里的每个参数都在解决什么问题

先用前台方式跑一次，把问题暴露在眼前。完整命令长这样：

x11vnc -display :0 -auth guess -forever -loop -noxdamage \ -repeat -rfbauth ~/.vnc/passwd -rfbport 5900 -shared \ -desktop "ubuntu-24-04-x11"

逐个拆开说，因为后面写服务单元时这些参数会原样搬过去，理解它们比记住它们重要。

-display :0指定要抓哪个 X 显示。单显示器单用户的机器基本都是:0，多 seat 或者多 X 服务器的情况才需要改，普通场景不用动。

-auth guess让 x11vnc 自己去猜 X 授权文件的路径。这个参数是整套配置里最容易出问题的地方，原因后面 4.2 节细说。现阶段先知道它的作用是"自动找授权文件"就行。

-forever表示客户端断开之后不要退出，继续监听下一个连接。没有它，第一个客户端一断服务就没了，得手动重开。

-loop表示 X 服务器重启后自动重连。这个参数配合-forever才能真正撑住"用户注销再登录"这种场景，因为注销时 GDM 通常会重启 Xorg 进程，原来那个连接就断了。没有-loop，服务进程会挂掉或者进入空转，画面永远停在上一次的内容上。

-noxdamage关掉 XDAMAGE 扩展。这个扩展本来是让 X 服务器告诉客户端"哪块区域变了"，理论上能减少传输量，但在某些显卡驱动和虚拟显示环境下脏区计算会出错，表现为画面局部不刷新、拖影、或者只更新左上角一块。关掉之后 x11vnc 改用轮询比对，代价是 CPU 占用略高，换来的是画面稳定。桌面用途下这个取舍很划算。

-repeat处理按键重复。没有它会有一个怪现象：远程按住方向键或者退格键，光标只动一格，得反复点。加上之后长按行为才和本地一致。

-rfbauth指定密码文件路径。这里演示用的是用户家目录下的~/.vnc/passwd，由x11vnc -storepasswd不带路径时自动生成。写成服务时换成/etc/x11vnc.pass更合适。

-rfbport 5900指定监听端口。5900 是 VNC 的默认端口，客户端不填端口时也连这个。改端口的意义主要在多实例或者想避开扫描，安全性上帮助有限。

-shared允许多个客户端同时连接。默认行为是后来者把先来者踢掉，加上这个参数后大家都能看。团队排障时很有用，但也要意识到这意味着屏幕内容会被多方同时看到。

-desktop给这个桌面起个名字，客户端连接列表里会显示，纯属可读性优化。

3.3 用客户端连上去，先确认"画面是真的"

前台跑起来之后，终端会打印一堆初始化信息，包括用的哪个显示、授权文件路径、监听端口。看到类似PORT=5900和The VNC desktop is: ...的输出就说明服务在跑了，别急着关终端。

客户端这边，Linux 上可以用 Remmina 或者 TigerVNC Viewer，Windows 和 macOS 上也有对应客户端。新建连接时填目标IP:5900，协议选 VNC，密码就是刚才存的那个。

连上之后先做三个动作验证画面"是真的"而不是缓存的假象。第一，在远程桌面里打开一个终端，敲几个字，看本地屏幕是不是同步出现。第二，把鼠标移到屏幕边缘，看指针位置是否准确对应。第三，打开一个会动的窗口，比如系统监视器，观察曲线是否在刷新。

如果这三项都正常，说明整条链路通了。如果画面出来了但敲键盘没反应，多半是 XTEST 扩展的问题，检查一下 X 服务器启动参数里有没有禁用；如果鼠标位置偏移，通常是分辨率或者缩放设置在客户端侧配错了，不是服务端的问题。

验证完先把前台进程 Ctrl+C 停掉。接下来交给服务托管，不然每次重启都要手动敲一遍。

4. 交给 systemd 托管：开机自启与注销重登后的自愈

4.1 服务单元文件里几个不能省的字段

新建/etc/systemd/system/x11vnc.service，内容如下：

[Unit] Description=x11vnc server for X11 desktop sharing After=display-manager.service network.target Wants=display-manager.service [Service] Type=simple ExecStart=/usr/bin/x11vnc -display :0 -auth guess -forever -loop \ -noxdamage -repeat -rfbauth /etc/x11vnc.pass \ -rfbport 5900 -shared -desktop ubuntu-24-04-x11 \ -o /var/log/x11vnc.log Restart=always RestartSec=3 [Install] WantedBy=multi-user.target

After=display-manager.service和Wants=display-manager.service这两行是启动顺序的保证。没有它们，服务可能在 X 服务器还没起来的时候就启动，第一次连接必然失败。Wants是弱依赖，表示"希望它在之前启动"，但即使显示管理器启动失败，这个服务仍然会尝试运行，比Requires更宽容一些，适合这种场景。

Type=simple是因为 x11vnc 前台运行时不会自己 fork 到后台，systemd 直接跟踪主进程就行。如果加了-bg参数让它自己后台化，就得改成Type=forking，反而更麻烦，不如不加。

Restart=always配合RestartSec=3是自愈的关键。x11vnc 在-loop模式下遇到 X 服务器长时间不可用，有可能自己退出，always保证它三秒后重新拉起来。用on-failure在这里不够，因为某些退出场景返回码是 0。

-o /var/log/x11vnc.log把日志单独落到文件里。systemd 自己的 journal 也能看，但 x11vnc 的日志行数多、信息密，单独一个文件方便用tail -f盯着看，也方便事后翻。

有一点要说明：这个服务是以 root 身份运行的。原因是它需要读取 GDM 生成的授权文件，那个文件通常只有特定身份能读。如果改成以普通用户身份运行，会读不到登录管理器阶段的授权文件，覆盖不到"停在登录界面也能连"的需求。代价是服务权限较高，所以第 6 节的访问控制部分要认真做。

4.2 -auth 的真实取值逻辑与 guess 的边界

-auth guess不是一个魔法参数，它的行为是有明确范围的。x11vnc 会依次尝试几个固定位置：当前用户家目录下的.Xauthority、/run/user/<uid>/gdm/Xauthority、/var/lib/gdm3/.Xauthority这类历史遗留路径，还有一些发行版特有的位置。找到第一个可读的就用。

在 Ubuntu 24.04 上，用户登录后，X 的授权文件通常在/run/user/1000/gdm/Xauthority，其中 1000 是第一个普通用户的 UID。这个路径里带 UID，意味着换用户、换机器就可能变，所以不适合写死在服务文件里，guess在这里是合理选择。

但guess也有失效的时候。典型情况是：机器上有多个普通用户，或者会话不是由 GDM 启动的（比如手动startx），授权文件位置不在候选列表里。这时候日志里会出现类似XOpenDisplay failed或者unable to open XAUTHORITY的报错。

排查办法是先手动确认授权文件在哪。登录桌面后执行：

echo $XAUTHORITY ps aux | grep -i xorg | grep -v grep

第一行如果输出路径，就用那个路径；如果为空，去看/run/user/$(id -u)/gdm/Xauthority存不存在。找到之后，把服务文件里的-auth guess换成-auth /实际路径/Xauthority。写死路径的代价是换用户要改配置，但换来的是确定性。

还有一种更稳妥的写法，是在[Service]段里加一行环境变量：

Environment=XAUTHORITY=/run/user/1000/gdm/Xauthority

这样 x11vnc 启动时会优先用这个值。前提是 UID 固定，多用户机器上不适用，得配合模板服务或者每次改。

4.3 启用服务后必须做的三项验证

写完文件之后按顺序执行：

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

daemon-reload在新写或者修改单元文件后必须执行，否则 systemd 用的还是旧的定义，这个坑很隐蔽，改了半天没生效多半就是漏了这一步。

状态显示active (running)之后，做三项验证。第一项，看日志有没有报错：

sudo tail -n 50 /var/log/x11vnc.log

重点找PORT=、The VNC desktop is、以及任何error或failed字样。第二项，从另一台机器实际连一次，确认画面正常。第三项，模拟最恶劣的场景：在远程桌面里注销当前用户，等回到登录界面，再连一次。

第三项是关键。很多配置在用户登录状态下工作正常，一注销就废了，原因就是授权文件跟着会话一起没了，或者 X 服务器重启后guess找不到新路径。加上-loop之后，x11vnc 会周期性重试，通常几秒内就能恢复。如果注销后连不上、重新登录后又好了，说明guess在 greeter 阶段失效，得手动指定 greeter 的授权文件路径，或者接受"只在用户登录后可连"这个限制。

5. 连不上、黑屏、卡成幻灯片：按症状走的排查链路

5.1 XOpenDisplay failed 这一类报错

这是最常见的一类，症状是服务起不来，或者起来了但日志里反复刷这一行。按可能性从高到低排，排查顺序如下。

第一步，确认会话类型。echo $XDG_SESSION_TYPE是不是x11。这是 Wayland 没关干净的典型表现，占我遇到过的问题里一半以上。别嫌重复，这一条值得每次先查。

第二步，确认:0这个显示真的存在。ls /tmp/.X11-unix/看有没有X0。如果没有，说明 X 服务器根本没起，可能是显示管理器挂了，或者机器停在某种异常状态。systemctl status gdm3看一下。

第三步，确认授权文件。用 4.2 节的方法找到实际路径，把-auth guess换成明确路径，重启服务再看。

第四步，确认权限。以 root 身份运行的服务读普通用户的授权文件，理论上没问题，但如果文件权限是600且属主是某个普通用户，而 SELinux 或者 AppArmor 有额外限制，也可能被拦。Ubuntu 24.04 默认的 AppArmor 对这类读取一般不管，但如果之前动过策略，值得看一眼dmesg里有没有 denied 记录。

第五步，如果前面都对还报错，试试手动以前台方式跑同一条命令，看报错是否一致。手动能跑、服务不能跑，问题一定在服务文件的环境差异上，比如工作目录、环境变量、启动时机。

5.2 连上了但黑屏或局部不刷新

黑屏分两种。一种是全黑但鼠标能动、点击有反应，这种通常是抓到画面了但没渲染出来，常见原因是客户端和服务端的色深或者编码协商不一致。换一个客户端试试，或者服务端加-depth 24明确指定色深。

另一种是全黑且鼠标也没反应，这种更可能是抓错了显示或者抓到了一个空会话。检查日志里的X DISPLAY和实际会话是否对应。多显示器环境下，-display :0抓的是整个 X 屏幕，但某些客户端只显示主屏，看起来像黑屏，实际是显示区域被裁掉了。

局部不刷新、拖影、只有部分区域更新，这一类几乎都是 XDAMAGE 的问题。确认启动参数里有-noxdamage。如果加了还有问题，试试再加-noxfixes，或者干脆加-onetile强制整屏刷新。整屏刷新的代价是带宽和 CPU 占用上升，但在局域网里基本感觉不到。

还有一种少见情况：画面正常但颜色发灰、发暗。这通常是客户端侧的渲染问题，或者服务端用了 16 位色深。检查-depth参数，默认应该是 24 位。

5.3 带宽吃紧时的参数组合与实测取舍

局域网内一般不用管性能，但如果是跨网段、或者链路质量一般，调参就有意义了。我试过的几组组合和效果大致如下。

-ncache的效果很明显，但兼容性一般。我遇到过某个客户端开了缓存之后窗口位置错乱，关掉就正常。所以这个参数建议先不加，确认基础功能稳定之后再逐步引入，出问题好定位。

-speeds有 0 到 3 几个档位，数字越小越保守。链路稳定的话别动，默认值就好。真的卡到没法用时，从-speeds 1试起。

压缩相关的参数要一起看。-compresslevel和-quality是两套不同的机制，前者影响无损压缩的强度，后者影响有损压缩的质量。文字类内容对-quality敏感，降到 5 以下文字边缘会糊；图片类内容对压缩级别更敏感。我的经验是-compresslevel 6 -quality 6这个组合在大多数场景下平衡得不错，别一味往低里调。

还有一个容易忽略的点：客户端侧的设置也影响很大。同样的服务端参数，不同客户端渲染效率差好几倍。如果卡，先换客户端试试，比调服务端参数来得快。

6. 5900 端口不该裸奔：访问控制与传输保护

6.1 防火墙按来源放行

x11vnc 的监听默认对所有网络接口开放，这意味着同一网段里任何知道 IP 和密码的人都能尝试连接。VNC 协议本身的认证强度不高，密码再复杂也只是防住暴力猜解，传输过程本身不加密，中间链路上能抓到内容和凭据。

第一步是把监听范围收窄。Ubuntu 用 ufw 的话：

sudo ufw allow from 192.168.50.0/24 to any port 5900 proto tcp sudo ufw status numbered

把网段换成你自己的实际网段。这条规则只允许那个网段的地址访问 5900，其他来源一律拒绝。比sudo ufw allow 5900/tcp这种全放开的写法安全得多。

如果要更严格，只允许单台机器：

sudo ufw allow from 192.168.50.23 to any port 5900 proto tcp

规则生效后从另一台不在白名单里的机器试一次，确认真的连不上，别只看状态输出。ufw 的规则顺序会影响最终效果，用numbered列出来检查一下有没有更靠前的允许规则把它覆盖掉。

6.2 SSH 端口转发这条最省事的路

更彻底的做法是让 x11vnc 只监听回环地址，外部完全不可见，所有访问都走 SSH 隧道。服务文件里的启动参数加一个-localhost：

-rfbport 5900 -localhost

这样 x11vnc 只绑定127.0.0.1，网络上的其他机器连这个端口会直接拒绝。然后客户端侧建立 SSH 端口转发：

ssh -N -L 5900:127.0.0.1:5900 labuser@192.168.50.23

这条命令在客户端机器上执行，把本地的 5900 转发到远端服务器的回环 5900。执行后终端会挂住，这是正常的，-N表示不执行远程命令、只做转发。

然后 VNC 客户端连127.0.0.1:5900就通了。整条链路里，数据先经过 SSH 加密，服务器上的 5900 端口对外完全不可见。

这套方案的好处有三个。加密由 SSH 负责，不用额外配置证书；认证复用 SSH 的密钥体系，比 VNC 密码可靠；访问控制收敛到 SSH 一处，不用在两套系统里各维护一份白名单。代价是多一层 SSH 连接，初次建立时略微多花一两秒，之后就无感了。

有个小坑要注意：如果本地 5900 端口被占用，ssh -L会直接报错退出。换个本地端口就行，比如-L 5901:127.0.0.1:5900，客户端相应连127.0.0.1:5901。另外 SSH 连接断了隧道就失效，长时间使用建议加ServerAliveInterval之类的保活参数。

6.3 密码、会话可见性与几个加固小动作

除了网络层的控制，还有几件小事值得做。

密码文件用600权限，这一点前面说过，但要定期检查，特别是团队里多个人维护同一台机器的时候，某次手误chmod 644就前功尽弃。

不要在多个地方复用同一个 VNC 密码。它存在明文可读的文件里，一旦泄露影响面要控制到最小。

连接成功后，桌面上的通知、弹窗、剪贴板对连接方都是可见的。处理敏感内容前，先确认没有其他人连着。-shared允许多客户端，如果不需要，去掉这个参数，后来者会踢掉先来者，至少能保证同一时刻只有一个人在看。

日志文件/var/log/x11vnc.log会记录连接来源和断开时间，定期看一眼有没有陌生地址尝试连接。x11vnc 日志里对失败尝试的记录不算详细，但连接成功的行一定有，对照自己的使用时间就能发现异常。

最后，如果这台机器只在特定时段需要远程访问，干脆用 systemd 的定时器或者手动systemctl start/stop控制服务开关，比让它 24 小时常驻更省心。

我在几台机器上跑下来，最稳的组合是：关掉 Wayland、-auth guess配合日志观察、-loop -forever -noxdamage三个参数常驻、服务用Restart=always、对外只留 SSH 隧道。这一套用了大半年，中间经历过系统更新、显卡驱动更换、用户注销重登，都能自己缓过来。唯一一次翻车是某次改完custom.conf忘了重启 gdm3，然后对着日志找了半小时才发现会话还是 Wayland——所以现在我的习惯是，任何配置改完，第一件事就是重新跑一遍echo $XDG_SESSION_TYPE，确认自己站在正确的地基上再往下走。