K8s部署WebSocket应用Ingress配置教程解决WS连接重置问题方法-js教程-PHP中文网

根本原因是ingress控制器未透传upgrade/connection头且超时参数配置不当：必须设置nginx.ingress.kubernetes.io/proxy-set-header（含upgrade $http_upgrade; connection $connection_upgrade）和proxy-read-timeout≥3600，否则后端无法收到升级请求而返回400/200，或60秒后被nginx主动断连。

k8s部署websocket应用ingress配置教程解决ws连接重置问题方法

WebSocket在K8s中连接重置（如400 Bad Request、200非101响应、60秒断连），根本原因不是后端代码或客户端写法，而是Ingress控制器未正确透传协议升级头和超时参数——nginx.ingress.kubernetes.io/proxy-set-header 和 proxy-read-timeout 这两个注解漏配或值不合理，90%的“WS连不上”都卡在这儿。

为什么WebSocket握手返回400或200而不是101

NGINX默认不转发Upgrade和Connection这两个关键HTTP头，导致后端服务收不到协议升级请求，直接按普通HTTP处理，返回200或400。云厂商LB（如华为云ELB、阿里云SLB）还会二次拦截，进一步加剧问题。

必须显式配置nginx.ingress.kubernetes.io/proxy-set-header，且值要带换行和引号包裹：
```
Upgrade $http_upgrade;
Connection $connection_upgrade;
```
proxy-http-version 必须设为"1.1"（注意字符串引号），HTTP/1.0不支持Upgrade机制
若Ingress规则路径与后端实际路径不一致（如Ingress暴露/ws但后端监听/api/ws），需配合nginx.ingress.kubernetes.io/rewrite-target，否则404或路由错位

为什么连接总在60秒后自动断开

ingress-nginx默认proxy-read-timeout和proxy-send-timeout都是60秒，而WebSocket长连接需要保持空闲心跳，超时一到NGINX就主动断链，客户端收到WebSocket is closed before the connection is established之类报错。

WebSocket 8.18.2

WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。

下载

生产环境建议设为"3600"（1小时），足够覆盖多数心跳间隔（如每30秒ping一次）
不要盲目设为"0"：NGINX 0表示“无限”，但云LB通常有自己的连接空闲超时（如AWS ALB默认4000秒），需对齐，否则LB先断
若后端是Java Spring Boot，还需检查server.tomcat.connection-timeout是否大于Ingress超时值，否则Tomcat层先关

多副本部署下连接频繁漂移

WebSocket是状态连接，客户端建立连接后必须固定落在同一个Pod上；默认轮询策略会导致后续帧被转发到其他实例，触发Invalid frame header或直接断连。

启用会话亲和性：nginx.ingress.kubernetes.io/affinity: "cookie"
配合nginx.ingress.kubernetes.io/session-cookie-name自定义cookie名（避免冲突），如"ws-affinity"
注意：该机制依赖客户端支持Cookie，浏览器天然满足；但Python/Node.js客户端需手动携带cookie，否则无效

如何快速验证Ingress配置是否生效

别等前端页面报错再排查，用命令行工具直击链路：

用wscat绕过浏览器限制测试：wscat -c ws://your-domain.com/your-path，看是否成功升为101
检查Ingress controller日志：kubectl logs -n ingress-nginx deploy/ingress-nginx-controller | grep "UPGRADE\|101"
确认NGINX实际生成的配置：kubectl exec -n ingress-nginx deploy/ingress-nginx-controller -- cat /etc/nginx/nginx.conf | grep -A5 -B5 upgrade，验证proxy_set_header Upgrade是否真实写入

真正容易被忽略的是云厂商LB层——即使Ingress配置全对，如果前面还有一层ELB/ALB，它可能没开长连接支持或覆盖了超时设置。务必查清流量路径上每一跳的超时与头透传策略，少一环，WS就掉一环。