如果你在 Linux 上折腾过远程桌面大概率见过这个名场面配置看着都没问题密码文件建好了端口也放行了结果执行x11vnc -display :0终端冷冷地甩出两行字x11vnc: unable to open display :0 XOpenDisplay failed.第一反应通常是怀疑自己命令写错了或者 x11vnc 没装好于是重装、换版本、翻博客折腾一晚上第二天才发现问题其实特别原始甚至有点“丢人”。这篇文章就是把我这些年跟XOpenDisplay failed搏斗的经验整理成一份能直接照着抄的排查手册。内容会覆盖报错背后的 X11 显示协议原理、DISPLAY 环境变量的坑、Xauthority 授权机制、Wayland 会话的雷区以及手动启动、systemd 自启、无头服务器和容器场景下的完整命令示例。适合刚接触 x11vnc 的新手也适合已经被这个报错折磨过好几回的老手——你们在我这应该能找到几个能直接拿去用的命令片段。1. 理解 XOpenDisplay failed 的核心逻辑1.1 X11 里的“显示”到底是个什么东西很多人第一次看到 “XOpenDisplay” 这个函数名会懵其实它来自 X11 图形系统最底层的库 libX11。X11 是个典型的客户端/服务端模型运行在你电脑上的 X Server通常叫 Xorg负责管理屏幕、键盘、鼠标而各种 GUI 程序是 X Client它们通过网络套接字向 X Server 发送绘制请求。x11vnc 的本质是一个 X Client它要做的事情很简单连接到一个已经存在的 X Server然后把这个 X Server 管理的那块屏幕内容转换成 VNC 协议发给远端的 VNC Viewer。所以你在这台机器上没有图形界面在跑x11vnc 自己一个人是撑不起桌面的它必须“寄生”在某个 X Server 上。这就能解释为什么报错信息里有个“display”的概念。X Server 不是只靠“进程存在”就能连上的它还有一个对外暴露的地址也就是 display name。平时我们看到的:0其实完整写法是unix:0或者localhost:0数字 0 代表第 0 号显示对应系统里那个 socket 文件/tmp/.X11-unix/X0。你要是连 :1就对应/tmp/.X11-unix/X1。所以当你看到XOpenDisplay failed翻译成人话就是x11vnc 想去访问显示编号对应的那个 X Server socket结果要么找不到文件要么能访问但认证没通过要么压根就没有这个 X Server 在运行。整个报错并不复杂关键是你得顺着这条线索把原因分层剥出来。1.2 拆解这条报错它到底想告诉你什么XOpenDisplay是 libX11 提供的函数功能就是解析 display name并尝试和对应 X Server 建立连接。函数返回 NULL 时x11vnc 就会把错误信息打出来也就是我们看到的XOpenDisplay failed。但“连接失败”这个结论太宽泛了下面藏着至少三种完全不同的情境X Server 不存在这台机器根本没有启动 Xorg比如一个无头服务器、云主机、容器里你装了个 x11vnc 就开始敲命令那它当然什么都连不上。X Server 存在但权限不够X Server 开启了访问控制而 x11vnc 找不到正确的授权文件Xauthority导致连接被拒。这种情况通常发生在你用sudo启动 x11vnc或者从 SSH 会话里启动的时候。X Server 存在但在别处你当前所在的会话压根不是 X11而是 Wayland。Wayland 会话下有时候会有兼容层 XWayland但那个环境对 x11vnc 来说并不友好容易摸不着北。这三种情况对应三种完全不同的修复思路所以别一看到报错就急着重装 x11vnc。你真正需要做的是先回答一个问题这台机器上到底有没有一个能用的 X Server我能不能拿到它的访问权限。1.3 常见诱因速查表我先给一张速查表方便你对照自己遇到的场景。后面每一行都会展开讲。报错特征常见原因首要排查方向x11vnc: unable to open display :0X Server 没启动或显示编号不对检查 Xorg 进程和 /tmp/.X11-unix/报错前有 permission deniedXauthority 文件缺失或指错使用-auth guess或指定 auth 文件SSH 里跑 x11vnc 报错DISPLAY 环境变量没带上显式使用-display :0echo $XDG_SESSION_TYPE返回 wayland会话不是 X11切换 Xorg 会话或走 Xvfb 虚拟显示端口冲突 / 服务启动失败5900 被占用检查端口和 systemd 日志这张表不是万能的但能帮你把问题框到一个小范围内不至于瞎试。2. 先从根上排查X Server 到底在不在2.1 三条命令快速确认 X Server 状态遇到XOpenDisplay failed我习惯先跑三条命令十几秒就能确定是不是 X Server 本身的问题。第一条看进程ps aux | grep -E Xorg|Xwayland如果是正常启动的图形界面环境你会看到类似/usr/lib/xorg/Xorg :0 ...或者/usr/bin/Xwayland :0 ...的输出。啥都没有说明当前机器确实没有 X Server 在跑那问题就出在源头。第二条看 socket 文件ls -la /tmp/.X11-unix/正常情况下列表里有一个X0文件ls显示两个也没关系那代表有多个显示。如果你的系统里这个目录是空的甚至目录本身都不存在那基本可以断定 X Server 没有起来。第三条直接测试连接xdpyinfo -display :0 | head如果xdpyinfo能输出一堆屏幕信息说明:0这个显示是活的x11vnc 报错就不是“X 不存在”的问题而是权限或环境问题。如果提示unable to open display那就和 x11vnc 的报错同根同源。2.2 DISPLAY 环境变量最容易踩坑哪怕 X Server 是活的你也不一定能连上因为 x11vnc 默认会读环境变量DISPLAY。很多人从 SSH 里登录远程机器以后直接敲x11vnc结果报了XOpenDisplay failed就是因为 SSH 会话里根本没有设置DISPLAY或者它被设置成了类似localhost:10.0的转发地址。你先看一眼echo $DISPLAY如果输出是空的或者不是你预期的:0那你就要么在命令里显式指定x11vnc -display :0 ...要么先 export 一下再运行export DISPLAY:0 x11vnc ...这里有个隐藏知识点很多发行版上Xorg 启动时会把DISPLAY:0写入登录用户的图形会话环境但 SSH 会话不会继承这个变量。所以从 SSH 进去跑 GUI 相关命令时环境变量经常是残缺的。你可以在图形终端里执行env | grep DISPLAY看一下再对比 SSH 里的输出往往就能发现问题。顺便说一句-display :0这个参数优先级高于环境变量所以我更推荐在脚本和 systemd 服务里显式写死 display省得被环境变量坑。2.3 无头服务器和云主机的特殊情况还有一种很常见的场景你手里的是一台云主机或者 mini 服务器压根就没装桌面环境。你执行ps aux | grep Xorg大概率没有输出因为这类服务器默认只有命令行。这种情况下x11vnc 再怎么折腾都报XOpenDisplay failed因为它找不到可依附的 X Server。两个办法老老实实装一个完整的桌面环境比如apt install ubuntu-desktop或者dnf groupinstall GNOME Desktop然后启动图形会话。用虚拟显示方案装 Xvfb 创建一个不依赖物理屏幕的 X Serverapt install xvfb Xvfb :1 -screen 0 1920x1080x24 DISPLAY:1 x11vnc -forever -shared -rfbauth ~/.vnc/passwdXvfb 全称 X Virtual Framebuffer本质是个在内存里画画的 X Server没有真正的显示设备。它非常适合给无头服务器提供 GUI 测试环境或者配合 x11vnc 做远程桌面。这招我后面在实战案例里还会再提。3. Xauthority九成权限问题的根源3.1 为什么 sudo 之后反而报错如果你确认 X Server 在运行、DISPLAY 也对但还是XOpenDisplay failed那十有八九是授权文件出了问题。这也几乎是新手最容易撞上的坑而且撞得莫名其妙直接在图形界面终端里运行 x11vnc 没事一加sudo就报错。X11 的访问控制机制叫 Xauthority说白了就是一把“钥匙”。当你登录图形界面时显示管理器GDM、SDDM 等会生成一个授权文件里面保存着一个 magic cookie然后通过环境变量XAUTHORITY告诉所有图形程序“你用这个文件里的钥匙去开 X Server 的门。”默认情况下这个文件位于每个用户的家目录下叫.Xauthority。问题就出在这个文件的位置上。当你执行sudo x11vnc -display :0时程序是 root 身份在跑它自动去/root/.Xauthority找钥匙但那里根本没有当前登录用户的 cookie。你想想就好比你拿着别人家的钥匙去开自己家的门门肯定不给你开。此时 x11vnc 的打屏日志里通常会有类似Authorization required, but no authorization protocol specified的提示紧接着就是XOpenDisplay failed。3.2 -auth guess 和手动指定授权文件x11vnc 自带一个非常实用的参数叫-auth guess它会尝试从 X Server 进程的运行环境中“猜”出正确的授权文件路径。大多数场景下直接这么跑就能解决sudo x11vnc -display :0 -auth guess -forever -shared -rfbauth ~/.vnc/passwd-auth guess的原理很简单它会去检查 X Server 进程/proc/pid/environ里有没有XAUTHORITY或者HOME变量然后从这些路径里找可用的授权文件。这个方法对付多数显示管理器都有效但也有失手的时候尤其是 GDM 这类会把授权文件放在临时目录的场合。如果guess猜不中你可以手动指定授权文件。先找到它sudo find /run /var /home -name Xauthority 2/dev/null常见路径包括/home/你的用户名/.Xauthority、/var/run/gdm3/auth-for-用户名-xxx/database这一类。找到以后加进命令sudo x11vnc -display :0 -auth /home/你的用户名/.Xauthority -forever -shared -rfbauth ~/.vnc/passwd其实核心逻辑就一句话x11vnc 用谁的授权文件启动就要确保这把“钥匙”能对上 X Server 的锁。你不想用 sudo 的话也可以切到图形登录用户下直接运行不指定 auth 也能通。3.3 应急方案xhost 临时放开访问控制如果你的机器环境比较可控想快速验证是不是授权问题可以用xhost命令临时放开 X Server 的访问控制。在图形登录用户的终端或者能访问 X 会话的终端里执行xhost SI:localuser:root这句话的意思是允许本地 root 用户连接当前的 X Server。之后你再开一个 root 终端运行 x11vnc就不会报权限问题了。更粗暴一点的写法是xhost 它的作用是关闭所有访问控制允许任意客户端连接。我强烈不建议你在公共网络、办公网络或者互联网可达的机器上用这个相当于把家门钥匙直接挂在门口。它只适合你在自己家里、内网环境、临时排除故障时用一下解决完问题要立刻改回来xhost -3.4 其他权限暗坑除了常见的sudo场景还有几个授权相关的小坑值得留意。一个是授权文件本身权限不对。.Xauthority文件如果被 chmod 成了全局可读某些安全策略比较敏感的 X Server 会拒绝使用。正常情况它的权限应该是600属于当前用户。你可以手动修正chmod 600 ~/.Xauthority另一个是容器或远程开发环境里的 UID 错位。比如容器内进程是 root宿主机图形用户是 uid 1000你把宿主的.Xauthority挂载进容器容器里 root 可能因为 uid 映射问题读不了文件或者读到了却因为环境变量没配对报错。这类问题排查起来比较绕前面说的-auth guess在容器里大概率猜不准手动指定 plus 环境变量XAUTHORITY一起配比较好docker run -e DISPLAYunix:0 -e XAUTHORITY/tmp/.Xauthority \ -v /tmp/.X11-unix:/tmp/.X11-unix:ro \ -v $HOME/.Xauthority:/tmp/.Xauthority:ro \ ...还有 AppArmor 和 SELinux这两个安全模块偶尔也会插一脚导致 x11vnc 明明授权文件对了还是连不上。遇到这种情况先查系统日志比如journalctl -u x11vnc如果有 avc denied 或者 apparmor 相关提示再说放开策略的事别一上来就关 SELinux。4. Wayland 下的双面孔问题4.1 怎么一眼认出 Wayland 会话近几年主流发行版默认登录会话都切到了 Wayland这也是XOpenDisplay failed变多的一个隐含原因。很多人压根没意识到自己用的是 Wayland还在用老一套 X11 命令去排查。先确认会话类型执行echo $XDG_SESSION_TYPE如果输出是wayland恭喜你踩进了最经典的认知盲区。也可以用loginctl更精确地看loginctl list-sessions loginctl show-session session-id -p TypeTypex11就是传统 Xorg 会话Typewayland就是 Wayland。4.2 为什么 Wayland 上 x11vnc 老是报错Wayland 从架构上就不是 X11它没有传统的 X Server 概念也不存在一个统一的/tmp/.X11-unix/X0让你去连。x11vnc 是为 X11 设计的客户端它天然无法直接访问 Wayland 合成器的桌面内容。不过很多 Wayland 桌面为了兼容老应用会内置一个 XWayland 服务它会创建一个 X display通常是:0。这就导致了很分裂的局面ps里能看到 Xwayland 进程ls /tmp/.X11-unix/也能看到 X0 文件你以为 X Server 活着但实际上 x11vnc 连上它以后可能只能捕获到 XWayland 窗口而 GNOME Shell 这类原生 Wayland 界面它根本抓不到或者干脆因为授权对不上直接XOpenDisplay failed。所以在 Wayland 会话下我的首要建议是别跟它死磕换一条路走。4.3 三条务实路线路线一把登录会话切回 Xorg。大多数发行版在登录界面上都有一个小齿轮或者类似选项比如 Ubuntu 的 GDM 登录界面左下角有会话类型选择选 “Ubuntu on Xorg” 就行。改完重新登录再跑 x11vnc 就会顺很多因为整个桌面都跑在 X11 上了。缺点是你得注销一次而且如果硬件驱动对 Xorg 支持不好可能会遇到别的怪问题。路线二搭一个独立的 Xvfb 虚拟显示跟系统主桌面彻底分离。这种方式很适合需要在 Wayland 桌面上“另起炉灶”的场景比如你只是想远程看某个测试程序而不是共享整个 GNOME 桌面Xvfb :10 -screen 0 1920x1080x24 DISPLAY:10 x11vnc -forever -shared -rfbauth ~/.vnc/passwd -rfbport 5910这样 x11vnc 监听 5910 端口远端 Viewer 连上来看到的是 Xvfb 的虚拟桌面完全绕开了 Wayland 的问题。路线三用 Wayland 原生的 VNC 方案。如果你的合成器支持 wlr 协议可以试试wayvncGNOME 的话可以用gnome-remote-desktop走 RDP。这些工具能直接捕获 Wayland 桌面内容效果往往比 x11vnc 加 XWayland 的组合稳定得多。老牌 x11vnc 在这些场景下确实英雄迟暮没必要硬用。5. 手动启动与 systemd 自启的完整命令示例5.1 一条“保熟”的手动启动命令排查完各种原因之后你最终总要落到一个能用的启动命令上。我平时在 X11 会话下跑 x11vnc固定用下面这串x11vnc -display :0 \ -auth guess \ -forever \ -shared \ -rfbauth /etc/x11vnc.pass \ -rfbport 5900 \ -noxdamage \ -bg \ -o /var/log/x11vnc.log这里每个参数都值得说清楚不然你哪天调参都不知道在调什么。-display :0指定连接本地 0 号显示避免环境变量干扰。-auth guess自动猜测授权文件解决前面说的权限问题。-forever表示 VNC Viewer 断开后服务不退出继续监听否则默认情况下第一个客户端断开它自己就跟着退了这可能是很多新手觉得 x11vnc“不稳定”的原因。-shared允许多个客户端同时连接默认是每次只能有一个连接新连接会把旧的踢掉。-rfbauth指定 VNC 密码文件避免裸奔。-rfbport 5900让 VNC 服务监听在标准端口。-noxdamage关闭 XDamage 扩展在某些显卡驱动下能减少花屏和黑屏问题。-bg让程序后台运行终端不会被占住。-o写日志文件方便出问题后排查。密码文件生成方式如下注意执行后它会要你输入两次密码sudo x11vnc -storepasswd /etc/x11vnc.pass注意运行-storepasswd时如果后面直接跟明文密码比如x11vnc -storepasswd 123456 /etc/x11vnc.pass密码会出现在 shell 历史和ps输出里有一定风险。交互式输入更稳妥。5.2 systemd 服务一次配好开机生效手动启动只适合临时用想开机自启、崩溃自动拉起建议你还是写个 systemd 服务。下面这个是我在 Ubuntu 22.04 上验证过的例子sudo nano /etc/systemd/system/x11vnc.service[Unit] Descriptionx11vnc Remote Desktop Server Aftergraphical.target network-online.target [Service] Typesimple User你的用户名 EnvironmentDISPLAY:0 EnvironmentXAUTHORITY/home/你的用户名/.Xauthority ExecStart/usr/bin/x11vnc -forever -shared -rfbauth /etc/x11vnc.pass -rfbport 5900 -noxdamage -o /var/log/x11vnc.log Restarton-failure RestartSec3 [Install] WantedBygraphical.target然后启用并启动sudo systemctl daemon-reload sudo systemctl enable --now x11vnc这里的User设置了运行身份对应 X 会话的登录用户这样它去读你家目录的.Xauthority就不会像 root 那样扑空了。如果你一定要以 root 身份跑那就得配合-auth guess或者手动指定授权文件路径否则大概率还会栽在授权上。Aftergraphical.target这个设置很关键它能确保图形会话已经拉起来以后再启动 x11vnc 服务。不然开机的时候 X Server 还没就绪x11vnc 一启动就撞上XOpenDisplay failed然后退出自启就白配了。我刚开始配服务时就是因为少了这一行每天重启机器后都得手动拉一次服务。5.3 自启失败的隐形坑systemd 服务场景下还有几个容易忽略的细节。Restarton-failure配上以后如果 x11vnc 因为 X Server 还没起来而退出它会自动重启一次。配合RestartSec3能覆盖大部分“启动时序”问题。但注意不要设成always否则日志报错时会无限刷屏。日志别漏看。systemd 服务出问题先执行sudo journalctl -u x11vnc -n 50 --no-pager你会发现自启失败和服务启动失败虽然表面都叫XOpenDisplay failed但时间点可能完全不同。一个是开机时 X 没准备好一个是运行一段时间后 X 会话注销导致 display 消失。后一种情况x11vnc 会随之退出Restarton-failure可能反复拉起但一直失败直到下个用户登录进入桌面才恢复。想让它更“钝感”一点可以考虑把服务设置为Typesimple然后让脚本做循环重试。不过大多数家用场景不用搞这么复杂。防火墙也记得放行 5900 端口否则服务起来了远端 Viewer 还是白屏sudo ufw allow 5900/tcp6. 远程 SSH、容器和特殊场景的额外注意6.1 SSH 进去后DISPLAY 为什么是空的很多人在笔记本上 SSH 到家里的台式机想远程看台式机的桌面。执行ssh userhost登录成功后直接运行x11vnc结果报错。这里有个特别容易误解的点SSH 会话默认不会继承图形会话的环境变量。你在图形终端的会话里DISPLAY可能是:0但 SSH 会话里echo $DISPLAY十有八九是空。就算你开了 X11 转发DISPLAY也只会被设置成类似localhost:10.0的地址它指向的是你的笔记本电脑而不是远程台式机的 X Server。换句话说x11vnc 会去连你笔记本上的显示当然连不上。解决办法就是显式指定 displayssh userhost x11vnc -display :0 -auth guess -forever -shared -rfbauth ~/.vnc/passwd另外提醒一下从 SSH 里跑 x11vnc就算成功了如果 SSH 会话被退出x11vnc 也可能收到挂断信号跟着结束。想彻底断开终端还能继续运行用-bg参数或者套一层nohup和setsidnohup x11vnc -display :0 -auth guess -forever -shared -rfbauth ~/.vnc/passwd /dev/null 21 6.2 在容器里跑 x11vnc 的注意点有人在 Docker 容器里跑 x11vnc共享宿主机桌面或者给容器里的 GUI 程序做远程显示。这种场景下最容易踩的坑还是 display socket 和授权文件。要让容器里的 x11vnc 能连上宿主机的 X Server至少要把/tmp/.X11-unix挂载进容器并且让容器进程读得到正确的.Xauthority。一个常用示例docker run -d \ -e DISPLAYunix:0 \ -e XAUTHORITY/home/dev/.Xauthority \ -v /tmp/.X11-unix:/tmp/.X11-unix:ro \ -v /home/你的用户名/.Xauthority:/home/dev/.Xauthority:ro \ -p 5900:5900 \ your-x11vnc-image这里有个容易忽视的问题容器内用户的 uid 如果和宿主流用户的 uid 不一致挂载进去的.Xauthority可能因为权限不匹配而被拒绝读取。解决思路是把容器进程运行时的 uid 改成跟宿主流用户一致或者把.Xauthority复制一份并修正容器内属主。再说个安全层面的提醒.Xauthority里存的是 X Server 的访问凭证挂载给容器意味着你把这个凭证暴露给了容器内所有进程。只在信任的镜像里这么干不要随便跑第三方镜像。6.3 多显示器和显示编号错位如果你的机器接了多个显示器X Server 可能会为它们分配一个大的虚拟屏幕也可能配置成多个显示编号。你登录到桌面后看xrandr输出通常还是一个:0只是横跨了多块物理屏幕x11vnc 默认也能捕获整个虚拟屏幕。但要是你机器上还跑了别的 X Server比如手动起过 Xvfb那 /tmp/.X11-unix 下会出现X0、X1两个 socket。此时如果你打开了一个通过 Xvfb 启动的 GUI 程序它可能占用了:1而 x11vnc 默认连:0时可能连到了另一个桌面。这不是报错但你会发现自己远程看到的桌面和预期不一致。排查时不妨多看一眼for i in /tmp/.X11-unix/X*; do echo $i; done再配合xdpyinfo -display :0、:1试试就能弄清楚每个显示是谁。7. 我踩过的坑与最终排查清单7.1 三个真实案例第一个案例就是我自己第一次给 Ubuntu 桌面配 x11vnc 的经历。当时我人在公司家里台式机开着 GNOME 桌面我从 SSH 进去执行sudo x11vnc -display :0结果报错。我第一反应是端口问题检查了一轮没找到原因后来才意识到是授权问题root 没有正确的 Xauthority 文件。改成sudo x11vnc -display :0 -auth guess -forever -shared一切正常。这个命令值得刻进脑子它解决了我的第一个XOpenDisplay failed。第二个案例是一台跑着 Ubuntu Server 的云主机系统里没有图形界面我天真地装了个 x11vnc 就想看桌面自然是XOpenDisplay failed。后来装上xvfb起了一个虚拟显示再运行DISPLAY:1 x11vnc才真正打开了远程桌面。这个案例说明没有 X Server 的时候x11vnc 确实一个巴掌拍不响你得给它造一个 X Server。第三个案例是帮朋友排查 systemd 自启问题。他配置了开机自启 x11vnc但每次开机后都得手动敲systemctl start x11vnc才能连上。我看了下服务文件问题很典型没有写Aftergraphical.targetsystemd 在图形会话还没起来的时候就把 x11vnc 拉起来了它报了XOpenDisplay failed然后就退出。补上依赖项加上Restarton-failure问题解决。7.2 全流程排查清单这里是我现在每次遇到XOpenDisplay failed都会过一遍的检查清单保证从粗到细不会漏。排查点执行方式期望结果确认会话类型echo $XDG_SESSION_TYPEx11 或 wayland确认 X Server 进程ps aux | grep -E Xorg|Xwayland有对应进程确认 socket 文件ls -la /tmp/.X11-unix/至少存在 X0确认 DISPLAY 变量echo $DISPLAY:0或你能预期到的值测试连接xdpyinfo -display :0 | head输出屏幕信息确认授权文件sudo find /run /var /home -name Xauthority找到对应 login 用户的文件尝试授权修复x11vnc -display :0 -auth guess不再报错检查端口占用ss -lntp | grep 59005900 空闲或属于 x11vnc查看服务日志journalctl -u x11vnc -n 50 --no-pager定位真实报错行这张表不能保证覆盖所有环境但它已经帮我解决了绝大多数问题。每一条都能快速回答“是不是这个原因”。7.3 少走弯路的个人经验最后聊几点实操中的心得。第一调试时永远带着日志跑。我不管手动启动还是 systemd 服务都会加-o /var/log/x11vnc.log遇到问题第一件事就是打开日志。日志里比终端输出多不少上下文尤其是授权失败时会顺带打印缺失的 cookie 信息。你能少猜很多。第二X11 的授权问题千万别靠“反复安装”解决。我见过有人在论坛求助重装了三遍 x11vnc最后发现只是没加-auth guess。这类问题先确认授权文件再确认 DISPLAY思路清晰以后十分钟能搞定。第三如果你打算长期跑远程桌面建议明确一下自己是“共享现有桌面”还是“提供独立虚拟桌面”。两种需求的技术选型完全不一样共享现有桌面就老老实实解决 Xauthority走 Wayland 的机器要么切 Xorg 要么用 wayvnc独立虚拟桌面就用 Xvfb 或 x11vnc 加虚拟显示干净利落不会干扰主桌面。XOpenDisplay failed这个报错乍看唬人但剥开以后会发现它只是 X11 世界里一次普通的握手失败。弄懂了 display 的概念、X Server 的运行状态、Xauthority 的授权链路以及 Wayland 和 X11 的差异这个报错基本就成了一个送分题。下次再撞上它希望你能想起这句话先问 X Server 在不在再问钥匙对不对最后才问命令写得全不全。