MCP Gateway（MCP 网关）vs 代理 vs 注册表：你到底需要哪个

MCP 网关（MCP Gateway） 是位于 AI 客户端和众多 MCP 服务器之间的单一入口。客户端只需连接网关一次；网关负责认证用户、决定他们能看到和调用哪些工具、把每次调用路由到正确的上游服务器、注入凭据，并记录发生的一切。你可以把它理解为专为 Model Context Protocol 打造的 API 网关。

MCP 代理（proxy）是更简单的基础组件（转发 MCP 流量，通常还负责传输方式的转换），而注册表（registry）是告诉你有哪些服务器存在的目录。大多数团队一开始直接连接服务器，遇到传输方式不匹配时加一个代理，等到多人或多个 Agent 共享同一批服务器时再引入网关。本文讲清三者的区别、值得为之付费的功能，以及今天真正可以部署的网关。

为什么会有 MCP 网关

MCP 本身是一个简单的客户端-服务器协议（参见 MCP 如何工作）。每个客户端都要分别连接每个服务器。对于在 Claude Code 里用三个服务器的个人开发者来说，这没问题。但在以下情况就撑不住了：

• 10 个客户端 × 10 个服务器 意味着 100 条配置，每条都保存着自己的 API Key。
• 没人能回答"谁调用了哪个工具？"，因为每个服务器都用自己的方式记录日志（或者根本不记录）。
• 每个服务器各自实现 OAuth，有些干脆没实现。
• Agent 看到的工具太多。 把所有服务器的所有工具都加载进来，会撑大上下文，也增加模型选中危险工具的风险（参见 MCP 工具发现）。

网关把这些问题集中到一个地方处理，就像当年 API 网关之于 REST 微服务。

MCP 网关 vs 代理 vs 注册表

这三个词在营销文案里经常混用，下面是它们在实践中的区别：

两点实用说明：

• 网关是带有主见的代理。 每个网关都会代理流量，但不是每个代理都是网关。如果它不处理身份、策略和审计，就叫它代理。
• 很多网关内置注册表。 ContextForge 和 MCPJungle 都自称"注册表 + 网关"：服务器注册一次，网关就把它们暴露出去。而像官方 MCP Registry（仍处于预览阶段）这样的公共注册表只发布 server.json 元数据，从不出现在请求路径上。

MCP 网关的核心功能

比较产品时，重点检查这六项能力。

1. 认证与 OAuth 终结

网关应该是客户端直接对话的、受 OAuth 保护的资源。用户通过你的身份提供商登录一次，然后网关用自己的凭据调用上游服务器。这一点很重要，因为 MCP 规范明确禁止 Token 透传（token passthrough）：根据安全最佳实践，MCP 服务器"MUST NOT accept any tokens that were not explicitly issued for the MCP server"（不得接受任何并非明确签发给该 MCP 服务器的 Token）。一个把客户端 Token 原样转发给下游 API 的简单代理就违反了这条规则。同一文档还描述了针对 OAuth 代理的 confused deputy（混淆代理人） 攻击，并要求实现按客户端的授权同意。完整流程见 MCP 认证与 OAuth。

2. 策略与访问控制

谁可以使用哪个服务器、哪个工具？好的网关会把这件事绑定到身份组或角色上，而不是共享的 API Key。Microsoft 的网关使用 Entra ID 应用角色；Kong 使用 Consumer 和 Consumer Group ACL；Cloudflare 使用 Zero Trust Access 策略。

3. 工具过滤与精选

按客户端暴露工具子集：给客服机器人只读工具，给工程师完整工具集。这既是安全控制，也是上下文窗口优化。留意是否支持白名单、按工具启用/禁用，以及重命名或改写工具描述的能力（Cloudflare portals 支持别名和描述覆盖）。

4. 审计日志与可观测性

每次工具调用都应记录用户、客户端、工具名、参数（必要时脱敏）和结果状态。支持 OpenTelemetry 导出更好，这样 MCP 流量能和你其他的链路追踪放在一起看。

5. 多路复用与聚合

一个入口，多个服务器。网关合并所有上游的 tools/list 结果，给名称加命名空间以避免冲突（MCPJungle 使用 server__tool 约定），并把每个 tools/call 路由到正确的后端。有些网关更进一步，把普通 REST API 包装成 MCP 工具（ContextForge 和 Kong 都支持）。

6. 密钥管理

上游 API Key 存放在网关里，而不是散落在每台笔记本上。Docker 的网关在启动时把密钥注入服务器容器；ContextForge 会加密存储认证密钥。有些网关还会在工具响应中屏蔽密钥或个人信息（Lasso 的插件）。

这些功能所应对的完整威胁模型，请阅读 MCP 安全最佳实践。

2026 年的 MCP 网关选择

下面每个产品都在 2026 年 10 月对照其官方文档或代码仓库核实过。

Docker MCP Gateway

