Cloudflare Gateway 怎么识别 MCP 流量：is_mcp 策略与 AI Security 报表实测

团队把 MCP 客户端接入办公网络后，最先遇到的不是“要不要允许”，而是“这批请求到底是不是 MCP”。Cloudflare Gateway 在 2026 年 8 月加入 MCP 协议识别，HTTP 策略里可以用实验性的 experimental.is_mcp 选择器单独匹配这类流量，AI Security 报表则负责回答它来自谁、去了哪些服务器、数量是否异常。

这次 Cloudflare Gateway 更新解决了什么

过去，Gateway 管理员通常只能按域名、IP、端口、用户或应用标签去猜测 MCP 流量。问题在于，同一个 HTTPS 出口里可能混着普通 API、网页访问和 MCP 请求，靠域名分类很容易把规则写得过宽。

新能力把识别层单独提出来：Gateway 通过协议特征判断请求是否属于 MCP，HTTP 策略再使用 Is MCP 选择器做允许、阻断或隔离。这个选择器目前仍是 beta，名称和行为可能调整，因此适合先做小范围验证，不宜直接当成永久合规边界。

先准备一个可回看的最小验证场景

验证目标不是立刻拦截所有 MCP，而是确认三件事：识别结果能出现、策略命中能解释、报表里的统计能与测试请求对上。建议准备一台测试客户端、一个已批准的 MCP 入口和一个暂不批准的入口，并给测试请求加上容易定位的时间窗口。

在 HTTP Policies 里创建第一条 MCP 观察规则

进入 Cloudflare One 控制台的 Gateway HTTP Policies，新建一条仅用于观察的规则。条件先保持最小：选择器设为 Is MCP，运算符设为 is，值设为 True。动作先选择记录或观察类动作，具体名称以当前控制台显示为准。

如果控制台还提供流量来源、用户、设备姿态或 MCP 门户条件，先不要一次性全部叠加。发出一条已知的 MCP 测试请求，再检查策略命中详情；如果没有命中，优先确认 Gateway 代理路径和策略顺序，而不是马上改成“允许所有”。

把“识别为 MCP”收窄成可执行的访问边界

确认识别稳定后，再加第二个条件。例如只针对不属于批准门户的 MCP 流量：

Is MCP       is       True
Traffic Source  is not  Approved MCP Portal
Action: Block

这条规则表达的是“非批准入口的 MCP 才阻断”，不是“所有 MCP 都阻断”。实际部署时还要核对组织的策略优先级、绕过角色和设备范围。若团队有多个代理出口，建议先按用户组或设备组灰度，保留一条明确的回退路径。

用 AI Security 报表核对策略是否真的生效

打开 Insights & Logs > Dashboards 下的 AI Security 报表，重点看四组信息：MCP 请求总量、唯一用户数、唯一 MCP 服务器数，以及针对 MCP 流量的 Gateway 策略摘要。验证时不要只看总量，最好把测试请求的时间段、用户和目标服务器一起对照。

1. 先记录观察规则启用前的请求量，作为基线。
2. 发起一条批准入口请求和一条非批准入口请求。
3. 回到策略详情，确认两条请求的命中动作不同。
4. 刷新 AI Security 报表，核对服务器数和策略摘要是否出现对应变化。
5. 把结果写进变更记录，注明 beta 选择器和测试时间窗口。

报表只说明 Gateway 观察到了什么，不等于 MCP 服务器本身可信。服务器的工具权限、返回数据和下游访问仍要在 MCP 客户端与服务端侧单独审查。

常见误区与回滚动作

最容易踩的坑是把协议识别当成身份认证：识别为 MCP 只能说明请求具备相关协议特征，不能证明调用者有权读取某个内部数据源。第二个坑是把 beta 选择器写进一条没有例外的全局阻断规则，导致批准门户也无法工作。

出现误拦截时，先停用新增策略，确认业务恢复，再查看命中记录定位是来源条件、策略顺序还是门户识别范围过窄。不要删除报表数据或覆盖原规则，这些证据对下一轮收窄条件更有价值。

相关问题

Is MCP 选择器能识别所有自定义 MCP 客户端吗？

不能直接保证。识别依赖 Gateway 能看到的协议特征与代理路径，客户端、传输方式或中间层变化都可能影响结果，应先用测试请求验证。

AI Security 报表能替代 MCP 权限审计吗？

不能。它主要帮助观察网络侧流量和策略命中，工具级权限、数据范围和服务端行为仍需要应用侧审计。

第一条规则应该直接 Block 吗？

更稳妥的做法是先观察，再按用户组、设备组或入口灰度阻断；确认批准门户不受影响后再扩大范围。

Cloudflare Gateway 的价值在于把“猜测 MCP 流量”变成可观察、可匹配、可回看的策略流程。真正上线前，保留观察基线、明确例外入口，并把 beta 能力纳入变更复查周期。