尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

2026 年开源 CAPTCHA 选型全景:Cap、ALTCHA、mCAPTCHA 与 Anubis 深度对比

2026 年开源 CAPTCHA 选型全景:Cap、ALTCHA、mCAPTCHA 与 Anubis 深度对比 网络安全应用安全后端【免费下载链接】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点击查看免费下载开源、可自托管的 CAPTCHA 替代方案在 2026 年已经形成清晰的格局以 Cap 为代表的全栈自托管服务以 ALTCHA 为代表的极简 PoW 库以 mCAPTCHA 为代表的先行者以及以 Anubis 为代表的全站反爬虫墙。本文基于 Cap 官方文档docs/fr/guide/open-source-captcha.md展开逐一拆解各选项的许可证、工作机制、架构边界与选型标准并结合 Cap 仓库的真实源码core/src/index.js、standalone/src/siteverify.js 等验证其底层实现帮助你在自建完整服务与只引入一个库之间做出有依据的决定。什么才算真正的开源 CAPTCHA仅仅公开一个客户端 widget 的仓库是不够的。对于反机器人保护来说开源只有在你能审计并亲自运行做出放行/拦截决策的组件时才有意义。一份可审计的开源 CAPTCHA 至少应满足三个条件客户端与服务端代码都以 OSI 许可证发布确保挑战逻辑不是黑盒验证环节可以完全自托管放行或拒绝用户永远不依赖某个厂商 API 的可用性、诚信度或价格没有隐藏的外部数据外发——这一点正因你能读到全部代码而变得可验证。值得注意的是不少商业 CAPTCHA 会把客户端集成代码开源却把服务端验证引擎保持闭源FriendlyCaptcha 就是典型例子。这种形态只能算开源化的集成层而不是开源 CAPTCHA决策引擎仍然是一个你付费租用的黑盒。这一判定标准也解释了为什么下面的对比清单只包含 Cap、ALTCHA、mCAPTCHA 与 Anubis 四个真正端到端可审计的项目。为什么要把 CAPTCHA 自托管自托管不是一种偏执而是一系列可量化的收益官方文档在 compliance 一节给出了完整论证隐私可证明访客数据永远不会到达第三方厂商这大幅简化了 GDPR、CCPA 等合规应答——Cap 的设计目标是访客数据不离开你的基础设施无 Cookie、无追踪、验证链路无第三方调用无配额、无按请求计费流量高峰和 bot 洪峰不会变成账单无厂商风险不会有突然的涨价、产品停摆或并购导致的平台变更控制权在手你可以按站点密钥site key独立设置挑战难度而不是把用户交给某个远端模型的判定高可用第三方接入点宕机时你的表单不会跟着挂掉。在成本侧官方文档 FAQ 给出的结论是Cap 用Docker 容器 Valkey即可运行一台 5 美元档位的 VPS 就足够约五分钟可以完成部署。四大开源选项逐个拆解Cap全栈自托管 CAPTCHAApache 2.0Cap 是本文对比中的完整栈方案许可证为 Apache 2.0客户端与服务端一致。它的组成在官方文档 standalone/index.md 中有完整描述widget约 20 KB 的 Web Component零运行时依赖只需引入一个script即可使用Cap Standalone一个 Docker 容器Bun 运行时空闲内存约 50 MB加一个 Valkey/Redis 实例对外暴露 REST APIWeb 管理面板支持多站点密钥管理、按密钥配置难度与协议、查看分析数据/siteverify端点API 形态与 reCAPTCHA 的 siteverify 兼容迁移成本被压缩到改一个 URL。其防护机制是两条相互独立、并行运行的验证层HashWX 工作量证明默认协议与 SHA-256 这类固定哈希函数不同HashWX 每次挑战都会从一个种子派生出一个全新的单向函数其指令集仅使用 WebAssembly 1.0 支持的操作64 位乘法、加减、XOR、OR、旋转与移位配合 16 KB 非对齐访问的 scratchpad 和 256 次分支把 GPU 相对 CPU 的优势从约 150 倍压缩到约 2 倍。官方在 hashwx.md 中给出的实测数据tevador 提供为算法CPURyzen 3700X16 线程GPURTX 5060 TiGPU 优势SHA-25641 MH/s6150 MH/s~150xRSW26 H/s4400 H/s~170xHashWX2.8 MH/s5.8 MH/s~2x在浏览器端HashWX 通过 WASM 运行约 60% 原生速度服务端验证单次挑战仅需约 40 µsApple M3 单核实测详见 hashwx.md。其子挑战拆分机制默认 4 个用于把指数分布的求解时间拉平同样难度下p90 约降低四分之一。需要留意的是不支持 WebAssembly 的客户端无法求解 HashWX这类场景官方建议退回到带纯 JS 兜底的 SHA-256 PoW。动态 instrumentation 挑战服务端为每一次请求生成一段独一无二的 JavaScript 程序在访客浏览器 iframe 内执行探测真实渲染引擎才具备的 DOM 行为构建元素树、经布局引擎读值、再拆除并把计算结果经postMessage回传由服务端对照预期值验证。当开启blockAutomatedBrowsers后脚本还会收集文本度量、窗口几何、navigator.webdriver等向量交由服务端检测拦截时返回reason: instr_automated_browser并附blockedBy数组检测项清单见 instrumentation.md 的七项检查表。击败一层不等于击败另一层工作量证明证明的是付出了算力instrumentation 证明的是发生在真实浏览器环境中两者在两条独立轴线上抬高滥用成本。源码印证挑战生成与验证的真实调用链Cap 的挑战与验证逻辑集中在 core/src/index.jsgenerateChallenge(secret, opts)L108默认生成c50个子挑战、s32位十六进制盐、d4位前缀难度挑战 TTL 默认 10 分钟DEFAULT_CHALLENGE_TTL_MS 10 * 60 * 1000L81令牌经 JWT 签名secret必须至少 16 字节assertSecretL88validateChallengeL177依次检查 scope 匹配、过期、解长度与数值类型逐个子挑战验证 PoW 前缀命中再验证 instrumentation 结果最后才调用consumeNonce回调做防重放——顺序保证攻击者用垃圾解重放不能烧掉合法用户的 nonceL262-L273format-2 协议generateChallengeV2支持在同一响应中混合sha256-pow、hashwx、rsw、instrumentation多种协议其中 HashWX 无需任何密钥材料首次验证时编译内置 WASM 模块仅需几毫秒可用hashwxReady()预热。服务端的/siteverify实现位于 standalone/src/siteverify.js校验 secret 与 site key 后用GETDEL原子地取出并删除一次性令牌L51-L52天然实现单次使用令牌过期返回 403。这也印证了官方文档强调的两点secret key 不是管理面板的 ADMIN_KEY这是最常见的配置错误同一令牌验证两次必然失败可用作集成自检。自托管部署的最小配置Cap Standalone 推荐以 Docker Compose 运行完整示例见官方 快速入门services: cap: image: tiago2/cap:latest container_name: cap ports: - 3000:3000 environment: ADMIN_KEY: your_secret_password # 管理面板登录口令建议至少 32 字符 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。前端引入 widget 并指向实例script srchttps://cdn.jsdelivr.net/npm/cap-widgetversion/script form action/submit methodPOST !-- 你的表单字段 -- cap-widget>curl https://your-instance/site-key/siteverify \ -X POST \ -H Content-Type: application/json \ -d { secret: key_secret, response: captcha_token }合法令牌返回{ success: true }。关键运行参数汇总详见 standalone/options.md配置项默认值说明REDIS_URLredis://localhost:6379全部数据存储于 Redis/ValkeyREDIS_PREFIX可做键命名空间CORS_ORIGIN*挑战生成与兑换接口的跨域白名单可逗号分隔多个来源ENABLE_ASSETS_SERVERfalse是否自托管 widget/WASM 静态资源配合WIDGET_VERSION、WASM_VERSION限流每 IP 每 5 秒 30 次面板/PUT /settings/ratelimit可调/siteverify默认不限流HashWX 难度1_000_000客户端期望哈希数拆分为 4 个子挑战合法范围50_000–5_000_000若不想部署容器capjs-core 无状态库如果你更愿意把挑战逻辑嵌进自己的服务而不是部署独立容器Cap 提供了无状态服务端库capjs-corecapjs-core.mdgenerateChallenge/validateChallenge两个函数即可生成并验证基于 JWT 的挑战不触碰文件系统天然适合 Cloudflare Workers、Lambda 等边缘环境防重放通过可选的consumeNonce回调接入你自己的 KV/数据库实现。其默认参数与源码实现一致50 个子挑战、10 分钟挑战 TTL、20 分钟兑换令牌 TTL见 core/src/index.js。ALTCHA极简 PoW 库MITALTCHA 是与 Cap 精神最接近的项目开源、纯工作量证明、无指纹识别、无第三方依赖。区别在于形态——它只是一个轻量 widget约 34 KB gzip后端需要你自己搭建开源版本没有管理面板、没有 standalone 服务器其机器学习式的第二层检测属于付费产品ALTCHA Sentinel。许可证MITwidget机制工作量证明适合想要一个小型库、愿意自己写服务端验证逻辑的开发者mCAPTCHAPoW 先行者但成熟度存疑mCAPTCHA 是最早实践可调难度 PoW想法的项目之一完全开源核心为 AGPL-3.0客户端库为宽松许可。但它的状态需要审慎评估仍处于 pre-1.0 阶段发布节奏缓慢widget 体积比 Cap 与 ALTCHA 都大。官方文档的建议是值得研究但在其上构建之前要掂量它的成熟度。Anubis全站反爬虫墙MITAnubis 解决的是另一个问题在反向代理层用 PoW 墙保护整个站点或某个路径主要针对 AI 抓取机器人与激进的爬虫。它不是表单级 CAPTCHA也不提供独立的验证服务器。它更关心的是每个访客在加载任何页面之前先解决一个小挑战而 Cap 关心的是某个具体动作表单提交、API 调用、注册之前要求成本。两者可以共存Anubis 挡在站点前面防爬虫Cap 放在站点内部的高价值表单与 API 上互不冲突。四者并排对比下表完整继承官方文档的对比矩阵CapALTCHAmCAPTCHAAnubis许可证Apache 2.0MITwidgetAGPLMIT积极维护✅✅ pre-1.0发布慢✅机制PoW instrumentationPoWPoWPoW防护粒度按动作表单、API按动作按动作整个站点Standalone 服务器与管理面板✅❌✅❌reCAPTCHA 兼容 siteverify✅❌❌❌widget 体积~20 KB~34 KB更重不适用透明GPU 抗性 PoW 选项✅ HashWX❌❌❌矩阵中GPU 抗性一行是 Cap 的显著差异化点HashWX 把 GPU 优势压到约 2 倍而其余三者均为固定哈希类 PoWGPU 吞吐优势通常在百倍量级。如何选择一张决策路线图官方文档给出的选型逻辑可以压缩为四条路径想要部署一次、面板管理的完整服务选Cap。五分钟起步Docker Valkey 单容器详见快速入门想要最轻的依赖、且愿意自己承担后端接线选 Cap 的无状态库capjs-corecapjs-core.md或ALTCHA对抗的是全站爬虫而非表单垃圾选Anubis可在其后的高价值表单上再叠加 Cap正在离开 reCAPTCHA / hCaptchaCap 的兼容 siteverify 把迁移简化为一次 URL 替换官方提供了专门的迁移指南。若你完全不愿运行任何基础设施则 Cap 并不适合——官方文档明确承认这一条 Cap 故意不满足没有托管服务此时 Turnstile 或 FriendlyCaptcha 更合适完整 12 项指标矩阵见功能对比页。FAQ官方文档给出的常见问题结论哪个开源 CAPTCHA 最好官方文档的结论是分场景的想要完整栈双验证层 管理面板 兼容 siteverify选 Cap只想要最小化库选 ALTCHA。开源 CAPTCHA 能自托管吗能而且比想象中简单。Cap 用 Docker 容器 Valkey 运行5 美元级 VPS 即可承载约五分钟完成部署。Cap 免费吗完全免费。Apache 2.0无配额、无付费档无论流量多大。Cap 比 ALTCHA 好吗官方文档的表述是Cap 提供得更多ALTCHA 提供得更少且是有意为之Cap 多出 instrumentation 层、standalone 服务器、管理面板、进度回显和更轻的 widget选择取决于你打算自己构建多少。开源 CAPTCHA 保护隐私吗它把隐私从承诺变成可验证的事实自托管的 PoW 不需要指纹识别、不需要行为画像、不需要第三方调用且代码开卷可查。延伸阅读2026 年最佳 CAPTCHA 替代方案含闭源阵营Cap 功能对比总表Cap 工作原理架构详解Cap 与 ALTCHA 专项对比Cap 与 Anubis 专项对比在线演示直接在浏览器里试跑 widget赞分享网络安全应用安全后端【免费下载链接】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点击查看免费下载相关推荐2026 年开源 CAPTCHA 方案横向对比Cap、ALTCHA、mCAPTCHA 与 Anubis 怎么选2026 年开源 CAPTCHA 方案横向对比Cap、ALTCHA、mCAPTCHA 与 Anubis 怎么选 导读 本文基于 Cap 项目官方指南《Die网络安全应用安全后端Cap vs Altcha开源自托管 PoW CAPTCHA 的全面对比与选型指南Cap vs Altcha开源自托管 PoW CAPTCHA 的全面对比与选型指南 Cap 与 Altcha 是当前开源、自托管 CAPTCHA 领域气质最接网络安全应用安全后端Cap 开源 CAPTCHA 全景对比Cap vs. reCAPTCHA、Turnstile、hCaptcha、Altcha 与 12 项能力评估矩阵Cap 开源 CAPTCHA 全景对比Cap vs. reCAPTCHA、Turnstile、hCaptcha、Altcha 与 12 项能力评估矩阵 Cap网络安全应用安全后端上一篇掌握CubiFS日志配置轻松调试分布式文件系统的终极指南下一篇Google Sheets数据清洗自动化gspread与Pandas结合最佳实践创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表