标题里的“渲染技术”，不指 Chromium 或 Blink 的页面排版引擎，而是云浏览器跑在 Linux、容器或服务器环境里的这一层：

显示服务器 / 虚拟显示 / 远程桌面接入链路

浏览器窗口落在什么图形栈上，远程用户又通过 noVNC、VNC、RDP 还是其他协议看到它。

这层看起来是基础设施细节，但它直接决定 WebGL、GLX、chrome://gpu、屏幕信息、RANDR 行为，以及最终暴露给指纹检测脚本的环境特征。

1. 结论

• 只需要“打开桌面、远程看到浏览器”：TigerVNC Xvnc 够用，部署最简单。
• 跑 CI 截图、自动化测试：Xvfb 是传统选择，够用但 GLX / RANDR 能力有限。
• 需要 WebGL 可用、GLX 完整、做浏览器指纹一致性测试：Xorg dummy + x11vnc + noVNC 更适合做基线。
• Xorg dummy 不等于真实 GPU。没有真实 GPU 时，WebGL 还是会落到 Mesa llvmpipe、swrast 或 SwiftShader 上。它的优势是图形栈更完整，Chrome 的 GPU 初始化路径更正常。
• 真正需要 GPU 性能和高真实性的场景，直接评估 GPU passthrough、vGPU 或 KVM 方案。

2. 三种虚拟显示方案

TigerVNC Xvnc

Chrome / Chromium
        ↓ DISPLAY=:99
TigerVNC Xvnc :99  ← VNC 自带 X server
        ↓
websockify / noVNC
        ↓
用户浏览器

Xvnc 把 X server 和 VNC server 做成了同一个进程。设计目标是远程桌面，不是完整的图形栈。GLX 支持有限或缺失，Chrome 在这种环境下经常拿不到 OpenGL context，WebGL 直接变 null。

好处是部署极简：一条命令启一个虚拟桌面，VNC 就绑好了。

Xvfb

Chrome / Chromium
        ↓ DISPLAY=:99
Xvfb :99            ← X Virtual Framebuffer
        ↓
x11vnc              ← 把 Xvfb 画面转成 VNC
        ↓
websockify / noVNC
        ↓
用户浏览器

Xvfb（X Virtual Framebuffer）是 X.org 项目里一个独立的 X server 实现，帧缓冲放在内存里，不需要显示设备。CI 环境大量用它跑需要 DISPLAY 的程序，xvfb-run 这个包装脚本很常见。

Xvfb 的问题在于它不是 Xorg。Xorg server 启动时会按 xorg.conf 加载一系列模块（GLX、RANDR、RENDER 等），每个模块有各自的实现和配置入口。Xvfb 不走这套机制，它自己内部实现了一组 X 扩展，能力更有限。典型表现：

• glxinfo 经常报错，或只能看到非常有限的 GL 能力
• RANDR 的 mode 管理不如 Xorg 灵活
• Chrome 检测到的 GL 环境和普通 Linux 桌面差距明显

对 CI 截图和 headless 测试来说 Xvfb 够了，但如果要测 WebGL 是否可用、浏览器指纹长什么样，它提供的环境太简陋。

Xorg dummy

Chrome / Chromium
        ↓ DISPLAY=:99
Xorg dummy :99     ← 标准 Xorg + dummy 显示驱动
        ↓
x11vnc             ← 把 Xorg 画面转成 VNC
        ↓
websockify / noVNC
        ↓
用户浏览器

Xorg dummy 跑的是标准 Xorg server，xorg.conf 里 Driver 设成 "dummy"。dummy 驱动的作用是提供一块虚拟帧缓冲当显示输出，相当于接了一块假显示器。

关键区别在模块加载。因为跑的是真正的 Xorg，它会加载 GLX、RANDR、RENDER 这些标准模块。GLX 模块可以接 Mesa 的 DRI 驱动（比如 llvmpipe），提供完整的软件 OpenGL。glxinfo -B 能返回正常的 GL vendor、renderer、version，Chrome 的 GPU 进程初始化也能走正常路径。

代价是部署比 Xvfb 麻烦：需要写 xorg.conf（配 dummy 驱动、分辨率、色深），另外起 x11vnc 做 VNC 转发，再接 websockify / noVNC。

对比

3. WebGL 为什么经常挂

Chrome 启动时会探测 GLX 环境，尝试创建 OpenGL context。在 Xvnc 和 Xvfb 下，这个探测经常失败：

GLX 不可用
OpenGL context 创建失败
WebGL context 创建失败

Chrome GPU Process 随后自动降级：

--use-gl=disabled
WebGL: unavailable

页面层面的结果：

canvas.getContext('webgl') === null

