WebSocket长连接DDoS攻击防护方案：四道闸配置

WebSocket长连接DDoS攻击防护方案的落点是四道闸：握手鉴权、单IP并发连接配额、消息频率与帧大小限制、空闲心跳超时回收。之所以要另起一套方案，是因为传统逐请求型WAF在HTTP 101 Upgrade之后失去检测点。典型症状是：游戏对局房间或行情推送的连接数在几分钟内翻倍，而带宽与QPS保持低位，内存与文件描述符（FD）不断爬升。

实时业务的全面WebSocket化，正在把一种新型的连接耗尽型攻击推到台前。OWASP 在 2026 年的 WebSocket 安全指引中，将握手阶段校验、单 IP 并发连接配额与单连接消息速率限制列为明确要求；Cloudflare 的网络设置文档也确认了边缘节点对 WebSocket 长连接的原生支持与空闲超时机制。这些标准与官方表述，共同指向一套四道闸的防御框架。

先分流：连接数暴涨但带宽和QPS都不高，到底是攻击还是自己的问题

攻击形态有三类：一是握手洪泛，攻击者用极低成本反复完成握手，把连接池占满，连接曲线只增不减，但单连接几乎无业务流量；二是单连接高频小包帧洪泛，一条合法连接内持续发送大量小型数据帧，推高内存与CPU占用；三是伪造跨站握手（CSWSH，Cross-Site WebSocket Hijacking），利用浏览器同源策略盲区，把受害者会话引导到攻击者控制的端点。若连接建立后长期低速占用而不断开，形态更接近慢速CC攻击防护所述场景。

与之相对，不少“攻击”其实是自己的问题：代码里连接未正确关闭导致泄漏、客户端在弱网下反复重连形成风暴。区分的关键是看连接曲线形态——攻击性增长通常是阶梯式或突发式上涨，且不会自然回落；连接泄漏往往是缓慢爬坡，重连风暴则呈现周期性波动。

为什么逐请求型WAF在HTTP Upgrade之后就不再介入：检测断点在哪

WebSocket 的握手过程是客户端先发一个普通的 HTTP Upgrade 请求，服务端响应 HTTP 101 Switching Protocols 之后，连接就切换为双向持久数据传输。关键点在于，从 101 响应发出后，这条 TCP 连接内流动的不再是“请求-响应”对，而是连续的、不分包的文本或二进制数据帧。逐请求型 WAF 只能逐请求检测，无法对长连接内部的持续数据帧做持续过滤。这导致传统 CC 防护在 WebSocket 场景下几乎失效，攻击者只需一次握手即可长期占用资源。WebSocket 攻击与 HTTP CC 攻击的本质区别在于计量单位：HTTP CC 按请求数，WebSocket 按连接数和消息数；成本结构也不同，握手成本远低于完整请求，且更耗内存和 FD 而非带宽。这正是WebSocket长连接DDoS攻击防护方案必须另起炉灶的原因。

第一道闸：握手阶段的Origin与凭证校验，把拒绝动作放在建连之前

连接一旦建立，回收的成本远高于拒绝的成本。OWASP 指引强调，握手阶段必须强制校验 Origin 与凭证。具体校验清单包括三点：一是校验 Origin 头，只放行白名单内的来源，防止跨站伪造握手；二是认证令牌在握手阶段核验，而非等首帧到达——因为恶意连接可能在首帧之前就产生资源占用；三是拒绝时直接返回握手失败，而非先升级再断开。

副作用与误伤风险：移动端原生客户端、服务端间通信往往不携带 Origin 头，强制校验会导致合法连接被拒。建议对带 Origin 的请求校验来源，无 Origin 的兜底校验凭证，并把白名单做成配置项。

第二道闸：按IP或用户设并发连接配额，配额怎么估、NAT用户会不会误伤

单 IP 并发连接配额是四道闸里最容易配错的一环。配太少，NAT 后的真实用户被误杀；配太多，又起不到隔离攻击者的作用。合理做法是先用业务基线估算：统计正常用户平均连接数，乘以安全系数作为配额起点。实现上在边缘或应用层按 IP 维度限制，但更推荐叠加用户维度。Nginx 的 limit_conn 指令作用于连接维度，需配合 Upgrade 和 Connection 头透传。Nginx 侧的限流写法可参考Nginx防CC攻击限流配置最佳实践。

副作用与误伤风险：企业出口和移动网络普遍存在 NAT，纯 IP 配额容易误伤，配额值必须根据自身流量分布压测校准。

第三道闸：消息频率与单帧大小限制，为什么要按消息数而不是按请求数计量

