# R2.4.1 任务报告

## 结论

用户 `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 ID `efdb251f-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 或调度。