问题不止 WebGL 不可用。浏览器的 UA 和 platform 看起来像普通桌面，但 WebGL 是 null，GL renderer 异常，屏幕和 RANDR 行为像远程虚拟桌面。这几项放在一起，指纹就不一致了：

UA / Platform → 普通桌面
WebGL / GLX / 屏幕 / RANDR → 虚拟或远程桌面

指纹检测系统会据此判定：

Virtual Machine: Yes
Browser Tampering: Yes
WebGL: disabled / null / suspicious

排查 WebGL 或 VM 检测问题时，别只盯 JS 层的指纹补丁，先确认图形栈有没有 GLX 和 WebGL 能力。

4. 为什么用 Xorg dummy 做基线

Xorg dummy 跑标准 Xorg server，GLX、RANDR、RENDER 这些扩展都能显式启用。即使最终是 Mesa llvmpipe 做软件渲染，Chrome 看到的也是一个标准 Linux Xorg 环境，不是 Xvnc 的特殊 X server 或者 Xvfb 的简化实现。排查问题时，通过 glxinfo -B、xdpyinfo、xrandr、chrome://gpu 能看清楚问题卡在哪一步：Xorg 扩展没开？Mesa / GLX 组件缺失？Chrome 启动参数把 GL 禁了？还是浏览器封装层又做了一层覆盖？

WebGL context 能创建的时候，指纹层才有东西可改。vendor、renderer、extensions 这些字段都可以修正。WebGL 直接 null，能操作的就很少了。

排查浏览器指纹问题时，最怕“代理出口""自动化痕迹""图形栈""JS 指纹”几个变量搅在一起。Xorg dummy 至少把图形栈这一层稳定住了，有个可对比的基准。

5. 其他方案

除了上面三种，还有一些选择。

6. 验证清单

排查的时候，系统侧、Chrome 侧、页面侧分开看。只盯其中一层，容易误判。

系统侧

echo $DISPLAY
xdpyinfo | egrep "GLX|RANDR|RENDER"
xrandr --query
glxinfo -B

关注点：

• GLX、RANDR、RENDER 是否存在。
• OpenGL renderer string 是真实 GPU、llvmpipe、swrast 还是 SwiftShader。
• xrandr 能否正常返回分辨率和 mode。
• glxinfo -B 是否报 couldn't find RGB GLX visual or fbconfig 之类错误。

Chrome 侧

打开：

chrome://gpu

关注点：

• Graphics Feature Status
• GL_VENDOR / GL_RENDERER
• ANGLE backend
• WebGL / WebGL2 状态
• 是否有 GPU process crash 或 fallback 日志
• 启动参数里是否显式禁用了 GL / GPU

页面侧

const canvas = document.createElement('canvas');
const gl = canvas.getContext('webgl') || canvas.getContext('experimental-webgl');
console.log('webgl available:', !!gl);

if (gl) {
  const info = gl.getExtension('WEBGL_debug_renderer_info');
  if (info) {
    console.log('vendor:', gl.getParameter(info.UNMASKED_VENDOR_WEBGL));
    console.log('renderer:', gl.getParameter(info.UNMASKED_RENDERER_WEBGL));
  }
}

Chrome 启动日志里出了软件渲染 fallback，不代表页面一定能拿到 WebGL。页面里 WebGL 是不是 null，还是要在浏览器上下文里跑一遍才知道。

7. 选择建议

8. 小结

云浏览器的“指纹问题”，很多时候根子在图形栈。

建议的排查顺序：先确认 WebGL / GLX / RANDR / chrome://gpu 是否正常，再去调 UA、platform、canvas、WebGL vendor/renderer 的一致性。WebGL 本身是 null 的话，在 JS 层补 vendor/renderer 没有意义。把显示栈换到更接近标准 Linux 桌面的环境，再测指纹一致性，问题定位会更清楚。

参考资料

xorg.freedesktop.orgXVFBhttps://xorg.freedesktop.org/archive/X11R7.7/doc/man/man1/Xvfb.1.xhtml

GitHubxpra/docs/Usage/Xdummy.md at master · Xpra-org/xpraPersistent remote applications for X11; screen sharing for X11, MacOS and MSWindows. - xpra/docs/Usage/Xdummy.md at master · Xpra-org/xpra

virtualgl.orgVirtualGL | Documentation / Documentationhttps://www.virtualgl.org/Documentation/Documentation

turbovnc.orgTurboVNC | Main / TurboVNChttps://turbovnc.org/

chromium.googlesource.comChromium Docs - Using Chromium with SwiftShaderhttps://chromium.googlesource.com/chromium/src/+/main/docs/gpu/swiftshader.md

Chrome for DevelopersChrome Headless mode  |  Automation and testing  |  Chrome for DevelopersLearn how to run Chrome in an unattended environment without UI.