nginx代理websocket断连主因是默认按http短连接处理，须同步配置proxy_read_timeout、proxy_send_timeout、keepalive_timeout（均建议86400），并透传upgrade和connection头、启用http/1.1、精准路径匹配及完整https。
WebSocket 连接在 Nginx 代理下断开，绝大多数不是后端或前端问题，而是 Nginx 把长连接当成了普通 HTTP 短连接处理——默认 60 秒无数据就主动切断。设置超时时间不是简单调大数字，关键在于匹配心跳节奏、覆盖读写双向空闲期，并确保协议升级已成功建立。
必须同步调整的三个超时参数
这三个值要设在同一 location 块中，且建议保持一致（如都设为 86400），避免某一个成为瓶颈：
- proxy_read_timeout：控制 Nginx 等待后端推送数据的空闲时间。WebSocket 空闲时不发业务数据，只靠心跳维持，若该值 ≤ 心跳间隔，连接必断。不能设为 0（Nginx 不支持，会回退到 60）。
- proxy_send_timeout：控制 Nginx 向客户端发送数据时的连续等待时间。适用于后端分片发大消息、或响应延迟场景，同样需 ≥ 心跳间隔。
- keepalive_timeout：维持客户端与 Nginx 之间的 keep-alive 连接时长。虽不直接控制 WebSocket 帧流，但影响复用连接的稳定性，建议同步设长。
超时值怎么定才合理
数值不能拍脑袋，要结合实际心跳策略：
- 若后端每 30 秒发一次 ping，客户端 pong 回应，则 proxy_read_timeout 至少设为 60，推荐设为 300（5 分钟）或 86400（24 小时）。
- 生产环境常见取值范围是 300–86400 秒；不建议盲目设为 604800（7 天），否则异常连接无法及时释放，堆积文件描述符和内存。
- 所有超时值必须 ≥ 后端真实心跳帧的往返周期，且心跳帧必须经由 WebSocket 通道发出（不能仅服务端内存计时）。
超时生效的前提条件
再大的超时值也无效，如果握手阶段就失败：
- 必须启用 proxy_http_version 1.1：HTTP/1.1 是 Upgrade 机制基础，HTTP/2 不支持 WebSocket 升级。
- 必须透传升级头：proxy_set_header Upgrade $http_upgrade 和 proxy_set_header Connection "upgrade"（注意双引号，不是变量）。
- 路径匹配要精准，避免
rewrite或 proxy_pass 尾部斜杠导致路径错位，造成后端收不到 Upgrade 请求头。
HTTPS 下 wss 的额外注意点
使用 wss 时，Nginx 终止 SSL 的配置必须完整：
- server 块中需配置有效的 ssl_certificate 和 ssl_certificate_key。
- 明确声明 ssl_protocols TLSv1.2 TLSv1.3，禁用不安全旧协议。
- 显式关闭 HTTP/2：http_v2 off 或不启用 http_v2 指令，防止协议冲突导致升级失败。
