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 证书在生产中会触发安全警告,导致连接中断:
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 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 大师之旅:从入门到精通的终极指南










