无头浏览

无头浏览是指使用网络浏览器而不显示其正常的图形界面。 浏览器仍然可以加载页面、执行 JavaScript、管理 cookie、与元素交互以及生成屏幕截图。 代码控制浏览器,而不是通过可见窗口工作的人。

此设置对于自动化测试、网站监控、屏幕截图生成和其他可重复的浏览器任务非常有用。 它也适用于没有桌面显示器的服务器。

缺少的窗口只是设置的一部分。 无头浏览不会自动变得更快、私密、无状态或更难以检测。 这些结果取决于浏览器、网站以及工作流程的构建方式。

什么是无头浏览?

无头浏览器是一种运行时不显示其通常界面的浏览器。 无头浏览是使用浏览器访问网站并与网站交互的过程。

该浏览器仍然可以完成常规浏览器所需的大部分工作。 它下载资源、解析 HTML、应用 CSS、执行 JavaScript、构建 DOM、存储 cookie 并处理网络请求。 它可以单击按钮、填写表格、滚动页面并等待内容出现。

改变的是浏览器的控制方式。 人们通常通过选项卡、按钮、菜单和可见页面进行工作。 无头浏览器从脚本、命令行工具或自动化框架接收指令。

无头浏览是运行 浏览器自动化 的一种方式。 浏览器自动化是一个更广泛的概念。 它可以在有可见窗口的情况下运行,也可以在没有可见窗口的情况下运行。

现代无头模式不应与纯文本浏览器混淆。 这也不意味着浏览器停止处理视觉内容。 即使屏幕上没有出现浏览器窗口,无头浏览器也可以计算页面布局并生成屏幕截图。

Chrome 在版本 112 中更改了其无头架构。 其当前的无头模式使用常规 Chrome 代码库并创建平台窗口而不显示它们。 旧的实现现在作为 Headless Shell 单独存在。 Chrome Headless 文档 解释了当前的差异。

无头浏览器如何工作?

无头浏览器遵循与有头浏览器相同的一般页面加载过程。 主要区别在于控制层。

典型的工作流程有五个阶段。

  1. 浏览器启动

脚本启动 Chrome、Chromium、Firefox 或其他受支持的浏览器。 该进程可以在本地计算机、构建服务器、容器或远程基础设施上运行。

  1. 自动化工具连接

控制程序通过自动化协议与浏览器通信。 Chromium 工具通常使用 Chrome DevTools 协议。 其他工作流程使用 WebDriver 标准。

  1. 浏览器加载页面

浏览器请求页面及其资源。 它处理 HTML、CSS、JavaScript、字体、图像、cookie 和存储。 客户端应用程序可以在第一个文档到达后继续加载数据。

  1. 脚本执行操作

自动化工具可以查找元素、单击按钮、输入文本、滚动、等待请求、打开新页面或下载文件。 它还可以检查 DOM 并监听浏览器事件。

  1. 工作流程记录结果

最终结果可能是测试报告、屏幕截图、PDF、下载的文件、DOM 值、性能跟踪或网络日志。 然后,工作流将关闭浏览器或保留会话以供以后工作使用。

Playwright、Puppeteer 和 Selenium 等工具位于脚本和浏览器之间。 它们提供实用的 API 并处理大部分低级协议通信。

Chrome 是一个浏览器。 Playwright 和 Puppeteer 是控制浏览器的工具。 将它们视为同一类型的软件会导致工具比较不佳和技术文档不明确。

无头浏览器与有头浏览器

有头浏览器显示熟悉的浏览器窗口。 无头浏览器则不然。 两者都可以通过自动化工具进行控制。

区域无头浏览器头浏览器
可视窗口没有正常的浏览器窗口浏览器窗口可见
主要控制方式代码或自动化工具人工输入或自动化
共同环境服务器、容器和 CI 系统台式机和开发机
最适合计划的和可重复的任务调试、审核和交互工作
目视观察使用屏幕截图、痕迹或录音可以直接观看
人为干预不太方便更轻松
页面处理加载和处理网页内容加载和处理网页内容
资源利用可以减少接口开销包括可见的界面
故障调查很大程度上取决于保存的证据通常更容易现场检查

