[求助] Web 面板约每 12 秒断连重连（"连接成功"反复弹出）——session/follow 大快照疑似触发服务器端销毁 mux 连接

[54145a]

web 面板左下角"连接成功"提示约每 12 秒出现一次。该提示只在"断开→重连"时出现，说明连接被周期性断开。浏览器控制台每 ~12 秒打印：

[connection] connection lost, retry #1
[connection] generation is still not ready after 3000ms

每次重连还伴随全量 bootstrap API 的重复请求（settings/describe、commands/list、agentPresets/list 等）。

排查过程（均在浏览器内实测）

1. 客户端从未主动关闭：挂钩 WebSocket.prototype.close，整个观察期内 mux 连接上只有 send，零次 close 调用。
2. 断连是非正常关闭：浏览器收到 code=1006, wasClean=false——双方均未发送 WS close 帧，TCP 被直接销毁。本地回环上没有中间设备，只能是服务器进程所为。
3. 不是无差别断连：
   • 无鉴权的裸 new WebSocket("/api/remote.mux") 探测连接存活 14 分钟以上；
   • 同一页面内新开的 WS，仅订阅 workspace/follow、job/list、session/control、$events 时存活 30 分钟以上。
4. 触发源锁定 session/follow 流的快照投递：仅订阅 session/follow 的连接在收到 snapshot 后 2ms 内被断（1006）。
5. 快照大小相关性（同一会话，仅调整 maxMessages）：

maxMessages	快照大小	结果
5	68KB	连接存活
100	1.6MB	快照到达后 186ms 断连
250	4.2MB	快照到达后 44ms 断连
500（页面默认）	4.3MB	快照到达后 2ms 断连

6. 会话处于"已停止"状态，快照内容每次完全相同（cursor 恒为 3514），因此每个循环浪费约 4.3MB 带宽 + 页面全量重初始化。

周期成因

服务器生成快照约 11.5s + 客户端退避重连约 0.5s ≈ 12s。

影响与求助

• 断连时客户端没有机会发送 close 帧，无法在客户端根治；
• 想确认：是否有人遇到类似 ~12 秒断连？mux 服务端~~（疑似 uWebSockets.js）~~是否可调整 maxBackpressure/最大消息限制，或将大快照分块为多条小消息发送？

环境：DeepSeek Harness web（dsh），浏览器 WebSocket 至 /api/remote.mux。

以上内容由 Culiq 撰写

补充：dsh 版本为 0.2.1 alpha1

[PerryLink]

你的现象与"服务端非正常断开"这个判断是对的，但归因错了：mux 服务端用的是 ws，不是 uWebSockets.js，所以没有 maxBackpressure 可调。真因是 Gateway 的应用层心跳。我核完最新线（origin/master = 571902028a，2026-10-14）后给你可直接用的调法。

1. ⚠️ 更正：本仓库不存在 uWebSockets.js

packages/api/gateway/src/stream-server.ts：

• :7 → import WebSocket, { WebSocketServer, type RawData } from 'ws'
• :46 → private readonly server = new WebSocketServer({ noServer: true })

⇒ 是 ws。全仓检索 uWebSockets|uws 只命中 pnpm-lock.yaml 里的一个 sha 子串。

⇒ 因此没有 maxBackpressure、也没有"按背压断开连接"的逻辑。你拟合出的那个阈值区间（68KB–1.6MB）是巧合，不是真实的判定依据。建议把这一整段从报告里删掉，否则维护者第一句就是"我们用 ws"。

（ws 的 maxPayload 默认 100 MiB，全仓只有桌面端 account-backend.ts 显式设过 65 536，与 mux 无关。）

2. ✅ 真正的断开机制：应用层心跳到期即 terminate()

同文件：

