Nginx代理WebSocket被防火墙中断主因是升级头未透传、超时过短或TLS/ALPN配置异常；须配置proxy_http_version 1.1、proxy_set_header Upgrade $http_upgrade与Connection "upgrade"、proxy_read_timeout≥300、proxy_ssl_*适配WSS，并用tcpdump+Wireshark抓包定位RST来源。
WebSocket 代理在 Nginx 中被防火墙中断，通常不是 Nginx 自身配置错误，而是连接未被正确“维持”或“识别”，导致中间设备（如企业防火墙、云安全组、运营商 NAT）主动断连。排查需从协议特征、Nginx 透传设置、连接生命周期三方面入手。
确认 WebSocket 升级头是否完整透传
Nginx 必须显式转发 Upgrade 和 Connection 请求头，否则后端收不到升级请求，握手失败，连接降级为普通 HTTP，后续帧会被防火墙视为异常流量而拦截。
检查 proxy_pass 配置中是否包含以下关键指令：
- proxy_http_version 1.1;（必须为 1.1，HTTP/1.0 不支持 Upgrade）
- proxy_set_header Upgrade $http_upgrade;（将客户端的 Upgrade 头原样传递）
- proxy_set_header Connection "upgrade";（固定值，不是 $http_connection；注意引号）
- proxy_set_header Host $host;（避免后端因 Host 不匹配拒绝连接）
检查超时设置是否过短，触发防火墙空闲断连
多数防火墙对“长连接但无数据”的 TCP 流会设置 60–300 秒空闲超时。WebSocket 连接若长时间静默，中间设备可能直接 RST 断开，而 Nginx 默认 proxy_read_timeout 是 60 秒，极易撞上该阈值。
建议在 location 块中显式延长：
- proxy_read_timeout 300;（推荐 300–600，确保大于防火墙空闲阈值）
- proxy_send_timeout 300;（配合心跳发送，避免单向阻塞）
- 避免使用
keepalive_timeout替代——那是 HTTP keep-alive，不适用于 WebSocket
验证是否被 TLS 或 SNI 检查干扰（尤其 HTTPS 场景）
当 Nginx 终止 HTTPS 后反向代理到 ws:// 后端，或代理 wss:// 时，部分深度包检测（DPI）防火墙会因 TLS 握手特征、SNI 域名、ALPN 协议协商异常而拦截。
排查要点：
- 若后端是
wss://，确保 Nginx 开启proxy_ssl_*相关配置（如proxy_ssl_verify off、proxy_ssl_protocols TLSv1.2 TLSv1.3） - 用
openssl s_client -connect your-domain.com:443 -servername your-domain.com -alpn h2,http/1.1检查 ALPN 是否返回http/1.1（WebSocket 要求） - 临时改用纯 HTTP + ws:// 测试，排除 TLS 层干扰；若 HTTP 正常而 HTTPS 中断，问题大概率出在证书链、SNI 或 ALPN
抓包定位中断发生在哪一环
仅靠日志无法区分是防火墙、Nginx 还是后端断连。最有效方式是在 Nginx 服务器上抓包：
- tcpdump -i any port 80 or port 443 -w ws-debug.pcap（捕获进出流量）
- 复现问题后，用 Wireshark 打开，过滤
tcp.stream eq X && websocket - 观察 FIN/RST 出现在哪一侧：若 Nginx 发出 RST → 查 Nginx 日志和超时；若客户端发 FIN 后无响应 → 可能防火墙丢包；若中间 IP 突然发 RST → 基本确定是防火墙或网关干预
