Nginx代理WebSocket真正安全的关键是TLS终止实现WSS加密：需配置有效SSL证书、启用TLSv1.2+、透传Upgrade和Connection头，并配合后端认证与消息校验。
要让 Nginx 代理的 WebSocket 连接真正安全，关键不是“代理”本身，而是用 TLS 将明文 ws 升级为加密的 wss，并在握手、传输、验证环节做系统性加固。
必须启用 TLS 终止并配置强 SSL 策略
Nginx 在 443 端口完成 TLS 握手后，才把解密后的 Upgrade 请求转发给后端。这意味着所有 WebSocket 帧数据都在 TLS 层加密传输，中间人无法窃听或篡改。
- 使用有效的证书（如 Let’s Encrypt 的 fullchain.pem 和 privkey.pem）
- 禁用 SSLv2/v3、TLSv1.0 等老旧协议，只启用 TLSv1.2 或 TLSv1.3
- 选用支持前向保密（PFS）的加密套件，例如 ECDHE-ECDSA-AES128-GCM-SHA256
严格透传 WebSocket 协议升级头
WebSocket 握手依赖一次标准 HTTP 升级请求，Nginx 必须原样传递两个逐跳头部，否则后端收不到升级信号，会返回 200 而非 101，连接失败。
- proxy_http_version 1.1; —— HTTP/1.0 不支持 Upgrade 机制
- proxy_set_header Upgrade $http_upgrade; —— 转发客户端原始值（如 websocket、mqtt）
- proxy_set_header Connection "upgrade"; —— 必须是带英文双引号的字面量，不能写成 $http_connection（可能含 keep-alive）
配合后端实现端到端可信链路
Nginx 的 TLS 终止只保护公网段，内网到后端仍为明文。若需全程加密或强认证，需额外措施：
- 后端启用双向 TLS（mTLS），要求客户端证书校验
- 在 WebSocket 握手后增加 Token 鉴权（如 JWT 放在 query 或 header 中），由后端校验有效性
- 对敏感业务消息做签名或 AES 加密，避免依赖通道层单一防护
避免常见配置陷阱
看似简单几行配置，稍有遗漏就会导致 wss 连接静默失败或降级为 ws。
- 不要省略 ssl_certificate 和 ssl_certificate_key，路径必须可读
- location 匹配要精确（如 = /ws 或 /ws/），避免被 rewrite 或其他规则拦截
- 禁用 proxy_buffering 和 proxy_cache，防止帧被缓存合并或延迟投递
