OpenAI Secure MCP Tunnels：工作原理（2026 指南）

2026 年 5 月 27 日，OpenAI 发布了 Secure MCP Tunnel。其承诺简单明确：在保持 MCP 服务器私密性的同时，仍允许 OpenAI 的产品对其进行调用。官方指南和客户端仓库已在本文末尾的来源部分完整列出，以便你在阅读完本指南后查阅原始文档。

1. TL;DR（摘要）

当你的 MCP 服务器位于笔记本电脑、虚拟机、Kubernetes 集群或私有网络中，且希望在不将其公开的情况下让 ChatGPT、Codex、Responses API 或 AgentKit 使用它时，请使用 Secure MCP Tunnel。你只需在服务器旁运行一个名为 tunnel-client 的小型守护进程。它通过 HTTPS 向 OpenAI 发起出站连接，通过长轮询获取任务，将每个请求转发给你的服务器，并将响应回传。无需入站端口，无需公共 URL，也无需 ngrok。

如果你的 MCP 服务器已经安全地公开（只需使用带有 server_url的常规托管 MCP 工具即可），或者你不愿意将 MCP 流量通过 OpenAI 托管的端点进行路由，则无需使用此功能。此外，请务必仔细阅读安全部分：该隧道移除了 网络和凭据泄露，而非 提示词注入或工具投毒风险。这些是不同的问题。

2. 它是什么

以下是直接摘自文档的定义，值得逐字引用，因为 AI 搜索引擎会直接抓取它：

“Secure MCP Tunnel 让您可以将私有 MCP 服务器连接到受支持的 OpenAI 产品，而无需打开入站防火墙端口或将这些服务器暴露在公共互联网上。”

关于隧道本身，深入一层： “MCP 隧道是从您网络内部的主机到 OpenAI 托管的 MCP 端点的仅限出站的连接。” 这一个词 — 仅限出站（outbound-only） — 是整个设计的核心。您的网络永远不会接受来自 OpenAI 的连接，只会主动发起连接。

MCP (Model Context Protocol) 是一种开放标准，允许 AI 模型通过 JSON-RPC 调用外部工具。普通的托管 MCP 工具需要一个公共 server_url — OpenAI 自己的示例指向了类似 https://mcp.stripe.com的内容。Secure MCP Tunnel 移除了这一要求。服务器可以保留在 localhost上。

3. 存在意义

在此之前，将私有 MCP server 连接到托管模型意味着必须在三种不理想的选择中做出抉择。每种选择都存在安全团队会拦截的故障模式。

1. 公开暴露。 将 MCP server 部署在带有 TLS 和身份验证的公共 URL 上。这会产生一个新的面向互联网的攻击面，且意外暴露的 MCP server 已被证实是现实世界中存在的问题。
2. 使用 ngrok 或 Cloudflare Tunnel 进行隧道传输。 虽然能用，但它只是一个通用的反向代理。快速隧道（Quick tunnels）“并非设计为安全边界”——默认开启 CORS，没有路径过滤，也不具备 MCP 感知能力。
3. 开放入站防火墙规则。 这是安全团队最不赞成的选项，也是开发者机器根本无法提供的方案。

Secure MCP Tunnel 的解决方案是反转连接。文档中说得很清楚：隧道访问“遵循现有的组织和工作区上下文，而不是引入一个独立的公共入口路径。”你无需建立一个新的前门，而是让一个由你控制的守护进程通过你现有的门向外连接。

4. 心智模型：核心组件

整个功能由五个部分组成。掌握这些术语，你就能一次性读懂文档。