对于需要在无人监督的情况下运行的稳定任务,无头模式是一个实用的选择。 在开发工作流程时,有图形界面模式通常会更好。

观察浏览器可以使计时问题和不正确的点击更容易理解。 一旦工作流程可靠,将其转移到无头模式可以简化计划执行。

许多团队都使用两者。 他们无头地执行日常工作,并以有头模式重现故障。 这比将一种模式视为每个浏览器任务的答案更可靠。

无头浏览与相关概念

多个浏览器术语描述了自动化系统的不同部分。 它们不应该被用作彼此的替代品。

概念它描述了什么它与无头浏览有何不同
浏览器自动化浏览器操作的编程控制可在无图形界面(headless)或有图形界面的模式下运行
云浏览器在远程基础设施上运行的浏览器它可能是无头的或提供可见的实时视图
HTTP客户端发送网络请求的软件它通常不提供完整的浏览器环境
浏览器隔离将 Web 执行与本地设备或其他会话分离它描述的是隔离边界而不是接口可见性
虚拟浏览器在虚拟或远程环境中运行的浏览器它不一定是无头的
网页抓取从网页收集信息无头浏览器只是一种可能的抓取工具

云浏览器展示了为什么这些区别很重要。 云描述了浏览器运行的位置。 Headless描述了其正常界面是否显示。 远程浏览器仍然可以将可见页面流式传输给用户。

同样的区别也适用于浏览器隔离。 隔离控制 Web 内容的运行位置或浏览器数据的分离方式。 删除可见窗口不会创建该安全边界。

基本的 HTTP 客户端也有所不同。 它可以比完整的浏览器以更少的开销请求文档。 这使得它成为许多静态页面和记录的 API 的更好选择。 当任务需要 JavaScript 执行、浏览器存储、页面交互或特定于浏览器的行为时,无头浏览器就会变得有用。

无头模式并不能决定浏览器数据在进程关闭后是否仍然存在。 工作流的 会话管理 规则确定何时创建、重用、刷新或删除登录状态。 临时上下文可能会在每次运行后丢弃其数据。 持久上下文可以将其保留以供以后的会话使用。

当多个上下文同时运行时,Cookie 隔离 可防止其存储的登录数据混合。 这种分离来自浏览器上下文或配置文件设计,而不是来自无头模式本身。

无头浏览器有什么用?

当任务需要真实的浏览器行为但不需要人监视每一步时,无头浏览器最有用。

自动化网络测试

测试是无头浏览最明显的用途之一。 测试可以打开页面、填写表单、提交并检查结果。

无头测试自然适合持续集成系统。 它们可以在每次代码更改后运行,而无需在开发人员计算机上打开浏览器窗口。

常见的例子包括:

  • 功能测试
  • 回归测试
  • 端到端测试
  • 跨浏览器测试
  • 表单和导航测试
  • JavaScript 错误检查

无头测试并不能消除有头测试的需要。 工作流程可能会无头通过,但仍然存在视觉或交互问题。 重要的用户旅程应该在两种模式下进行检查。

屏幕截图和 PDF 生成

无头浏览器可以生成屏幕截图,而无需在屏幕上显示页面。 这对于视觉回归测试、链接预览、报告、存档和页面监控非常有用。

它还可以将网页转换为 PDF。 浏览器在生成文件之前处理页面布局。 打印样式、字体、页面大小和加载状态仍然会影响结果。

这个用例暴露了一个常见的误解。 无头浏览器确实处理视觉内容。 他们只是不通过普通的浏览器窗口显示该内容。

网站监控

监控任务可以按计划加载页面并检查是否出现预期的内容。 它还可以测量页面时间、捕获控制台错误、检查失败的网络请求以及在发生变化时保存证据。

当页面依赖于 JavaScript 或在重要内容出现之前需要执行多项操作时,这会比基本正常运行时间请求提供更清晰的结果。

良好的监控工作流程会检查特定的结果。 它不应仅依赖于最终的 HTTP 状态。 当页面的主应用程序损坏时,页面可以返回成功的响应。

JavaScript 渲染和数据收集

