Realtime 方案

先把边界和方案说清，再决定要不要做 WebSocket 中继。

这页既说明当前边界，也记录独立 `realtime-relay` 已经做到哪一步。

查看接口参考查看接口 FAQ

当前边界

现在真正能承诺的是 session 创建，加独立 relay 进程。

当前已支持

`POST /v1/realtime/sessions` 已支持。独立 `realtime-relay` 进程也已经提供鉴权、upgrade 校验、双向 WS 透传、心跳、空闲超时和 `/metrics`。

当前边界

WebSocket relay 已放到独立进程，不进 Next Route Handlers。现在还缺真实联调验收、更多协议事件验证和更完整运维接入。

为什么不直接做

不是不能做，是不能在当前承载层里硬塞进主站。

当前 Next Route Handlers 部署模型下，WebSocket 连接不是稳妥承诺面。
长连接会受超时、响应生命周期和宿主环境限制影响，不适合直接当生产契约。
所以现在的做法是把 WS 从主站剥离，单独放到 `realtime-relay` 进程里。

推荐方案

真正可落地的还是这两种，而且第二种已经能跑真实代理。

方案 A: 继续只代理 session

最稳。
用户只把 session 创建地址换到 TokenAI。
后续 WebSocket 仍直连 OpenAI 官方 Realtime。

方案 B: 独立 Realtime 中继服务

不要放在当前 Next Route Handlers 里。
单独起一个长连接友好的服务，比如当前仓库里的 `scripts/realtime-relay.ts`。
由它负责双向 WS 转发、鉴权、审计、心跳和限流。

落地步骤

独立中继下一步该做什么，顺序应该是这样。

保留现有 `POST /v1/realtime/sessions`，不要回退。
继续把 WS 边界固定在独立 `realtime-relay` 服务，不和普通 `/v1/*` 混用。
先做真环境联调，确认 `openai-beta`、subprotocol、close code 和 query 透传都稳定。
把 `/metrics` 接到监控，再补告警和连接级 dashboard。
补部署文档：`start:realtime-relay`、PM2、Docker 和反向代理示例。
把 `REALTIME_RELAY_PUBLIC_WS_URL` 配进正式环境，并让客户端优先读取 relay 地址。
完成联调后再决定是否把 relay 写进默认接入文档。

Realtime 方案

先把边界和方案说清，再决定要不要做 WebSocket 中继。

这页既说明当前边界，也记录独立 `realtime-relay` 已经做到哪一步。

查看接口参考查看接口 FAQ

当前边界

现在真正能承诺的是 session 创建，加独立 relay 进程。

当前已支持

`POST /v1/realtime/sessions` 已支持。独立 `realtime-relay` 进程也已经提供鉴权、upgrade 校验、双向 WS 透传、心跳、空闲超时和 `/metrics`。

当前边界

WebSocket relay 已放到独立进程，不进 Next Route Handlers。现在还缺真实联调验收、更多协议事件验证和更完整运维接入。

为什么不直接做

不是不能做，是不能在当前承载层里硬塞进主站。

当前 Next Route Handlers 部署模型下，WebSocket 连接不是稳妥承诺面。
长连接会受超时、响应生命周期和宿主环境限制影响，不适合直接当生产契约。
所以现在的做法是把 WS 从主站剥离，单独放到 `realtime-relay` 进程里。

推荐方案

真正可落地的还是这两种，而且第二种已经能跑真实代理。

方案 A: 继续只代理 session

最稳。
用户只把 session 创建地址换到 TokenAI。
后续 WebSocket 仍直连 OpenAI 官方 Realtime。

方案 B: 独立 Realtime 中继服务

不要放在当前 Next Route Handlers 里。
单独起一个长连接友好的服务，比如当前仓库里的 `scripts/realtime-relay.ts`。
由它负责双向 WS 转发、鉴权、审计、心跳和限流。

落地步骤

独立中继下一步该做什么，顺序应该是这样。

保留现有 `POST /v1/realtime/sessions`，不要回退。
继续把 WS 边界固定在独立 `realtime-relay` 服务，不和普通 `/v1/*` 混用。
先做真环境联调，确认 `openai-beta`、subprotocol、close code 和 query 透传都稳定。
把 `/metrics` 接到监控，再补告警和连接级 dashboard。
补部署文档：`start:realtime-relay`、PM2、Docker 和反向代理示例。
把 `REALTIME_RELAY_PUBLIC_WS_URL` 配进正式环境，并让客户端优先读取 relay 地址。
完成联调后再决定是否把 relay 写进默认接入文档。

页面加载中

先把边界和方案说清，再决定要不要做 WebSocket 中继。

现在真正能承诺的是 session 创建，加独立 relay 进程。

不是不能做，是不能在当前承载层里硬塞进主站。

真正可落地的还是这两种，而且第二种已经能跑真实代理。

独立中继下一步该做什么，顺序应该是这样。

先把边界和方案说清，再决定要不要做 WebSocket 中继。

现在真正能承诺的是 session 创建，加独立 relay 进程。

不是不能做，是不能在当前承载层里硬塞进主站。

真正可落地的还是这两种，而且第二种已经能跑真实代理。

独立中继下一步该做什么，顺序应该是这样。