Nginx代理WebSocket实现WSS安全的关键在于TLS终止与协议升级协同：需配置SSL证书、启用TLSv1.2+、透传Upgrade和Connection头，并配合后端认证与消息校验。
靠 Nginx 代理 WebSocket 本身不自动保证安全，真正起作用的是它配合 TLS/SSL 实现的 WSS（WebSocket Secure）通道。核心不是“代理”这个动作，而是把明文 WS 升级为加密的 WSS，并在握手、传输、验证各环节做加固。
用 TLS 终止建立加密通道
Nginx 在 443 端口接收客户端的 WSS 请求，完成 TLS 握手（证书校验、密钥协商），之后才把解密后的 HTTP 升级请求转发给后端。这意味着：所有 WebSocket 帧数据都在 TLS 层加密后再走公网，中间人无法窃听或篡改。
- 必须配置有效的 SSL 证书（推荐 Let’s Encrypt 的 fullchain.pem + privkey.pem）
- 禁用老旧协议（如 SSLv2/v3、TLSv1.0），只启用 TLSv1.2/TLSv1.3
- 选用强加密套件，例如 ECDHE-ECDSA-AES128-GCM-SHA256，支持前向保密（PFS）
正确透传协议升级头
WebSocket 连接始于一次 HTTP Upgrade 请求。Nginx 必须原样传递关键头部，否则后端无法识别并接受升级，连接会降级成普通 HTTP 或直接失败。
- proxy_http_version 1.1：HTTP/1.0 不支持 Upgrade 机制
- proxy_set_header Upgrade $http_upgrade：把客户端发来的 Upgrade: websocket 头传过去
- proxy_set_header Connection "upgrade"：告诉后端这是协议切换请求，不是普通连接
后端身份与消息级防护不能省
Nginx 负责链路层加密，但不处理业务层安全。真实风险常出现在握手后：
- 认证不能只靠 URL 参数（如
?token=xxx），容易泄露在日志或代理头中；推荐用带 Secure+HttpOnly+SameSite=Strict 的 Cookie，或 Authorization Bearer 请求头 - 服务端必须在 accept 连接前校验令牌有效性，并定期刷新会话（比如每 30 分钟重验一次）
- 每条收到的消息都要做输入验证：UTF-8 合法性检查、JSON 结构校验、二进制帧长度限制（建议 ≤1MB）、敏感内容转义
补充加固降低攻击面
除了加密和认证，还需防止常见滥用行为：
- 关闭不必要的响应头：server_tokens off 隐藏 Nginx 版本号
- 限制连接速率：limit_req 防暴力建立大量无效连接
- 设置长连接超时：proxy_read_timeout 86400（24 小时），避免连接被中间设备误断
- 禁用缓冲：proxy_buffering off，确保实时消息不被延迟或截断
