WebSocket服务器单点故障暴露状态同步、连接路由和数据落盘缺陷，需从连接层、会话层、数据层三重加固；websocketd无状态但下游脚本有状态，不管理session生命周期，进程退出即断连并触发1006错误。
WebSocket 服务器挂了，不是“重启就完事”，而是暴露了架构里没处理好的状态同步、连接路由和数据落盘问题。真要扛住故障，得从连接层、会话层、数据层三处同时加固。
为什么 websocketd 单实例一挂就全断？
websocketd 本身无状态，但它的下游脚本（比如 ./count.sh）往往有状态；更关键的是，它不管理客户端 session 生命周期，也不感知连接归属。一旦进程退出，所有已建立的 WebSocket 连接底层 socket 就被内核回收，客户端收到 1006 错误——这个错误不会触发 onerror，只会在 onclose 里静默出现。
- 它不保存连接元数据（如 client IP、user ID、订阅主题），无法在新实例启动后恢复上下文
- 它不支持热重载或平滑 reload，
SIGHUP会直接 kill 当前进程 - 若用
--origin或--address做简单校验，挂掉后 DNS 缓存或 LB 转发延迟会导致部分客户端反复重连失败
用 nginx 做反向代理时，1006 错误大概率是它干的
很多团队把 1006 归咎于后端，其实 nginx 默认的 proxy_read_timeout 是 60 秒，且对 WebSocket 的 Upgrade 连接不做特殊保活。只要后端没在 60 秒内发任何帧（包括 ping），nginx 就会主动断开 TCP 连接，客户端看到的就是无 reason 的 1006。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 必须显式配置：
proxy_read_timeout 300;（建议 ≥ 客户端 ping 间隔 × 3） - 必须透传升级头：
proxy_set_header Connection "upgrade";和proxy_set_header Upgrade $http_upgrade; - 如果用了
keepalive指令，注意它只对 HTTP 连接池生效，对 WebSocket upgrade 后的长连接无效
真正能抗住挂掉的方案：分离连接网关与业务逻辑
别让 websocketd 承担业务逻辑。把它降级为纯协议网关，把用户识别、消息路由、广播分发全部交给后端服务（如 Redis Pub/Sub + 独立 worker）。
- 前端连的是统一
wss://gateway.example.com，由 nginx 分流到多个websocketd实例（仅做 WS 握手和帧转发） - 每个
websocketd实例启动时，通过--shell调用一个轻量 wrapper 脚本，该脚本只负责：解析 URL 参数（如token）、调用鉴权 API、将 client ID 写入 Redis、然后 exec 到真实业务进程 - 所有消息收发走 Redis channel：
websocketd收到消息后发给 Redis，worker 订阅后处理并广播，再由各websocketd实例根据本地 session map 推送——session map 用 Redis Hash 存，带 TTL，避免单点丢失 - 这样即使某个
websocketd进程崩溃，只影响当前连接的瞬时推送，不影响全局路由和消息可达性
Websocat + borgbackup 不是备份 WebSocket，是备份它的“数据流契约”
你不能备份一个正在跑的 WebSocket 连接，但可以备份它承载的协议语义。比如聊天场景中，每条 {"type":"msg","from":"u123","to":"u456","text":"hi"} 就是可审计、可重放、可验证的数据单元。
- 用
Websocat在网关层旁路抓取所有进出帧：websocat --binary --ping-interval=10 wss://backend/ | borg create /backup::ws-2026-05-28-{now} - - 关键不是压缩率，而是
borg的 deduplication 能自动去重相同心跳包、重复 ACK 帧，只存业务有效载荷 - 恢复时不用还原连接，而是用
borg extract拿出 JSON 日志，喂给回放工具或审计系统——这才是灾备的真实价值点
最易被忽略的一点：所有 session ID、client token、路由 key 必须用加密随机生成（如 /dev/urandom），不能依赖时间戳或自增 ID。否则 backup 里暴露的 token 可能被重放利用，高可用反而成了高风险。
