nginx代理websocket断连主因是默认超时与协议升级配置缺失：需配齐proxy_http_version 1.1、upgrade和connection头以确保101握手成功，并将proxy_read_timeout设为86400秒以上，避免空闲连接被误杀，同时前端重连须结合服务端心跳与连接id实现智能恢复。
前端 WebSocket 连接断开后自动重连，不能只靠前端“拼命重试”，必须和 Nginx 代理配置协同设计。否则容易陷入“刚连上就断”“重连越频繁越崩”的恶性循环。核心是：让 Nginx 别主动掐线，让后端能稳定维持连接，前端再基于真实状态智能重连。
确保 Nginx 不在握手或空闲阶段误杀连接
这是重连机制能生效的前提。Nginx 默认行为会直接破坏连接稳定性：
-
握手失败（返回 200/502 而非 101）：说明 Upgrade 头没传过去。必须在
location块中配齐三行：proxy_http_version 1.1;proxy_set_header Upgrade $http_upgrade;proxy_set_header Connection "upgrade";
-
连接建立后几秒/几十秒就断（无错误日志或报
upstream prematurely closed connection）：大概率是proxy_read_timeout太小。WebSocket 是空闲长连接，不是 HTTP 请求响应流。建议设为proxy_read_timeout 86400;（24 小时），至少不低于后端心跳间隔的 3 倍。 -
后端推送延迟导致断连：同步设置
proxy_send_timeout 86400;，避免 Nginx 在等待后端发数据时中途放弃。
后端需提供稳定的心跳与连接标识
前端重连逻辑是否合理，取决于它能否区分“网络抖动临时断开”和“服务端已清理连接”。这需要后端配合：
- 服务端定期发送 Ping 帧（或自定义
{"type":"ping"}消息），前端收到即更新本地“最后活跃时间”； - 每次新连接建立后，服务端分配唯一连接 ID（如 UUID 或 session token），并通过消息下发给前端；
- 断线重连时，前端带上该 ID 发起新连接请求（例如作为 query 参数：
ws://api.example.com/ws?cid=abc123），服务端可识别并复用会话状态或拒绝重复连接。
前端重连策略要避开 Nginx 和后端的敏感窗口
盲目指数退避（如 1s→2s→4s→8s）在 Nginx + WebSocket 场景下可能适得其反：
- 若 Nginx 的
proxy_connect_timeout设为 30s，前端在 5s 内反复重连 5 次，可能触发 Nginx 连接数限制或后端连接风暴； - 建议采用“带 jitter 的渐进退避”：首次失败后等 1–3 秒（随机），第二次 2–6 秒，第三次 4–12 秒，上限封顶在 30 秒；
- 连续失败超过 5 次，暂停自动重连，提示用户“网络异常”，避免掩盖真实问题（如证书过期、域名解析失败、SSL 握手卡住）；
- 监听
onclose事件的code和reason：code 1006（abnormal closure）大概率是 Nginx 主动断链；code 4001/4999 等业务码则应走登录态刷新流程，而非简单重连。
HTTPS（WSS）场景下额外验证 TLS 层是否通畅
很多“重连失败”其实根本没走到 HTTP 升级阶段：
- 浏览器访问
wss://your.com/ws，但 Nginx 只监听listen 80;或 SSL 配置缺失 → 直接net::ERR_CONNECTION_REFUSED，前端无法捕获 WebSocket 错误，只能看到连接被拒绝； - 确保证书有效、域名匹配、server 块含
listen 443 ssl;，且私钥权限正确（chmod 400）； - 用
curl -i -k -H "Connection: upgrade" -H "Upgrade: websocket" https://your.com/ws手动测试握手，确认返回HTTP/1.1 101 Switching Protocols，排除 TLS 和 Nginx 路由层问题。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
