# 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 网关载荷验收。