OWASP 指引把单连接消息速率限制列为 DoS 防御的明确要求。正确做法是把计量单位切换到消息数、字节数和帧大小。建议分维度限制：每连接每秒消息数上限、单帧最大字节数、单连接累计流量上限。超限处置可梯度进行：先丢帧降速，再关闭连接并计入 IP 信誉。合法业务可能有突发，需设置豁免通道。

副作用与误伤风险：限流阈值过紧会拦截真实业务流，建议先统计正常业务消息分布再设定阈值，保留动态调整接口。

第四道闸：空闲超时与心跳回收，超时值设多短会误断真实客户端

空闲超时是防止连接泄漏与僵尸连接堆积的兜底闸。Cloudflare 的 WebSocket 文档中提到，其边缘网络默认设定 100 秒无活动即切断连接——该值作为常见默认参考，不是行业标准，更不是你的业务标准。关键是把应用层心跳间隔设得短于链路上最短的空闲超时窗口。一条连接从客户端到源站可能经过 CDN、负载均衡、NAT 网关，每段都可能有自己的空闲切断机制，最短窗口决定真实保活期限。建议心跳间隔设为链路最短超时的一半以下，如 30 秒起步（该值为经验起点，需按自身链路各段实际空闲超时与断线率压测校准，非通用建议），同时客户端支持指数退避重连。

WebSocket长连接DDoS攻击防护方案四道闸对照表与不合格信号速查

下表汇总了WebSocket长连接DDoS攻击防护方案的四道闸：

对照此表自查，若缺任何一道闸都可能被攻击者利用。不合格信号速查：连接数只涨不落、内存与 FD 同步逼近上限、断开率长期为零、单 IP 连接占比畸高。

为什么连接终止与频控应前移到边缘：RockCloud的落位方式

现代 CDN 与边缘反向代理原生支持 WebSocket 透传与连接汇聚，在 Anycast 节点完成协议终结与连接清洗，可显著收敛回源连接数，是抵挡连接耗尽型攻击的天然屏障。把连接终止和频控放在边缘，攻击者的握手请求在到达源站前就被处理，源站只保留超时回收与业务校验兜底。RockCloud 高防 CDN 与游戏盾在握手层承载长连接，按 IP 下发并发连接配额与消息速率策略，配合源站白名单与回源收口，防止攻击者绕过边缘直连 WebSocket 端口。边缘防护并非万能，无法完全阻断真实客户端发起的长连接滥用，也不能零误伤。若担心源站 IP 暴露，可参考如何防止源站真实IP暴露中的收口方案。

上线前后的验证清单：压测方法与要盯的三个指标

WebSocket长连接DDoS攻击防护方案配置完成后，必须做三类压测：握手洪泛、单连接帧洪泛、半僵尸连接。每类压测验证对应道闸是否按预期拒绝。灰度阶段先只告警不阻断，观察误断率再逐步收紧。三个必盯指标：①并发连接数与回源连接数比值，边缘生效时回源数应远小于客户端数；②进程 FD 与内存占用曲线应平稳；③真实用户异常断线率与重连成功率，过高说明配置过紧需回调。

常见问题

websocket连接数被占满怎么办？

先看连接曲线：只增不减且带宽低，大概率是攻击，立即启用配额与超时回收；若缓慢爬坡，可能是连接泄漏，需检查代码中的关闭逻辑。

websocket攻击和http cc攻击有什么区别？

核心在计量单位：HTTP CC 按请求数，WebSocket 按连接数和消息数。握手成本远低于完整请求，且主要耗内存和 FD 而非带宽。

websocket握手要不要校验origin？

要。OWASP 明确要求校验 Origin 防止 CSWSH。移动端和服务端间可能不带 Origin，需兜底校验凭证。拒绝时直接返回握手失败。

websocket心跳超时设置多少合适？

没有标准值，需看链路最短空闲超时。以 Cloudflare 默认 100 秒为参考，建议心跳间隔设为链路最短超时的一半以下，如 30 秒起步（该值为经验起点，需按自身链路各段实际空闲超时与断线率压测校准，非通用建议）。

高防CDN支持websocket吗？

支持。现代高防 CDN 原生支持 WebSocket 透传与连接汇聚，可在边缘终结连接、清洗攻击并收敛回源连接数。具体并发上限和超时参数需咨询服务商。

nginx websocket 单IP并发连接限制怎么配？

使用 limit_conn 指令限制单 IP 连接数，需配合 Upgrade 和 Connection 头透传。配额值应基于业务基线估算，避免误伤 NAT 用户。

长连接服务内存暴涨是被攻击了吗？

不一定，也可能是连接泄漏或重连风暴。观察连接数是否只增不减、FD 是否同步爬升。若连接数稳定但内存涨，可能是帧洪泛，需结合四道闸排查。