pikasTech-unidesk/docs/MDTODO/details/sub2api-upstream-reliability/R2.7.3_Task_Report.md

R2.7.3 Grok 账号测试与网关路径复核报告

新证据

用户在 Sub2API 管理端对 https://sub.yjxm1221.top grok 执行账号连接测试成功：账号类型为 API Key，模型为 grok-4.5，上游返回正常文本。这证明账号凭据、base URL 和最小 xAI Responses 请求可用。

网关复测

使用绑定 Grok 分组的 Sub2API Key，经公开 /v1/responses 复测：

• 结构化 Codex 风格请求返回 502，请求 ID 86069838-2559-45a7-a683-8b029f03b447。
• 账号连接测试同形态的 input:"hi" + stream:true 请求，在调度恢复后仍返回 502，请求 ID dfd99f91-52e4-4de9-bea9-d64a3e8e623b。
• 502 后 v0.1.155 会把 Grok 账号临时不可调度 2 分钟；期间请求返回 503 no available accounts。这解释了中间的 503，但不是首个 502 的根因。
• 原生窗口显示账号 36 可恢复为 AVAILABLE=true，因此不是永久禁用或认证错误。

v0.1.155 源码路径差异

管理端 testGrokAccountConnection：

• 直接使用账号的 API Key 和 base URL。
• 请求体固定为 model + input:"hi" + stream:true。
• 不经过分组调度。
• 不注入 Grok prompt-cache identity。

公开 Grok gateway 的 forwardGrokResponses：

• 先经过分组调度和模型映射。
• 调用 resolveGrokCacheIdentity，按 Sub2API API Key、模型和请求内容生成租户隔离 identity。
• 即使是 Grok API Key 账号，也会向 Responses body 写入 prompt_cache_key，并写入 X-Grok-Conv-Id header；只有 Free OAuth 专属工具注入受 IsGrokOAuth() 限制。
• 第三方 base URL 因而收到的载荷不等同于管理端连接测试。

结论

“账号连接测试成功”与“Codex 经 Sub2API Grok 分组成功”并不矛盾。前者证明最小直连可用；后者当前稳定在上游账号 36 返回 502 后失败。根据 v0.1.155 源码，最值得优先验证的差异是公开网关为第三方 Grok API Key 上游增加的 prompt_cache_key / X-Grok-Conv-Id 及其他 Responses 净化，而不是本地 config.toml.grok、auth.json.grok 或账号凭据。

本任务保持只读，没有修改账号、runtime、分组或 Sub2API 源码。当前 Codex profile 配置仍正确，但该第三方上游尚未通过真实 Codex 网关载荷验收。