1. WebSocket连接异常断开的典型表现
最近在做一个实时消息推送系统时，遇到了一个让人头疼的问题：WebSocket连接总是莫名其妙地断开。具体表现是每隔90秒左右，客户端就会收到一个EOFException异常，然后连接就被强制关闭了。这种问题在长连接场景中特别常见，尤其是在使用Nginx作为反向代理的时候。
我查看了Tomcat的日志，发现异常堆栈是这样的：
java.io.EOFException at org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.fillReadBuffer(NioEndpoint.java:1206) at org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.read(NioEndpoint.java:1140) at org.apache.tomcat.websocket.server.WsFrameServer.onDataAvailable(WsFrameServer.java:72) // 省略部分堆栈信息这种异常通常意味着连接的另一端突然关闭了，而我们的应用还没来得及正常处理。在实际项目中，这种问题会导致用户体验非常糟糕——用户正在进行的操作会被中断，需要重新建立连接。
2. Nginx超时配置的底层原理
2.1 为什么Nginx会断开WebSocket连接
Nginx作为反向代理，默认会对所有连接设置超时时间。这原本是为了防止资源被长时间占用，但对于WebSocket这种长连接场景就很不友好了。Nginx有两个关键参数控制着连接的生命周期：
- proxy_read_timeout：定义Nginx等待后端服务响应的最长时间
- keepalive_timeout：控制空闲连接保持打开状态的时间
这两个参数的单位都是秒，默认值通常是60秒。也就是说，如果你的WebSocket连接在60秒内没有任何数据交互，Nginx就会认为这个连接已经"死"了，主动把它关闭。
2.2 参数之间的优先级关系
这里有个坑我踩过：即使你设置了很大的proxy_read_timeout，如果keepalive_timeout的值更小，最终还是会按小的那个时间断开连接。就像我最初把proxy_read_timeout设为5000秒，但keepalive_timeout还是默认的65秒，结果65秒后连接还是断了。
正确的做法是同时调整这两个参数：
location / { proxy_pass http://backend; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_read_timeout 3600s; # 1小时 keepalive_timeout 3600s; # 必须与proxy_read_timeout匹配 }3. 完整解决方案与最佳实践
3.1 Nginx配置的完整示例
经过多次测试，我发现最稳定的配置是这样的：
server { listen 80; server_name yourdomain.com; location / { proxy_pass http://localhost:8080; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; # 关键超时设置 proxy_read_timeout 86400s; # 24小时 proxy_connect_timeout 75s; proxy_send_timeout 60s; keepalive_timeout 86400s; # 其他优化参数 proxy_buffering off; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }3.2 客户端心跳机制
即使Nginx配置了很长的超时时间，网络设备（如路由器、负载均衡器）也可能有自己的超时设置。更可靠的做法是在应用层实现心跳机制：
前端JavaScript示例：
const socket = new WebSocket('wss://yourdomain.com'); const heartbeatInterval = 30000; // 30秒 let heartbeatTimer; socket.onopen = () => { heartbeatTimer = setInterval(() => { if(socket.readyState === WebSocket.OPEN) { socket.send('heartbeat'); } }, heartbeatInterval); }; socket.onclose = () => { clearInterval(heartbeatTimer); };后端Java示例（Spring Boot）：
@GetMapping("/heartbeat") public ResponseEntity<String> heartbeat() { return ResponseEntity.ok("alive"); }4. 疑难排查与进阶技巧
4.1 如何确认问题确实出在Nginx
当遇到连接断开问题时，可以按照以下步骤排查：
- 直接连接后端服务（绕过Nginx），观察是否还会断开
- 检查Nginx错误日志：
tail -f /var/log/nginx/error.log - 使用tcpdump抓包分析：
tcpdump -i any port 80 -w websocket.pcap - 在Nginx配置中增加调试日志：
log_format wsdebug '$remote_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent" $connection'; access_log /var/log/nginx/websocket.log wsdebug;
4.2 其他可能影响连接稳定性的因素
除了Nginx配置，这些因素也可能导致WebSocket连接异常：
- 操作系统级别的TCP超时设置
- 中间网络设备（防火墙、负载均衡器）的超时策略
- 浏览器自身的WebSocket实现限制
- 移动设备网络切换时的连接中断
对于生产环境，我建议采用指数退避重连机制：
let reconnectDelay = 1000; const maxDelay = 30000; function connect() { const ws = new WebSocket('wss://yourdomain.com'); ws.onclose = () => { reconnectDelay = Math.min(reconnectDelay * 2, maxDelay); setTimeout(connect, reconnectDelay); }; ws.onopen = () => { reconnectDelay = 1000; // 重置延迟 }; }在实际项目中，我发现将Nginx超时设置为24小时（86400秒）并配合30秒一次的心跳检测，能够很好地平衡连接稳定性和资源利用率。当然，具体参数需要根据你的业务场景调整——如果并发连接数很大，可能需要设置更短的超时时间。
