WebSocket 使用 wss:// 协议时前端无需手动加密，浏览器自动完成 TLS 握手；关键在于服务端提供可信 HTTPS 环境，域名、证书（需含 SAN）、Nginx 代理配置（Upgrade 头透传）及服务端基于 HTTPS 启动并正确处理 upgrade 事件。
JavaScript 中 WebSocket 使用 wss:// 协议本身不需额外写加密代码——它依赖底层 TLS 通道，关键在于服务端是否真正提供了可验证的 HTTPS/WSS 环境。浏览器会自动完成 TLS 握手和加解密，前端只需确保 URL 正确、证书可信、代理透传到位。
前端连接必须用 wss:// 且域名严格匹配
协议、域名、端口（默认443）三者必须与服务端 HTTPS 配置完全一致：
- ✅ 正确：
new WebSocket('wss://api.example.com/ws')（域名与证书绑定，路径与后端 upgrade 路径一致） - ❌ 错误：
new WebSocket('wss://192.168.1.100:8080')（IP 地址无法通过证书校验，浏览器直接拒绝） - ❌ 错误：
new WebSocket('wss://example.com:8443')（若证书未声明该端口或 Nginx 未监听，连接失败）
证书必须由可信 CA 签发（生产环境）
浏览器只信任公共 CA（如 Let’s Encrypt、DigiCert）签发的证书。自签名或私有 CA 证书在生产中会触发安全警告，导致连接中断：
- Let’s Encrypt 证书路径示例：
/etc/letsencrypt/live/example.com/fullchain.pem（证书链）+privkey.pem（未加密私钥） - 前端无需加载证书文件，但访问域名必须出现在证书的 Subject Alternative Name（SAN）中
- 开发阶段可用自签名证书 + 本地信任，但不能用于线上
Nginx 或 CDN 必须正确透传 WebSocket 升级请求
多数 wss:// 连接失败并非证书问题，而是反向代理未识别 Upgrade 流程：
- 必须设置三项关键头：
proxy_http_version 1.1、proxy_set_header Upgrade $http_upgrade、proxy_set_header Connection "upgrade" - 确保 Nginx 的
location块匹配 WebSocket 请求路径（如/ws），且不被其他 rewrite 或 proxy 规则拦截 - 检查浏览器开发者工具 Network 面板：成功升级应返回状态码 101 Switching Protocols；若显示 200，则代理未转发升级请求
服务端必须基于 HTTPS 创建并处理 upgrade 事件
不能复用 HTTP 服务器。以 Node.js + ws 库为例：
- 用
https.createServer({ key, cert })启动服务，而非http.createServer() - 监听
'upgrade'事件，交由wss.handleUpgrade()处理，而不是在 Express 路由里响应 - 若使用 Swoole、EMQX、Spring WebSocket 等框架，需确认其 SSL 模块已启用，且配置了
ssl_cert_file和ssl_key_file（PEM 格式、私钥无密码）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
