Cloudflare推出Application Profiles：请求偏离会被标记，是否拦截仍由规则决定

10-01 5阅读

2026 年 9 月 29 日，Cloudflare 公布 Application Profiles，通过学习应用请求的结构与格式，识别偏离预期的流量。最容易误读的地方是把“检测已经持续运行”理解成“所有异常都会自动被拦截”。官方说明，检测先生成信号，执行动作需要客户另行决定。

配图为 AI 生成的概念示意图，并非产品截图或真实活动照片。

开放范围和检测边界

按照公告，已有 API Security 的客户可以使用相关能力；没有该产品的客户进入面向受邀企业的封闭测试。这不是对全部套餐正式开放的承诺。画像来自观测到的流量，没有画像的操作不会被此功能分类。

支持范围包括查询参数、请求头、Cookie、JSON 和表单编码请求体等。公告也列明若干限制：暂不支持 multipart、GraphQL 与 XML；不会单凭出现新参数就阻止请求，也不会学习并强制必填参数。读者应把这些边界纳入覆盖范围检查。

以下是假设场景：某查询接口过去只见过短编号，产品更新后开始接收更长的新编号。请求结构变化可能来自正常功能发布，也可能来自输入错误。因此，“和历史不同”可以成为调查线索，却不足以单独证明恶意。

评估时，应同时保留命中的路径、字段、发布版本与业务结果，再找应用负责人核对。若一批正常客户恰好使用新客户端，先看版本分布通常比立即收紧规则更有帮助。反过来，符合已学画像也不等于整个业务请求安全，权限与业务逻辑仍需要自身的控制。

本文建议先选格式稳定、业务负责人清楚、流量有代表性的少量操作，观察误报情况，记录什么条件会触发调查。不要把低频但合法的流程从验证样本中删掉，否则试点会显得很整齐，实际用户仍可能遇到问题。

新闻层面的意义是多了一种结构信号，可以和既有检查结合。实际启用执行规则之前，团队还需要明确谁能批准、如何观察影响、如何恢复。这些是部署判断，不能用厂商的功能发布替代。

主要来源：Cloudflare：Enforce positive security with Application Profiles（2026-09-29）。本文于北京时间 2026 年 10 月 1 日核验；产品开放范围仍以官方后续更新为准。