wss:// 是最基础标准的安全 WebSocket 连接方式，依赖 TLS 传输层加密而非前端加密；需服务端配置有效证书、443 端口及反向代理的 Upgrade 头支持，前端仅需将 ws:// 替换为 wss://；WSS 保障传输安全，敏感数据仍需应用层 AES-GCM 加密与动态密钥；必须配合短期 token 或首帧认证机制防未授权接入。
直接用 wss:// 开头的地址创建 WebSocket 实例，就是最基础、最标准的安全连接方式。它本身不依赖前端代码加密，而是靠 TLS 协议在传输层完成加密，前提是服务端已正确配置 HTTPS/WSS 支持。
第一步：确保服务端已启用 WSS
WSS 不是前端能“自己实现”的加密，而是客户端和服务端共同协商建立的加密通道。关键在服务端必须：
- 拥有有效的 SSL/TLS 证书（如 Let’s Encrypt 或商业证书）
- 监听 443 端口（或自定义 HTTPS 端口），并支持 WebSocket Upgrade 请求
- 若使用 Nginx / Apache 等反向代理，需显式开启 WebSocket 支持（转发
Upgrade和Connection头）
例如 Nginx 配置片段：
location /ws/ {
proxy_pass http://backend;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
}
第二步：前端用 wss:// 创建连接
只需把 ws:// 换成 wss://，浏览器会自动走 TLS 握手：
立即学习“Java免费学习笔记（深入）”；
const socket = new WebSocket('wss://api.example.com/ws');
注意：
- 如果页面本身是
https://，但尝试连接ws://，现代浏览器会直接拦截并报Mixed Content错误 - 域名、端口、路径必须和服务端证书匹配，否则会出现证书无效警告或连接失败
- 连接成功后，所有帧（包括握手阶段的 HTTP header）都经过 TLS 加密，中间人无法窃听或篡改
第三步：需要应用层加密吗？看场景
WSS 保障的是“线上传输安全”，但数据在浏览器内存、服务端进程、日志、代理节点等环节仍可能是明文。如果涉及敏感信息（如用户身份、金额、指令），建议额外做应用层加密：
- 前端用
window.crypto.subtle（非 CryptoJS）执行 AES-GCM 加密 - 密钥由服务端动态下发，绑定 session 或短期 token，绝不硬编码
- 每次加密使用随机 12 字节 IV，并随密文一同发送
- 附加数据（如时间戳 + client_id）用于防重放和来源校验
示例发送逻辑（简化）：
const encoder = new TextEncoder();
const data = encoder.encode(JSON.stringify({ action: 'pay', amount: 99.9 }));
const iv = window.crypto.getRandomValues(new Uint8Array(12));
const key = await importKeyFromServer(); // 服务端返回的密钥
const encrypted = await window.crypto.subtle.encrypt(
{ name: 'AES-GCM', iv, additionalData: encoder.encode(Date.now() + clientId) },
key,
data
);
socket.send(JSON.stringify({
iv: btoa(String.fromCharCode(...iv)),
data: btoa(String.fromCharCode(...new Uint8Array(encrypted)))
}));
第四步：配合认证机制防未授权接入
WSS 加密不等于身份可信。攻击者仍可发起合法 WSS 连接，因此必须叠加认证：
- 首次连接时，在 URL 中携带短期有效 token：
wss://api.example.com/ws?token=abc123 - 或在
open后立即发送认证消息，服务端验证通过才允许后续通信 - 服务端应校验 token 签名、有效期、绑定设备/IP 等维度，拒绝无效或过期请求
避免把敏感凭证放在 query string 中长期暴露，优先使用连接后首帧认证 + token 刷新机制。
