[Bug] WebSocket 会话被服务端反复关闭，前端「新建会话」死锁（Windows 11 / iOS / Android 全部实测复现）

[ChiefToolMan]

环境（2026-10-30 编辑更正）

服务端	飞牛 fnOS（基于 Debian 12 bookworm）· Linux 内核 6.18.18.c1126-trim（厂商自定义）· node v24.18.0 · x86_64 NAS
DSH	0.2.1-rc.2 与 0.2.1-rc.5（web profile）两个版本行为一致
受影响端（全部实测）	Windows 11 PC（Edge） · iPhone 18 Pro（Edge / Safari 双浏览器） · 小米平板 7 Ultra（Edge / Chrome） · vivo X500（Edge）
正常端	macOS（注：为保护唯一可用环境未做「新建会话」验证，推测同样受影响）
拓扑	客户端 → 反向代理（TLS + Host 改写为 127.0.0.1:3080）→ 127.0.0.1:3080；已用无反代纯直连复现，排除代理因素

覆盖面：跨 OS、跨浏览器内核，且触发条件精确

实测覆盖 Windows 11、iOS（iPhone 18 Pro）、Android（小米 Pad 7 Ultra / vivo X500） 三个操作系统；iOS 上 Safari（WebKit）与 Edge 双浏览器均复现，Android 上 Edge 与 Chrome 均复现——跨浏览器内核（WebKit / Blink）无豁免，可排除浏览器实现差异。

触发条件明确且一致：点击「新建会话」即触发（多端表现相同）；继续在现有会话中对话不受影响（HTTP 通道正常）。「新建会话」是全站唯一强依赖 WS ready 的 UI 操作——WS 处于重连循环时 ready 永远无法达成，前端死等。

现象

受影响设备进入 Web GUI 后：

1. 点击「新建会话」即卡死；新设备首访时「预览版说明」弹窗的「继续」同样无法完成（读写均失败，报「暂时无法保存确认状态，请重试」）
2. 实时事件流被中止：net::ERR_CONNECTION_ABORTED（/plugins/events）
3. Console 反复出现 [connection] connection lost, retry #1
4. HTTP 层全部正常：/api/session/list、/api/session/create、/api/session/prompt 全部 200——经 API 直接创建会话、发送消息均成功，坏的只有 WS 之上的实时通道

证据：是服务端主动关闭的

反代侧访问日志（记录 WS 升级与关闭方）：

UPGRADE /api/remote.mux → WS 101
WS closed by DSH 63984ms      ← 服务端关闭，连接存活 64s
UPGRADE /api/remote.mux → WS 101
WS closed by DSH 816ms        ← 0.8s 后被关
UPGRADE /api/remote.mux → WS 101
WS closed by DSH 22672ms      ← 22.7s 后被关
（每次关闭后客户端立即重连，重连的 WS 同样 101 后被关——形成循环）

对照组（完全相同的链路）：macOS 客户端的 WS 存活 23.5 分钟，tcpdump 验证 ping/pong 34:34 正常。

DSH 服务端日志对这些关闭零输出（静默），无法从服务端定位踢出原因。

补充：重启整机无效

重启整个 NAS 主机（进程全新、网络重置、连接状态清空）后问题依旧——排除「进程状态累积」，这是每次新建连接都会发生的持续性问题，不是资源泄漏或长时间运行导致。

版本对比：rc.2 与 rc.5 行为一致

0.2.1-rc.5 升级前后行为无变化，并已回滚验证。核心连接链路包逐字节 diff 结果为零变更：dsh-client-connection（server 与 browser 两侧）、dsh-api-gateway、dsh-app-boot、dsh-agent-loop、dsh-base、dsh-api-session-controller 全部一致——排除单一版本回归。

复现步骤

路径一（最简，无任何代理，已实测复现）：

npx @deepseek-ai/dsh web --host <LAN-IP> --port 3090 --trusted-host <LAN-IP>

Windows / Android / iOS 浏览器直连 http://<LAN-IP>:3090/?token=<启动输出的token> → 点「新建会话」→ 复现。

路径二（经反代 / HTTPS / 公网映射）：同现象。

已排除（全部实测）

假设	排除依据
公网端口映射	局域网内复现
反向代理 / HTTPS / Host 改写	无反代纯直连（路径一）同样复现
浏览器	Edge / Chrome / Safari 均复现（iOS、Android 上双浏览器验证）
单一设备 / 单一 OS	跨 Windows / iOS / Android 四台设备复现
网络路径	内网直连、公网回环、手机热点均复现
客户端省电/网络策略	未开启相关限制
插件干扰	禁用全部第三方插件后仍复现
cookie/认证	会话 cookie 有效，HTTP 层全部通过
DSH 版本	rc.2 与 rc.5 一致（核心连接包代码零 diff）
进程状态累积	重启整机后依旧复现

方向建议

• WS 升级（/api/remote.mux）101 成功，但之后的会话初始化（attach / generation ready）疑似未完成 —— 前端 generationReadyTimeoutMs: 15000 触发重连，与观察到的反复重连吻合；「新建会话」与欢迎确认等依赖 WS ready 的操作因此死锁
• 服务端关闭完全静默，建议在关闭路径补充原因日志（心跳超时 / attach 超时 / 协议错误），否则此类问题无法从服务端定位

[wantRP]

我试过清空cookie有效