1. 需求梳理从一台Ubuntu到另一台电脑的远程桌面如果你和我一样平时的主力机器装的是 Ubuntu 桌面版难免会遇到“人不在机器旁边却想直接操作这台机器桌面”的时刻。我第一次被逼着去折腾 Ubuntu 远程桌面配置是因为需要在异地操作一台装机不下十次、专门跑模拟计算的主机程序在那儿桌面也在那儿可人不在。先后试过 TightVNC、再换到 x11vnc中间踩遍了黑屏、连不上、服务启动就退、Wayland 不认 Xauthority 的坑最后才把整条链路稳定下来。这篇文章就把整套折腾过程完整记录下来包含每一步命令、预期效果和翻车现场适合正在配置 Ubuntu 远程桌面或者已经发现 TightVNC 怎么都连不上真实桌面的朋友拿来对照参考。1.1 先分清需求你要的是“虚拟桌面”还是“共享当前屏幕”很多第一次配置 Linux 远程桌面的人没意识到这个领域里有两条完全不同的技术路线。第一种是虚拟桌面服务器。典型代表是 TightVNC、TigerVNC 自带的vncserver这类工具。它会在你现有系统之外再创建一个“虚拟显示器”在这个虚拟显示器上启动一个全新的桌面会话。你远程连过去看到的不是物理屏幕上正在运行的东西而是一个独立、空白、需要单独登录的全新桌面。这种方案适合无头服务器没有接显示器的机器需要跑一个 GUI 程序的场景。第二种是共享当前屏幕。典型代表就是 x11vnc。它直接“附加”到你正在使用的 X 服务上把真实显示器上显示的内容通过 VNC 协议实时转给远程客户端。你远程看到的就是物理显示器上此刻的内容鼠标、键盘操作也会直接作用到当前桌面上。用一句话概括前者是“再造一个桌面”后者是“镜像眼前这个桌面”。我当时的需求其实是后者那台 Ubuntu 主机上已经跑着重要的程序、开着一堆终端窗口和工作流我不想也不应该再切到一个陌生会话里重新操作。我需要的是“屏幕上有啥我远程就看到啥”。这也决定了后来 TightVNC 无论怎么调方向都不对——它再稳定也解决不了“我想操控当前这面屏幕”这个核心诉求。1.2 候选方案对比与最终选择在确定走 VNC 路线之前我把常见的远程桌面方案都过了一遍方案优点缺点适不适合我xrdpRDP 协议客户机自带的远程桌面工具就能连与 Ubuntu 自带 GNOME 桌面兼容性小坑不少经常需要额外配置桌面会话可以试但坑也不浅TeamViewer / AnyDesk 等商业软件开箱即用速度不错闭源个人使用免费用于内部服务时有些受限临时应急可以长期依赖不放心TightVNC 虚拟桌面配置简单客户端普及无法直接操控当前物理桌面性能一般方向不对x11vnc直接共享当前物理屏幕轻量协议开放需要了解 X11、Wayland 相关概念初次配置不够“傻瓜”最终选择选择 VNC 体系还有一个重要原因客户端生态太成熟了。桌面端有 Remmina、TigerVNC Viewer手机端也有现成的 VNC 客户端不需要额外安装太多东西。只要服务端跑起来剩下的就只是“连一个地址、输一次密码”。工具选型的原则最后沉淀成一句话能开源绝不用闭源能直接共享当前屏幕就绝不另起一个会话。这句话也直接决定了我从 TightVNC 转向 x11vnc 的必然性。但那都是踩完坑之后才想明白的一开始我也老老实实从 TightVNC 开始折腾。2. 前置检查不搞定这些后面全是黑屏很多人配远程桌面失败不是最后的命令写错而是环境准备没做扎实。这里的环境不是说你装个 Ubuntu 就行而是要确认几件容易被忽略的事当前会话是 X11 还是 Wayland、屏幕会不会自动锁、防火墙端口有没有放开。这几项不提前解决后面 x11vnc 连上的概率极低连上也大概率是一块黑屏。2.1 确认你的 Ubuntu 会话是 X11 而不是 Wayland这是一个决定性的检查也是最容易被忽略的。从 Ubuntu 22.04 开始默认用的是 GDM 登录管理器桌面环境默认跑在 Wayland 协议上。而 x11vnc 从协议层面只支持 X11它读的是 X 服务的画面、用的是 Xauthority 的认证机制。Wayland 会话下直接跑 x11vnc 会报错或者起来之后黑屏、无法授权。检查当前会话类型最简单的方法在终端里执行echo $XDG_SESSION_TYPE如果是x11那没问题。如果是wayland继续往下看。我那次遇到的机器正是默认 Wayland 会话。解决办法是在登录界面的用户图标下方点那个齿轮小按钮选择“Ubuntu on Xorg”再登录。但这属于临时的每次都得手动切。要做到一劳永逸需要把 GDM 的 Wayland 支持关掉。编辑 GDM 配置文件sudo nano /etc/gdm3/custom.conf找到这一行#WaylandEnablefalse取消注释改成WaylandEnablefalse保存退出重启机器。之后echo $XDG_SESSION_TYPE就会稳定输出x11。这一步直接决定了 x11vnc 能不能在这个系统上存活建议在所有操作之前先做。2.2 关掉息屏、锁屏让远程连接更省心远程桌面最烦的情况之一就是你连过去之后看到的是锁屏界面或者更糟——屏幕已经休眠看起来就像一台死机。Linux 桌面默认的省电策略会在空闲一段时间后锁屏、熄屏。从远程操作时经常因为本地没人碰键盘机器很快就自动息屏了。等你想连上去要么画面全黑要么卡在密码解锁界面。我在配好 x11vnc 之后仍然频繁遇到黑屏排查半天才发现是 GNOME 电源管理在搞鬼。解决方法是把桌面空闲锁屏和自动息屏都关掉# 关闭命令行界面的空闲延迟 gsettings set org.gnome.desktop.session idle-delay 0 # 关闭插电状态下的自动息屏 gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type nothing # 关闭电池状态下的自动息屏 gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-battery-type nothing # 关闭屏幕变暗 gsettings set org.gnome.settings-daemon.plugins.power idle-dim false # 关闭自动锁屏 gsettings set org.gnome.desktop.screensaver lock-enabled false这些命令拿到普通桌面电脑上毫无压力。如果你觉得关闭屏幕节能有点浪费电也可以保留自动息屏但在 x11vnc 启动参数里加上-nodpms告诉它不要理会显示器的电源管理信号——后面讲服务配置时会提到。2.3 确认 IP、放开防火墙端口网络层面看起来不复杂却是最容易“莫名其妙连不上”的地方。先确认这台机器的局域网 IPip a找到有线或无线网卡对应的 IPv4 地址记下来。建议在路由器里给这台机器的 MAC 地址绑定一个固定 IP省得 DHCP 频繁变化。很多 Ubuntu 桌面默认自带 UFW 防火墙但没有规则时默认是放行所有流量。如果之前设置过防火墙需要单独放行 VNC 端口sudo ufw allow 5900/tcp sudo ufw status注意如果后面决定用 SSH 隧道转发 VNC这是我最推荐的用法那么 5900 端口不应该对局域网开放而是只绑定 127.0.0.1靠 SSH 把流量从远程带回来。这个话题放到第五部分细讲。3. TightVNC 踩坑全记录它和“当前桌面”是两回事现在说回正题为什么我一开始选了 TightVNC又为什么最终放弃。如果你只是想找一个最快能远程连上 Ubuntu 桌面的办法可能也有人会推荐tightvncserver因为它一条命令就能装好、启动。但我踩坑之后可以负责任地说它解决的是“有没有桌面可用”而不是“能不能共享现有桌面”。3.1 vncserver 创建的是一块“虚拟显示器”先交代一下背景知识。Linux 的图形体系里X display是一个概念用:0、:1这样编号区分。物理屏幕上跑着的桌面通常在:0。而vncserver这个工具做的事情等价于在系统里创建了一块不存在于物理硬件的虚拟显示器编号一般是:1然后在这块虚拟显示器上启动一个新的桌面会话。你远程连接 5901 端口对应:1看到的其实是另一个完全独立的桌面。这也是我第一次用 TightVNC 时最困惑的场景本机桌面上明明开着终端、浏览器和编辑器远程连过去却是一个空荡荡的初始桌面仿佛一台刚装好的新电脑。我当时还以为是自己配置错了翻了一堆资料后来才搞明白原理vncserver不是“镜像”你面前的屏幕而是“另起炉灶”。这个知识点很关键因为它解释了一系列后续问题为什么 TightVNC 连上看不到真正的桌面为什么黑屏为什么程序跑在物理桌面VNC 窗口里却看不见3.2 xstartup 黑屏问题的调试实录主要问题从改配置文件开始TightVNC 启动虚拟桌面时需要一个~/.vnc/xstartup脚本指定在这个虚拟显示器上启动哪个桌面环境。我最初的配置很简单结果连上去是纯黑屏。后来把脚本改成了这样#!/bin/sh unset SESSION_MANAGER unset DBUS_SESSION_BUS_ADDRESS export XAUTHORITY$HOME/.Xauthority export PATH$PATH:/usr/local/bin xrdb $HOME/.Xresources || true dbus-launch --exit-with-session gnome-session 改完重启 vncserver桌面终于出来了但出来的是 GNOME 默认会话依然不是我物理桌面上的那个会话。调通之后我只能捏着鼻子用它顶了两天。远程进去之后必须重新打开需要的应用、重新登录各种工具、重新导航到项目目录。如果你只是想把文件拖过来、点几下操作那还好但如果远程的是一台正在跑长时间任务的机器这种“第二个桌面”的模式就很分裂。后来我也查了很多资料发现不少人用 TightVNC 时桌面环境会换成 XFCE而不是 GNOME。因为 GNOME 本身比较吃资源在虚拟显示器上跑容易出各种渲染和启动问题。如果你看到这里仍打算用 TightVNC建议把桌面装成 XFCE 再跑脚本sudo apt install xfce4 xfce4-goodies脚本改为#!/bin/sh startxfce4 这套方案跑个纯远程办公工具是没问题的但它依然解决不了“镜像物理桌面”这件事。3.3 TightVNC 让人忍不了的两个短板第一个短板是性能。TightVNC 在处理高分辨率桌面时画面更新明显跟不上尤其是拖动窗口、切换工作区、滚动网页时马赛克和撕裂感很重。它对带宽和 CPU 的开销都不友好长期远程操作体验很差。第二个短板是安全。VNC 协议默认是明文的TightVNC 也没有传输加密机制。密码只是用来做接入认证不能保护传输内容。只要有人在同一网络中抓包遥控期间敲的每一个键、屏幕上显示的内容都可能被还原出来。这两个短板让我下定决定换方向我要的不是“再造一个会话”而是“把现有桌面安全地、流畅地搬到远程”。4. x11vnc 配置实录直接把眼前的桌面搬过去x11vnc 这个名字看着和 VNC 很像但它做的事情完全不同它是一个轻量的 VNC 服务进程直接读取你当前 X session 的画面并提供给任何 VNC 客户端。配上好一点的参数操作手感和体验都会好不少。4.1 安装和口令文件安装非常直接sudo apt update sudo apt install x11vnc然后生成口令文件。VNC 客户端的认证口令是独立于你的系统登录密码的。我这里强烈建议单独设置一个和系统密码不同的口令因为 VNC 口令经常会在配置文件里出现如果和系统密码一致等于多暴露了一个入口。mkdir -p ~/.vnc x11vnc -storepasswd ~/.vnc/passwd chmod 600 ~/.vnc/passwd-storepasswd会提示输入两遍密码然后加密写入~/.vnc/passwd。设置完成后这个文件只能当前用户读写避免其他用户轻易读到口令。4.2 首次手动运行先确认链路通先不要在浏览器里看一堆教程然后直接上 systemd先手动跑一次前提条件都满足之后再考虑持久化。x11vnc -display :0 -auth guess -rfbauth ~/.vnc/passwd -rfbport 5900 -forever -shared -o /tmp/x11vnc.log这个命令里的参数逐个解释-display :0告诉 x11vnc 去抓取哪个显示的屏幕。正常物理桌面是:0。如果你不确定是:0还是:1用echo $DISPLAY可以查到当前会话编号。-auth guess自动猜测 Xauthority 文件的位置。这个对 GDM 用户尤其重要因为你的 Xauthority 可能不在默认路径。-rfbauth ~/.vnc/passwd指定刚刚生成的口令文件。-rfbport 5900VNC 服务端口5900 是 VNC 默认端口对应显示编号:0。-forever有客户端断开之后继续保持服务否则第一个客户端退出后进程就结束了。-shared允许多个客户端同时连接。-o /tmp/x11vnc.log日志写到这个文件里方便排查。运行之后用任意 VNC 客户端连接你的IP:5900。我用的是 Remmina连接类型选 VNC填地址、输口令几秒内应该就能看到物理桌面的一比一镜像。如果日志里有类似Automatic XAUTHORITY guess successful的字样说明认证文件找对了链路已经通。如果这里就报错先回头确认第 2 部分的 X11 会话和息屏配置绝大多数问题根源在那两个地方。4.3 用 systemd 服务把它变成开机自启的常驻进程手动跑通之后下一步就是让它开机自启、掉线自动拉起。我踩过的一个教训是不要在multi-user.target阶段启动 x11vnc因为那时候 GDM 可能还没起来没有 X display 可以附加。正确做法是让服务放在graphical.target之后并且依赖显示管理器。创建服务文件sudo nano /etc/systemd/system/x11vnc.service内容如下[Unit] Descriptionx11vnc remote desktop server Afterdisplay-manager.service Wantsdisplay-manager.service [Service] Typesimple User你的用户名 Group你的用户组 EnvironmentDISPLAY:0 ExecStart/usr/bin/x11vnc -display :0 -auth guess -rfbauth /home/你的用户名/.vnc/passwd -rfbport 5900 -forever -shared -wait 10 -defer 5 -ncache 10 -ncr -nodpms -o /var/log/x11vnc.log Restarton-failure RestartSec5 [Install] WantedBygraphical.target几个需要注意的点一是User和Group要换成你平时登录桌面的那个用户名和用户组不能写成 root否则 x11vnc 以 root 身份运行时权限和处理认证的路径会非常别扭。二是-auth guess在 systemd 场景下不一定稳定。如果重启之后日志一直提示找不到 Xauthority需要手动指定。常见路径在/run/user/你的uid/gdm/Xauthority可以先执行ls /run/user/*/gdm/查看实际文件然后把服务里ExecStart的-auth guess替换成-auth /run/user/你的uid/gdm/Xauthority。三是把日志定向到/var/log/x11vnc.log。调试远程服务日志是最直接的线索来源一定要留。启动并设置开机自启sudo systemctl daemon-reload sudo systemctl enable --now x11vnc sudo systemctl status x11vnc看到状态是active (running)再用客户端连一次。这次连接成功就说明整条链路已经可以长期运作了。5. 让连接更顺畅性能参数与加密实践服务和配置都起来之后还有两件事很影响体验性能和安全性。VNC 裸奔在局域网里也许暂时没问题但只要这台机器有公网 IP就必须认真考虑加密。不然哪天连不上、被入侵了后悔都来不及。5.1 实测有效的参数组合x11vnc 的默认参数不是最优的。默认的轮询间隔比较慢高分辨率屏幕下会显得卡顿。我最后用的参数组合在系统服务文件里已经体现这里单独拆开解释x11vnc -display :0 -auth guess -rfbauth /home/用户/.vnc/passwd -rfbport 5900 -forever -shared -wait 10 -defer 5 -ncache 10 -ncr -nodpms -o /var/log/x11vnc.log-wait 10两次屏幕轮询之间的间隔毫秒数。默认是 50改成 10 意味着更快的画面刷新但 CPU 占用会略高。-defer 5屏幕更新发送的延迟。数值越小操作响应越跟手。实测 5 毫秒在局域网内手感很好。-ncache 10开启客户端缓存缓存帧数设为 10。这个参数对滚动网页、移动窗口的帮助非常大画面重绘不再一帧一帧地糊。-ncr配合-ncache使用启用 Improved ncache Reader 模式。-nodpms忽略显示器的电源管理信号防止远程连接期间屏幕休眠。这套参数在局域网内实测效果不错1080p 分辨率下拖动终端窗口已经感受不到明显掉帧。但也要注意-wait 10会把 CPU 占用拉高一点低性能机器上可以把-wait调回 20~30换取更低的空闲负载。如果你的网络环境非常差可以考虑用-bgr233强制 8 位色彩画面会偏色但带宽占用会降得很明显。这个参数只建议在万不得已时用。5.2 用 SSH 隧道加密 VNC而不是把端口暴露到公网VNC 协议本身不加密。哪怕设置了 VNC 口令抓包者只要拿到了口令依然可以直接进入你的桌面。口令只负责“准入”不负责“加密传输”。最稳妥的做法VNC 服务只绑定到本机回环地址远程通过 SSH 隧道访问。这样 VNC 端口对外完全不可见所有流量都走 SSH 的加密通道。先把服务文件里ExecStart加一个参数-localhost-localhost会让 x11vnc 只监听127.0.0.1局域网内其他机器直接连 5900 会失败只有本机能访问。然后重新加载服务sudo systemctl daemon-reload sudo systemctl restart x11vnc在本地电脑上先建立 SSH 隧道ssh -L 5900:127.0.0.1:5900 你的用户名目标主机IP -N这个命令的含义是把本地电脑的 5900 端口通过 SSH 隧道转发到目标主机的 5900 端口。-N表示只转发不执行远程命令。隧道建立后VNC 客户端连接127.0.0.1:5900就能经过加密隧道访问到目标主机的桌面。为了方便可以写一个简单脚本放在本地#!/bin/bash ssh -f -N -L 5900:127.0.0.1:5900 你的用户名目标主机IP sleep 1 remmina -c vnc://127.0.0.1:5900这样每次只需要执行这个脚本就能一键加密连接到远程桌面。同时注意SSH 需要保持运行隧道才能在后台稳定工作。6. 高频故障排查方案配置过程说不踩坑是假的。尤其是从重启到服务自动拉起之间有太多环节可以出问题。我把实际遇到过的以及排查思路比较典型的问题整理成一个速查表之后再单独聊一次完整的排查过程。6.1 常见问题速查表现象可能原因处理方式客户端提示连接被拒绝服务没起来 / 端口没监听 / 防火墙拦截ps aux | grep x11vnc确认进程ss -lnt | grep 5900确认端口sudo ufw status查防火墙能连上但全黑屏当前会话是 Wayland / DISPLAY 不对echo $XDG_SESSION_TYPE确认是 x11echo $DISPLAY确认是:0提示认证失败口令文件路径不对 / 权限过宽确认-rfbauth路径执行chmod 600 ~/.vnc/passwd服务起来几秒就退出-auth guess在 systemd 环境下猜不到文件看/var/log/x11vnc.log手动指定 Xauthority 路径远程画面卡顿严重默认轮询参数太保守用-wait 10 -defer 5 -ncache 10 -ncr组合开机后自动连接失败服务启动时图形会话还没就绪确认服务Restarton-failure并且放在graphical.target远程能看到桌面但无法操作多显示器时附加了错误的显示指定-display :0必要时用-clip限制共享区域6.2 一次重启后连不上的完整排查过程有一次我给系统挂了安全更新顺手就重启了机器。直到想远程登录才发现VNC 客户端怎么都连不上。当时第一反应是“看来又得折腾半天”但后来耐着性子按步骤排查十分钟内就定位到了问题。第一步看服务状态systemctl status x11vnc输出显示服务处于activating (auto-restart)状态说明它在反复重启一直没有正常运行。第二步看日志journalctl -u x11vnc -n 30日志里反复出现一行关键信息could not open configured Xauthority file。这说明 systemd 启动 x11vnc 时-auth guess猜不到 GDM 给当前用户生成的 Xauthority 文件路径。第三步找到真实的 Xauthority 路径ls /run/user/*/gdm/Xauthority看到输出是/run/user/1000/gdm/Xauthority对应的用户 uid 是 1000。第四步修改服务文件里ExecStart把-auth guess替换为-auth /run/user/1000/gdm/Xauthority第五步重新加载并重启服务sudo systemctl daemon-reload sudo systemctl restart x11vnc这次再看日志服务状态稳定连接也立即恢复正常。整个过程没有什么玄学就是按“进程-端口-日志-认证文件”这条线一层层地排查。这也是我想强调的一个经验远程桌面调试不要凭感觉乱猜先把显示栈、认证栈、网络栈拆开每一步都验证到最终连上就是顺理成章的事。最后再分享一个沉淀下来的小习惯每次改完配置第一件事永远是看日志。手动跑一次 x11vnc 时日志里能看到Automatic XAUTHORITY guess successful这样的提示看到它再连客户端才会稳。如果日志里都报错了客户端怎么折腾都是白费力气。折腾 Linux 远程桌面就是这样底层原理理顺一步后面就省一百分钟。
1. 需求梳理从一台Ubuntu到另一台电脑的远程桌面如果你和我一样平时的主力机器装的是 Ubuntu 桌面版难免会遇到“人不在机器旁边却想直接操作这台机器桌面”的时刻。我第一次被逼着去折腾 Ubuntu 远程桌面配置是因为需要在异地操作一台装机不下十次、专门跑模拟计算的主机程序在那儿桌面也在那儿可人不在。先后试过 TightVNC、再换到 x11vnc中间踩遍了黑屏、连不上、服务启动就退、Wayland 不认 Xauthority 的坑最后才把整条链路稳定下来。这篇文章就把整套折腾过程完整记录下来包含每一步命令、预期效果和翻车现场适合正在配置 Ubuntu 远程桌面或者已经发现 TightVNC 怎么都连不上真实桌面的朋友拿来对照参考。1.1 先分清需求你要的是“虚拟桌面”还是“共享当前屏幕”很多第一次配置 Linux 远程桌面的人没意识到这个领域里有两条完全不同的技术路线。第一种是虚拟桌面服务器。典型代表是 TightVNC、TigerVNC 自带的vncserver这类工具。它会在你现有系统之外再创建一个“虚拟显示器”在这个虚拟显示器上启动一个全新的桌面会话。你远程连过去看到的不是物理屏幕上正在运行的东西而是一个独立、空白、需要单独登录的全新桌面。这种方案适合无头服务器没有接显示器的机器需要跑一个 GUI 程序的场景。第二种是共享当前屏幕。典型代表就是 x11vnc。它直接“附加”到你正在使用的 X 服务上把真实显示器上显示的内容通过 VNC 协议实时转给远程客户端。你远程看到的就是物理显示器上此刻的内容鼠标、键盘操作也会直接作用到当前桌面上。用一句话概括前者是“再造一个桌面”后者是“镜像眼前这个桌面”。我当时的需求其实是后者那台 Ubuntu 主机上已经跑着重要的程序、开着一堆终端窗口和工作流我不想也不应该再切到一个陌生会话里重新操作。我需要的是“屏幕上有啥我远程就看到啥”。这也决定了后来 TightVNC 无论怎么调方向都不对——它再稳定也解决不了“我想操控当前这面屏幕”这个核心诉求。1.2 候选方案对比与最终选择在确定走 VNC 路线之前我把常见的远程桌面方案都过了一遍方案优点缺点适不适合我xrdpRDP 协议客户机自带的远程桌面工具就能连与 Ubuntu 自带 GNOME 桌面兼容性小坑不少经常需要额外配置桌面会话可以试但坑也不浅TeamViewer / AnyDesk 等商业软件开箱即用速度不错闭源个人使用免费用于内部服务时有些受限临时应急可以长期依赖不放心TightVNC 虚拟桌面配置简单客户端普及无法直接操控当前物理桌面性能一般方向不对x11vnc直接共享当前物理屏幕轻量协议开放需要了解 X11、Wayland 相关概念初次配置不够“傻瓜”最终选择选择 VNC 体系还有一个重要原因客户端生态太成熟了。桌面端有 Remmina、TigerVNC Viewer手机端也有现成的 VNC 客户端不需要额外安装太多东西。只要服务端跑起来剩下的就只是“连一个地址、输一次密码”。工具选型的原则最后沉淀成一句话能开源绝不用闭源能直接共享当前屏幕就绝不另起一个会话。这句话也直接决定了我从 TightVNC 转向 x11vnc 的必然性。但那都是踩完坑之后才想明白的一开始我也老老实实从 TightVNC 开始折腾。2. 前置检查不搞定这些后面全是黑屏很多人配远程桌面失败不是最后的命令写错而是环境准备没做扎实。这里的环境不是说你装个 Ubuntu 就行而是要确认几件容易被忽略的事当前会话是 X11 还是 Wayland、屏幕会不会自动锁、防火墙端口有没有放开。这几项不提前解决后面 x11vnc 连上的概率极低连上也大概率是一块黑屏。2.1 确认你的 Ubuntu 会话是 X11 而不是 Wayland这是一个决定性的检查也是最容易被忽略的。从 Ubuntu 22.04 开始默认用的是 GDM 登录管理器桌面环境默认跑在 Wayland 协议上。而 x11vnc 从协议层面只支持 X11它读的是 X 服务的画面、用的是 Xauthority 的认证机制。Wayland 会话下直接跑 x11vnc 会报错或者起来之后黑屏、无法授权。检查当前会话类型最简单的方法在终端里执行echo $XDG_SESSION_TYPE如果是x11那没问题。如果是wayland继续往下看。我那次遇到的机器正是默认 Wayland 会话。解决办法是在登录界面的用户图标下方点那个齿轮小按钮选择“Ubuntu on Xorg”再登录。但这属于临时的每次都得手动切。要做到一劳永逸需要把 GDM 的 Wayland 支持关掉。编辑 GDM 配置文件sudo nano /etc/gdm3/custom.conf找到这一行#WaylandEnablefalse取消注释改成WaylandEnablefalse保存退出重启机器。之后echo $XDG_SESSION_TYPE就会稳定输出x11。这一步直接决定了 x11vnc 能不能在这个系统上存活建议在所有操作之前先做。2.2 关掉息屏、锁屏让远程连接更省心远程桌面最烦的情况之一就是你连过去之后看到的是锁屏界面或者更糟——屏幕已经休眠看起来就像一台死机。Linux 桌面默认的省电策略会在空闲一段时间后锁屏、熄屏。从远程操作时经常因为本地没人碰键盘机器很快就自动息屏了。等你想连上去要么画面全黑要么卡在密码解锁界面。我在配好 x11vnc 之后仍然频繁遇到黑屏排查半天才发现是 GNOME 电源管理在搞鬼。解决方法是把桌面空闲锁屏和自动息屏都关掉# 关闭命令行界面的空闲延迟 gsettings set org.gnome.desktop.session idle-delay 0 # 关闭插电状态下的自动息屏 gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type nothing # 关闭电池状态下的自动息屏 gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-battery-type nothing # 关闭屏幕变暗 gsettings set org.gnome.settings-daemon.plugins.power idle-dim false # 关闭自动锁屏 gsettings set org.gnome.desktop.screensaver lock-enabled false这些命令拿到普通桌面电脑上毫无压力。如果你觉得关闭屏幕节能有点浪费电也可以保留自动息屏但在 x11vnc 启动参数里加上-nodpms告诉它不要理会显示器的电源管理信号——后面讲服务配置时会提到。2.3 确认 IP、放开防火墙端口网络层面看起来不复杂却是最容易“莫名其妙连不上”的地方。先确认这台机器的局域网 IPip a找到有线或无线网卡对应的 IPv4 地址记下来。建议在路由器里给这台机器的 MAC 地址绑定一个固定 IP省得 DHCP 频繁变化。很多 Ubuntu 桌面默认自带 UFW 防火墙但没有规则时默认是放行所有流量。如果之前设置过防火墙需要单独放行 VNC 端口sudo ufw allow 5900/tcp sudo ufw status注意如果后面决定用 SSH 隧道转发 VNC这是我最推荐的用法那么 5900 端口不应该对局域网开放而是只绑定 127.0.0.1靠 SSH 把流量从远程带回来。这个话题放到第五部分细讲。3. TightVNC 踩坑全记录它和“当前桌面”是两回事现在说回正题为什么我一开始选了 TightVNC又为什么最终放弃。如果你只是想找一个最快能远程连上 Ubuntu 桌面的办法可能也有人会推荐tightvncserver因为它一条命令就能装好、启动。但我踩坑之后可以负责任地说它解决的是“有没有桌面可用”而不是“能不能共享现有桌面”。3.1 vncserver 创建的是一块“虚拟显示器”先交代一下背景知识。Linux 的图形体系里X display是一个概念用:0、:1这样编号区分。物理屏幕上跑着的桌面通常在:0。而vncserver这个工具做的事情等价于在系统里创建了一块不存在于物理硬件的虚拟显示器编号一般是:1然后在这块虚拟显示器上启动一个新的桌面会话。你远程连接 5901 端口对应:1看到的其实是另一个完全独立的桌面。这也是我第一次用 TightVNC 时最困惑的场景本机桌面上明明开着终端、浏览器和编辑器远程连过去却是一个空荡荡的初始桌面仿佛一台刚装好的新电脑。我当时还以为是自己配置错了翻了一堆资料后来才搞明白原理vncserver不是“镜像”你面前的屏幕而是“另起炉灶”。这个知识点很关键因为它解释了一系列后续问题为什么 TightVNC 连上看不到真正的桌面为什么黑屏为什么程序跑在物理桌面VNC 窗口里却看不见3.2 xstartup 黑屏问题的调试实录主要问题从改配置文件开始TightVNC 启动虚拟桌面时需要一个~/.vnc/xstartup脚本指定在这个虚拟显示器上启动哪个桌面环境。我最初的配置很简单结果连上去是纯黑屏。后来把脚本改成了这样#!/bin/sh unset SESSION_MANAGER unset DBUS_SESSION_BUS_ADDRESS export XAUTHORITY$HOME/.Xauthority export PATH$PATH:/usr/local/bin xrdb $HOME/.Xresources || true dbus-launch --exit-with-session gnome-session 改完重启 vncserver桌面终于出来了但出来的是 GNOME 默认会话依然不是我物理桌面上的那个会话。调通之后我只能捏着鼻子用它顶了两天。远程进去之后必须重新打开需要的应用、重新登录各种工具、重新导航到项目目录。如果你只是想把文件拖过来、点几下操作那还好但如果远程的是一台正在跑长时间任务的机器这种“第二个桌面”的模式就很分裂。后来我也查了很多资料发现不少人用 TightVNC 时桌面环境会换成 XFCE而不是 GNOME。因为 GNOME 本身比较吃资源在虚拟显示器上跑容易出各种渲染和启动问题。如果你看到这里仍打算用 TightVNC建议把桌面装成 XFCE 再跑脚本sudo apt install xfce4 xfce4-goodies脚本改为#!/bin/sh startxfce4 这套方案跑个纯远程办公工具是没问题的但它依然解决不了“镜像物理桌面”这件事。3.3 TightVNC 让人忍不了的两个短板第一个短板是性能。TightVNC 在处理高分辨率桌面时画面更新明显跟不上尤其是拖动窗口、切换工作区、滚动网页时马赛克和撕裂感很重。它对带宽和 CPU 的开销都不友好长期远程操作体验很差。第二个短板是安全。VNC 协议默认是明文的TightVNC 也没有传输加密机制。密码只是用来做接入认证不能保护传输内容。只要有人在同一网络中抓包遥控期间敲的每一个键、屏幕上显示的内容都可能被还原出来。这两个短板让我下定决定换方向我要的不是“再造一个会话”而是“把现有桌面安全地、流畅地搬到远程”。4. x11vnc 配置实录直接把眼前的桌面搬过去x11vnc 这个名字看着和 VNC 很像但它做的事情完全不同它是一个轻量的 VNC 服务进程直接读取你当前 X session 的画面并提供给任何 VNC 客户端。配上好一点的参数操作手感和体验都会好不少。4.1 安装和口令文件安装非常直接sudo apt update sudo apt install x11vnc然后生成口令文件。VNC 客户端的认证口令是独立于你的系统登录密码的。我这里强烈建议单独设置一个和系统密码不同的口令因为 VNC 口令经常会在配置文件里出现如果和系统密码一致等于多暴露了一个入口。mkdir -p ~/.vnc x11vnc -storepasswd ~/.vnc/passwd chmod 600 ~/.vnc/passwd-storepasswd会提示输入两遍密码然后加密写入~/.vnc/passwd。设置完成后这个文件只能当前用户读写避免其他用户轻易读到口令。4.2 首次手动运行先确认链路通先不要在浏览器里看一堆教程然后直接上 systemd先手动跑一次前提条件都满足之后再考虑持久化。x11vnc -display :0 -auth guess -rfbauth ~/.vnc/passwd -rfbport 5900 -forever -shared -o /tmp/x11vnc.log这个命令里的参数逐个解释-display :0告诉 x11vnc 去抓取哪个显示的屏幕。正常物理桌面是:0。如果你不确定是:0还是:1用echo $DISPLAY可以查到当前会话编号。-auth guess自动猜测 Xauthority 文件的位置。这个对 GDM 用户尤其重要因为你的 Xauthority 可能不在默认路径。-rfbauth ~/.vnc/passwd指定刚刚生成的口令文件。-rfbport 5900VNC 服务端口5900 是 VNC 默认端口对应显示编号:0。-forever有客户端断开之后继续保持服务否则第一个客户端退出后进程就结束了。-shared允许多个客户端同时连接。-o /tmp/x11vnc.log日志写到这个文件里方便排查。运行之后用任意 VNC 客户端连接你的IP:5900。我用的是 Remmina连接类型选 VNC填地址、输口令几秒内应该就能看到物理桌面的一比一镜像。如果日志里有类似Automatic XAUTHORITY guess successful的字样说明认证文件找对了链路已经通。如果这里就报错先回头确认第 2 部分的 X11 会话和息屏配置绝大多数问题根源在那两个地方。4.3 用 systemd 服务把它变成开机自启的常驻进程手动跑通之后下一步就是让它开机自启、掉线自动拉起。我踩过的一个教训是不要在multi-user.target阶段启动 x11vnc因为那时候 GDM 可能还没起来没有 X display 可以附加。正确做法是让服务放在graphical.target之后并且依赖显示管理器。创建服务文件sudo nano /etc/systemd/system/x11vnc.service内容如下[Unit] Descriptionx11vnc remote desktop server Afterdisplay-manager.service Wantsdisplay-manager.service [Service] Typesimple User你的用户名 Group你的用户组 EnvironmentDISPLAY:0 ExecStart/usr/bin/x11vnc -display :0 -auth guess -rfbauth /home/你的用户名/.vnc/passwd -rfbport 5900 -forever -shared -wait 10 -defer 5 -ncache 10 -ncr -nodpms -o /var/log/x11vnc.log Restarton-failure RestartSec5 [Install] WantedBygraphical.target几个需要注意的点一是User和Group要换成你平时登录桌面的那个用户名和用户组不能写成 root否则 x11vnc 以 root 身份运行时权限和处理认证的路径会非常别扭。二是-auth guess在 systemd 场景下不一定稳定。如果重启之后日志一直提示找不到 Xauthority需要手动指定。常见路径在/run/user/你的uid/gdm/Xauthority可以先执行ls /run/user/*/gdm/查看实际文件然后把服务里ExecStart的-auth guess替换成-auth /run/user/你的uid/gdm/Xauthority。三是把日志定向到/var/log/x11vnc.log。调试远程服务日志是最直接的线索来源一定要留。启动并设置开机自启sudo systemctl daemon-reload sudo systemctl enable --now x11vnc sudo systemctl status x11vnc看到状态是active (running)再用客户端连一次。这次连接成功就说明整条链路已经可以长期运作了。5. 让连接更顺畅性能参数与加密实践服务和配置都起来之后还有两件事很影响体验性能和安全性。VNC 裸奔在局域网里也许暂时没问题但只要这台机器有公网 IP就必须认真考虑加密。不然哪天连不上、被入侵了后悔都来不及。5.1 实测有效的参数组合x11vnc 的默认参数不是最优的。默认的轮询间隔比较慢高分辨率屏幕下会显得卡顿。我最后用的参数组合在系统服务文件里已经体现这里单独拆开解释x11vnc -display :0 -auth guess -rfbauth /home/用户/.vnc/passwd -rfbport 5900 -forever -shared -wait 10 -defer 5 -ncache 10 -ncr -nodpms -o /var/log/x11vnc.log-wait 10两次屏幕轮询之间的间隔毫秒数。默认是 50改成 10 意味着更快的画面刷新但 CPU 占用会略高。-defer 5屏幕更新发送的延迟。数值越小操作响应越跟手。实测 5 毫秒在局域网内手感很好。-ncache 10开启客户端缓存缓存帧数设为 10。这个参数对滚动网页、移动窗口的帮助非常大画面重绘不再一帧一帧地糊。-ncr配合-ncache使用启用 Improved ncache Reader 模式。-nodpms忽略显示器的电源管理信号防止远程连接期间屏幕休眠。这套参数在局域网内实测效果不错1080p 分辨率下拖动终端窗口已经感受不到明显掉帧。但也要注意-wait 10会把 CPU 占用拉高一点低性能机器上可以把-wait调回 20~30换取更低的空闲负载。如果你的网络环境非常差可以考虑用-bgr233强制 8 位色彩画面会偏色但带宽占用会降得很明显。这个参数只建议在万不得已时用。5.2 用 SSH 隧道加密 VNC而不是把端口暴露到公网VNC 协议本身不加密。哪怕设置了 VNC 口令抓包者只要拿到了口令依然可以直接进入你的桌面。口令只负责“准入”不负责“加密传输”。最稳妥的做法VNC 服务只绑定到本机回环地址远程通过 SSH 隧道访问。这样 VNC 端口对外完全不可见所有流量都走 SSH 的加密通道。先把服务文件里ExecStart加一个参数-localhost-localhost会让 x11vnc 只监听127.0.0.1局域网内其他机器直接连 5900 会失败只有本机能访问。然后重新加载服务sudo systemctl daemon-reload sudo systemctl restart x11vnc在本地电脑上先建立 SSH 隧道ssh -L 5900:127.0.0.1:5900 你的用户名目标主机IP -N这个命令的含义是把本地电脑的 5900 端口通过 SSH 隧道转发到目标主机的 5900 端口。-N表示只转发不执行远程命令。隧道建立后VNC 客户端连接127.0.0.1:5900就能经过加密隧道访问到目标主机的桌面。为了方便可以写一个简单脚本放在本地#!/bin/bash ssh -f -N -L 5900:127.0.0.1:5900 你的用户名目标主机IP sleep 1 remmina -c vnc://127.0.0.1:5900这样每次只需要执行这个脚本就能一键加密连接到远程桌面。同时注意SSH 需要保持运行隧道才能在后台稳定工作。6. 高频故障排查方案配置过程说不踩坑是假的。尤其是从重启到服务自动拉起之间有太多环节可以出问题。我把实际遇到过的以及排查思路比较典型的问题整理成一个速查表之后再单独聊一次完整的排查过程。6.1 常见问题速查表现象可能原因处理方式客户端提示连接被拒绝服务没起来 / 端口没监听 / 防火墙拦截ps aux | grep x11vnc确认进程ss -lnt | grep 5900确认端口sudo ufw status查防火墙能连上但全黑屏当前会话是 Wayland / DISPLAY 不对echo $XDG_SESSION_TYPE确认是 x11echo $DISPLAY确认是:0提示认证失败口令文件路径不对 / 权限过宽确认-rfbauth路径执行chmod 600 ~/.vnc/passwd服务起来几秒就退出-auth guess在 systemd 环境下猜不到文件看/var/log/x11vnc.log手动指定 Xauthority 路径远程画面卡顿严重默认轮询参数太保守用-wait 10 -defer 5 -ncache 10 -ncr组合开机后自动连接失败服务启动时图形会话还没就绪确认服务Restarton-failure并且放在graphical.target远程能看到桌面但无法操作多显示器时附加了错误的显示指定-display :0必要时用-clip限制共享区域6.2 一次重启后连不上的完整排查过程有一次我给系统挂了安全更新顺手就重启了机器。直到想远程登录才发现VNC 客户端怎么都连不上。当时第一反应是“看来又得折腾半天”但后来耐着性子按步骤排查十分钟内就定位到了问题。第一步看服务状态systemctl status x11vnc输出显示服务处于activating (auto-restart)状态说明它在反复重启一直没有正常运行。第二步看日志journalctl -u x11vnc -n 30日志里反复出现一行关键信息could not open configured Xauthority file。这说明 systemd 启动 x11vnc 时-auth guess猜不到 GDM 给当前用户生成的 Xauthority 文件路径。第三步找到真实的 Xauthority 路径ls /run/user/*/gdm/Xauthority看到输出是/run/user/1000/gdm/Xauthority对应的用户 uid 是 1000。第四步修改服务文件里ExecStart把-auth guess替换为-auth /run/user/1000/gdm/Xauthority第五步重新加载并重启服务sudo systemctl daemon-reload sudo systemctl restart x11vnc这次再看日志服务状态稳定连接也立即恢复正常。整个过程没有什么玄学就是按“进程-端口-日志-认证文件”这条线一层层地排查。这也是我想强调的一个经验远程桌面调试不要凭感觉乱猜先把显示栈、认证栈、网络栈拆开每一步都验证到最终连上就是顺理成章的事。最后再分享一个沉淀下来的小习惯每次改完配置第一件事永远是看日志。手动跑一次 x11vnc 时日志里能看到Automatic XAUTHORITY guess successful这样的提示看到它再连客户端才会稳。如果日志里都报错了客户端怎么折腾都是白费力气。折腾 Linux 远程桌面就是这样底层原理理顺一步后面就省一百分钟。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
