网络安全应用安全后端【免费下载链接】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 是一个免费、开源、可自托管的 CAPTCHA 替代方案用工作量证明proof-of-work与 instrumentation 挑战取代传统视觉验证码主打隐私优先、轻量快速与极简集成。本文以仓库 README.md 为骨架结合 工作原理、HashWX、instrumentation 与 Standalone 配置 等官方文档及源码系统讲解 Cap 的定位、双防线技术原理、五分钟左右的自托管部署流程以及服务端配置与无状态核心库的实战用法。读完本文你将能够独立部署一套 Cap Standalone 实例完成前端 widget 接入与后端 token 校验并理解如何按业务场景调优难度、检测与限流策略。Cap 是什么根据 README 的官方定义Cap 是一款轻量级、现代化的开源 CAPTCHA 替代方案核心由两类挑战组成Proof-of-Work工作量证明让访问者的浏览器在后台完成真实计算如 SHA-256 哈希以计算成本抑制自动化滥用Instrumentation challenges插桩挑战每次请求动态生成一段 JavaScript在真实浏览器环境中执行并回传结果用于验证对面是一个真实浏览器环境。它替代的是 reCAPTCHA、hCaptcha、Cloudflare Turnstile 这类商业验证码服务特点可以概括为四个词快速fast、私密private、集成极简simple to integrate。与传统验证码不同Cap 不包含图片、不做用户追踪、无第三方依赖并且默认支持在任意环境运行。生态组成从仓库结构见 core 核心库、widget 组件、standalone 服务端可以看出Cap 由三个可独立使用的部分组成组件作用仓库位置capjs-core无状态的服务端库生成与校验 JWT 签名挑战可部署到边缘函数core/src/index.jscap-widget浏览器端 Web Component负责渲染复选框、执行 PoW 与 instrumentationwidget/src/src/cap.jsCap Standalone一站式自托管服务端Docker 容器 REST API 管理面板 多站点密钥standalone/src/index.js官方文档明确推荐大多数用户直接使用 Standalone Docker 容器见 快速上手指南只有当你无法运行 Docker、想把挑战生成嵌入现有服务、或需要部署到无持久存储的边缘环境Cloudflare Workers、Lambda时才直接使用 capjs-core 库。为什么选择 Cap七大核心特性README 的 Why Cap 一节给出了官方定位下的七项核心优势下面逐条展开并结合仓库证据说明其含义。1. 体积比 hCaptcha 小约 250 倍官方声明Cap 的 widget 约20KB、零依赖、毫秒级加载对比 hCaptcha 的体量缩小约 250 倍。从仓库看widget 的构建产物 cap.min.js 与 cap.compat.min.js 正是面向生产环境的压缩包通过单行script标签即可引入不依赖任何第三方框架。2. 隐私优先Privacy-firstCap不向官方服务器发送任何遥测数据。由于是自托管架构挑战生成、校验、数据存储全部发生在你自己的基础设施上。官方 有效性说明 进一步指出Cap 默认不使用 cookie、不启用任何遥测完全自托管意味着中央服务器上不采集、不存储任何用户数据同时内置重放保护replay protection与基于签名的挑战 token。3. 完全可定制Fully customizablewidget 支持通过 CSS 变量改变颜色、尺寸、位置、图标等外观。可参考 widget 文档 了解全部自定义选项也可以在 Standalone 选项文档 中看到服务端行为级配置CORS、限流、资产服务器、HashWX 难度等。4. 工作量证明Proof-of-Work用户不再需要浪费时间解决视觉谜题。挑战在浏览器后台静默完成用户只需点击一次复选框甚至无需交互见下一条。5. Standalone 自托管模式用单个 Docker 容器即可在任何地方运行完整的 Cap 后端内置分析与仪表盘、多站点密钥管理、与 reCAPTCHA 兼容的 siteverify API。具体能力详见下文部署与配置章节。6. 无需用户交互可以隐藏 widget 界面让挑战在后台静默完成对正常用户完全无感。官方文档提供了编程式调用programmatic与悬浮模式floating两种高级用法。7. 开源Open-source项目以Apache-2.0协议开源见 LICENSE完全免费。版权信息见 LICENSE 文件。核心技术原理双防线架构README 的一句话概括是proof-of-work instrumentation challenges但正如 工作原理 文档强调的Cap 运行的其实是两条独立防线缺一不可。理解这一点是正确调优的前提。完整挑战流程官方文档给出的九步流程如下Cap 初始化时浏览器自动注册 widget 对应的自定义元素custom elementwidget 创建 shadow DOM 并挂载所需元素请求挑战时widget 向服务器发送请求服务器返回token、挑战配置以及可选的压缩后的 instrumentation 数据widget 用挑战 token 作为种子seed结合服务器下发的配置生成多个挑战若带有 instrumentation 数据则解压后在沙箱 iframe 中执行widget 通过 Rust 编译的 WASM 与 Web Worker并行求解每个 worker 反复尝试——把 salt 与不同的 nonce 组合、计算 SHA-256 哈希、检查结果哈希是否以目标前缀开头直到找到匹配的 nonce若存在 instrumentation 挑战则解压并执行找到有效解后widget 将结果回传服务器校验服务器用相同 token 与配置自行生成同样的挑战核对 widget 提交的解校验成功后服务器兑换redeem该解并签发一个可用于鉴权的 token。为什么引入 Instrumentation 作为第二防线instrumentation 文档 给出了清晰的定位Proof-of-Work 证明的是付出过计算代价Instrumentation 证明的是在真实浏览器环境中完成计算两者从两个独立维度抬高滥用成本缺一不可。instrumentation 挑战的机制是服务器为每个请求生成一段自包含self-contained的 JavaScript包含浏览器 API 探针与一条主计算链——多个整数变量以随机种子初始化然后经过随机化的运算按位 AND/OR/XOR/NAND、原型链技巧、基于 DOM 的算术持续变异。其中 DOM 算术会在页面中追加一棵元素树、沿树回走累积值、再将其移除。服务器在生成脚本的同时并行追踪每个操作的期望结果因此它预先知道最终四个值应当是什么。所有检查在 iframe 内运行通过postMessage把答案回传给父页面。为什么要用 DOM 操作纯算术可以在无浏览器环境里直接执行 JS 复现而 DOM 操作不能——构造真实元素树、经浏览器布局引擎读取值、再拆除这一过程触及了非浏览器运行时通常被 stub 掉、实现错误或为性能而跳过的那部分能力因此很难在真实渲染引擎之外低成本重放。自动化浏览器检测可选当开启blockAutomatedBrowsers时instrumentation 脚本还会收集一组浏览器事实向量文本度量、窗口几何、navigator.webdriver、引擎标记随计算结果回传由服务器端检测器对向量做判断——客户端自身的结论不被信任因为隐身补丁可以改掉客户端检查。官方文档给出七项可能导致请求失败的检查全部针对自动化层或篡改不针对浏览器版本检查捕获对象为何对真人安全geometry_quantizedCamoufox 把文本宽度吸附为整像素真实 Blink/Gecko/WebKit 返回小数宽度需至少 5/17 个字体栈为整像素且至少 2 个不同整数值单一字体系统不会误伤webdriver_true裸 Selenium、Playwright、Puppeteer、rebrowser规范定义的自动化标志任何发行版浏览器都不会设置webdriver_stripped删除navigator.webdriver的隐身补丁真实 Chrome 总是暴露falsegecko_contradiction在 Gecko 引擎上伪造navigator.deviceMemory或userAgentDataFirefox 从未提供这两个 APIwindow_exceeds_screenCDPEmulation.setDeviceMetricsOverride使窗口高于屏幕screen.isExtended为 true 时跳过更高的第二显示器可通过viewport_override视口与屏幕完全相等但浏览器 chrome 存在移动端全屏视口属正常跳过headless_tokenUA 或userAgentData.brands中的HeadlessChrome无消费者浏览器会暴露它另有两个信号只采集、不拦截native_tampercanvas/WebGL/权限方法的Function.prototype.toString不再是[native code]可捕获 puppeteer-stealth 等但隐私插件同样会改写故仅作为风险标记供提高 PoW 难度与浏览器表面聚类无window.chrome、无插件、无 PDF 阅读器——移动 Chrome 与 Android WebView 会合法命中故完全不使用。被拦截时validateChallenge返回reason: instr_automated_browser并附blockedBy数组列出命中的检查校验通过则携带riskFlagsStandalone 面板上对应展示为automated_browser_detected。官方也诚实列出了已知缺口undetected-chromedriver、nodriver驱动有头 Chrome 能通过全部七项检查无头 Firefox 也能通过——因此PoW 仍是让此类流量变贵的兜底层。HashWXGPU 抗性工作量证明新站点的默认挑战协议是HashWX详见 HashWX 文档。它的核心思想不再使用固定的 SHA-256 哈希函数而是每次挑战都从种子生成一个全新的单向函数由整数运算与分支构成让 GPU 无法比 CPU 快太多。为什么需要 GPU 抗性瓶颈在于吞吐量攻击者不在乎单个挑战耗时多久只在乎每小时能清掉多少个挑战。官方给出的对比数据CPU 为 Ryzen 3700X 16 线程GPU 为 RTX 5060 Ti算法CPU 吞吐GPU 吞吐GPU 优势SHA-25641 MH/s6150 MH/s~150xRSW26 H/s4400 H/s~170xHashWX2.8 MH/s5.8 MH/s~2xCap 之前的 RSW 时间锁谜题在单谜题延迟上有优势顺序平方无法并行但吞吐量惨败HashWX 把 GPU 优势压到了约 2 倍。RSW 已弃用旧密钥仍可选择且继续工作但不建议新部署使用。协议要点铸造Mint服务器随机取 32 字节作为挑战C与难度d无密钥材料、无预计算一次随机读取加一次 JWT 签名即可客户端求解寻找 64 位 nonceN使H(N) (2^64 - 1) / d其中H hashwx_make(sha256(C || u64le(N / n)))。每n个连续 nonce 共享一个生成的哈希函数。Cap 取n 65536参考协议原生端用 463但浏览器需为每个 block 通过WebAssembly.Module做 JIT 编译更大的 block 可摊薄该开销GPU 抗性的四个来源每个实例含 32 个程序、每个循环以 1/2 概率分支回自身起点共 256 个分支/哈希GPU 上撕裂 warp16KB 未对齐加载的 scratchpadGPU 需本地内存 L2 约 100 周期交错浅/深寄存器源列表CPU 平均 2.75 个依赖加载GPU 解释器几乎总要吃满 6 个依赖加载链指令集仅限 WebAssembly 1.0 的 64 位乘/加/减/XOR/OR/移位这也是它能在浏览器中运行的前提服务器校验按 nonce 隐含的 block 索引从C重算种子生成该哈希函数、运行一次、与目标比较。程序生成比 HashX 便宜约 5 倍校验耗时在几十微秒量级。成本与体验的权衡数据官方在 Apple M3 单核上实测的服务器成本经validateChallenge测量中位数单个 HashWX 挑战铸造 14µs、校验 40µs默认 4 个子挑战共约 149µs——比 SHA-256 贵但仅为 RSW1536µs的十分之一且难度不影响校验成本校验就是每个子挑战一次哈希。默认把难度拆成4 个子挑战是为了抹平求解时间的彩票效应单挑战的求解时间指数分布同一难度有人 30ms 有人 3 秒。官方实测release Chrome、M3 8 核、各 72 次求解单挑战d1,330,000中位数 536ms / p90 1447ms4 子挑战d1,000,000中位数 490ms / p90 778ms。拆分不改变攻击者的总期望工作量期望仍是d次哈希只是把典型求解时间的中位数推到均值的约 0.92、显著缩短长尾。浏览器引擎方面单 worker 下 Chrome/Firefox/Safari 相差约 5%8 worker 时 Safari 约为 Chrome 的 70%因此调难度要按 Safari 校准。手机端官方 BrowserStack 实测Galaxy S24 中位数 1.1s 到 Vivo Y21 的 5.9s 不等若流量以移动端为主应下调难度求解时间随难度线性变化500,000 大约把求解部分减半。无 WebAssembly 的客户端完全无法求解 HashWX需要支持时请为该站点改用带纯 JS 回退的 SHA-256iOS 上的 widget 需 iOS 15 及以上。五分钟快速上手从部署到校验官方 快速上手指南 给出了完整的集成路径约五分钟即可跑通。核心是两部分widget跑挑战、显示复选框server签发挑战、校验解。1. 运行服务器Standalone推荐使用 Cap Standalone 单容器。创建docker-compose.ymlservices: 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与secret key两把都要保存。要点ADMIN_KEY是面板密码建议至少 32 字符端口冲突就改3000:3000面板不可达时可给cap服务加network_mode: host。2. 添加 widgetwidget 是一个单文件 Web Component一行脚本引入script srchttps://cdn.jsdelivr.net/npm/cap-widgetversion/script表单内最简单的用法widget 在form内时Cap 自动注入隐藏的cap-token字段随表单提交无需写任何 JavaScriptform action/submit methodPOST !-- your fields -- cap-widget>const widget document.querySelector(cap-widget); widget.addEventListener(solve, (e) { const token e.detail.token; // 把 token 发给你的后端、启用提交按钮等 });React、Vue、Svelte 等框架片段见 widget 文档隐藏式编程调用见 programmatic悬浮模式见 floating。3. 后端校验 token向实例的/siteverify端点发POSTcurl / fetch / Python / PHP 写法在快速上手指南中都有完整示例curl https://your-instance/site-key/siteverify \ -X POST \ -H Content-Type: application/json \ -d { secret: key_secret, response: captcha_token }key_secret是面板里的secret key不是面板密码ADMIN_KEY——混用是最常见的配置错误captcha_token是 widget 产生的 token表单字段cap-token或e.detail.token。有效 token 返回{ success: true }token 一次性使用每次只校验一次然后执行你自己的业务逻辑。4. 端到端自检加载页面复选框应自动勾选solve处理器或表单字段产出 token把 token 发给/siteverify得到{ success: true }再发一次同一个 token应当失败——这确认一次性机制生效。若校验总是失败检查是否用了 secret key而非 ADMIN_KEY以及your-instance是否与 widget 指向的地址一致。reCAPTCHA 兼容迁移官方特别说明Cap 的/siteverify与 reCAPTCHA 的 API 兼容你可以只改一个 URL 把现有校验代码指向 Cap两者并行运行、择机切换无需重写、没有大爆炸式迁移风险详见 alternatives 对比。Standalone 服务端配置深入官方 Standalone 选项文档 是生产化部署的核心参考以下按主题整理关键配置。CORS通过环境变量CORS_ORIGIN控制挑战签发与兑换的跨域策略默认*多个来源用逗号分隔如domain1.tld,domain2.tld。资产服务器Asset server默认关闭设ENABLE_ASSETS_SERVERtrue后由/assets端点提供静态文件。需配套设置WIDGET_VERSION与WASM_VERSION默认latest官方不建议生产环境用可能携带破坏性变更可用版本为cap.js/widget与cap.js/wasm的 npm 发布版。示例ENABLE_ASSETS_SERVERtrue WIDGET_VERSION0.1.58 WASM_VERSION0.0.8随后即可通过以下路径引用/assets/widget.js、/assets/floating.js、/assets/cap_wasm_bg.wasm、/assets/hashwx.wasm、/assets/cap_wasm.js并配合window.CAP_CUSTOM_WASM_URL与window.CAP_CUSTOM_HASHWX_URL指向自托管 WASM。注意hashwx.wasm随cap.js/wasm0.0.8 起提供旧版本下/assets/hashwx.wasm会返回 503此时应让 widget 从 jsdelivr 加载。资产默认从process.env.CACHE_HOST默认https://cdn.jsdelivr.net拉取并缓存进 Redis、每小时刷新若端点返回Asset not cached yet请检查ENABLE_ASSETS_SERVER是否真正生效改过 compose 需重建容器、容器能否访问CACHE_HOST、版本号是否真实存在于 npm。限流Rate-limiting挑战端点按客户端 IP 固定窗口限流默认每 5 秒 30 次请求。全局限制可在面板Settings中调整或PUT /settings/ratelimit也可在单个站点的Configuration页覆盖。超限返回429与X-RateLimit-Remaining: 0头。/siteverify是服务端对服务端的接口默认不限流。客户端 IP 识别顺序为X-Forwarded-For、X-Real-IP、CF-Connecting-IP最后回退 socket 地址反代使用其他头时设RATELIMIT_IP_HEADERCloudflare 场景可设cf-connecting-ip。务必让反代真的转发客户端 IPnginx 示例见选项文档否则所有请求共享同一 IP 桶同时由于X-Forwarded-For被信任原样服务器绝不能直接暴露在公网否则客户端可伪造头绕过限流。Redis / Valkey所有数据都存 Redis或兼容的 Valkey通过REDIS_URL配置默认redis://localhost:6379。多实例共用同一 Redis 时用REDIS_PREFIX命名空间隔离如cap:前缀默认空不影响存量部署。健康检查与优雅关闭GET /healthRedis 2 秒内应答PING返回200 {status:ok}否则503 {status:unavailable}——用于就绪检查GET /health/live进程存活即返回200即使 Redis 宕机——用于存活检查避免编排器在 Redis 故障期间反复重启容器。同一秒内的多次检查共享一次PING轮询/health不会给 Redis 增加负载。Kubernetes 与 Compose 的探针配置示例见选项文档。收到SIGTERM/SIGINT后停止接新连接、等待在途请求完成、关闭 Redis 连接、退出码 0若 8 秒后仍有请求在跑则强制以码 1 退出保持在 Docker 默认 10 秒停止超时内第二次信号立即退出。HashWX 与 Instrumentation 的站点级配置新站点密钥默认启用HashWX可在密钥的Configuration页按协议切换存量密钥保持原协议直至手动更改HashWX difficulty滑块即期望的哈希次数默认1_000_000拆 4 个子挑战合法范围50_000-5_000_000调整前务必参考上文手机实测数据不支持 WebAssembly 的客户端请切到 SHA-256有纯 JS 回退RSW仍可对存量部署选择但已弃用GPU 优势约 170 倍RSW difficulty设t顺序平方次数范围10_000-300_000RSW_BITS2048可在启动时覆盖模数大小Instrumentation新站点默认开启可在密钥配置中开关Attempt to block headless browsers拦截无头浏览器需另行开启。官方建议混淆级别保持level 3级别过高会显著降低生成吞吐若嫌慢可降到 level 1单核下明显更快widget 会从线上格式自动识别协议切换密钥是唯一需要做的改动。错误消息与 IP 数据库错误消息默认脱敏SHOW_ERRORStrue可关闭脱敏并记录到控制台DISABLE_ERROR_LOGGINGtrue可关闭日志。国家与 ASN 查询支持三个数据源DB-IP Lite、MaxMind GeoLite2、IPInfo API面板Settings IP Data配置。DB-IP 与 MaxMind 的.mmdb会下载到容器内/usr/src/app/data/容器以非特权bun用户UID 1000运行绑定挂载宿主目录时必须保证 UID 1000 可写否则报EACCES: permission deniedsudo chown 1000:1000 ./cap-data或改用命名卷/无本地文件的提供方。REST API 与权限Standalone 的完整 API 参考见 API 文档。在面板Settings → API Keys创建 API key 后以Authorization: Bot YOUR_API_KEY请求端点清单可在http://localhost:3000/swagger查看。API key 支持两种限制可组合站点密钥作用域只能操作指定 site key 的/server/keys/:siteKey/...端点与GET /server/keys其余含设置端点一律403与只读仅允许GET任何创建/更新/轮换/删除返回403。通过 API 创建受限密钥POST /server/settings/apikeys Content-Type: application/json { name: acme stats, siteKeys: [site key], readonly: true }此外还支持分享链接share links为单个站点创建公开只读统计页挑战/校验计数、活动图、地域/网络/平台/OS 分布token 放在 URL 片段#之后不经过 referer 泄漏可用GET /share/:token?chartDurationlast7days与GET /share/:token/geo-stats两个无鉴权限流端点取数chartDuration支持today、yesterday、last7days、last28days、last91days、alltime通过POST /server/keys/:siteKey/shares创建时expiresIn以秒计省略或传0表示永不过期。capjs-core面向边缘的无状态核心库若你无法运行 Docker或需要把挑战生成嵌入现有服务、部署到 Cloudflare Workers/Lambda 等无持久存储环境直接使用核心库 capjs-core# bun add capjs-core / npm i capjs-core / pnpm i capjs-coreimport { generateChallenge, validateChallenge } from capjs-core; const SECRET process.env.CAP_SECRET; // 长随机高熵跨进程保持一致 // 服务端路由创建挑战 const ch await generateChallenge(SECRET, { scope: signup, // 可选 instrumentation: true, // 可选 }); // → { challenge: { c, s, d }, token, expires, instrumentation? } // 服务端路由校验兑换结果 const result await validateChallenge( SECRET, { token: req.body.token, solutions: req.body.solutions, instr: req.body.instr, }, { scope: signup, consumeNonce: async (sigHex, ttlMs) myStore.setIfNotExists(cap:${sigHex}, 1, ttlMs), }, ); if (result.success) { /* result.token, result.tokenKey, result.expires, result.scope */ }核心 API 参数详见 capjs-core 文档generateChallenge(secret, opts?)secret为 ≥16 字节的 HMAC 主密钥challengeCount默认 50PoW 谜题数、challengeSize默认 32salt 十六进制字符数、challengeDifficulty默认 4目标前缀十六进制字符数、expiresMs默认 60000010 分钟 TTL、scope校验时须一致、extra嵌入 JWT 负载、instrumentation可传{ blockAutomatedBrowsers, obfuscationLevel }validateChallenge(secret, body, opts?)成功返回{ success, token, tokenKey, expires, scope, iat, riskFlags }失败返回{ success: false, reason, instr_error?, blockedBy? }。与旧库cap.js/server的关键差异官方对比表无状态挑战 token 是签名 JWT、无构造函数每次调用传 secret、重放预防改为可选consumeNonce回调、TTL 编码在 JWTexp、不触碰文件系统、天然兼容 Worker/边缘运行时。注意 capjs-core 不会替你校验兑换 token——它返回一个tokenKey供你自己存储、一个token交给用户后续校验时按用户提交的 token 重新派生 key 并查库文档给出了用node:crypto的sha256派生示例。效果边界与合规定位官方 有效性文档 对为什么有效给出了清晰论证任何 CAPTCHA 最终都能被 AI、算法、指纹伪造或验证码农场攻破真正的差别在于强加给攻击者的成本。其经济模型是假设发 10,000 条垃圾消息成本 $1、潜在收益 $10若 Cap 把计算成本抬到 $100攻击者净亏 $90动机即被消除。PoW 的设计灵感来自 Hashcashinstrumentation 挑战则参考了 Twitter 与 YouTube 自研挑战。因此Cap 的目标不是永远拦不住的绝对防破解而是让自动化滥用变贵、同时让真实用户体验近乎无感。合规方面详见快速上手的 Built for compliance 小节与 compliance 文档自托管 无 cookie 无追踪 无第三方调用用户数据不离开你的基础设施围绕 GDPR、CCPA、HIPAA、LGPD 等隐私制度设计PoW 复选框避免了图片/音频谜题在 WCAG 2.2 下的可访问性障碍。结语从 README 的一句定位出发本文完整梳理了 Cap 的架构与实战PoW默认 HashWX与 instrumentation 两条独立防线共同构成反滥用体系Standalone 单容器提供了一站式部署、多站点密钥、reCAPTCHA 兼容校验与可观测仪表盘capjs-core则为边缘环境提供了无状态 JWT 挑战库。官方文档明确强调Cap 不只是 proof-of-work调优难度、开启自动化浏览器检测、理解限流与反代 IP 语义都是生产化部署中直接决定防护效果与用户体验的关键决策点。深入源码可从 core/src/index.js、standalone/src/cap.js、widget/src/src/cap.js 入手测试用例则在 core/test 与 standalone/test 中给出了完整的行为契约。赞分享网络安全应用安全后端【免费下载链接】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 项目全览以 Proof-of-Work 与 Instrumentation 为核心的自托管开源验证码替代方案Cap 项目全览以 Proof of Work 与 Instrumentation 为核心的自托管开源验证码替代方案 Cap 是一个免费、开源、可完全自托管的网络安全应用安全后端Cap 与 Altcha 全面对比开源自托管 Proof-of-Work CAPTCHA 的选型指南Cap 与 Altcha 全面对比开源自托管 Proof of Work CAPTCHA 的选型指南 Altcha 是当前开源生态里与 Cap 理念最接近的网络安全应用安全后端Cap 无头验证Programmatic Mode实战指南用 new Cap() 与 solve() 在自托管 CAPTCHA 中实现无界面 proof-of-work 验证Cap 无头验证Programmatic Mode实战指南用 new Cap 与 solve 在自托管 CAPTCHA 中实现无界面 proof of w网络安全应用安全后端创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Cap：轻量级开源 CAPTCHA 替代方案实战指南——基于 Proof-of-Work 与 Instrumentation 的自托管验证码系统
网络安全应用安全后端【免费下载链接】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 是一个免费、开源、可自托管的 CAPTCHA 替代方案用工作量证明proof-of-work与 instrumentation 挑战取代传统视觉验证码主打隐私优先、轻量快速与极简集成。本文以仓库 README.md 为骨架结合 工作原理、HashWX、instrumentation 与 Standalone 配置 等官方文档及源码系统讲解 Cap 的定位、双防线技术原理、五分钟左右的自托管部署流程以及服务端配置与无状态核心库的实战用法。读完本文你将能够独立部署一套 Cap Standalone 实例完成前端 widget 接入与后端 token 校验并理解如何按业务场景调优难度、检测与限流策略。Cap 是什么根据 README 的官方定义Cap 是一款轻量级、现代化的开源 CAPTCHA 替代方案核心由两类挑战组成Proof-of-Work工作量证明让访问者的浏览器在后台完成真实计算如 SHA-256 哈希以计算成本抑制自动化滥用Instrumentation challenges插桩挑战每次请求动态生成一段 JavaScript在真实浏览器环境中执行并回传结果用于验证对面是一个真实浏览器环境。它替代的是 reCAPTCHA、hCaptcha、Cloudflare Turnstile 这类商业验证码服务特点可以概括为四个词快速fast、私密private、集成极简simple to integrate。与传统验证码不同Cap 不包含图片、不做用户追踪、无第三方依赖并且默认支持在任意环境运行。生态组成从仓库结构见 core 核心库、widget 组件、standalone 服务端可以看出Cap 由三个可独立使用的部分组成组件作用仓库位置capjs-core无状态的服务端库生成与校验 JWT 签名挑战可部署到边缘函数core/src/index.jscap-widget浏览器端 Web Component负责渲染复选框、执行 PoW 与 instrumentationwidget/src/src/cap.jsCap Standalone一站式自托管服务端Docker 容器 REST API 管理面板 多站点密钥standalone/src/index.js官方文档明确推荐大多数用户直接使用 Standalone Docker 容器见 快速上手指南只有当你无法运行 Docker、想把挑战生成嵌入现有服务、或需要部署到无持久存储的边缘环境Cloudflare Workers、Lambda时才直接使用 capjs-core 库。为什么选择 Cap七大核心特性README 的 Why Cap 一节给出了官方定位下的七项核心优势下面逐条展开并结合仓库证据说明其含义。1. 体积比 hCaptcha 小约 250 倍官方声明Cap 的 widget 约20KB、零依赖、毫秒级加载对比 hCaptcha 的体量缩小约 250 倍。从仓库看widget 的构建产物 cap.min.js 与 cap.compat.min.js 正是面向生产环境的压缩包通过单行script标签即可引入不依赖任何第三方框架。2. 隐私优先Privacy-firstCap不向官方服务器发送任何遥测数据。由于是自托管架构挑战生成、校验、数据存储全部发生在你自己的基础设施上。官方 有效性说明 进一步指出Cap 默认不使用 cookie、不启用任何遥测完全自托管意味着中央服务器上不采集、不存储任何用户数据同时内置重放保护replay protection与基于签名的挑战 token。3. 完全可定制Fully customizablewidget 支持通过 CSS 变量改变颜色、尺寸、位置、图标等外观。可参考 widget 文档 了解全部自定义选项也可以在 Standalone 选项文档 中看到服务端行为级配置CORS、限流、资产服务器、HashWX 难度等。4. 工作量证明Proof-of-Work用户不再需要浪费时间解决视觉谜题。挑战在浏览器后台静默完成用户只需点击一次复选框甚至无需交互见下一条。5. Standalone 自托管模式用单个 Docker 容器即可在任何地方运行完整的 Cap 后端内置分析与仪表盘、多站点密钥管理、与 reCAPTCHA 兼容的 siteverify API。具体能力详见下文部署与配置章节。6. 无需用户交互可以隐藏 widget 界面让挑战在后台静默完成对正常用户完全无感。官方文档提供了编程式调用programmatic与悬浮模式floating两种高级用法。7. 开源Open-source项目以Apache-2.0协议开源见 LICENSE完全免费。版权信息见 LICENSE 文件。核心技术原理双防线架构README 的一句话概括是proof-of-work instrumentation challenges但正如 工作原理 文档强调的Cap 运行的其实是两条独立防线缺一不可。理解这一点是正确调优的前提。完整挑战流程官方文档给出的九步流程如下Cap 初始化时浏览器自动注册 widget 对应的自定义元素custom elementwidget 创建 shadow DOM 并挂载所需元素请求挑战时widget 向服务器发送请求服务器返回token、挑战配置以及可选的压缩后的 instrumentation 数据widget 用挑战 token 作为种子seed结合服务器下发的配置生成多个挑战若带有 instrumentation 数据则解压后在沙箱 iframe 中执行widget 通过 Rust 编译的 WASM 与 Web Worker并行求解每个 worker 反复尝试——把 salt 与不同的 nonce 组合、计算 SHA-256 哈希、检查结果哈希是否以目标前缀开头直到找到匹配的 nonce若存在 instrumentation 挑战则解压并执行找到有效解后widget 将结果回传服务器校验服务器用相同 token 与配置自行生成同样的挑战核对 widget 提交的解校验成功后服务器兑换redeem该解并签发一个可用于鉴权的 token。为什么引入 Instrumentation 作为第二防线instrumentation 文档 给出了清晰的定位Proof-of-Work 证明的是付出过计算代价Instrumentation 证明的是在真实浏览器环境中完成计算两者从两个独立维度抬高滥用成本缺一不可。instrumentation 挑战的机制是服务器为每个请求生成一段自包含self-contained的 JavaScript包含浏览器 API 探针与一条主计算链——多个整数变量以随机种子初始化然后经过随机化的运算按位 AND/OR/XOR/NAND、原型链技巧、基于 DOM 的算术持续变异。其中 DOM 算术会在页面中追加一棵元素树、沿树回走累积值、再将其移除。服务器在生成脚本的同时并行追踪每个操作的期望结果因此它预先知道最终四个值应当是什么。所有检查在 iframe 内运行通过postMessage把答案回传给父页面。为什么要用 DOM 操作纯算术可以在无浏览器环境里直接执行 JS 复现而 DOM 操作不能——构造真实元素树、经浏览器布局引擎读取值、再拆除这一过程触及了非浏览器运行时通常被 stub 掉、实现错误或为性能而跳过的那部分能力因此很难在真实渲染引擎之外低成本重放。自动化浏览器检测可选当开启blockAutomatedBrowsers时instrumentation 脚本还会收集一组浏览器事实向量文本度量、窗口几何、navigator.webdriver、引擎标记随计算结果回传由服务器端检测器对向量做判断——客户端自身的结论不被信任因为隐身补丁可以改掉客户端检查。官方文档给出七项可能导致请求失败的检查全部针对自动化层或篡改不针对浏览器版本检查捕获对象为何对真人安全geometry_quantizedCamoufox 把文本宽度吸附为整像素真实 Blink/Gecko/WebKit 返回小数宽度需至少 5/17 个字体栈为整像素且至少 2 个不同整数值单一字体系统不会误伤webdriver_true裸 Selenium、Playwright、Puppeteer、rebrowser规范定义的自动化标志任何发行版浏览器都不会设置webdriver_stripped删除navigator.webdriver的隐身补丁真实 Chrome 总是暴露falsegecko_contradiction在 Gecko 引擎上伪造navigator.deviceMemory或userAgentDataFirefox 从未提供这两个 APIwindow_exceeds_screenCDPEmulation.setDeviceMetricsOverride使窗口高于屏幕screen.isExtended为 true 时跳过更高的第二显示器可通过viewport_override视口与屏幕完全相等但浏览器 chrome 存在移动端全屏视口属正常跳过headless_tokenUA 或userAgentData.brands中的HeadlessChrome无消费者浏览器会暴露它另有两个信号只采集、不拦截native_tampercanvas/WebGL/权限方法的Function.prototype.toString不再是[native code]可捕获 puppeteer-stealth 等但隐私插件同样会改写故仅作为风险标记供提高 PoW 难度与浏览器表面聚类无window.chrome、无插件、无 PDF 阅读器——移动 Chrome 与 Android WebView 会合法命中故完全不使用。被拦截时validateChallenge返回reason: instr_automated_browser并附blockedBy数组列出命中的检查校验通过则携带riskFlagsStandalone 面板上对应展示为automated_browser_detected。官方也诚实列出了已知缺口undetected-chromedriver、nodriver驱动有头 Chrome 能通过全部七项检查无头 Firefox 也能通过——因此PoW 仍是让此类流量变贵的兜底层。HashWXGPU 抗性工作量证明新站点的默认挑战协议是HashWX详见 HashWX 文档。它的核心思想不再使用固定的 SHA-256 哈希函数而是每次挑战都从种子生成一个全新的单向函数由整数运算与分支构成让 GPU 无法比 CPU 快太多。为什么需要 GPU 抗性瓶颈在于吞吐量攻击者不在乎单个挑战耗时多久只在乎每小时能清掉多少个挑战。官方给出的对比数据CPU 为 Ryzen 3700X 16 线程GPU 为 RTX 5060 Ti算法CPU 吞吐GPU 吞吐GPU 优势SHA-25641 MH/s6150 MH/s~150xRSW26 H/s4400 H/s~170xHashWX2.8 MH/s5.8 MH/s~2xCap 之前的 RSW 时间锁谜题在单谜题延迟上有优势顺序平方无法并行但吞吐量惨败HashWX 把 GPU 优势压到了约 2 倍。RSW 已弃用旧密钥仍可选择且继续工作但不建议新部署使用。协议要点铸造Mint服务器随机取 32 字节作为挑战C与难度d无密钥材料、无预计算一次随机读取加一次 JWT 签名即可客户端求解寻找 64 位 nonceN使H(N) (2^64 - 1) / d其中H hashwx_make(sha256(C || u64le(N / n)))。每n个连续 nonce 共享一个生成的哈希函数。Cap 取n 65536参考协议原生端用 463但浏览器需为每个 block 通过WebAssembly.Module做 JIT 编译更大的 block 可摊薄该开销GPU 抗性的四个来源每个实例含 32 个程序、每个循环以 1/2 概率分支回自身起点共 256 个分支/哈希GPU 上撕裂 warp16KB 未对齐加载的 scratchpadGPU 需本地内存 L2 约 100 周期交错浅/深寄存器源列表CPU 平均 2.75 个依赖加载GPU 解释器几乎总要吃满 6 个依赖加载链指令集仅限 WebAssembly 1.0 的 64 位乘/加/减/XOR/OR/移位这也是它能在浏览器中运行的前提服务器校验按 nonce 隐含的 block 索引从C重算种子生成该哈希函数、运行一次、与目标比较。程序生成比 HashX 便宜约 5 倍校验耗时在几十微秒量级。成本与体验的权衡数据官方在 Apple M3 单核上实测的服务器成本经validateChallenge测量中位数单个 HashWX 挑战铸造 14µs、校验 40µs默认 4 个子挑战共约 149µs——比 SHA-256 贵但仅为 RSW1536µs的十分之一且难度不影响校验成本校验就是每个子挑战一次哈希。默认把难度拆成4 个子挑战是为了抹平求解时间的彩票效应单挑战的求解时间指数分布同一难度有人 30ms 有人 3 秒。官方实测release Chrome、M3 8 核、各 72 次求解单挑战d1,330,000中位数 536ms / p90 1447ms4 子挑战d1,000,000中位数 490ms / p90 778ms。拆分不改变攻击者的总期望工作量期望仍是d次哈希只是把典型求解时间的中位数推到均值的约 0.92、显著缩短长尾。浏览器引擎方面单 worker 下 Chrome/Firefox/Safari 相差约 5%8 worker 时 Safari 约为 Chrome 的 70%因此调难度要按 Safari 校准。手机端官方 BrowserStack 实测Galaxy S24 中位数 1.1s 到 Vivo Y21 的 5.9s 不等若流量以移动端为主应下调难度求解时间随难度线性变化500,000 大约把求解部分减半。无 WebAssembly 的客户端完全无法求解 HashWX需要支持时请为该站点改用带纯 JS 回退的 SHA-256iOS 上的 widget 需 iOS 15 及以上。五分钟快速上手从部署到校验官方 快速上手指南 给出了完整的集成路径约五分钟即可跑通。核心是两部分widget跑挑战、显示复选框server签发挑战、校验解。1. 运行服务器Standalone推荐使用 Cap Standalone 单容器。创建docker-compose.ymlservices: 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与secret key两把都要保存。要点ADMIN_KEY是面板密码建议至少 32 字符端口冲突就改3000:3000面板不可达时可给cap服务加network_mode: host。2. 添加 widgetwidget 是一个单文件 Web Component一行脚本引入script srchttps://cdn.jsdelivr.net/npm/cap-widgetversion/script表单内最简单的用法widget 在form内时Cap 自动注入隐藏的cap-token字段随表单提交无需写任何 JavaScriptform action/submit methodPOST !-- your fields -- cap-widget>const widget document.querySelector(cap-widget); widget.addEventListener(solve, (e) { const token e.detail.token; // 把 token 发给你的后端、启用提交按钮等 });React、Vue、Svelte 等框架片段见 widget 文档隐藏式编程调用见 programmatic悬浮模式见 floating。3. 后端校验 token向实例的/siteverify端点发POSTcurl / fetch / Python / PHP 写法在快速上手指南中都有完整示例curl https://your-instance/site-key/siteverify \ -X POST \ -H Content-Type: application/json \ -d { secret: key_secret, response: captcha_token }key_secret是面板里的secret key不是面板密码ADMIN_KEY——混用是最常见的配置错误captcha_token是 widget 产生的 token表单字段cap-token或e.detail.token。有效 token 返回{ success: true }token 一次性使用每次只校验一次然后执行你自己的业务逻辑。4. 端到端自检加载页面复选框应自动勾选solve处理器或表单字段产出 token把 token 发给/siteverify得到{ success: true }再发一次同一个 token应当失败——这确认一次性机制生效。若校验总是失败检查是否用了 secret key而非 ADMIN_KEY以及your-instance是否与 widget 指向的地址一致。reCAPTCHA 兼容迁移官方特别说明Cap 的/siteverify与 reCAPTCHA 的 API 兼容你可以只改一个 URL 把现有校验代码指向 Cap两者并行运行、择机切换无需重写、没有大爆炸式迁移风险详见 alternatives 对比。Standalone 服务端配置深入官方 Standalone 选项文档 是生产化部署的核心参考以下按主题整理关键配置。CORS通过环境变量CORS_ORIGIN控制挑战签发与兑换的跨域策略默认*多个来源用逗号分隔如domain1.tld,domain2.tld。资产服务器Asset server默认关闭设ENABLE_ASSETS_SERVERtrue后由/assets端点提供静态文件。需配套设置WIDGET_VERSION与WASM_VERSION默认latest官方不建议生产环境用可能携带破坏性变更可用版本为cap.js/widget与cap.js/wasm的 npm 发布版。示例ENABLE_ASSETS_SERVERtrue WIDGET_VERSION0.1.58 WASM_VERSION0.0.8随后即可通过以下路径引用/assets/widget.js、/assets/floating.js、/assets/cap_wasm_bg.wasm、/assets/hashwx.wasm、/assets/cap_wasm.js并配合window.CAP_CUSTOM_WASM_URL与window.CAP_CUSTOM_HASHWX_URL指向自托管 WASM。注意hashwx.wasm随cap.js/wasm0.0.8 起提供旧版本下/assets/hashwx.wasm会返回 503此时应让 widget 从 jsdelivr 加载。资产默认从process.env.CACHE_HOST默认https://cdn.jsdelivr.net拉取并缓存进 Redis、每小时刷新若端点返回Asset not cached yet请检查ENABLE_ASSETS_SERVER是否真正生效改过 compose 需重建容器、容器能否访问CACHE_HOST、版本号是否真实存在于 npm。限流Rate-limiting挑战端点按客户端 IP 固定窗口限流默认每 5 秒 30 次请求。全局限制可在面板Settings中调整或PUT /settings/ratelimit也可在单个站点的Configuration页覆盖。超限返回429与X-RateLimit-Remaining: 0头。/siteverify是服务端对服务端的接口默认不限流。客户端 IP 识别顺序为X-Forwarded-For、X-Real-IP、CF-Connecting-IP最后回退 socket 地址反代使用其他头时设RATELIMIT_IP_HEADERCloudflare 场景可设cf-connecting-ip。务必让反代真的转发客户端 IPnginx 示例见选项文档否则所有请求共享同一 IP 桶同时由于X-Forwarded-For被信任原样服务器绝不能直接暴露在公网否则客户端可伪造头绕过限流。Redis / Valkey所有数据都存 Redis或兼容的 Valkey通过REDIS_URL配置默认redis://localhost:6379。多实例共用同一 Redis 时用REDIS_PREFIX命名空间隔离如cap:前缀默认空不影响存量部署。健康检查与优雅关闭GET /healthRedis 2 秒内应答PING返回200 {status:ok}否则503 {status:unavailable}——用于就绪检查GET /health/live进程存活即返回200即使 Redis 宕机——用于存活检查避免编排器在 Redis 故障期间反复重启容器。同一秒内的多次检查共享一次PING轮询/health不会给 Redis 增加负载。Kubernetes 与 Compose 的探针配置示例见选项文档。收到SIGTERM/SIGINT后停止接新连接、等待在途请求完成、关闭 Redis 连接、退出码 0若 8 秒后仍有请求在跑则强制以码 1 退出保持在 Docker 默认 10 秒停止超时内第二次信号立即退出。HashWX 与 Instrumentation 的站点级配置新站点密钥默认启用HashWX可在密钥的Configuration页按协议切换存量密钥保持原协议直至手动更改HashWX difficulty滑块即期望的哈希次数默认1_000_000拆 4 个子挑战合法范围50_000-5_000_000调整前务必参考上文手机实测数据不支持 WebAssembly 的客户端请切到 SHA-256有纯 JS 回退RSW仍可对存量部署选择但已弃用GPU 优势约 170 倍RSW difficulty设t顺序平方次数范围10_000-300_000RSW_BITS2048可在启动时覆盖模数大小Instrumentation新站点默认开启可在密钥配置中开关Attempt to block headless browsers拦截无头浏览器需另行开启。官方建议混淆级别保持level 3级别过高会显著降低生成吞吐若嫌慢可降到 level 1单核下明显更快widget 会从线上格式自动识别协议切换密钥是唯一需要做的改动。错误消息与 IP 数据库错误消息默认脱敏SHOW_ERRORStrue可关闭脱敏并记录到控制台DISABLE_ERROR_LOGGINGtrue可关闭日志。国家与 ASN 查询支持三个数据源DB-IP Lite、MaxMind GeoLite2、IPInfo API面板Settings IP Data配置。DB-IP 与 MaxMind 的.mmdb会下载到容器内/usr/src/app/data/容器以非特权bun用户UID 1000运行绑定挂载宿主目录时必须保证 UID 1000 可写否则报EACCES: permission deniedsudo chown 1000:1000 ./cap-data或改用命名卷/无本地文件的提供方。REST API 与权限Standalone 的完整 API 参考见 API 文档。在面板Settings → API Keys创建 API key 后以Authorization: Bot YOUR_API_KEY请求端点清单可在http://localhost:3000/swagger查看。API key 支持两种限制可组合站点密钥作用域只能操作指定 site key 的/server/keys/:siteKey/...端点与GET /server/keys其余含设置端点一律403与只读仅允许GET任何创建/更新/轮换/删除返回403。通过 API 创建受限密钥POST /server/settings/apikeys Content-Type: application/json { name: acme stats, siteKeys: [site key], readonly: true }此外还支持分享链接share links为单个站点创建公开只读统计页挑战/校验计数、活动图、地域/网络/平台/OS 分布token 放在 URL 片段#之后不经过 referer 泄漏可用GET /share/:token?chartDurationlast7days与GET /share/:token/geo-stats两个无鉴权限流端点取数chartDuration支持today、yesterday、last7days、last28days、last91days、alltime通过POST /server/keys/:siteKey/shares创建时expiresIn以秒计省略或传0表示永不过期。capjs-core面向边缘的无状态核心库若你无法运行 Docker或需要把挑战生成嵌入现有服务、部署到 Cloudflare Workers/Lambda 等无持久存储环境直接使用核心库 capjs-core# bun add capjs-core / npm i capjs-core / pnpm i capjs-coreimport { generateChallenge, validateChallenge } from capjs-core; const SECRET process.env.CAP_SECRET; // 长随机高熵跨进程保持一致 // 服务端路由创建挑战 const ch await generateChallenge(SECRET, { scope: signup, // 可选 instrumentation: true, // 可选 }); // → { challenge: { c, s, d }, token, expires, instrumentation? } // 服务端路由校验兑换结果 const result await validateChallenge( SECRET, { token: req.body.token, solutions: req.body.solutions, instr: req.body.instr, }, { scope: signup, consumeNonce: async (sigHex, ttlMs) myStore.setIfNotExists(cap:${sigHex}, 1, ttlMs), }, ); if (result.success) { /* result.token, result.tokenKey, result.expires, result.scope */ }核心 API 参数详见 capjs-core 文档generateChallenge(secret, opts?)secret为 ≥16 字节的 HMAC 主密钥challengeCount默认 50PoW 谜题数、challengeSize默认 32salt 十六进制字符数、challengeDifficulty默认 4目标前缀十六进制字符数、expiresMs默认 60000010 分钟 TTL、scope校验时须一致、extra嵌入 JWT 负载、instrumentation可传{ blockAutomatedBrowsers, obfuscationLevel }validateChallenge(secret, body, opts?)成功返回{ success, token, tokenKey, expires, scope, iat, riskFlags }失败返回{ success: false, reason, instr_error?, blockedBy? }。与旧库cap.js/server的关键差异官方对比表无状态挑战 token 是签名 JWT、无构造函数每次调用传 secret、重放预防改为可选consumeNonce回调、TTL 编码在 JWTexp、不触碰文件系统、天然兼容 Worker/边缘运行时。注意 capjs-core 不会替你校验兑换 token——它返回一个tokenKey供你自己存储、一个token交给用户后续校验时按用户提交的 token 重新派生 key 并查库文档给出了用node:crypto的sha256派生示例。效果边界与合规定位官方 有效性文档 对为什么有效给出了清晰论证任何 CAPTCHA 最终都能被 AI、算法、指纹伪造或验证码农场攻破真正的差别在于强加给攻击者的成本。其经济模型是假设发 10,000 条垃圾消息成本 $1、潜在收益 $10若 Cap 把计算成本抬到 $100攻击者净亏 $90动机即被消除。PoW 的设计灵感来自 Hashcashinstrumentation 挑战则参考了 Twitter 与 YouTube 自研挑战。因此Cap 的目标不是永远拦不住的绝对防破解而是让自动化滥用变贵、同时让真实用户体验近乎无感。合规方面详见快速上手的 Built for compliance 小节与 compliance 文档自托管 无 cookie 无追踪 无第三方调用用户数据不离开你的基础设施围绕 GDPR、CCPA、HIPAA、LGPD 等隐私制度设计PoW 复选框避免了图片/音频谜题在 WCAG 2.2 下的可访问性障碍。结语从 README 的一句定位出发本文完整梳理了 Cap 的架构与实战PoW默认 HashWX与 instrumentation 两条独立防线共同构成反滥用体系Standalone 单容器提供了一站式部署、多站点密钥、reCAPTCHA 兼容校验与可观测仪表盘capjs-core则为边缘环境提供了无状态 JWT 挑战库。官方文档明确强调Cap 不只是 proof-of-work调优难度、开启自动化浏览器检测、理解限流与反代 IP 语义都是生产化部署中直接决定防护效果与用户体验的关键决策点。深入源码可从 core/src/index.js、standalone/src/cap.js、widget/src/src/cap.js 入手测试用例则在 core/test 与 standalone/test 中给出了完整的行为契约。赞分享网络安全应用安全后端【免费下载链接】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 项目全览以 Proof-of-Work 与 Instrumentation 为核心的自托管开源验证码替代方案Cap 项目全览以 Proof of Work 与 Instrumentation 为核心的自托管开源验证码替代方案 Cap 是一个免费、开源、可完全自托管的网络安全应用安全后端Cap 与 Altcha 全面对比开源自托管 Proof-of-Work CAPTCHA 的选型指南Cap 与 Altcha 全面对比开源自托管 Proof of Work CAPTCHA 的选型指南 Altcha 是当前开源生态里与 Cap 理念最接近的网络安全应用安全后端Cap 无头验证Programmatic Mode实战指南用 new Cap() 与 solve() 在自托管 CAPTCHA 中实现无界面 proof-of-work 验证Cap 无头验证Programmatic Mode实战指南用 new Cap 与 solve 在自托管 CAPTCHA 中实现无界面 proof of w网络安全应用安全后端创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考