什么是Xvfb？
无抓取抓取浏览器提供了一个受管控的云浏览器环境，因此自动化团队可以在不维护本地Xvfb显示的情况下运行浏览器工作流程。
TL;DR
- Xvfb是一个由内存支持的X11显示服务器，而不是物理显示器。 图形应用程序可以连接到它，即使机器没有显示硬件。
- Xvfb不是浏览器，也不是窗口管理器。 它提供了X11客户端所期望的显示服务器。
- 原生无头浏览器模式和Xvfb解决相关但不同的问题。 无头模式改变了应用程序的模式；Xvfb允许应用程序作为图形X11客户端运行。
- 屏幕尺寸和色深是配置输入。 它们可以影响布局、截图和渲染测试。
- 虚拟显示不再现物理GPU。 图形加速、字体、桌面服务和设备行为需要单独的验证。
为何显示基础设施很重要
Xvfb影响浏览器如何公开状态、渲染内容，或决定何时自动操作是安全的。精确定义防止团队将狭窄信号视为普遍答案。这也使得测试失败更容易诊断，因为预期的浏览器行为与文档化的生命周期、API或系统边界相关联。
对于网络自动化，实际问题通常比 “页面准备好了吗？” 或 “浏览器看起来真实吗？” 更狭窄。下一步可能需要启用一个控制、完成一个框架导航、一个组件附加其内部树，或一个渲染表面保持一致。以下部分将概念转化为可观察的检查，而不是依赖于民间传说。
Xvfb一句话简介
Xvfb是一个X Window系统服务器，将内容渲染到存储在内存中的虚拟framebuffer，而不是驱动一个物理屏幕。一个X11应用程序连接到一个显示编号，创建窗口，绘制内容，并通过正常的X协议接收事件。虽然没有监视器连接，但像素依然存在。
这个 官方Xvfb手册 将其描述为一个针对没有显示硬件或物理输入设备的机器的X服务器。framebuffer可以存在于分配的内存、共享内存或内存映射文件中。最初的测试用途扩展到了批量渲染、应用测试以及对坚持使用X服务器的程序的支持。
这个名称扩展为X虚拟framebuffer。重要的词是服务器。X11客户端不会直接在监视器上绘制；它们与X服务器交谈。Xvfb实现了服务器侧，同时用内存替换了硬件支持的framebuffer。这就是为什么设置显示环境变量将应用程序指向Xvfb，而不是单独让它们变成无头模式。
虚拟显示是如何结合在一起的
X11显示有一个显示编号和一个或多个屏幕。Xvfb在可用的显示编号上启动，并创建一个带有配置宽度、高度和色深的屏幕。客户端进程通过DISPLAY环境变量接收显示地址。对于客户端来说，该连接看起来像一个普通的X服务器连接。
Xvfb处理绘图请求并将生成的像素保存在其framebuffer中。它不会自动提供桌面外壳、窗口装饰或合成管理器。有些测试套件只需要服务器。其他测试则需要一个轻量级的窗口管理器或额外的桌面服务，因为应用程序假设它们存在。
这个 X服务器手册 解释了显示编号、服务器选项、授权和X服务器共享的常见行为。这种分离有助于排查故障：不可用的显示编号是服务器启动问题，缺少DISPLAY值是客户端路由问题，缺少窗口管理器是桌面环境假设。
为何浏览器测试使用Xvfb
在浏览器提供成熟的本地无头模式之前，持续集成机器仍然需要启动其图形构建。Xvfb提供了这些构建所期望的显示。测试运行器可以打开页面、与窗口交互、捕获截图，并在没有物理桌面会话的情况下关闭浏览器。
当应用程序在图形模式和无头模式下表现不同，或者当旧工具没有本地无头选项，或者当GUI依赖于X11时，Xvfb仍然有用。它还可以支持跨浏览器和其他桌面应用程序的测试。虚拟屏幕为这些客户端提供共享坐标空间。
配置几何体影响响应式断点和截图尺寸。色深可能会影响渲染路径。字体可用性来自操作系统映像，而不是Xvfb本身。因此，可重复的测试固定显示配置和周围系统包，而不将虚拟服务器视为整个环境。
Xvfb与本地无头模式的对比
本地无头模式由应用程序实现，例如可以在不连接到桌面显示服务器的情况下渲染的浏览器。Xvfb则提供一个显示服务器，因此应用程序可以在其图形模式下运行。两者都消除了对物理显示器的需要，但它们是在不同层次上实现的。
本地无头模式通常需要更少的后台进程，并且更容易打包。Xvfb下的图形浏览器对于与老版本、扩展、对话框或期望窗口环境的集成兼容性很有用。现代浏览器项目缩小了许多行为差异，然而团队仍应验证其测试所使用的确切功能。
根据观察到的应用程序行为进行选择。如果支持的无头模式能够渲染页面、处理下载、捕获屏幕截图并暴露工作流所需的API，则这是更简单的本地选项。如果某个依赖项需要X11或图形构建具有明显不同的行为，Xvfb可以弥补这个差距。托管的远程浏览器完全消除了客户端机器上的本地显示决策。
Xvfb不解决的限制
Xvfb不创建物理GPU。如果缺少预期的图形库，WebGL可能使用软件渲染或失败。它不安装字体、音频设备、摄像头、D-Bus服务、窗口管理器或桌面会话。每个假设必须独立提供或移除。
Xvfb也不会让浏览器自动化更难以识别。浏览器指纹、网络身份、自动化属性和请求行为仍然是单独的关注点。虚拟显示可以影响屏幕和图形信号，但它不是一个反检测系统。将其视为一个反检测系统会导致错误的安全假设。
这个 当前的X.Org文档索引 涵盖了更广泛的X服务器和客户端生态系统。当测试在基本绘图之外失败时，生态系统上下文变得重要。检查浏览器日志、Xvfb日志、已安装的库、字体、进程所有权和显示授权，而不是在没有证据的情况下增加延迟。
CI和容器的操作指南
为每个并行工作者分配一个唯一的显示编号，或使用一个选择未使用服务器的包装器。在配置中固定屏幕几何和颜色深度，以便结果不依赖于默认值。在客户端之前启动服务器，并在作业结束时停止它。保留X服务器和应用程序的日志，因为任一方都可以解释连接失败。
使用适合环境的访问控制。广泛禁用X服务器访问控制可能会使显示暴露给共享主机上的其他进程。隔离工作负载，限制可以连接的人，并避免将容器边界视为唯一的安全决策。屏幕截图和帧缓冲区可能包含敏感应用数据，因此仅在测试需要时保留它们。
对于浏览器自动化，在图像或浏览器更新后验证一个小页面矩阵：纯HTML、JavaScript渲染、画布、必要时的WebGL、字体、下载、对话框和屏幕截图。仅在重要的行为上比较本地无头和Xvfb。如果本地显示维护消耗的精力超过应用逻辑，托管的云浏览器可以将基础设施转移出测试运行器。
选择Xvfb、本地无头或云
以证明任务可以进行的最小条件或配置开始。保持标准兼容的浏览器行为，然后仅在工作流需要的地方添加配置控制。记录浏览器构建和相关状态，以便后来可以解释差异。可重复的观察比简单声明一个页面、框架、显示或指纹“完成”或“安全”更有用。
- 定义下一步行动。 准确说明脚本或用户在等待或配置步骤后需要做什么。
- 选择一个可观察的信号。 更喜欢直接支持该行动的浏览器属性、生命周期状态、元素条件或渲染结果。
- 保持相关值一致。 浏览器、操作系统、屏幕、区域设置、图形和会话设置应描述一个可信的环境。
- 验证正常应用行为。 隐私或自动化干预不应无声地破坏其所更改的API或组件。
- 捕获诊断证据。 当检查失败时，保存相关的URL、状态、控制台消息和配置名称。
结论
Xvfb是一个内存支持的X11服务器，允许图形Linux应用程序在没有物理显示硬件的情况下运行。它在期望使用X11的兼容性测试和GUI工作负载中仍然很有用，而本地无头模式通常对于受支持的浏览器任务更简单。可靠使用依赖于固定的屏幕设置、进程隔离和字体、图形和桌面服务的单独验证。
这个 Scrapeless Scraping Browser文档 解释了如何配置托管的浏览器会话，而这个 Scraping Browser产品概述 描述了浏览器自动化表面。这些资源提供了在授权工作流中应用该概念的产品背景。
准备超越本地虚拟显示吗？
将浏览器渲染、会话配置和自动化基础设施移入托管的Chromium环境。
今天注册并获得 5美元的免费信用 — 无需信用卡.
索取5美元信用→常见问题
Xvfb是一个无头浏览器吗？
不是。Xvfb是一个虚拟的X11显示服务器，而浏览器是一个可以在图形模式或本地无头模式下运行的单独客户端进程。
Xvfb需要GPU吗？
不需要。Xvfb可以在没有显示硬件的情况下维持一个内存中的帧缓冲区，尽管需要加速图形的应用程序需要额外的支持和验证。
Xvfb包括窗口管理器吗？
不包括。Xvfb提供了X服务器；依赖窗口管理或桌面服务的工作流必须单独提供它们。
团队何时应偏好本地无头模式？
当本地无头模式支持所需的浏览器功能并产生正确结果时，应该首选本地无头模式，因为它通常减少本地基础设施和进程管理。