WebSocket连接失败的首要排查点是WAF拦截，因其常误判Upgrade头为攻击而403静默丢弃；需通过hosts绕行、查WAF日志、临时关防护、添加放行策略、开启WebSocket识别开关来确认和解决；其次检查系统防火墙及云安全组是否开放端口；最后验证请求头是否完整抵达服务端。
WebSocket 连接失败，但控制台只显示 WebSocket connection to 'wss://xxx' failed，服务端日志无报错、Nginx 配置已加 Upgrade 头、端口也开放了——这类“查无可查”的问题，十有八九是 Firewall 或 WAF 在握手阶段悄悄拦截了 Upgrade: websocket 请求头。
确认是否被 WAF 拦截
这是最关键的一步，不能跳过。WAF（如阿里云WAF、腾讯云WAF、Cloudflare）默认会对 HTTP 请求做深度解析，而 WebSocket 握手请求中的 Upgrade 和 Connection: upgrade 头，常被误判为异常协议行为或攻击特征，直接 403 拦截或静默丢弃。
- 用本地 hosts 绕过 WAF：将域名直接解析到源站服务器公网 IP（跳过 WAF），再访问前端页面测试 WebSocket 是否能连通；如果能通，基本锁定是 WAF 干扰
- 查看 WAF 访问日志：筛选目标 URL（如
/ws或/socket），重点看响应状态码是否为 403/444/502，且响应体为空或含 “blocked by waf” 字样 - 临时关闭 WAF 的正则防护引擎和 CC 安全防护（非生产环境），观察连接是否恢复；若恢复，说明某类规则误匹配了 WebSocket 握手流量
针对性放行 WebSocket 握手请求
WAF 不像系统防火墙能简单开个端口，它基于 HTTP 层规则过滤。必须让 WAF 明白：“这个请求不是攻击，是合法的协议升级”。
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 在 WAF 控制台添加自定义防护策略，匹配条件设为：请求 URI 包含
/ws、/socket或你实际的 WebSocket 路径，且 请求头中包含Upgrade: websocket - 动作设为“放行”，并禁用所有关联规则（如 SQL注入、XSS、恶意爬虫等），避免二次拦截
- 部分 WAF（如阿里云）支持“Websocket 协议识别”开关，开启后会自动识别并透传 Upgrade 流量，务必检查并启用
检查 Firewall（系统级）是否干扰 TCP 层
即使 WAF 放行了，系统防火墙仍可能阻断 WebSocket 所用端口的初始 TCP 连接，导致根本发不出握手请求。
- 确认服务监听端口（如 8586、2346、8282）已在
firewalld或ufw中永久开放：
firewall-cmd --zone=public --add-port=8586/tcp --permanent && firewall-cmd --reload - 用
telnet your-server-ip 8586从客户端机器直连测试：如果连不上，说明防火墙或云厂商安全组未放行，与 WAF 无关 - 云服务器（如阿里云、腾讯云）需额外检查安全组规则——WAF 是应用层，安全组是网络层，两者都要配对放行
验证握手请求是否完整抵达服务端
WAF 和 Firewall 都放行后，还需确认关键请求头没被意外清洗。
- 在服务端入口（如 Node.js 的
req.headers、Go 的r.Header）打印全部请求头，重点确认是否存在：
Upgrade: websocket、Connection: upgrade、Sec-WebSocket-Key - 若缺失
Upgrade或Connection头，说明 WAF 或反向代理做了头过滤；若Origin头被篡改或清空，可能是 WAF 的跨域策略干预 - Nginx 若与 WAF 共存（例如 WAF 前置 + Nginx 反向代理），需确保 Nginx 的
proxy_pass配置中proxy_set_header指令未被 WAF 覆盖或覆盖不全
