代理门禁
代理门禁统计
门禁保有它自己的统计，和一个站点密钥的 验证统计 分开。验证页回答“真人在通过游戏吗？”；这一页回答一个更窄的问题：“门禁挑战访客，相对于放一个已放行访客通过，有多频繁？”它是你确认门禁已接好、已调好的方式，也是 预览模式 在你还在测试时写入的同一个界面。
它住在哪
有两个视图：
- 按站点密钥：一个站点密钥下的 代理统计 页，针对一个受门禁的源。
- 按团队：团队一级的 代理统计 页，跨团队里每个站点密钥聚合。
两者都需要 Alpha 套餐或更高；低于此，该页改为展示一张升级卡。
四个计数
每个门禁决定都被记录为四类之一：
- 直接放行：一个请求带着有效通行证到来并被允许。这是取胜条件；一个已放行访客浏览站点会生成这些。
- 已展示挑战：一个请求没有有效通行证，于是访客被送去游戏。
- 签发通行证：一位访客解开了游戏，一张通行证被铸出（回调随后设置了 Cookie）。
- 拒绝：授权方在一个失败即关闭的策略下、在它无法确认通行证时拒绝了该请求。
直接放行对挑战的比率
头号数字是直接放行相对于挑战。一旦访客们通过了门禁，他们的大多数请求应当是 直接放行，只在一次访问开始时、或一张通行证过期之后才有一次挑战。一个高的直接放行比率意味着你的 通行 TTL 在做它的活儿，一次解题买下许多请求。如果挑战相对于直接放行一直很高，那 TTL 可能太短（访客在会话中途被重新挑战），或者 Cookie 没被设置（检查回调）。
在推出期间读它
预览模式开着时，在一次测试访问里留意这个序列：一个 challenge_served（还没有 Cookie），然后在你解题后一个 pass_issued，然后随着你刷新，passthrough 在爬升。缺失的挑战意味着授权方块没被命中；一个从不变成直接放行的 pass_issued 意味着 Cookie 没粘住。
保留
历史按套餐档保留，更旧的桶按每日计划被修剪，所以你能回望的窗口随你的套餐变宽。实时比率和近期活动始终可用。
这里没有什么
- 没有来自你代理的失败即开放式直接放行。 当你的代理配置为失败即开放、而 Caputchin 不可达时，代理自行放行请求；Caputchin 从不看见它，所以无法在这里计数。
- 没有逐访客数据。 只有计数，没有 IP、没有 user agent、没有请求内容，与 Caputchin 的隐私立场一致。