OpenAI 推出 Secure MCP Tunnel 让私有 MCP 服务器无需公网暴露

我们构建 Secure MCP Tunnel，是因为团队最看重的 MCP 服务器，往往正是他们最不愿暴露到互联网上的那些。

我们想分享我们是如何应对这一约束的：让私有服务器保持私有，同时仍为 ChatGPT、Codex 及其他 OpenAI 产品提供正常的 MCP 请求路径。

Model Context Protocol 让 AI 系统更容易连接外部工具和数据。但许多最有价值的 MCP 服务器运行在企业网络、私有服务网格、开发者笔记本电脑以及其他旨在拒绝入站公网流量的环境中。将这些服务器连接到托管式 AI 产品，通常需要团队创建公网端点、部署额外的代理基础设施，或将新的网络运维方引入敏感路径。

Secure MCP Tunnel 提供了一种更简单的方法： 客户在其私有环境内运行一个小型客户端，该客户端与 OpenAI 建立出站 HTTPS 连接。该客户端：

1. 接收 MCP 请求
2. 将其转发到已获批准的本地服务器
3. 通过同一连接返回响应和通知。

OpenAI 产品可以使用标准的 MCP 请求和响应模型，而底层服务器仍处于客户现有网络控制之后。

要让这一机制可靠且安全地运行，需要同时解决若干工程问题：保留服务器的私有网络边界、支持 MCP 的流式传输和身份验证流程，并为团队提供一个可检查、可操作的客户端。本文将逐一介绍这些决策。

我们围绕一小组原则设计了该隧道：仅出站连接、显式目标配置、与 MCP 流式传输和通知兼容，以及一个由客户运行、团队可自行检查和操作的客户端。

这些原则共同使得将私有工具和数据轻松连接到 OpenAI 产品成为可能，而无需将私有 MCP 服务器变成公共服务。

错误的默认做法

如今，团队通常通过三种方式之一让私有服务可被访问：暴露公网端点、运行第三方隧道，或通过 VPN 或对等连接扩展网络。

• 公网端点通过削弱边界来让访问变得容易。
• 第三方隧道提供商可以快速让私有服务器可被访问，但它也引入了另一个需要审查、签约、运营并在连接路径中信任的供应商。对于企业团队来说，这不是一个小细节：隧道提供商成为安全审查、采购流程、运维手册和元数据面的一部分，而这个系统的目的恰恰是让私有工具保持私有。
• VPN 和网络对等连接通过创建广泛的网络连通性来解决可达性问题，对于狭窄的 MCP 集成来说，这往往是大材小用。

Secure MCP Tunnel 采取了更聚焦的方法。它不要求客户迁移 MCP 服务器、扩展网络边界或引入另一个连接供应商，而是将一个小的、可检查的开源客户端放在私有服务器旁边，让该客户端发起并控制与 OpenAI 的连接。

Secure MCP Tunnel 将可达性反转过来：由私有侧主动发起连接。OpenAI 产品将 MCP 请求发送到 OpenAI 托管的隧道端点。隧道服务将工作排队到特定隧道，而客户运行的客户端（已运行在私有 MCP 服务器旁边）通过出站 HTTPS 拉取该工作。客户端在本地转发请求，并通过同一路径返回响应。

这让 OpenAI 产品拥有一条正常的 MCP 请求路径，而无需私有服务器接受入站公网流量，也无需建立更广泛的网络连接。

为什么从长轮询开始？

我们有意从一种在运维上平淡无奇的传输方式开始。出站 HTTPS 对企业防火墙、代理环境和平台团队来说早已熟悉。长轮询让隧道客户端只请求它能处理的工作量，这为客户端侧队列提供了天然的背压点，而不是鼓励无限制的缓冲。

这一选择也让交付的形态易于理解：

1. 产品将 MCP JSON-RPC 发送到 OpenAI 托管的端点。
2. 隧道服务保持或流式传输该请求，直到客户运行的客户端返回最终响应。
3. 当请求流式结果时，隧道可以转发中间的服务端发送事件。

结果是产品拥有一条正常的 MCP 请求/响应路径，而 MCP 服务器及其地址保持私有。请求、响应和中间事件都通过 OpenAI 托管的隧道端点中继。

保持安全边界明确

隧道不是消除网络边界的方式，而是让该边界变得明确的方式。客户运行的隧道客户端向隧道控制平面进行身份验证，产品侧使用 OpenAI 托管的隧道端点，而私有 MCP 地址仅在客户环境内部使用。隧道访问与客户现有的 OpenAI 组织和 workspace 上下文以及配置的隧道身份绑定，而不是成为一条拥有自己访问模型的独立网络路径。