Docker 的网关把每个 MCP 服务器作为隔离容器运行，并通过一个入口统一暴露。你把服务器分组到 profile 中，用 docker mcp gateway run --profile <name> 启动，再把 Claude Code、Cursor 或 VS Code 连上去。它作为 docker mcp CLI 插件随 Docker Desktop 一起提供，也可以通过 Compose 无界面运行。完整教程：Docker MCP Gateway 配置指南。

Microsoft MCP Gateway

运行在 Kubernetes 上的反向代理和管理层。它负责路由（每个服务器对应 /adapters/{name}/mcp，外加一个 /mcp 工具路由）、部署和管理服务器实例，并使用 Microsoft Entra ID Bearer Token 和应用角色对请求授权。它包含 REST 控制面和 Web 管理门户。如果你的服务器已经运行在 AKS 或其他 Kubernetes 集群里，就选它。

IBM ContextForge

采用 Apache-2.0 许可的注册表兼网关，把 MCP 服务器、A2A Agent 和 REST/gRPC API 联合到一个入口之后。亮点功能：虚拟服务器（把选定的工具打包成一个新的 MCP 入口）、REST 转 MCP、管理 UI、丰富的插件库以及 OpenTelemetry 追踪。安装方式：

pip install mcp-contextforge-gateway

或者运行 ghcr.io/ibm/mcp-context-forge 容器。没有 JWT_SECRET_KEY 和 AUTH_ENCRYPTION_SECRET 它会拒绝启动；README 里说明了如何生成。

Kong AI MCP Proxy

如果 Kong 已经是你的 API 网关，AI MCP Proxy 插件可以桥接 MCP 和 HTTP：代理现有 MCP 服务器、把 REST API 转换为 MCP 工具，或者把多个插件实例的工具聚合成一个 MCP 服务器。按工具的访问控制使用 Consumer ACL。它需要 Kong Gateway 3.12+，属于 AI Gateway Enterprise 产品的一部分。

Cloudflare MCP server portals

Cloudflare Zero Trust 中的托管方案。一个 portal 把多个 MCP 服务器放在形如 https://subdomain.your-domain/mcp 的同一个 URL 之后。用户通过 Cloudflare Access 登录；Allow 策略决定每个用户能看到哪些服务器；管理员精选要暴露的工具和提示词；Access 会记录工具请求。你需要一个托管在 Cloudflare 上的域名，并在 Zero Trust 中配置好身份提供商。文档提醒：除非 Access 同时也是上游服务器的 OAuth 提供方，否则被拦截的用户仍可通过直接 URL 访问该服务器，所以源站也要锁好。

MCPJungle

自托管的"注册表 + 网关"，提供单一入口（默认 http://localhost:8080/mcp）。它支持工具组（在独立入口暴露精选的工具子集），以及带客户端白名单、访问 Token 和指标的企业模式。通过 brew install mcpjungle/mcpjungle/mcpjungle 或 Docker Compose 安装。

Lasso MCP Gateway

基于插件的本地网关（pip install mcp-gateway），读取你现有的 mcp.json，启动其中的服务器并对流量做净化。插件可以屏蔽密钥和 Token（basic）、通过 Presidio 屏蔽个人信息（presidio）、应用 Lasso 托管的护栏（lasso，需要 API Key），或追踪调用（xetrack）。--scan 模式会在使用前检查服务器信誉和工具描述。

什么时候需要 MCP 网关（什么时候不需要）

你可能不需要，如果：

• 你是个人开发者，只用几个本地服务器，比如 Filesystem 或 Playwright。客户端的配置文件就是你的网关。
• 你只用已经正确实现 OAuth 的官方远程服务器，比如 GitHub MCP Server。直接连接即可（远程 MCP 服务器指南）。
• 你只是需要把 stdio 服务器变成 HTTP 服务器。这是代理的活，不是网关的活。

你很可能需要，如果：

• 不止几个人或 Agent 共享同一批服务器，而你希望在一个地方添加、移除或撤销访问权限。
• 安全或合规部门要求每次工具调用都有可归属到用户的日志。
• 上游 API Key 目前被粘贴在许多笔记本的配置文件里。
• 你希望每个团队或每个 Agent 拥有不同的工具集，或者需要对生产 Agent 隐藏破坏性工具。
• 你要把内部 API 暴露为 MCP 工具，并希望在前面加上认证、限流和审计。

如何选择： 本地开发栈选 Docker；Kubernetes 加 Entra ID 选 Microsoft；已经在用 Kong 或 Cloudflare 就用现成的；开源自托管且需要广泛协议支持选 ContextForge；轻量级团队方案选 MCPJungle；在现有配置之上加防数据泄露选 Lasso。无论选哪个，都要确认它是终结认证，而不是透传 Token。

下一步

• 在 mcp.so 浏览 MCP 服务器，规划网关后面要接哪些服务器，或按分类探索。
• 用 Docker MCP Gateway 配置指南在十分钟内本地试用一个网关。
• 上生产之前，回顾 MCP 安全最佳实践和 MCP OAuth 认证。