Codex
2.3 KiB
2.3 KiB
R2.2.16 任务报告
结论
用户 mail0795336304@163.com 的“卡住约 15 分钟”不发生在 Sub2API 的在途请求、账号排队或 proxy 3 出网阶段。服务端证据显示，上一笔请求于 2026-07-14 14:43:33（UTC+8）成功结束，下一笔直到 14:59:54 才进入 Sub2API，中间约 16 分 21 秒没有该用户的新入站请求。卡点因此位于 Sub2API 入站之前，优先怀疑客户端、本地 Agent 状态机或客户端到入口之间的请求提交链路。
原生运维证据
- 用户 ID：22；账号状态 active；用户并发上限 10，调查时 current concurrency 为 0。
- API Key：名称
pika_win、ID 46、分组unidesk-codex-pool；调查时 current concurrency 为 0。 - 最近 30 分钟共 7 笔请求，均为成功，无用户可见错误。
- 14:43:33 完成请求
client:1daa3f3e-99a5-4fc4-809c-6f6ef854a2b2，流式、gpt-5.6-sol，耗时 28.922 秒，账号 33。 - 14:59:54 下一笔请求
client:8d1f8ef9-e703-482c-ace9-0d8f13a5c8e3才进入服务端；内部 request IDefdb251f-8e86-4f18-99ee-fa1094419dc0，15:00:43 完成，HTTP 200，耗时 49.115 秒。 - 最新请求使用上游账号
https://api.iceiu.com plus 0.03（ID 33）、模型gpt-5.6-sol、proxy 3；没有 failover、select failure 或 forward failure。 - proxy 3 为
platform-infra-sub2api-pk01-local-egress-proxy，127.0.0.1:10809；对应 Hysteria 客户端自 7 月 8 日持续 active，调查窗口无错误日志，当前存在正常连接。
判定边界
Sub2API v0.1.153 当前原生 request 明细记录请求完成耗时，但未记录流式首字时间和逐事件间隔。因此不能从现有数据精确证明客户端何时展示首字；不过“16 分 21 秒无入站请求”、用户/API Key 并发均为 0，以及随后请求 49 秒正常完成，足以排除 Sub2API 内部排队、上游账号占槽 15 分钟和 proxy 3 在该窗口报错。
建议
让用户侧保留该时段客户端日志，重点检查本地 Agent 是否在上一轮完成后未推进状态、请求是否直到 14:59:54 才真正发出，以及本地 HTTP/SSE 客户端是否错误等待已经关闭的流。后续 CLI 可泛化补充按用户邮箱映射用户 ID、请求间空窗和 TTFT/末事件可见性；本次只读调查未取消请求，也未修改 runtime、YAML、proxy 或调度。