WebSocket握手失败若由防火墙或代理引起，通常表现为ERR_CONNECTION_REFUSED、ERR_CONNECTION_TIMED_OUT等；需绕过浏览器分层验证链路，优先改用标准端口443、避免自签名证书、检查代理PAC脚本，并用curl或openssl手动模拟握手确认问题层级。
WebSocket 握手失败若由防火墙或代理引起，通常表现为 ERR_CONNECTION_REFUSED、ERR_CONNECTION_TIMED_OUT、net::ERR_PROXY_CONNECTION_FAILED，或控制台仅显示 WebSocket connection to 'wss://...' failed 而无进一步错误。关键排查思路是：**绕过浏览器自动行为，分层验证网络链路是否真正可达 WebSocket 端点**。
确认 WebSocket URL 协议与端口未被策略阻断
企业防火墙/代理常默认放行 http/https（80/443），但显式拦截非标准端口（如 wss://api.example.com:8080）或非常用协议。即使使用 wss://，若后端实际监听在非 443 端口，仍可能被拦截。
- 优先改用标准端口：确保服务端 WSS 监听在
443，且域名有有效 TLS 证书；前端连接写成wss://api.example.com（不带端口） - 避免自签名证书：浏览器会因证书无效直接终止握手，看似“被拦截”，实为 TLS 层失败；用 Let's Encrypt 等可信证书
- 检查 URL 是否含特殊字符或路径：某些老旧代理会错误解析
wss://host/path?token=...中的查询参数，可先简化为wss://host/测试
用 curl 或 OpenSSL 手动模拟 WebSocket 握手，隔离浏览器环境
浏览器封装了 WebSocket 协议细节，出错时无法看到底层 HTTP Upgrade 请求响应。用命令行工具直连，能明确判断是网络不通、TLS 失败，还是服务端未返回正确 Upgrade 响应。
- 测试 TLS 连通性（不涉及 WebSocket）：
openssl s_client -connect api.example.com:443 -servername api.example.com
若卡住或报connect: Connection refused，说明防火墙/代理已阻断 TCP 连接 - 模拟 WebSocket 握手请求（需手动构造 Header）：
curl -i -N -H "Connection: Upgrade" -H "Upgrade: websocket" -H "Sec-WebSocket-Version: 13" -H "Sec-WebSocket-Key: $(openssl rand -base64 16)" https://api.example.com/ws
正常应返回HTTP/1.1 101 Switching Protocols；若返回 4xx/5xx、超时或无响应，基本可定位为代理/防火墙干预或服务端配置问题
检查浏览器代理设置与 PAC 脚本行为
即使系统全局未设代理，企业环境常通过 Group Policy 或 PAC（Proxy Auto-Config）脚本强制路由流量。WebSocket 默认遵循 HTTP 代理规则，但部分代理不支持 CONNECT 隧道到非 443 端口，或直接丢弃 Upgrade 请求。
- 在 Chrome 地址栏输入
chrome://net-internals/#proxy，查看当前生效的代理配置和 PAC 脚本内容 - 临时关闭代理测试：Chrome 启动时加参数
--no-proxy-server，或在开发者工具 Network 标签页右键 WebSocket 请求 → “Replay XHR”（虽非完全等效，但可快速验证是否代理导致） - 确认 PAC 脚本是否对目标域名返回
DIRECT：例如if (shExpMatch(host, "api.example.com")) return "DIRECT";，避免 WebSocket 流量被导向不支持升级的代理
服务端日志与中间件检查不可少
客户端现象只能缩小范围，最终确认需依赖服务端视角。防火墙/代理可能静默丢包，也可能返回伪造的 HTML 错误页（如“访问被拒绝”），导致 WebSocket 客户端收不到 Upgrade 响应而超时。
- 检查反向代理（Nginx / Apache）配置：是否开启
proxy_http_version 1.1、proxy_set_header Upgrade $http_upgrade、proxy_set_header Connection "upgrade" - 抓包验证：在服务端执行
tcpdump -i any port 443 -w ws.pcap，用 Wireshark 打开，过滤tls.handshake.type == 1（Client Hello）和http.request.method == "GET"，看是否有完整的 TLS 握手 + HTTP Upgrade 请求到达 - 对比 HTTP 与 WS 行为：用
curl https://api.example.com/health成功，但curl -H "Upgrade: websocket" ...失败，大概率是代理层或负载均衡器未透传 Upgrade 请求
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