该设计不仅仅取决于选择正确的网络方向。由于隧道客户端运行在客户环境内部，其行为必须可检查且有意保持狭窄：客户应能理解正在运行什么代码、它打开什么出站路径，以及它被允许访问哪些私有服务。

让 MCP 开发感觉像本地开发

我们希望隧道客户端感觉像开发者工具，而不是网络项目。开发者应该能够在笔记本电脑上运行 MCP 服务器，在其旁边启动隧道客户端，并将该服务器连接到 ChatGPT 或 Codex，而无需创建公共端点，也无需等待 VPN、防火墙规则或对等连接变更。

当服务器从笔记本电脑迁移到 Kubernetes、VM 或其他客户控制的环境时，同样的流程应能延续。重要的是心智模型保持不变：在私有 MCP 服务器附近运行客户端，验证客户端可以访问它，并让客户端发起面向 OpenAI 的路径。健康检查、就绪状态、日志和本地管理 UI 的存在是为了在出现问题时让该循环可检查，而不是将隧道变成运维项目。

开发者体验同样体现在 Codex 本身。隧道客户端包含一个 Codex 插件，它将设置过程转变为引导式工作流，而不是要求开发者预先学习每一个 tunnel-client 标志、配置文件和管控平面细节。目标不是创建一个一次性的本地捷径：该插件应生成相同的配置形态，以便团队在服务器从笔记本电脑迁移到 Kubernetes、虚拟机或其他生产环境时能够沿用。

同样的思路也体现在 tunnel-client 附带的助手工作流中：由于助手可以读取 tunnel-client 暴露的本地隧道上下文，它能够帮助开发者基于实际设置进行推理，而不是给出通用指令——哪个配置文件处于活动状态、生成了什么配置、本地 MCP 服务器是否可达，以及隧道客户端处于启动路径的哪个位置。 这使得故障排查成为开发者循环的一部分，而不是一条单独的升级路径。

为什么开源隧道客户端很重要

该隧道客户端是开源的、由客户运行的软件，位于客户边界之内、紧邻私有 MCP 服务器。这为客户和安全审查人员提供了一种检查其环境内运行代码的方式。客户和安全审查人员可以检查客户端做了什么、它打开了什么出站连接、它如何在本地转发 MCP 请求，以及哪些配置控制着它的可达范围。

这种透明度使信任模型与架构保持一致：OpenAI 托管隧道服务，但在客户环境内运行的代码很小、可审查，并且处于客户的控制之下。

无需广泛网络访问的企业级认证

私有 MCP 服务器很少只是匿名的内部 HTTP 端点。它们可能依赖 OAuth、私有证书颁发机构、出站代理或 MCP 跳上的客户端证书。支持这些服务器意味着将企业网络假设视为隧道设计的一部分，而不是客户必须绕过的例外情况。

关键约束是 MCP 服务器仍然保持私有。MCP 服务器的 OAuth 发现通过隧道路径传输，因此托管产品可以了解如何进行认证，而无需 MCP 服务器在公共互联网上监听。在客户侧，隧道客户端可以针对本地环境进行配置：自定义 CA 捆绑包、代理设置和 MCP 侧 mTLS。

我们还保持了边界的明确性。隧道不会自动使所有相关的企业端点都能从 OpenAI 访问。如果授权服务器是私有的，它仍然必须能被执行 OAuth 流程的组件访问。这个边界是有意为之的：Secure MCP Tunnel 提供了一条通往已配置私有工具的狭窄路径，而不是一个通用网络桥接。

超越 MCP

MCP 是模型工具的主要形态，但与客户的早期 alpha 测试表明，还存在一个密切相关的问题：并非每个客户私有工作流都已经打包为 MCP 服务器。一些重要工作流是位于同一防火墙边界之后的现有 REST API。如果 Secure MCP Tunnel 只解决 MCP 可达性，团队仍然需要为这些相邻的私有 API 单独设置公共端点、隧道提供商、VPN 路径或对等互联项目。

Harpoon 将同样的窄连接模型扩展到已批准的 REST 目标。客户无需暴露任意 URL，而是在隧道客户端上注册带标签的目标。OpenAI 侧的调用方通过 Secure MCP Tunnel 调用这些标签，而实际的 HTTP 请求仍然源自客户环境内部，紧邻私有服务。

重要的约束在于，标签并非通用网络桥接。调用始终受限于客户拥有的目标注册、允许的方法、响应大小限制、超时、重定向行为以及隧道访问控制。这为已批准的 OpenAI 工作流提供了一条通往客户私有 API 的受控路径，而无需客户开放入站网络访问，也无需赋予 OpenAI 类似 VPN 的身份。

资源

• GitHub 上的 tunnel-client
• Secure MCP Tunnel 指南