数据流采用轮询循环机制，而非 OpenAI 在您网络中保持开启的持久化套接字。请从上至下阅读：

        OpenAI cloud                         Your network (trust boundary)
 ┌─────────────────────────┐          ┌──────────────────────────────────────┐
 │ ChatGPT / Codex /        │          │                                        │
 │ Responses API / AgentKit │          │   tunnel-client (daemon)               │
 │           │              │          │        │            │                  │
 │           v              │          │        │            v                  │
 │  OpenAI-hosted tunnel    │  <====== │  (1) outbound HTTPS long-poll          │
 │  endpoint  (queues work) │          │      GET /v1/tunnel/{id}/poll          │
 │           │              │  ======> │  (2) queued JSON-RPC request           │
 │           ^              │          │        │                               │
 │           │              │          │        v                               │
 │  (4) response returns    │  <====== │  (3) forward to private MCP server     │
 │      to the product      │          │      (stdio command or HTTP URL)       │
 └─────────────────────────┘          │        │                               │
                                       │        v                               │
                                       │   Private MCP server (localhost / VPC) │
                                       └──────────────────────────────────────┘
   The MCP server never has a public listener. Every arrow your network draws
   is OUTBOUND. OpenAI never initiates a connection into your boundary.

核心观点：轮询设计是关键所在。一个只进行外拨（dial out）的守护进程是防火墙和安全审查员能够真正理解和评估的，而持久化的入站套接字则不然。

5. 最小端到端示例

这是文档中原封不动的标准快速入门指南。它假设您已经在 Platform 隧道设置中创建了隧道并拥有其 tunnel_id。它将隧道指向本地的 stdio MCP server — 一个通过命令启动的 Python 脚本。

export CONTROL_PLANE_API_KEY="sk-..."

tunnel-client init \
  --sample sample_mcp_stdio_local \
  --profile local-stdio \
  --tunnel-id tunnel_0123456789abcdef0123456789abcdef \
  --mcp-command "python /path/to/server.py"

tunnel-client doctor --profile local-stdio --explain
tunnel-client run --profile local-stdio

三个命令即可完成工作。 init 从示例中写入一个命名配置文件。 doctor --explain 检查配置文件，并在你依赖它之前告知你任何不健康的原因。 run 启动守护进程的轮询循环。保持 run 存活状态，同时创建并测试连接器 — 文档明确指出“连接器发现和 MCP 工具调用依赖于正在运行的客户端。”

如果你的 MCP server 使用 HTTP 而非 stdio，只需切换一个标志 — 使用 --mcp-server-url 代替 --mcp-command：

tunnel-client init \
  --sample sample_mcp_stdio_local \
  --profile local-http \
  --tunnel-id tunnel_0123456789abcdef0123456789abcdef \
  --mcp-server-url https://mcp.internal.example.com/mcp

然后在接触 ChatGPT 之前，确认守护进程确实处于健康状态。 tunnel-client 暴露了操作员端点和一个回环管理 UI，正是为了实现这一点：

curl -fsS http://127.0.0.1:8080/healthz   # process is up
curl -fsS http://127.0.0.1:8080/readyz    # connected and polling
open    http://127.0.0.1:8080/ui          # local admin UI (loopback-only)

6. 各组件深度解析

6.1 请求生命周期

文档将该循环描述为五个步骤。产品向 OpenAI 托管的端点发送 MCP 请求。端点将其加入队列。 tunnel-client 对排队的工作进行长轮询，将每个 JSON-RPC 请求转发到你的私有 MCP server，并通过同一个隧道将响应发回。当连接器请求流式结果时，该路径可以转发中间的服务器发送事件（SSE），因此流式工具仍然有效。网络发起点始终保持在你的边界之内。

观点总结：“先长轮询，再仅转发你能处理的内容”为你提供了自然的背压机制。你的服务器永远不会受到来自 OpenAI 的惊群效应冲击 — 客户端会按照自己的节奏拉取工作。

6.2 tunnel-client 和配置文件

tunnel-client 是一个 Go 二进制文件，开源协议为 openai/tunnel-client. The docs are firm about distribution: get it from the Platform download link or the latest public release, and “keep your runbook pointed at the latest-release URL instead of hard-coding a specific release URL.” It is not on npm or PyPI. A profile 是一个命名配置（即上方的 local-stdio ），因此一台主机可以运行多个具有不同设置的隧道。你也可以通过环境变量和标志来驱动所有配置，其优先级为 flags > env vars > YAML > defaults。