许多网站提供一个小的 HTML 文档,然后使用 JavaScript 加载有用的内容。 一个简单的请求可能只收到初始的页面shell。

无头浏览器可以等待应用程序运行。 它可以与菜单、分页、模式窗口以及滚动后出现的内容进行交互。

但这并不意味着浏览器成为每个数据收集任务的首选。 有文档记录的 API 通常更稳定。 对于静态公共页面,直接 HTTP 请求通常更便宜。 当真正需要浏览器执行时,完整的浏览器才有意义。

任何数据收集工作流程都应尊重访问权限、网站条款、隐私要求和适用法律。

SEO 和渲染检查

无头浏览器可以帮助 SEO 团队检查依赖于客户端渲染的页面。 工作流程可以将初始 HTML 与渲染的 DOM 进行比较,检查规范标签,检查结构化数据,并确认 JavaScript 运行后出现内部链接。

它还可以捕获不同视口大小的页面并识别丢失的内容。

这是一个诊断工具。 它不会重现搜索引擎爬虫的每个部分。 搜索引擎使用自己的获取、呈现、调度和索引系统。

AI代理任务

AI代理可以使用浏览器作为其执行层。 代理决定采取什么操作,而浏览器打开页面并执行操作。

当没有人需要观看时,浏览器可能会无头运行。 当工作流程需要审查或手动输入时,它可能会切换到可见视图。

人工智能代理和无头浏览器具有不同的角色。 代理负责规划和决策。 浏览器处理网络执行。

无头浏览

主要好处是可操作性。 浏览器任务可以在没有人保持窗口打开的情况下运行。

这使得无头浏览非常有用:

  • 预定职位
  • 自动化测试管道
  • 服务器端浏览器任务
  • 可重复的屏幕截图和报告
  • 并行浏览器会话
  • 长期运行的监控系统

删除可见接口可能会减少一些开销。 它还可以使在没有桌面环境的计算机上的部署变得更加容易。

性能优势不应被夸大。 无头浏览器仍然下载资源、执行脚本、计算布局并维护浏览器状态。 在任一模式下,复杂页面都可以使用大量 CPU 和内存。

更大的收益通常来自自动化本身。 一致的工作流程可以在所需的时间运行、记录结果并报告故障,而无需等待某人重复相同的步骤。

限制和挑战

无头浏览会删除可见窗口。 它并不能消除浏览器自动化的正常困难。

有限的实时反馈

当没有人可以看到该页面时,失败的操作就更难理解。 该脚本可能单击了错误的元素、加载了意外的登录屏幕或等待从未出现的内容。

屏幕截图、跟踪、控制台消息和网络日志至关重要。 没有它们,唯一的结果可能是无益的暂停。

浏览器和框架的差异

无头模式和有头模式比以前更接近,但不应假设它们在每种情况下都表现相同。

浏览器版本发生变化。 自动化框架还会更新其浏览器版本、默认设置和支持的功能。 工作流在更新后可能会开始失败,即使其自身的代码没有更改。

媒体支持、浏览器扩展、企业策略、字体和操作系统依赖性也会影响结果。

不稳定的页面和选择器

网页更改时不会发出警告。 按钮移动,标签改变,加载顺序改变,登录流程增加了额外的步骤。

基于脆弱页面结构的选择器往往首先失败。 固定的延迟也会引起问题。 他们在快速页面上等待的时间太长,而在慢速页面上等待的时间不够长。

可靠的自动化等待有意义的页面状态。 它还确认每项重要行动都产生了预期结果。

CPU、内存和并发

无头浏览器仍然是一个浏览器进程。 运行一个会话可能很简单。 运行数百个需要资源限制、队列、超时、崩溃恢复和清理。

页面可能会泄漏内存或使后台工作继续运行。 失败的脚本还可能在作业结束后使浏览器进程保持打开状态。

应使用实际工作负载来测试并发性。 如果不知道页面、浏览器版本、主机容量和每个任务的长度,固定的会话计数就没有什么意义。

依赖于人类和设备的任务

有些任务不适合完全无头执行。

他们可能需要:

  • 人类的判断
  • 人工审批
  • 摄像头或麦克风访问
  • 硬件支持的凭证
  • 复杂的拖放交互
  • 本机移动应用程序行为
  • 故障期间的目视调查

