HTTP 负载均衡器后的 MCP 2026-07-28：路由与安全的缓存范围

是什么

本文反映截至 2026年10月25日的情况。MCP 2026-07-28 允许每个 HTTP 请求携带独立处理所需的上下文。修改网关规则前，应重新核对相应版本的 Streamable HTTP、缓存和工具规范。常规负载均衡与正确的结果缓存，是两项独立的部署决策。

核心协议不再要求传输会话。跨请求的应用状态仍需要明确的标识符和适当的存储。请求也可能得到流式响应；无状态并不意味着每个连接都很短暂。

为什么重要

RFC 9111规定，普通 HTTP 缓存键以 HTTP 方法和目标 URI 为基础，并在有规定时纳入额外的区分维度。MCP 操作共用一个 POST 端点，而方法和参数位于 JSON 内部。由此可推断：仅以 /mcp 为键的通用缓存无法安全地区分这些操作。JSON 中的 ttlMs 不是 HTTP Cache-Control 头，也不会自动配置代理。

工具列表可以因授权不同而变化，但不得因连接历史而变化。在可用工具集合未变时，建议保持确定的排序。这两个特性都不能让经过权限过滤的目录成为公开数据。

如何应用

• **保留并验证路由元数据。**转发 MCP-Protocol-Version 和 Mcp-Method；对于 tools/call、resources/read 和 prompts/get，还必须提供 Mcp-Name。处理请求体的服务器必须拒绝请求头不匹配或缺少必需请求头的请求，返回 HTTP 400 和 HeaderMismatch（-32020）。比较前，按规定的编码方式解码名称。在缺少相应校验要求的旧版路径上，不要信任这些与请求体对应的请求头。
• **不要将敏感输入放入路由请求头。**工具模式可以通过 x-mcp-header 暴露参数；工具规范建议不要用它标记密码、令牌或个人数据，因为中间节点可以看到这些内容。应使用获准的元数据进行路由，并在实际执行操作时保留授权校验。
• **保留流式传输。**支持 JSON 和 SSE 响应，关闭不适当的响应缓冲，并检查空闲超时行为。传输规范建议 SSE 使用 X-Accel-Buffering: no，长连接流使用保活注释。不要为此修订版配置 Last-Event-ID 恢复，也不要缓存订阅流。
• **限定可缓存的结果。**完整的发现、工具列表、提示词列表、资源列表、资源模板列表和资源读取结果必须包含缓存提示。中间态的 input_required 结果，以及携带 inputResponses 或 requestState 的请求不得缓存。不能仅凭工具被描述为只读，就推断其执行结果可以缓存。
• 分别落实有效期和隔离要求。ttlMs 以收到结果的时刻为起点，以毫秒计时；零表示立即过期。相关变更通知会使仍在有效期内的缓存条目失效。public 仅允许共享非用户专属数据；private 将复用限制在同一授权上下文内，包括为不同令牌使用独立缓存。以服务器、协议、方法和影响结果的参数构建条目键；分页的各页必须分别区分。
• **缓存结果，不复用过时的消息封装。**理解 MCP 的中间节点必须返回当前请求的 JSON-RPC ID。保留原来的有效期截止时间，不要在缓存命中时重新计时。对于普通 HTTP 代理，除非已明确实现并验证其 MCP 行为，否则应禁用 POST 缓存。如果必须禁止存储，除了应用策略，还应使用 HTTP no-store 指令；单靠 private 仍允许私有缓存存储。
• **使用彼此隔离的测试身份验证。**建议在预发布环境检查：交替访问不同实例、以不同权限获取同一列表、修改目录、让条目过期，以及用不同请求 ID 复用符合条件的结果。确认流式内容及时送达，并且不存在跨用户复用。

常见陷阱

TTL 是有效期提示，不保证数据不会变化。按请求头路由不等于身份验证。请求成功经过负载均衡，也不能证明具有副作用的操作可以安全重试。在启用基础设施优化时，应明确保留这些由应用决定的规则。