核心建议：使用 profiles，而不是堆砌一堆标志。一个签入（checked-in）的 profiles/ 目录，并将密钥引用为 env:VARNAME 或 file:/path ，这决定了部署是可复现的，还是无法重建的一次性配置。

6.3 运行位置

在与 MCP server 处于同一信任边界且能够访问该服务的地方运行 tunnel-client 。文档中提到了三种模式：

• Kubernetes sidecar — 在同一个 Pod 中与 MCP server 并行运行，并通过 localhost连接。
• 专用 Kubernetes 部署 — 当服务器已经可以通过私有 Service 访问时，将其单独运行。
• VM 或 systemd 服务 — 在可以通过私有网络访问服务器的主机上运行。

核心建议：sidecar 是最简洁的默认方案。在同一个 Pod 中， localhost hop，一个生命周期。仅当多个工作负载共享同一个 MCP 服务时，才考虑使用专用部署。

6.4 权限与身份

Tunnel 访问使用您现有的组织和工作区上下文。它由三个权限原子控制，并映射到实际角色：

运行时 API key，即 tunnel-client 运行所需的 Read + Use。单独的管理身份需要 Read + Manage 来创建或编辑 Tunnel 元数据。请将它们分开 — 守护进程（daemon）绝不应拥有创建/删除权限。

核心建议：最小权限原则是内置的，请务必使用。长生命周期的守护进程获得 Use 权限，而人类用户或 CI 任务获得 Manage 权限，两者绝不共享同一个密钥。

6.5 Harpoon：允许列表（allowlisted）HTTP 调用

除了 MCP 之外， tunnel-client 内置了一个名为 Harpoon 的 MCP server，它通过标签暴露了一组有限的私有 REST endpoints，并对请求和响应的大小进行了限制。它的用途是访问少量内部服务，而无需将其公开。文档中明确指出：“Harpoon 不是通用代理：调用者无法选择任意主机，请求仅限于客户配置的目标和方法。”

观点总结：Harpoon 是手术刀，而不是 VPN。如果你发现自己想用它访问“任何内部资源”，说明它已经无法满足你的需求，你应该转而部署一个标准的 MCP server。

6.6 通过 tunnel 进行 OAuth

如果你的 MCP server 使用 OAuth，有一个注意事项如果不留意，可能会让你浪费一下午的时间。OAuth 发现（discovery） 可以通过 tunnel-client tunnel 传输，且 tunnel 会为面向浏览器的流程保留上游授权服务器的元数据。但是，正如文档所述：“授权服务器本身不会自动通过 tunnel 传输。如果它无法从公共互联网和

host 访问，那么即使 MCP server 可达，OAuth 流程仍可能失败。”

观点总结：虽然可以通过 tunnel 暴露 MCP server，但请确保 OAuth 授权服务器在浏览器和客户端运行的环境中是可访问的。如果 MCP server 可达但授权服务器不可达，会导致静默且令人困惑的故障。

7. 我们犯的错误

在首次运行中，我们有四个假设出了偏差。而这些恰恰是营销宣传语让你容易产生的误解。 我们假设“私有”意味着数据永远不会触及 OpenAI。 事实并非如此。你服务器的 地址 和 凭据

确实保留在本地，但 MCP 的请求和响应负载仍然会经过 OpenAI 的托管 endpoint，这与任何其他托管的 tool call 完全一样。tunnel 隐藏了你服务器的位置，但并不能让工具流量避开 OpenAI 的平台。如果负载敏感度过高，不适合发送给托管模型，那么使用 tunnel 也无法改变这一点。 我们假设它是“OpenAI 版的 ngrok”。