• :42 → const MAX_MISSED_HEARTBEATS = 2
• :48 → private readonly missedHeartbeats = new WeakMap<WebSocket, number>()
• :108 → private startHeartbeat(): void { … :114 → if (missed >= MAX_MISSED_HEARTBEATS) { … :117 → socket.terminate()

而默认值有测试钉着：packages/api/gateway/tests/gateway-stream.host.spec.ts:420 →

expect(TypertGatewayService.Config({})).toEqual({ websocketHeartbeatIntervalMs: 2_000, streamInboxBytes: 262_144 })

⇒ 心跳周期默认 2000ms，连续 2 个周期没有应答就 socket.terminate() —— TCP 直杀，浏览器看到的就是 1006 / wasClean=false，与你观测的关闭特征完全一致。

等价转述：事件环（或网络）停顿超过约 4 秒，这个连接就会被服务端自己杀掉。

3. ⭐ 官方 README 已经把这条写成已知限制 + 调参建议

packages/api/gateway/README.md:93（你引的那段现在是这一行）：

websocketHeartbeatIntervalMs is both the Ping cadence and the activity deadline. The Host terminates a peer that shows no activity for two intervals, … a deployment whose event loop or network can stall longer than this interval must raise it.

⇒ 你设想的"能不能调大"是被文档背书的解法，不是偏方。 直接把它写进诉求即可。

4. ⚠️ 你设想的"分块发送"在当前协议下非法

packages/api/gateway/src/client/snapshot-stream.ts:76-83：

:76  if (this.options.isSnapshot(item.value)) {
:77    if (snapshotSeen) {
:78      throw protocolViolation(`${this.options.name} emitted more than one opening snapshot`)

⇒ 每一代只允许一个 opening snapshot（:81 置位；generation 变化时 :73-74 重置）。所以"把大快照拆成多条小消息"会被客户端直接判为协议违规。

要减小快照只有一条路：减小每页条数。页面默认在 packages/api/session-controller/src/client/sessions/session.ts:54 附近 → maxMessages: 500（服务端兜底更小）。你实测 100 条仍断、5 条（68KB）存活，与此一致。

5. 你另外两条观察与心跳模型自洽

• 「裸连接存活 14 分钟」 ⇒ 自洽：裸连接不做磁盘/折叠工作，事件环不卡，pong 按时回。
• 「只有 session/follow 会断」 ⇒ 自洽：只有它会在服务端做重活（读历史 + 折叠 + 序列化大帧），把事件环堵住。
• 「本地回环上不可能有中间设备，只能是服务器所为」 ⇒ 结论对，但杀连接的是心跳，不是背压。

6. 建议的修法（按可落地性）

1. 立刻可用：在 profile 的 cordis.patch.yml 里调大 gateway 的 websocketHeartbeatIntervalMs（例如 10 000–30 000），使其大于你实测的停顿。这是直接对症项，且被 README 背书。
2. 若能改客户端：把 HISTORY_PAGE_OPTIONS.maxMessages 从 500 降到 100 量级（注意 100 你实测仍断，需再降）；或对已停止的会话不重发全量 opening snapshot。
3. 值得作为上游 issue：这属于「大快照 + 4 秒心跳上限」的已知张力。你的复现数据很有价值：请附上浏览器侧 1006 的时间戳、快照字节数、以及服务端停顿的观测 —— 这三样能把"事件环被什么堵住"定位下来。

⚠️ 一处我无法替你定的：「为什么事件环会停顿超过 4 秒」我没有定位到具体代码路径。 上面第 2 节只说清了"停顿 > 4s 就会断"，停顿的成因（大快照序列化？历史折叠？）需要你的现场数据。

7. 版本与行号（请更新）

• 我核的是 origin/master = 571902028a（2026-10-14）。相比你报告时的版本，gateway 相关行号有漂移：stream-server.ts :44 → :46、:40 → :42、:105-124 → :108-127（terminate 在 :117）；README.md :89 → :93；gateway-stream.host.spec.ts :416 → :420。
• ✅ snapshot-stream.ts 的 :76-83 未漂移；stream-server.ts:7（ws 导入）未漂移。
• ⚠️ dsh-v0.2.1-alpha.3（2026-10-14）= 2fbf4359b8，与 master 不是同一提交（master 多 16 个）；上表是 master 行号。
• ⚠️ 你写"版本 dsh 0.2.1 alpha1"——建议更新到 0.2.1-alpha.3（2026-10-14 已发布），或注明你实测的版本，否则会被当作过期报告。

[xinkuang]

检查下有没启动多个dsh？ 试试 Update(~/.dsh/profiles/web/cordis.patch.yml)
⎿  Added 5 lines
17 reasoningEffort: balanced
18 - id: speech-to-text-sensevoice
19 disabled: true
20 +# SSH 隧道场景：默认 2s 心跳 + 2 次未响应即断连（约 6s），跨公网隧道丢包时
21 +# 会误杀连接导致浏览器每 5 秒重连刷新。放宽到 10s（容忍约 30s 无响应）。
22 +- id: typert-gateway
23 + config:
24 + websocketHeartbeatIntervalMs: 10000

[54145a]

#6950