dsh web:WebSocket 全部 "closed before the connection is established" — Node 默认 keepAliveTimeout=5s 在代理/NAT 部署下毒化浏览器连接池

[poverflow]

环境

• dsh 0.1.0-rc.6(npm 发行版),Docker 部署(node:24-slim)
• webserver 经配置补丁绑定 0.0.0.0,已配置 --trusted-host
• 客户端:Windows 11 + Edge(Chromium 146);同时在无任何扩展的 Electron 内嵌浏览器中同样复现
• 浏览器与 dsh 之间有透明代理(TUN)与 Docker 端口转发

症状

• 页面静态资源、普通 RPC 基本正常,但 events.mux(有时 events.host 一起)WebSocket 全部失败,控制台无限刷:
  WebSocket connection to 'ws://…/api/events.mux' failed: WebSocket is closed before the connection is established.
• 前端 [web-runtime] connection lost, retry #N 无限重试,工作区列表永远「正在加载工作区…」
• 同一台机器上 curl / Node 的 WebSocket 客户端连接同一端点全部秒连 101,服务端完全正常——极易误判为客户端/网络问题

与 #313 不同,这不是 /api 403 / 信任围栏问题:same-origin、trusted-host 配置正确、没有任何 403 响应,且在无扩展的浏览器同样复现。

根因
Node http 默认 keepAliveTimeout = 5s:空闲 keep-alive 连接 5 秒后被 dsh 关闭,但这个 FIN 经过代理/NAT/端口转发层时经常丢失,浏览器认为连接仍存活并继续复用:

1. 浏览器把 WebSocket 升级请求写进池中的死连接 → 挂起直到超时
2. 普通 HTTP 请求写进死连接时 Chromium 会静默换连接重试,所以页面能正常打开,只有 WS 暴露问题(WS 升级不可安全重试)
3. 僵尸连接逐渐占满浏览器对每个 host 的连接池,之后所有 WS 握手排队挂起
4. netstat 可见大量 TIME_WAIT 与长期 ESTABLISHED 的僵尸连接

字节级 TCP 中继(127.0.0.1)抓包实锤:升级请求 1ms 发出、服务端 3ms 返回(101/403)、4ms 送达浏览器并正常关闭——但页面 WebSocket 事件一个都不触发:响应已到浏览器,连接已坏不派发。

修复与验证
给 dsh 的 http server 显式设置更大的 keepAliveTimeout(monkey-patch http.Server.prototype.listen 设为 600s 验证)后,完全重启浏览器清掉被污染的连接池,一切恢复正常、连续使用不再复发。

建议
dsh-host-webserver 显式设置 server.keepAliveTimeout(≥65s,比常见反向代理与浏览器连接池更久)或提供配置项。Node 默认 5s 面向直连场景,任何「浏览器与 dsh 之间有代理/NAT/端口转发」的部署都可能踩中(反向代理、TUN、docker 端口映射)。