我们一直在寻找 npm install。 根本没有。 tunnel-client 是一个下载的二进制文件或来自 openai/tunnel-client的 Go 构建版本。我们浪费了十分钟，因为我们理所当然地认为存在一个软件包，毕竟其他所有 OpenAI SDK 都有。

我们曾以为隧道（tunnel）能让整个设置变得“安全”。 它确实保护了网络路径，但对于恶意或被篡改的工具调用却无能为力。被提示词注入（prompt-injected）的 Agent 仍然可以发出完全合法的请求，而你的服务器会照常执行。隧道只是一种网络控制手段，而非授权或内容控制手段。

8. 错误模式 vs 正确模式

9. 常见错误（源自文档）

这些内容直接摘自官方故障排除和配置说明，并附带了症状对应的根本原因。

• 在 ChatGPT 中无法看到 Tunnel。 根本原因： Tunnel 未与目标工作区关联，或者连接器操作员缺少 Tunnels Use 权限。请修正工作区范围和权限设置。
• 连接器发现或工具调用失败。 根本原因： tunnel-client run 已停止。发现和调用依赖于正在运行的客户端。请重启客户端并重新运行 doctor --explain。
• 可以查看 Tunnel 但无法进行编辑。 根本原因： 操作员拥有 Tunnels Read 权限但缺少 Manage 权限。请为负责编辑元数据的身份授予 Manage 权限。
• 尽管 MCP 服务器可达，但 OAuth 仍然失败。 根本原因： 授权服务器未通过隧道连接，且无法从公共互联网和客户端主机访问。请确保授权服务器可达。
• 通过 Tunnel 的请求间歇性失败。 根本原因： 客户端未连接。如果 tunnel-client 正在重新连接，请求会在恢复前失败。请监控 /readyz 和 /metrics。

10. 性能、扩展与成本说明

先说实话：OpenAI 并未发布针对 tunnel 的具体延迟或吞吐量数据，文档中也没有关于 tunnel 的定价记录。文档和仓库 确实 为你提供了调节行为的参数。

• 长轮询（Long-poll）计时。 客户端通过长轮询获取任务；轮询窗口和并发请求上限均可配置。你可以通过调整这些参数，在空闲连接数与任务获取延迟之间进行权衡。
• 连接 TTL。 MCP 连接窗口是有时限的（仓库默认值约为几分钟）。运行时间超过该窗口的工具必须通过流式传输进度或及时完成，否则会被强制中断。
• 背压（Backpressure）是天然具备的。 由于客户端是主动拉取任务而非被动接收推送，因此缓慢的 MCP 服务器会自行减缓任务摄入速度，而不会因负载过高而崩溃。你可以通过增加客户端数量或升级服务器性能来扩展，而不是通过硬抗流量洪峰。
• 成本。 对于托管的 MCP 工具，OpenAI 通常表示你只需为导入工具定义或进行工具调用时所消耗的 token 付费，没有额外的单次调用费用。针对 tunnel 的费用 文档中并未明确说明 — 在假设其大规模使用免费之前，请务必在 Platform 设置中进行核实。

11. 适用人群（及不适用人群）

12. 社区信号

该公告来自 OpenAI 的开发者账号，并由 Greg Brockman 转发，将其定义为“自带 MCP servers”。我们将发布推文移至文章顶部，以便读者能更早看到第一手背景信息，然后再深入了解技术细节。

这种架构并非 OpenAI 所独有。 Anthropic 在几周前就发布了功能类似的 MCP-tunnel 模式，而社区中最深入的讨论出现在 r/mcp 的一个帖子中，对比了两者：“Anthropic 的新 mcp tunnel 架构：agent 永远不会持有凭据。” 社区对此的共识是：肯定其 安全模型 —— 将凭据移至边界意味着被 prompt-injected 的 agent 没有 token 可窃取 —— 同时对厂商锁定持怀疑态度。

反对的声音值得引用。 该帖子中最高赞的评论清晰地指出了这种权衡：