混合工作流程通常更实用。 常规步骤会自动运行,而异常或敏感步骤则等待审核。

网站可以检测无头浏览器吗?

网站可能会识别浏览器自动化或异常的浏览器行为。 无头模式可以有助于该评估,但这并不是全部决定。

标准 navigator.webdriver 属性 可以告诉页面浏览器处于自动化控制之下。 站点还可以检查 HTTP 标头、浏览器 API、呈现结果、网络信息、请求计时和会话行为。

例如,报告的浏览器版本可能与可用的 API 不一致。 所声称的操作系统可能不适合浏览器公开的字体或图形信息。 重复操作也可能遵循与正常使用不同的模式。

网站将这些详细信息合并到 Bot 检测 系统中。 此类系统通常将网络、浏览器、帐户和行为信号一起考虑。 一个值很少能解释整个结果。

更改 User-Agent 标头不会更改浏览器的其余部分。 当新的浏览器声明与底层环境不匹配时,基本的 用户代理欺骗 可能会造成不一致。

图形检查添加了另一个上下文来源。 WebGL 指纹 可以揭示有关渲染环境的详细信息。 它并不能证明浏览器是无头的,但网站可以将其与其他浏览器声明进行比较。

无头模式不会自动更容易被检测到。 它也不会自动成为私有的。 结果取决于浏览器版本、启动设置、页面行为和网站的检测系统。

什么时候应该使用无头浏览器?

当任务需要浏览器行为并且不需要可见窗口时,请使用无头浏览器。

情况实用选择
可重复的 CI 测试无头
早期工作流程开发为首
可视化调试为首
预定的屏幕截图无头
静态 HTML 页面首先进行 HTTP 请求
已记录的 API 可用首先使用API
依赖于 JavaScript 的内容无头可能有帮助
需要人工批准头型或混合型
偶尔出现故障的生产任务无头,带有日志和手动回退
原生移动应用程序真实或虚拟的移动设备

在选择无头模式之前,先问五个问题:

  1. 该任务是否需要完整的 JavaScript 浏览器?
  2. 是否有人需要观看或接管会话?
  3. cookie 或登录状态是否应该在运行之间保留?
  4. 失败后可以获得哪些证据?
  5. 运行时能否处理预期的 CPU、内存和并发性?

对于新的工作流程,有图形界面模式通常是更好的起点。 它尽早暴露了错误的假设。 一旦理解了步骤和故障处理,无头模式就会变得有用。

常见的无头浏览器和自动化工具

浏览器运行该页面。 自动化工具告诉它要做什么。

工具类型覆盖范围常见配合
铬或铬无头浏览器运行时铬一般自动化和测试
剧作家自动化框架Chromium、Firefox 和 WebKit跨浏览器测试和自动化
傀儡师自动化库铬和铬重点Chrome 自动化、屏幕截图和 PDF
硒自动化框架多个浏览器系列建立跨浏览器测试套件

默认情况下,剧作家测试是无头运行的。 可以启用浏览器窗口进行调试。 其 浏览器文档 还解释了其 Chromium 版本和较新的 Chrome 无头模式之间的区别。

Puppeteer 默认情况下也会以无头模式启动。 它可以使用当前的 Chrome headless 模式或单独的 Headless Shell,具体取决于配置。 Puppeteer 无头模式指南 记录了该选择。

Selenium 在浏览器家族和编程语言方面有着悠久的历史。 它使用特定于浏览器的驱动程序和与 WebDriver 兼容的接口。

没有一个工具适合每个项目。 浏览器覆盖范围、语言支持、现有测试代码、调试工具、部署环境和维护需求比一般排名更重要。

可靠无头浏览的最佳实践

可靠的无头工作流程取决于明确的证据和可预测的恢复。

  1. 首先在头部模式下开发

观看初始工作流程的运行。 确认每个操作都针对预期的元素并产生预期的页面状态。

  1. 等待真实情况

等待元素、响应、URL 或应用程序状态。 避免使用固定延迟作为主要同步方法。

  1. 使用稳定的选择器

