模型 API 接入验收：如何确认超时设置不会误杀慢请求？

一个内部知识助手切换到 nexo 中转站时，可能遇到短问答能完成、长输入一发就超时。作者参与该站运营，本文经 AI 辅助整理。以下用本地模拟端点验证客户端和代理的超时分工，时间数字只是演练参数。

给三种超时分别取证

先让模拟端点在收到请求后等待两秒再发送首段，然后每秒发一个片段。记录应用发起请求、收到响应头、收到首个有效事件以及收到终止事件的时间。首段到得晚和开始输出后中途停住是不同场景，应在日志里分别归类。

第一次把首段等待上限设成一秒，预期在任何文本出现前失败。第二次把首段上限放宽到三秒，但让服务在第二个片段后停四秒，空闲上限设成两秒。预期界面能显示已有片段，并将状态标记为中断。第三次按原来的每秒一段输出，单独设总时长上限，验证持续输出也不会无限占用任务。

找出究竟是哪一层先关连接

先让客户端直连模拟端点，记下三轮结果。再加入实际部署路径中的代理，保持应用侧配置一致。如果加入代理后才在固定时间断开，查代理的读取超时及应用是否及时向下游转发事件。如果两条路径都在同一应用上限断开，先验证客户端计时器是否按设计开始和重置。不要一次把所有超时都调大，否则无法看出哪项设置起作用。

把结果变成验收条件

针对首段慢、流中空闲和任务超期各保存一份记录，至少写下预期结束原因、实际结束原因和最后一个已读事件。再加一条正常结束用例，确认取消计时器后不会把完整回答改判为失败。上线时用自己的正常请求分布选上限，演练里的一秒和两秒只用来快速触发路径。