camofox-browser访问控制：CAMOFOX_ACCESS_KEY全局Bearer认证实战
【免费下载链接】camofox-browserStealth headless browser for AI agents — bypass Cloudflare, bot detection, and anti-scraping. Drop-in Puppeteer/Playwright replacement.项目地址: https://gitcode.com/GitHub_Trending/ca/camofox-browser
camofox-browser 是面向 AI Agent 的反检测无头浏览器服务器，通过 REST API 提供标签页、快照、会话等全套浏览能力。当它部署在公网 VPS 或容器平台上时，默认对所有网卡监听意味着任何发现端口 9377 的人都能操控你的浏览器。启用CAMOFOX_ACCESS_KEY全局 Bearer 认证只需一行环境变量，即可让所有 API 必须携带有效令牌，是生产部署的推荐安全姿势。
为什么需要全局认证
- 服务器默认绑定所有网络接口，未设防时，
/tabs建页、/evaluate执行任意 JS 都对来者敞开 - 免认证回环（loopback）例外仅在非生产环境且来源为
127.0.0.1时生效，对云部署毫无意义 CAMOFOX_ACCESS_KEY是一把覆盖全部路由的"总钥匙"，一次配置，全局生效，无需逐个接口加防护
CAMOFOX_ACCESS_KEY 的工作原理
核心实现位于 lib/auth.js，有 4 个关键行为值得了解：
- 开关即生效：设置了该环境变量，全局中间件立即拦截所有请求；不设置则全部放行（向后兼容旧部署）
- Bearer 令牌校验：每个请求必须携带
Authorization: Bearer <key>请求头，密钥比较使用crypto.timingSafeEqual时序安全对比，防止时序攻击 - 清晰的 401 反馈：校验失败返回
401 Unauthorized，并附带WWW-Authenticate: Bearer realm="camofox"响应头，便于客户端快速定位问题 - 纵深防御：拥有专用密钥的路由（Cookie 导入、
/stop）只有在专用密钥确实被配置时才豁免，否则仍受访问密钥保护，避免留下未设防的接口
四步开启实战
第 1 步：生成强随机密钥
openssl rand -hex 32第 2 步：设置环境变量并启动
export CAMOFOX_ACCESS_KEY="上一步生成的密钥" npm start密钥在 lib/config.js 中统一读取，并透传给服务器子进程，因此 Docker、Fly.io 等多进程/多平台环境同样生效。
第 3 步：验证认证行为
# 不带令牌 -> 401 curl -i "http://localhost:9377/tabs?userId=agent1" # 带令牌 -> 正常响应 curl -H "Authorization: Bearer $CAMOFOX_ACCESS_KEY" \ "http://localhost:9377/tabs?userId=agent1"第 4 步：云端部署配置
- Docker：
docker run -e CAMOFOX_ACCESS_KEY=... camofox-browser - Fly.io：
fly secrets set CAMOFOX_ACCESS_KEY=... - Railway：
railway variables set CAMOFOX_ACCESS_KEY=...
配合CAMOFOX_BIND_HOST控制监听地址，就构成"可对外暴露、但访问必须认证"的完整部署方案。
哪些接口免认证
| 路由 | 豁免条件 |
|---|---|
GET /health | 始终豁免（Docker/Fly 健康检查需要） |
POST /sessions/:userId/cookies | 仅当CAMOFOX_API_KEY已设置 |
/auth-sessions/* | 仅当CAMOFOX_API_KEY已设置 |
POST /stop | 仅当CAMOFOX_ADMIN_KEY已设置 |
除此之外——包括/tabs、/evaluate、/metrics、/openapi.json甚至站点根路径——全部要求 Bearer 令牌。
与 CAMOFOX_API_KEY 的区别
CAMOFOX_ACCESS_KEY | CAMOFOX_API_KEY | |
|---|---|---|
| 作用范围 | 全部路由（全局门卫） | 仅 Cookie 导入等特定路由 |
| 定位 | 全局密钥 | 路由专用密钥，兼作"超级密钥" |
| 互通性 | 也被要求 API_KEY 的路由接受 | 无法通过全局门卫 |
双密钥配置下的完整组合行为（含"API_KEY 过不了全局门卫"这类细节）由 tests/unit/accessKey.test.js 全面覆盖，可自行阅读验证。
密钥管理建议
- 密钥放入 shell profile、systemd 单元或平台密钥管理，不要写进明文配置文件
- 怀疑泄露时直接换钥重启即可——密钥只从环境变量读取，无任何持久化依赖
- 需要更细粒度权限划分时，再叠加
CAMOFOX_API_KEY/CAMOFOX_ADMIN_KEY
延伸阅读：README 安全模型章节、OpenAPI 规范、docs/api.html。
小结
CAMOFOX_ACCESS_KEY用一行环境变量，把 camofox-browser 从"信任内网"的服务变成"每次请求都必须认证"的生产级 API：时序安全比对、清晰的 401 响应、纵深防御的豁免规则。将服务器暴露在公网之前，这应该是你配置的第一道安全线 🛡️
【免费下载链接】camofox-browserStealth headless browser for AI agents — bypass Cloudflare, bot detection, and anti-scraping. Drop-in Puppeteer/Playwright replacement.项目地址: https://gitcode.com/GitHub_Trending/ca/camofox-browser
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
