必须实施多层防护：Nginx层按IP限流并强制WSS，应用层校验Origin、JWT认证、独立滑动窗口限速及心跳超时，杜绝CSWSH、DoS与未授权操作。
要防御针对 WebSocket 的协议攻击，不能只靠前端或单一层防护，必须在反向代理层、传输层、应用逻辑层做多级联动配置。核心是堵住握手阶段的入口、加密通道、限制连接行为、校验身份来源。
强制启用 WSS 并禁用明文 ws://
所有 WebSocket 连接必须走 wss://，禁止任何 ws:// 请求抵达服务端。Nginx 或负载均衡器需配置 301 重定向或直接拒绝：
- 在 Nginx 中添加 location 块拦截 ws:// 请求：
if ($scheme = 'http') { return 301 https://$host$request_uri; } - 后端服务（如 ASP.NET Core、Node.js、uWebSockets）启动时检查
context.Request.IsHttps或req.socket.encrypted，非 HTTPS 握手直接返回 403 - 证书必须由可信 CA 签发，禁用 TLS 1.0/1.1，仅允许 TLS 1.2+ 与强加密套件（如
ECDHE-ECDSA-AES256-GCM-SHA384）
在反向代理层做 IP 级连接限流
浏览器的并发连接限制（6–10 个）完全不可信，攻击者可用 curl、ws-cli 或自研脚本绕过。Nginx 必须作为第一道闸门拦截超额连接：
- 用
map提取真实客户端 IP（支持X-Forwarded-For或CF-Connecting-IP，并配合set_real_ip_from防伪造） - 配置
limit_conn_zone按 IP 统计活跃连接数，例如单 IP 最多 5 个 WebSocket 并发连接 -
limit_conn作用于/ws路径，且仅对Upgrade: websocket请求生效——它在 HTTP 握手阶段就拦截，不消耗后端资源
服务端实施细粒度连接管控
连接建立后仍需防御高频消息、长连接滥用、未授权操作等：
- 每个
websocket.Conn实例绑定独立滑动窗口计数器，限制每秒最大消息数（如 ≤10 条），避免全局限速误杀正常用户 - 设置心跳超时（如 45 秒无 ping/pong 自动断连），防止空连接堆积耗尽 fd
- 在握手阶段验证
Origin头是否匹配白名单域名，防止跨站 WebSocket 劫持（CSWSH） - 拒绝携带非法
Sec-WebSocket-Protocol子协议的请求，只接受预定义协议名（如chat.v1、datafeed.v2）
认证与数据校验必须落地到帧处理环节
WebSocket 没有内置认证，凭证必须在握手时传递，并在后续每帧处理中复核权限：
- 推荐使用短期 JWT（有效期 ≤15 分钟）通过查询参数或
Authorization头传入，服务端解析后存入连接上下文 - 避免用 localStorage 存 token；若用 Cookie，必须设
Secure、HttpOnly、SameSite=Strict - 接收消息帧前，校验该连接对应的用户是否有权访问目标频道或执行对应操作（如 “用户 A 不能向频道 B 发送 admin 指令”）
- 对敏感指令（如资金划转、设备控制）额外要求二次确认或签名验签，不依赖前端传来的原始字段