优先选择可访问的角色、标签、测试 ID 或其他有意的标识符。 避免将选择器绑定到脆弱的 DOM 位置。

  1. 记录有用的失败证据

保存屏幕截图、跟踪记录、浏览器日志、网络错误和当前 URL。 仅堆栈跟踪是远远不够的。

  1. 设置清除超时

对导航、页面操作和完整任务使用单独的限制。 这可以防止被阻止的页面无限期地消耗工作人员。

  1. 验证重要结果

不要假设点击成功。 检查结果页面、下载的文件、保存的值或应用程序状态。

  1. 控制资源使用

限制并发并监控 CPU、内存、会话长度和浏览器崩溃。 使用代表性页面测试限制。

  1. 关闭浏览器资源

即使发生错误,页面、上下文和浏览器进程也应该关闭。 无论执行失败还是成功,都应进行资源清理。

  1. 跟踪浏览器版本

记录工作流使用的浏览器和自动化框架版本。 在将更新应用到重要的生产作业之前对其进行测试。

  1. 保留人力后备

当工作流程遇到意外的登录要求、审批步骤或敏感操作时,应安全停止。自动化不应凭猜测处理可能产生重大影响的决策。

要点

无头浏览器运行时不显示其正常界面。 它仍然加载网站、执行 JavaScript、处理布局、存储浏览器数据以及与页面元素交互。

无头浏览是浏览器自动化的一种模式。 它非常适合测试、监控、屏幕截图、PDF 和计划的浏览器任务。

它不会自动使工作流程变得更快、无状态、私有或不可检测。 可靠的结果仍然取决于健全的等待、验证、日志记录、资源管理和仔细的工具选择。

无头浏览常见问题解答

简单来说什么是无头浏览?

无头浏览是使用没有可见浏览器窗口的浏览器。 脚本控制导航和页面操作。 浏览器仍然处理网站,并可以返回数据、屏幕截图、PDF、日志或测试结果。

无头浏览器会执行 JavaScript 吗?

是的。 现代无头浏览器执行 JavaScript 并支持动态 Web 应用程序。 它们可以等待客户端内容、响应页面事件以及与第一个 HTML 文档加载后创建的元素进行交互。

无头浏览器会渲染网页吗?

是的。 它解析 HTML、应用 CSS、计算布局并处理视觉内容。 结果不会显示在正常窗口中。 浏览器仍然可以从渲染的页面生成屏幕截图和 PDF。

无头浏览器比普通浏览器更快吗?

对于某些工作负载来说,它可能会更快,因为它不显示正常界面。 差异无法保证。 页面复杂性、网络请求、JavaScript、图像、浏览器设置和系统容量通常会产生较大的影响。

无头模式和有头模式有什么区别?

无头模式运行时不显示浏览器窗口。 标题模式显示窗口。 无头模式适合无人值守的任务。 Headed模式更容易手动观察、调试和控制。

无头浏览器可以截图吗?

是的。 即使没有可见窗口,浏览器也可以捕获页面。 屏幕截图质量仍然取决于视口大小、字体、加载状态、动画和页面布局。

网站可以检测无头浏览器吗?

有些网站可以识别自动化信号或异常的浏览器行为。 无头模式可能是众多信号之一。 检测还可以考虑标头、浏览器 API、图形输出、网络信息、计时和会话行为。

无头浏览器会保存cookie吗?

可以。 Cookie 存储取决于工作流使用的浏览器上下文或配置文件。 临时上下文可能会在关闭后丢弃其 cookie。 持久上下文可以保留它们以供以后的会话使用。

无头浏览器与网页抓取相同吗?

不。 网页抓取是从网页收集信息的任务。 无头浏览器是可以执行该任务的一种工具。 静态页面和记录的 API 通常需要更简单的方法。

无头浏览合法吗?

无头浏览是一种技术方法,因此其合法性取决于它的使用方式。 工作流程应遵循访问权限、网站条款、隐私规则、数据权利以及适用于该任务的法律。

开始使用 MoreLogin 构建

探索 API 文档,通过命令行实现自动化,连接兼容 MCP 的工具,或创建可复用的 RPA 工作流。