“你并不拥有这个循环。你拥有的是边界。这笔交易对你是否划算，取决于你有多信任 [供应商] 来运行这个循环，以及你能承受多大程度的供应商锁定。”
— r/mcp，关于 tunnel 架构模式的讨论

该帖中的其他人提出了一个显而易见的问题：“有什么能阻止本地证书被泄露或窃取？”并指出，将风险点从令牌（tokens）转移到供应商的正常运行时间（uptime）上，只是转移了风险，而非消除风险。这些观点很中肯。Tunnel 是一种权衡：减少了网络暴露，但增加了对 OpenAI 托管控制平面的依赖。

13. 结论：值得使用吗？

14. 更大的格局

Secure MCP Tunnel 是更大变革中的一步：各大模型供应商正在竞相实现 您的私有工具 可供以下使用： 它们托管的 Agent 无需您暴露任何内容。Anthropic 这样做了，OpenAI 也这样做了。这种共享模式 — 仅限出站、凭据位于边界、由供应商运行循环 — 正成为企业级 Agent 连接的默认形态。预计 Google 和其他公司也会以不同的名称推出相同的原语。

关于后续的实际操作步骤，我们的 MCP Servers Setup Guide 涵盖了如何将服务器连接到 IDE， Build Your Own MCP Server 教程展示了如何编写您想要放置在隧道后的服务器，而 OpenAI Agents Python SDK guide

则解释了使用这些工具的更广泛的 Agent 运行时。

15. 常见问题解答

• MCP16. 术语表
• : Model Context Protocol，一种允许模型通过 JSON-RPC 调用外部工具的开放标准。MCP server
• : 一个向 MCP client 暴露工具、资源和提示词（prompts）的进程。Secure MCP Tunnel
• : OpenAI 的一项功能，用于在没有公共监听器的情况下将私有 MCP server 连接到其产品。tunnel-client
• OpenAI 托管的 tunnel 端点：OpenAI 产品调用的公共边缘节点；它负责为你的 tunnel 排队任务。
• tunnel_id：tunnel 的标识符，格式为 tunnel_ 加上 32 个十六进制字符。
• 运行时 API key：该凭据 tunnel-client 所使用的凭据；需要 Tunnels Read + Use 权限。
• 仅限出站 (outbound-only)：流量始终从你的网络内部发起；OpenAI 绝不会主动拨入。
• 长轮询 (long-poll)：客户端保持一个 HTTP 请求开启以等待排队任务，而不是被动接收推送。
• stdio 传输：一种通过命令启动，并使用标准输入/输出进行通信的 MCP server。
• Harpoon：一个嵌入在 tunnel-client 中的 MCP server，用于受限的私有 HTTP 调用白名单。
• mTLS：双向 TLS，即客户端和服务器均需提供证书；对于控制平面和 MCP 端是可选的。
• 连接器 (connector): 指向工具源（包括 tunnel）的 ChatGPT 端对象。
• Responses API 托管的 MCP 工具: mcp tool type that lets the API call an MCP server, normally via a public server_url.

17. 所有来源与链接

主要来源

• OpenAI: 安全 MCP Tunnel 指南
• GitHub 上的 openai/tunnel-client
• OpenAI: MCP 和 Connectors（托管式 MCP tool）
• MCP 授权规范 (OAuth 2.1)

社区

• @OpenAIDevs: 安全 MCP Tunnel 发布推文
• r/mcp: 隧道架构与锁定 (lock-in) 批判
• r/OpenAI: 对 ChatGPT MCP 支持的反应

Web 与安全背景

• Invariant Labs: MCP 工具投毒攻击
• Cloudflare: 远程 MCP servers（现有技术隧道方案）
• Solo.io：MCP 服务器中的安全漏洞

内部链接

• MCP 服务器设置指南
• 构建你自己的 MCP 服务器
• 热门 MCP 服务器目录
• OpenAI Agents Python SDK 指南