dots：自托管的反检测浏览器自动化项目，部署前要验证什么

把浏览器自动化任务放到自己的服务器上，难点往往不是“能不能打开网页”，而是登录状态能否保持、页面变化后任务会不会失控，以及目标站点出现验证或拒绝访问时该如何处理。dots 值得关注，正是因为它把 AI 指令、可见的浏览器操作和本地运行环境放在一起；但“自托管”和“反检测”都不等于可以无人值守地采集任意网站。

dots 适合解决什么问题

这里的 dots 指开源项目 feder-cr/dots，不是 OpenAI 或 Grok 的官方产品。已有项目介绍将它描述为一个带独立浏览器的 AI 网页代理：用户用自然语言提出任务，同时观察浏览器中的实际操作。它适合先由人确认步骤、再逐步自动化的工作，例如在获授权的后台查找记录、整理少量公开页面的信息，或验证一段跨页面操作流程。

它与传统爬虫的侧重点不同。固定网址、固定字段的大批量提取，通常更适合直接请求接口或编写确定性的脚本；dots 更适合需要阅读页面、点击控件、判断下一步的交互任务。代价是模型可能误判页面，浏览器会话也可能中断，因此关键结果仍需人工或程序复核。

项目介绍提到 dots 使用经过调整的 Firefox 浏览器。这是理解其“反检测”定位的起点，而不是成功率承诺：浏览器特征只是站点判断流量的一部分。服务器出口 IP、访问频率、账号状态和操作行为同样可能触发限制。自托管意味着运行环境由你管理，不意味着目标网站必须接受你的自动化访问。

部署前先核对三类条件

首先，核对项目身份和当前安装说明。从仓库 README 确认启动命令、支持的操作系统、浏览器依赖、配置项及许可证，不要把名称相近的 dots、Open Dot 或 invisible_dots 当作同一个项目。尤其不要仅凭第三方文章中的命令运行安装脚本：这些信息可能对应不同项目或旧版本。

其次，准备实际运行环境。项目介绍给出的入门路径涉及 uvx、OpenRouter 密钥和本地浏览器界面。部署机器需要能启动项目所需的浏览器、访问模型服务与目标网站；无图形界面的服务器还要特别核对仓库是否支持你的运行方式。若准备长期运行，应提前确定数据目录、日志保存位置、重启方式和资源上限，而不是先把任务接入生产账号。

最后，划定凭据与网络边界。先用低权限测试账号；将模型密钥放在项目支持的环境变量或密钥管理方式中，不要提交到代码仓库。确认浏览器配置文件、登录状态和任务记录存在哪里、哪些用户能读取，以及服务器会从哪个出口 IP 访问目标站点。如果使用云服务器，目标站点可能仅因数据中心 IP 就提出验证或拒绝请求，浏览器调整未必能改变这一点。

从安装到首次运行：先让过程可观察

建议按“仓库文档 → 本机或隔离环境 → 小任务”的顺序部署：

1. 打开仓库 README，确认当前推荐的安装命令和 Python、uv、浏览器等前置要求；记录所用版本或提交，以便排错。
2. 按文档配置模型服务密钥，再启动项目。不要把密钥直接写进终端截图、任务提示词或共享日志。
3. 先只允许本机访问管理界面。第三方项目介绍曾给出 http://127.0.0.1:8765 作为本地入口，但实际地址应以启动日志和当前文档为准；不要未经认证配置就将界面暴露到公网。
4. 打开界面后，确认你既能看到任务对话，也能观察浏览器正在访问的页面。若浏览器未启动，先检查项目日志及浏览器依赖，不要立即归因于网站的反检测机制。

首次任务可以选一个你有权访问、无需登录的测试页面，例如自己的测试站点。给 dots 一个范围明确的指令：“打开指定页面，读取页面标题和前三个列表项；如果出现登录、验证码或访问被拒绝，就停止并报告，不要重试。”把预期结果提前写下来，方便对照。

用小规模任务验证，而不是用“跑通一次”下结论

一次成功只能证明基本链路可用。正式使用前，至少做以下检查：

验证时给每项任务设置页面范围、最大步骤数或时长，并保持人工可随时中止。若目标页面更新，重新核对输出；若出现验证码、账号警告或明确的访问拒绝，应停止任务并检查授权与站点规则，而不是把“继续绕过”当作排错步骤。

什么时候不该选 dots

如果你需要的是高吞吐、字段固定的数据同步，优先寻找官方 API、数据导出功能或明确允许的接口。若任务涉及付款、发帖、删除数据等不可逆操作，也不宜让浏览器代理直接执行到底；更稳妥的做法是把它用于查找与准备，让人确认最终动作。

dots 的价值在于把需要人盯着网页完成的短流程，变成可观察、可逐步验证的自动化实验。是否值得自托管，取决于你能否管理浏览器环境、模型密钥、账号权限和失败后的人工接管。部署前把这些边界讲清楚，比追求“不会被封”的说法更能决定它能否稳定落地。