边缘欺诈检测：Cloudflare Workers + tracio.ai
在请求到达源服务器之前，在 Cloudflare Workers 中运行设备指纹校验。在边缘完成低于 5ms 的欺诈决策。
传统的欺诈检测发生在应用层：请求到达你的服务器，你查询欺诈检测 API，等待响应，然后决定放行还是拦截。这一次往返为每次请求增加了 50-200ms 的延迟——对于页面加载尚可接受，但对于 API 端点、AJAX 调用和实时交互而言就很难受了。
如果能在请求到达源服务器之前就做出欺诈决策会怎样？这正是边缘计算所实现的，而我们用来演示这一模式的平台是 Cloudflare Workers。
架构
该方案由三个组件构成：运行在浏览器中的 tracio.ai JS SDK（@tracio/sdk）、位于客户端与源站之间的 Cloudflare Worker，以及向你的后端投递完整信号分析的、经签名的 tracio.ai webhook。
流程如下：JS SDK 在页面加载期间采集设备信号并发送给 tracio.ai，向浏览器返回一个 visitorId。你的后端通过经签名的 webhook 接收完整的识别结果——机器人分类、smart signals、置信度——并将判定结果写入边缘缓存。浏览器在后续的 API 请求中（通过请求头或 cookie）携带该 visitorId。Cloudflare Worker 拦截每次请求，查找该 visitorId 对应的缓存判定结果，并在 5ms 内做出放行/拦截决策。
Worker 实现
Worker 使用 Cloudflare 的 KV 存储维护一个轻量级的近期设备校验结果缓存，该缓存由你的后端在收到经签名的 tracio.ai webhook 时填充。当带有 visitorId 请求头的请求到达时，Worker 会检查缓存。如果判定结果已缓存且访客为干净（机器人分数低、无 VPN、置信度高于阈值），请求会立即通过。如果尚无缓存的判定结果，Worker 会应用你的回退策略——以保守的速率限制放行，或发起质询挑战——直到由 webhook 驱动的缓存补齐为止。
关键在于校验缓存是被主动填充的。首次页面加载会触发信号采集并缓存结果。此后来自该访客的所有 API 调用都会命中缓存——无需再往返 tracio.ai。缓存 TTL 可配置；我们建议高安全性端点使用 5 分钟，一般内容使用 30 分钟。
性能数据
我们对该架构进行了基准测试，客户通过 Cloudflare Workers 处理每分钟 50,000 次请求。结果如下：
缓存命中率：94%（大多数请求来自已经加载过页面的访客）。边缘决策延迟（缓存命中）：中位 1.2ms，p99 为 3.8ms。边缘决策延迟（缓存未命中）：中位 45ms（包含对 tracio.ai 的 API 调用）。源站延迟节省：每次请求中位节省 120ms（消除了服务器端的欺诈检查）。
94% 的缓存命中率意味着 94% 的欺诈决策在边缘于 4ms 内完成，源站完全不参与。其余 6% 是需要完整 API 往返的首次访问请求。
拦截策略
Worker 支持三种拦截策略，可按路由配置：
硬拦截（Hard block）：对高风险访客（机器人分数 > 0.9、已知自动化框架）立即返回 403。软拦截（Soft block）：添加 X-Tracio-Risk 请求头，交由源站决定。当你希望在应用层结合上下文做决策时，这很有用。质询挑战（Challenge）：将可疑访客（机器人分数中等、检测到 VPN）重定向到需要额外验证的质询页面。
我们建议在生产环境中先从软拦截开始，监控一周的风险分布，然后针对明确无疑的情形（已知机器人、无头浏览器、高置信度的自动化）启用硬拦截。
成本分析
Cloudflare Workers 的定价基于请求数和计算时间。在每分钟 5 万次请求（每月 21.6 亿次）的情况下，Worker 成本约为每月 500 美元。将其与延迟节省相比较：消除源站侧 120ms 的欺诈检查可使服务器 CPU 使用率降低 15-20%，通常节省的计算成本会超过 Worker 的费用。
真正的价值在于欺诈预防：在机器人和欺诈请求消耗源站资源、数据库连接和下游 API 调用之前就将其拦截。一位客户在实施基于边缘的欺诈检测后，将源站服务器数量从 12 台减至 8 台——那些曾占用其 30% 计算资源的机器人再也没有到达源站。