WebSocket URL 必须为 wss:// 或 ws://，格式为协议://域名:端口/路径?查询参数；HTTPS 页面中 ws:// 会被浏览器静默拦截，必须用 wss://；wss:// 要求后端真实完成 TLS 握手，证书需有效、匹配、未过期且链完整。
必须用 wss:// 的地方，写成 ws:// 会直接失败——不是连不上，而是浏览器根本不会发请求。
WebSocket URL 的基本格式长什么样
WebSocket 连接地址本质是 URI，结构和 HTTP URL 一致：协议://域名:端口/路径?查询参数。协议部分只能是 ws 或 wss，其余字段可选但语义明确：
-
ws://localhost:8080/chat：本地开发常用，明文走 8080 端口（非默认 80） -
wss://api.example.com/v1/ws：生产环境标准写法，加密走 443（省略端口即默认） -
ws://192.168.1.100:3000：内网直连 IP，无域名证书问题 -
wss://example.com:8443/stream：显式指定非标 HTTPS 端口（需后端 TLS 终止在此端口）
注意：ws:// 和 wss:// 后不能跟 http:// 风格的完整 URL；也不能省略协议头直接写 localhost:8080——那不是合法 WebSocket 地址。
为什么 ws:// 在 HTTPS 页面里一定报错
现代浏览器（Chrome、Firefox、Safari 等）强制执行混合内容策略（Mixed Content Blocking）：HTTPS 页面中任何主动加载的非加密资源（包括 ws:// 连接）会被静默拦截，并在控制台抛出类似这样的错误：
Blocked loading mixed active content “ws://example.com”
这不是配置问题，是安全机制硬限制。即使你用 localhost、127.0.0.1 或自签名证书，只要页面本身是 https:// 开头，就必须用 wss://。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 开发时若用
https://localhost（如 Vite/HMR 默认启的 HTTPS），连本地ws://localhost:8080也会被拦 - 前端部署在 CDN 或 Nginx 反代后，若只配了 HTTPS 入口但没透传 WebSocket 升级头（
Upgrade、Connection），wss://请求会在代理层就降级成 HTTP 400 -
wss://不代表“只要加 s 就行”，它要求后端真实完成 TLS 握手——证书必须有效、域名匹配、未过期、链完整
wss:// 连接失败的常见证书类原因
wss:// 不是简单把 ws 换成 wss 就能通。它依赖 TLS 层成功建立，以下任一条件不满足都会在 onerror 或控制台报错，且通常不触发 onclose：
- 后端没绑定证书：Node.js 的
https.createServer({ key, cert }, app)忘传key或cert，连接会在 TLS 握手阶段直接断开 - 证书域名不匹配：用
localhost证书去连wss://example.com，浏览器拒绝信任 - 使用自签名证书但未手动信任：开发时用
mkcert生成的证书，需导入系统或浏览器根证书库，否则 Chrome 显示ERR_CERT_AUTHORITY_INVALID - CDN 或 LB 终止 TLS 但未正确配置 WebSocket 支持：例如 Cloudflare 默认不转发 WebSocket 流量，需开启“WebSockets”开关；Nginx 需显式添加
proxy_http_version 1.1和proxy_set_header Upgrade $http_upgrade
验证是否真通 TLS 层，最简单方法是用 curl 测试握手：curl -i -N -H "Connection: Upgrade" -H "Upgrade: websocket" -H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" https://example.com/path。如果返回 HTTP 101 Switching Protocols，说明 TLS 和升级头都 ok；若返回 400/502/证书错误，则问题在传输层。
开发阶段怎么快速绕过证书限制
仅限本地调试，不可用于测试环境或交付：
- Chrome 启动时加参数：
chrome --unsafely-treat-insecure-origin-as-secure="http://localhost:8080" --user-data-dir=/tmp/chrome-test，然后用http://localhost:8080页面连ws://localhost:8080 - 用
http://127.0.0.1:port替代https://localhost加载页面——因为localhost是浏览器白名单，http://localhost允许混用ws:// - 后端启用自签名证书并用
mkcert生成可信证书，比用openssl req手动生成更省事
真正要上线前，wss:// 的证书链、域名、端口、反代配置这四点一个都不能含糊——它不像 HTTP 错误还能看到响应体，TLS 握手失败时前端往往只收到一个空的 onerror，排查必须从网络层抓包或服务端日志入手。
