网络安全应用安全后端【免费下载链接】capFree, open-source and self-hosted CAPTCHA alternative to reCAPTCHA. Privacy-first and powered by proof-of-work and instrumentation challenges.项目地址https://gitcode.com/gh_mirrors/cap13/cap点击查看免费下载Cap 是免费、开源、可自托管的 reCAPTCHA 替代方案Anubis 则是流行于自托管社区的 Proof-of-Work Scraper 威慑工具。两者共享 Proof-of-Work 内核却解决完全不同的问题Anubis 在反向代理层为整站或路径竖一道 PoW 墙拦截 AI 训练爬虫与激进抓取Cap 则把验证放在具体动作上表单提交、登录、API 调用、账号创建让普通浏览保持畅通。读完本文你将掌握两种方案各自的适用场景、共存的组合架构以及 Cap 在每动作保护每动作难度双层验证独立服务器与仪表盘上的源码级实现依据。快速结论什么时候选谁选 Anubis当你需要在反向代理层把整站或某个路径对机器人和爬虫封锁时通常是爬虫正在消耗你的带宽。Anubis 的威胁模型是边缘的批量抓取或机器人驱动的请求洪泛并且你愿意接受每个访客在每次页面加载前都要解一道小 Challenge。选 Cap当你要保护一个特定动作——表单提交、API 调用、账号创建——并希望正常浏览不受打扰时。原文档的判据可以压缩为三句话Anubis 是围墙Cap 是门禁一个管整站流量一个管关键操作。场景一什么时候 Anubis 有意义你要在整站或子路径前放一道 PoW 墙威胁模型是边缘的大规模抓取或机器人驱动的请求洪泛你接受每个访客在任意页面加载前都要解一道小型 Challenge。这正是 Anubis 的定位它不区分人类正常浏览与机器人批量抓取的成本差异而是用统一的小难度 Challenge 抬高每一次请求的机器成本让爬虫的每小时吞吐量变得无利可图。场景二为什么 Cap 在表单与登录场景是更好的选择原文档给出四组核心论据每一组在仓库中都有对应的实现支撑按动作保护而非按页面访问Cap 保护的是表单、注册页、联系页与 API 端点——也就是滥用真正转化为成本的地方访客浏览页面时完全不受干扰。这种动作级粒度体现在整个架构中Standalone 的 API 按 Site-Key 组织参见 siteverify 路由实现每个 Key 独立配置难度与限额验证发生在提交动作的那一刻。难度按动作配置Anubis 的 Challenge 必须足够小以免拖慢每一次页面加载这限制了它能把难度调多高。Cap 按动作配置难度因此可以在注册或登录表单上把难度调得更高而不影响浏览体验。这一点与仓库中难度是每动作、每 Site-Key 的设计一致Standalone 在仪表盘中按 Key 设置难度参见 Standalone 选项文档HashWX 的难度参数hashwxDifficulty取值范围为 [1, 1_000_000_000]并可通过拆分为多个子 Challenge默认 4 个上限 64 个来平滑人类用户的等待时间参见 core/src/hashwx.js。双层验证Instrumentation 叠加在 PoW 之上Cap 把 Instrumentation-Challenges 叠加在 Proof-of-Work 之上即使机器人用 GPU 加速了 PoW 步骤仍然必须伪造一个真实浏览器环境。这是 Cap 与 Anubis纯 PoW 方案最关键的分野之一。从源码看Instrumentation 的实现位于 core/src/instrumentation.js其要点包括服务端生成唯一 JS 程序generateInstrumentation每次生成 32 字节随机 ID、4 个随机变量与随机初始化值再通过约 20 轮随机化的整数运算位运算 AND/OR/XOR/NAND、原型链技巧构造的辅助函数、以及 DOM 算术构建计算链服务端同步跟踪每个操作的期望结果core/src/instrumentation.jsDOM 操作不可廉价伪造挑战代码会向页面挂载真实元素树、向上遍历读取值并移除。文档明确指出纯算术可在非浏览器环境中直接执行 JS 复现而 DOM 操作依赖浏览器的布局引擎非浏览器运行时通常只提供 stub、实现错误或出于性能考虑直接省略因此离开真实渲染引擎后极难复现Iframe postMessage 回传所有检查在 Iframe 中运行通过postMessage将结果送回父窗口对应buildClientScript中parent.postMessage({type: cap:instr, ...}, *)的回传路径见 core/src/instrumentation.js可选自动化浏览器检测启用blockAutomatedBrowsers后会采样执行针对 Selenium、Puppeteer、PhantomJS、WebDriver、CefSharp、Nightmare 等标记的哈希比对检查标记列表见 core/src/instrumentation.js并在服务端通过detectAutomation复核core/src/instrumentation.js。文档也给出了诚实的边界这些检测并非万无一失——即使是 Turnstile 这类商业闭源 CAPTCHA 也能被带补丁的 stealth 浏览器绕过Instrumentation 证明的是环境计算发生在浏览器内PoW 证明的是成本客户端烧掉了 CPU 周期两者互补而非冗余同时击破两者远比击破其一困难。独立服务器与仪表盘Cap 自带开箱即用的独立服务器分析统计、多 Site-Key 管理、以及兼容 reCAPTCHA 的siteverify端点。Standalone 部署在 Docker一个容器 Valkey并在仪表盘中管理密钥/siteverify端点接受与 reCAPTCHA 相同的请求形态——POST携带{ secret, response }成功后返回{ success: true }参见 siteverify 路由实现 与 Standalone 使用文档。Widget UXCap 被设计为在表单上对人类可见复选框、进度指示器和品牌展示区。widget 端通过progress事件驱动进度条从 0 推进到 100参见 widget/src/src/cap.js 中的dispatchEvent(progress, ...)调用。Anubis 则是透明的门——用户几乎看不到它也就没有这类交互面。两者可以共存如果 Anubis 已经作为爬虫防护跑在网站前面你仍可以在这个网站内部的高价值表单与 API 端点上使用 Cap。两者解决的问题不同互不冲突——这正是 Open-Source-CAPTCHA 对比文档 中推荐的组合Anubis 管全站 ScraperCap 管表单垃圾。这也符合文档对四者Cap、ALTCHA、mCAPTCHA、Anubis的定位总结Anubis 是整站作用域、无独立验证服务器、默认低难度Cap 是每动作作用域、带 Standalone 服务器与仪表盘、支持 reCAPTCHA 兼容的 siteverify并默认使用 GPU 抗性更强的 HashWX-Proof-of-WorkSHA-256 的 GPU 优势约为 150 倍而 HashWX 约 2 倍见 HashWX 文档 中的实测对比表。部署速览把 Cap 架起来验证结论要验证上述差异最快的路径是跑一个 Standalone 实例详见 Standalone 安装文档services: cap: image: tiago2/cap:latest container_name: cap ports: - 3000:3000 environment: ADMIN_KEY: your_secret_password REDIS_URL: redis://valkey:6379 depends_on: valkey: condition: service_healthy restart: unless-stopped valkey: image: valkey/valkey:9-alpine container_name: cap-valkey volumes: - valkey-data:/data command: valkey-server --save 60 1 --loglevel warning --maxmemory-policy noeviction healthcheck: test: [CMD, valkey-cli, ping] interval: 5s timeout: 3s retries: 5 restart: unless-stopped volumes: valkey-data:docker compose up -d打开http://localhost:3000用ADMIN_KEY登录创建 Site-Key 并记下 Site-Key 与其 Secret-Key新 Key 默认启用 Instrumentation-Challenges。前端接入时把 Widget 指向你的实例cap-widget>curl https://instance_url/site_key/siteverify \ -X POST \ -H Content-Type: application/json \ -d { secret: key_secret, response: captcha_token }成功响应为{ success: true }Standalone 使用文档。至此你在同一台机器上同时拥有了透明整站 PoW 墙Anubis与表单级双重验证门禁Cap两套方案可以按真实流量形态取舍。决策清单判据AnubisCap作用域整站或子路径反向代理层单个动作表单、注册、API 端点威胁模型批量抓取、边缘请求洪泛表单滥用、账号创建、API 滥用对正常浏览的影响每页加载前需解小 Challenge无影响仅动作触发难度上限受不能拖慢页面限制按动作/Key 独立配置可调高验证层数PoWPoW Instrumentation 双层独立服务器与仪表盘无有分析、多 Key 管理、siteverify用户可见性透明门复选框 进度条 品牌区延伸阅读Live-Demo在浏览器中直接试用 CapCap 如何识别机器人Proof-of-Work 加 Instrumentation 的原理全部替代方案对比完整功能矩阵开源 CAPTCHA 选项Cap、ALTCHA、mCAPTCHA 与 Anubis 的横向比较HashWX-Proof-of-WorkGPU 抗性 PoW 的协议细节与实测数据赞分享网络安全应用安全后端【免费下载链接】capFree, open-source and self-hosted CAPTCHA alternative to reCAPTCHA. Privacy-first and powered by proof-of-work and instrumentation challenges.项目地址https://gitcode.com/gh_mirrors/cap13/cap点击查看免费下载相关推荐Cap vs Anubis自托管 PoW 验证码与全站爬虫墙的选型与实践指南Cap vs Anubis自托管 PoW 验证码与全站爬虫墙的选型与实践指南 Cap 与 Anubis 都建立在 proof of work工作量证明之上网络安全应用安全后端Cap 与 Altcha 全面对比开源自托管 Proof-of-Work CAPTCHA 的选型指南Cap 与 Altcha 全面对比开源自托管 Proof of Work CAPTCHA 的选型指南 Altcha 是当前开源生态里与 Cap 理念最接近的网络安全应用安全后端Cap vs Anubis自托管验证码与全站反爬 PoW 墙的定位对比与选型指南Cap vs Anubis自托管验证码与全站反爬 PoW 墙的定位对比与选型指南 Anubis 是一个在自托管社区中流行的基于工作量证明proof of w网络安全应用安全后端创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
