应用平台对接内网模型：OpenAI 兼容网关配置要点
内网模型接入的故障现场，往往长得不像“模型坏了”。上游服务本身健康，直连测试也通，但应用平台一调用就超时、返回 404，或者干脆长时间无输出。真正变化的是三个边界同时被替换了：网络边界从公网出口变成内网服务，信任边界从厂商签发的密钥变成内部凭证，协议边界从完整的 SaaS 端点变成只实现了部分接口的网关。
下面讨论的是接入侧的通用配置与排查方法。不同应用编排平台对同类配置的字段命名并不一致（有的叫 Base URL，有的叫 API Base），这里统一按语义描述；落到具体平台时，字段名与支持范围以其自身文档为准。
base_url 到最终请求路径的拼接
OpenAI 兼容接口的常见约定是：客户端持有一个 base URL，调用时在其后附加资源路径，例如 /v1/chat/completions。这意味着同一段 /v1 只应出现一次。
当网关把 /v1 写进路由前缀、平台侧又按默认约定再拼一次时，落到上游的就成了 /v1/v1/chat/completions，表现为 404 或 405，而模型服务完全正常。定位这类问题不要读平台报错，要在网关访问日志里看最终 upstream 的 path——那是唯一能确认拼接结果的地方。
末尾斜杠是第二个易错点。base URL 带不带结尾 /，会分别拼出 //v1/... 或吃掉最后一段路径。工程上建议：base URL 只写到版本号的上一级且不带结尾斜杠，由客户端补全资源路径；如果网关做了路径重写，重写目标必须以 / 开头，并单独为它写一条测试用例。
还有一个容易被忽略的差异：部分内网网关只放通了对话接口，没有实现 /v1/models 一类的元信息接口。如果平台的连通性测试会先探元信息接口，就会出现“测试不通过、但实际对话可用”的现象。这属于测试方法与实现范围的错配，不必按故障处理，但需要在交付时说明清楚。
鉴权头的两种落法
内网场景下，Authorization: Bearer 通常有两种处理方式。
一是透传：平台按约定发送 token，网关原样转发给上游。此时要确认 token 是发给谁的、有效期多长、上游是否校验完全相同的字符串。
二是换发：网关持有真实的上游凭证，对平台侧只校验自己的 token，再替换成上游凭证转发。这种方式更常见，因为上游密钥不必分发到应用团队。代价是网关必须区分“平台 token 校验失败”和“上游返回 401”这两种情况——前者是配置错误，后者是网关自身凭证过期或权限不足，如果混在同一个状态码里，排查方向会完全不同。可行的做法是让网关在响应体或日志中标注拒绝来源。
无论哪种模式，都应避免把上游长期密钥写进应用平台的可视化配置页；如果业务上必须这么做，至少要限制该凭证可调用的模型与配额，并让它可被单独吊销。
流式响应与超时分层
聊天类请求默认可能是流式（SSE）。链路上任何一跳做了响应缓冲，都会把逐字返回变成一个长时间无输出、最后一次性返回的“卡死”。反向代理层通常需要针对该路径关闭响应缓冲，并确认上游返回的 Content-Type: text/event-stream 没有被改写。以 Nginx 为例，常见的调整点是响应缓冲与读超时相关指令；换成其他网关产品，具体参数需要以其文档为准。
超时也不是一个数值，而是分层存在的：连接建立超时、等待首字节超时、两个数据块之间的间隔超时，以及平台自己的请求总超时。模型推理的首 token 延迟可以明显长于普通业务 API，如果第一层沿用面向短请求的默认值，长上下文请求会稳定失败。
一个实用的配置原则是：让每一跳的超时都严格大于它下游一跳的超时。否则最外层会先于内层放弃，你只能看到“平台超时”，无法判断是上游慢、网关等不到，还是中间某一跳提前断开了连接。
TLS 信任与内网寻址
内网模型服务常用自签证书或企业 CA 签发的证书，几处必须对齐：
- 证书的 SAN 要包含客户端实际访问的域名。用 IP 直连而证书只签了域名，校验会直接失败。
- 客户端环境的信任库要导入完整的签发链，而不是只导叶子证书。Java、Python、Node.js 各自的信任库位置不同，需要分别确认。
- 如果由网关终止 TLS、再以明文访问上游，那么证书校验只发生在平台到网关这一段；如果要求端到端加密，上游证书同样要被网关信任。
- 证书轮换应提前演练，避免某次续期后出现全量调用失败。
寻址方面需要确认：平台所在的容器或主机解析到的是 VIP、Kubernetes Service 名还是具体实例；如果环境里配了全局 HTTP 代理，必须把内网地址加入 NO_PROXY，否则请求会绕到外部代理再失败，而报错信息通常只显示连接超时。
一套逐跳验证顺序
排查这类问题，分层验证比反复改配置有效：
- 在上游所在网段直连模型服务，用
curl -sS -i https://model.internal/v1/models -H "Authorization: Bearer $TOKEN"确认路径、鉴权、证书三项同时成立。 - 在网关所在主机重复同一请求，但指向网关地址，确认转发与路径重写正确。
- 在平台所在环境执行同一请求，确认 DNS、代理、出网策略没有额外拦截。
- 在平台内先发起一次非流式调用，再发起一次流式调用，对比差异——流式失败而非流式成功，基本可以锁定缓冲或超时问题。
每次记录都要包含四项：请求 URL、状态码、端到端耗时、上游耗时。缺少上游耗时，就无法区分“上游慢”和“网关等不到”。
边界在哪里
协议层能解决的是路径拼接、鉴权传递、超时和证书这四类问题。参数语义是否被上游接受（例如采样参数、输出长度上限、工具调用等字段是否被透传和实现），属于平台与上游各自的实现范围，需要在联调阶段逐项验证。不同实现对 OpenAI 兼容接口的覆盖程度并不一致，“接口名相同”不等于“行为相同”。把这两件事分开处理，内网模型接入的排查成本会下降很多。