WSS安全需证书、TLS版本、加密套件、重定向及服务端配置协同加固：证书须由可信CA签发且含完整SAN；强制TLS 1.2+；启用PFS套件；HTTP→HTTPS/WSS重定向+前端协议校验。
WebSocket Secure（WSS）是 WebSocket 协议在 TLS/SSL 加密通道上的实现，其安全传输能力完全依赖于正确配置的 SSL 证书和服务器端安全策略。仅部署证书远远不够，需从证书有效性、协议版本、加密套件、HTTP 重定向及服务端配置等多维度协同加固。
证书必须由可信 CA 签发且覆盖完整域名
WSS 连接会严格校验证书链完整性与域名匹配性。自签名证书或仅用于 HTTP 的证书（如未包含 wss://example.com 对应的 SAN 条目）将导致浏览器直接拒绝连接，并抛出 NET::ERR_CERT_AUTHORITY_INVALID 或 SEC_ERROR_UNKNOWN_ISSUER 错误。
- 使用 Let’s Encrypt、Sectigo 或 DigiCert 等公共可信 CA 签发证书，避免私有 CA（除非客户端已预置根证书）
- 确保证书中 Subject Alternative Name（SAN）包含所有实际使用的 WSS 域名，例如：
DNS:api.example.com、DNS:ws.example.com - 证书有效期建议控制在 90 天内（如 Let’s Encrypt），并配置自动续期脚本，防止因过期导致连接批量中断
服务端必须启用 TLS 1.2 或更高版本
旧版 TLS 1.0/1.1 存在 POODLE、BEAST 等已知漏洞，主流浏览器（Chrome、Firefox、Safari）已默认禁用。若服务端仍支持 TLS 1.0，WSS 握手会在 ClientHello 阶段失败，表现为连接超时或 net::ERR_SSL_VERSION_OR_CIPHER_MISMATCH。
- Nginx 示例：在
ssl_protocols中显式限定为TLSv1.2 TLSv1.3，禁用低版本 - Node.js（ws + https 模块）：通过
https.createServer({ minVersion: 'TLSv1.2' }, ...)强制最低版本 - 使用 SSL Labs Test 验证服务器是否真正禁用不安全协议
优先选用前向保密（PFS）加密套件
即使私钥未来泄露，采用 ECDHE 或 DHE 密钥交换的套件可保障历史通信不被解密。非 PFS 套件（如 RSA 密钥交换）一旦私钥暴露，全部过往 WSS 流量均可被回溯解密。
立即学习“前端免费学习笔记（深入）”；
- Nginx 推荐配置：
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384; - 禁用含
RC4、DES、3DES、MD5、SHA1的弱套件 - 可通过
openssl s_client -connect ws.example.com:443 -tls1_2手动测试协商结果
强制 HTTP → HTTPS + WS → WSS 重定向与前端校验
仅靠后端支持 WSS 不足以防范中间人降级攻击。客户端若错误使用 ws:// 协议，攻击者可劫持并转发为明文连接，而浏览器不会主动警告。
- Web 服务器对
/ws或 WebSocket 入口路径返回 301 至wss://地址（注意：部分代理可能不透传 Upgrade 请求，慎用） - 前端代码中硬编码协议判断：
const protocol = location.protocol === 'https:' ? 'wss:' : 'ws:';，禁止用户手动切换协议 - 在 Service Worker 或 Nginx 中拦截
Upgrade: websocket且非 HTTPS 的请求，直接返回 403
WSS 安全不是单点配置任务，而是证书管理、传输层协议控制、加密策略设定与应用层防护的组合实践。忽略任一环节，都可能导致看似“已加密”的连接实际处于风险之中。
