Camofox Browser
部署 Camofox：包、浏览器二进制、原生库与就绪检查
结合 Node 22、明确绑定和独立健康检查，规划可复现的本地浏览器服务部署。
你将学会
- 分别跟踪包、浏览器完整包和原生运行环境。
- 部分固定版本的 Dockerfile 不等于不可变构建。
- 健康的空闲服务仍需真实页面就绪测试。
开始前需要
- 基础 HTTP 与 JSON 知识
- 隔离服务与自有或获准测试页面
解释本章真实服务边界，并核验建议的观察或生命周期样例。
先看结论
- 分别跟踪包、浏览器完整包和原生运行环境。
- 部分固定版本的 Dockerfile 不等于不可变构建。
- 健康的空闲服务仍需真实页面就绪测试。
JavaScript 包只是其中一项产物
所查包要求 Node 22 或更高版本，以 node server.js 启动，依赖 camoufox-js、playwright-core 和原生 SQLite 包。因此 npm 依赖安装成功，不足以证明浏览器能够启动。部署清单应分别记录包版本、浏览器完整包、操作系统和架构。
README 说明了 postinstall 下载，以及为已管理浏览器包指定 CAMOUFOX_EXECUTABLE 的方式，并警告外部可执行文件需要随附文件，而不只是一个孤立二进制。运行前应审查安装脚本。可复现部署需要固定并校验产物，不应依赖未来某个 latest 地址碰巧返回的版本。
将容器配方视为依赖地图
所查 Dockerfile 使用 node:22-trixie-slim，包含 GUI、音频、字体、软件渲染库及 Xvfb。它固定 Camoufox 版本与发布参数，但另一项下载使用最新 yt-dlp。因此，即使固定了浏览器版本，也不能称整个配方完全不可变。应根据自己的重建策略记录或固定所有重要产物。
Dockerfile 还安装原生依赖构建工具，并复制运行时导入所需的 mcp 和插件目录。其注释描述了可能隐藏在健康 HTTP 端点之后的失败。不要仅因目录或库名称看似与 REST 无关，就为加速构建将其删除；应在目标架构上验证导入和第一次真实标签操作。
分别验证监听、健康和有用的就绪状态
应明确设置 CAMOFOX_BIND_HOST。所查服务器在设置为空时向 listen 传入未指定主机，所以不能假设默认进程仅监听回环地址。本地测试应绑定 127.0.0.1 并配置 CAMOFOX_ACCESS_KEY。远程部署则需要认证访问、传输安全和受控浏览器出口。
主动空闲关闭后，GET /health 可以在 browserRunning 为 false 时报告成功，这符合延迟启动机制，却不证明页面已渲染。验收还需要获准页面冒烟测试、快照检查与资源清理。本章提供部署检查表，不宣称编辑审查期间构建了容器镜像或完整上游运行时。
实施步骤
- 1
审查固定版本的包与安装脚本。
- 2
记录浏览器包和架构相关依赖。
- 3
本地测试绑定回环地址并配置全局访问密钥。
- 4
检查 /health，再用获准页面及快照验收。
可复制示例
{
"NODE_ENV": "production",
"CAMOFOX_BIND_HOST": "127.0.0.1",
"CAMOFOX_PORT": "9377",
"CAMOFOX_CRASH_REPORT_ENABLED": "false",
"secretRequired": "通过单独秘密机制提供 CAMOFOX_ACCESS_KEY"
}常见问题
HTTP 健康成功就代表浏览器可用吗？
不能。主动空闲关闭时可能健康成功但 browserRunning 为 false，应另外测试获准页面。
外部可执行文件能单独复制吗？
README 要求完整 Camoufox 包及随附文件，部署时应核验文档规定的内容。
资料来源
- README.md来源核查 2026-09-08
- package.json来源核查 2026-09-08
- Dockerfile来源核查 2026-09-08
- lib/auth.js来源核查 2026-09-08
- lib/snapshot.js来源核查 2026-09-08
- lib/extract.js来源核查 2026-09-08
- lib/config.js来源核查 2026-09-08
- lib/reporter.js来源核查 2026-09-08
- lib/page-lease.js来源核查 2026-09-08
- server.js来源核查 2026-09-08
- tests/unit/snapshot.test.js来源核查 2026-09-08
- tests/unit/auth.test.js来源核查 2026-09-08