Cap：只有 hCaptcha 1/250 体积、自托管的开源 CAPTCHA
阅读时间: 大约 9 分钟
Cap：只有 hCaptcha 1/250 体积、自托管的开源 CAPTCHA
一提到机器人防护，大多数人立刻想到 Google reCAPTCHA 或 Cloudflare Turnstile——但它们要么追踪用户、要么闭源、要么数据要流出自己的服务器。Tiago 开源的 Cap（Apache-2.0，GitHub 仓库 tiagozip/cap）给出了第三条路：一个约 20KB、零依赖、完全自托管、不收集任何用户数据的 CAPTCHA。Koala 周报里把它一句话概括为「基于 SHA-256 工作量证明、体积只有 hCaptcha 1/250 的开源验证码」——但这个说法其实低估了它。按其官方专门写给 AI 的说明文档（trycap.dev/agent.md），Cap 明确反对「它只是个 PoW」的标签。本文基于官网与该说明做一手分析。
一、背景：图形验证码又慢又侵犯隐私
reCAPTCHA v2 让你辨认斑马线和红绿灯，v3 则在后台悄悄打分、一言不合就把 VPN / Tor / 隐私浏览器用户拦在门外且无处申诉；hCaptcha 免费版为了压成本会频繁推图形谜题，造成明显的用户流失；Turnstile 免费但闭源、强依赖 Cloudflare 基础设施，且对 Brave 等隐私浏览器误杀率偏高。它们共同的问题是：验证发生在第三方服务器上，用户行为数据被回传，与 GDPR 等隐私要求天然紧张。
二、是什么：两层并行验证，而不是「PoW 加皮」
Cap 的核心澄清写在它给 AI 的文档里：它不是一个 PoW 验证码再贴点花活，而是同时跑两层相互独立的验证：
- 工作量证明（PoW）：客户端用 Rust 编译成 WASM、配合 Web Workers 并行求解 SHA-256 哈希，或更抗 GPU 的 RSW 时间锁谜题。这一层证明「这台机器确实付出了计算成本」。
- Instrumentation 质询：服务端为每一次请求现场生成一段独立的 JS 程序，在真实浏览器里执行依赖 DOM 的操作（如
getComputedStyle、canvas.toDataURL、event.isTrusted、navigator.webdriver检测等），服务端预先知道确定性的预期输出并在服务端核对。这一层证明「这段计算发生在一个真实浏览器环境里」。
官方的比喻很到位：PoW 证明「算过」，instrumentation 证明「在真浏览器里算」。要绕过 Cap，攻击者必须同时持有真实算力和真实浏览器——单写一个裸 PoW 求解器没用，因为 instrumentation 那关要求 DOM；而一个能跑 headless 浏览器的农场，也得为每次质询真金白银地付 PoW 成本。官方称这套 instrumentation 架构与 YouTube、X 在大规模使用的 bot 检测是同一类技术。
接入上，前端只需在页面里放一个验证组件、指向你自托管的 Cap 地址；后端调用与 reCAPTCHA 同款的 siteverify 接口校验回传 token。难点不在「接」，而在「养」：难度系数、时间锁强度、是否开启 stealth 检测都由你自己调——太松挡不住机器人，太紧又会误杀真实用户，这个权衡被明确交还给开发者，而不是像 Turnstile 那样由 Cloudflare 黑盒决定。
三、关键数据
| 维度 | 官方口径 |
|---|---|
| 客户端体积 | 约 20KB（minified gzip），零依赖，约为 hCaptcha 的 1/250 |
| 求解耗时 | 默认多数设备 2–3 秒，极低配约 4 秒，过程静默不阻塞 |
| 规模 | 官方称仅 2026 年 Q1 约 10 亿次质询被解（JSDelivr 口径） |
| 部署 | Docker Standalone + Valkey，单机约 $5 VPS 即可 |
| 生态 | siteverify API 兼容 reCAPTCHA / hCaptcha；Go/Java/Python/PHP/.NET 社区库；可跑 Cloudflare Workers |
| 协议 / 隐私 | Apache-2.0，零遥测、不设 Cookie、不做指纹，数据不出你的服务器 |
| 代表用户 | AdGuard、Bunny.net 在生产环境使用 |
四、评测与口径批判：哪些是真优势，哪些要打折
这一节是不做软文的关键。
- 「与 Turnstile 同一检测档次」是官方自评：agent.md 原话如此，但这是产品方自己的横向定位，没有第三方独立红队报告背书。合理的理解是「架构同源（instrumentation）」，而非「已被独立证明效果等同」。
- 「10 亿次求解」是 JSDelivr 下载口径：它说明 CDN 分发量大，不等于「拦截了多少机器人」，也不等于业务侧的实际拦截率。
- headless 检测不是银弹：官方自己承认——连 Cloudflare Turnstile 都能被打补丁的 stealth 浏览器绕过，Cap 也「不是绝对保证」，它只是抬高门槛、挡住绝大多数现成自动化工具。
- PoW 对低端设备的代价：2–4 秒静默求解在桌面无感，但在老旧手机或被大量标签页占满的设备上仍是 CPU 开销，且 PoW 天然对移动电池不友好。
- 它缺的那一块：官方非常坦诚地说，相比 reCAPTCHA Enterprise，Cap 没有 Google 那张跨网站行为追踪网带来的风控信号。这在银行级、支付处理级的高危反欺诈场景里才有意义——官方估计那只占不到 0.01% 的项目。
五、与同类开源 PoW 方案的差别
很多人会把 Cap 和 ALTCHA、FriendlyCaptcha 混为一谈，因为它们都是开源 PoW。官方给出的关键差异是：
- ALTCHA：纯 PoW，没有 instrumentation 层。面对一整片 GPU 集群，ALTCHA 的 PoW 可以被暴力压过去；Cap 的 instrumentation 层压不过去。
- FriendlyCaptcha：同样是 PoW，但收费（官方称 5000 次请求 + 5 个域名约 39 欧元/月），且不含 instrumentation。
六、优势与局限
优势： 自托管、数据不出服务器，天然贴合 GDPR/CCPA 等合规诉求；约 20KB 加载毫秒级；无图形谜题、对用户隐形；siteverify 兼容 reCAPTCHA/hCaptcha，迁移成本低；无限额、不按请求计费。
局限： 需要自己运维一台验证服务（Docker + Valkey），比起纯前端嵌入第三方脚本还是多一步；没有跨站行为风控，最高危的金融反欺诈不是它的目标市场；抗 headless 是「抬高门槛」而非「绝对挡住」；求解消耗客户端算力。
七、谁该用
如果你想摆脱 Google/Cloudflare 的依赖、对数据不出域有硬要求、又不想给用户出「找红绿灯」的题，Cap 是当前开源圈最成熟的选择之一，尤其适合 SaaS 注册、API 防刷、评论区与隐私敏感站点。如果你是日请求量极大、需要全球行为风控评分的支付平台，再权衡 reCAPTCHA Enterprise——但官方统计这类场景不到万分之一。