接口首字延迟高？排查 CPA 和 NewAPI 的正确姿势

最近在折腾 API 反代，遇到一个挺让人头秃的问题：明明带宽和上游都正常，但通过 CPA 加 NewAPI 出来的接口，首字延迟（TTFT）偶尔会高得离谱。

具体来说，使用 /v1/responses 这个接口时，延迟经常飙升，但换成 /v1/chat/completions 又丝滑得不行。甚至有时候 /v1/responses 又会突然恢复正常，这种玄学问题确实搞心态。

如果你也遇到了类似情况，特别是 RPM（每分钟请求数）只有 1 这种低负载场景，别急着怀疑是上游限流，我们一步步来排查。

CPA 首字延迟对比图

对比显示 /v1/responses 接口延迟较高，而 /v1/chat/completions 延迟较低

首先得明确，虽然都是 API 调用，但 /v1/responses 和 /v1/chat/completions 的处理逻辑可能并不完全相同。

上游差异：如果你的上游是 ChatGPT Plus 账号反代，不同的接口路径对应的上游服务器集群或者模型可能不一样。/v1/responses 可能被路由到了负载较高的节点，或者该接口在某些特定时间段会有额外的风控检测。
协议差异：SSE（服务器推送事件）流式传输的首字时间，往往受“冷启动”影响最大。如果 /v1/responses 涉及更复杂的前置处理（比如特殊的 Model 映射或鉴权），这部分时间就会被算进首字延迟里。

很多人觉得 CPA 挂着就行，其实有几个小细节很容易被忽略，导致莫名其妙的延迟。

商业模式模式：你说 RPM 只有 1，理论上不需要开“商业模式”（Commercial/Business Mode）。但有时候，如果 CPA 误判了流量或者配置残留，开启了某些排队或账单逻辑，就会导致请求被挂起几秒钟才转发。建议去 CPA 后台确认一下，低负载下务必关闭商业/计费相关的高级选项，直接走透传模式。
并发与链接复用：CPA 对 HTTP/1.1 和 HTTP/2 的处理方式不同。如果 NewAPI 和 CPA 之间没有配置好 Keep-Alive，每次请求都要重新握手，那首字延迟必然高。检查一下 CPA 的连接池设置，确保开启了长连接复用。

既然下游是 NewAPI，那它也可能是瓶颈。

渠道轮询与负载均衡：如果你在 NewAPI 里配置了多个渠道（比如你的 Plus 和 Codex），NewAPI 可能会根据策略自动切流量。有时候 /v1/responses 被分配到了一个响应慢的渠道策略上。试着在 NewAPI 里把请求强制绑定到某个特定的上游渠道测试一下。
超时设置：检查 NewAPI 中该渠道的超时配置。如果 Timeout 设置得过短或者过长，可能会导致重试或者等待，影响体验。

如果以上配置都没问题，还是有延迟，建议按这个顺序实操：

直连测试：绕过 NewAPI，直接用 CPA 请求一次 /v1/responses。如果直连快，说明锅在 NewAPI；如果直连也慢，那就是上游或者 CPA 到上游的网络问题。
切换节点：Plus 账号反代的 IP 段有时候会被“针对”。换个干净的网络节点试试，或者看看是否有 IP 被风控（通常表现为 403 或极高延迟）。
抓包分析：这是最硬核但最有效的方法。看看发出请求到收到第一个字节之间，TCP 握手花了多久，TLS 握手花了多久，服务器是在处理还是单纯没回包。如果是 TLS 慢，那是网络问题；如果是 TLS 完成后等半天才是数据，那是应用层排队问题。

低 RPM 下出现高延迟，大概率不是所谓的“官方限流”，更多是中间链路（CPA 或 NewAPI）的配置细节在作祟。先关掉多余的商业模式配置，检查连接复用，再逐步做隔离测试，大概率能找到那个导致“憋气”的环节。希望这篇能帮你省下几个抓狂的夜晚！