nginx 对 websocket 数据帧流不支持 limit_rate 带宽限速，因其握手后进入隧道模式，仅透传tcp字节流而不解析或缓冲业务数据；真正有效的限速需在后端服务端实现帧级控制，或通过 limit_conn 限并发、limit_req 限握手频率。
WebSocket 是长连接，Nginx 本身不支持对 WebSocket 数据帧流做“每秒多少字节”的实时带宽限速（如 limit_rate 对普通 HTTP 响应体那样直接生效），因为 limit_rate 仅作用于 Nginx 向客户端发送的响应体数据，而 WebSocket 连接建立后，Nginx 实际上是作为 TCP 隧道透传双向帧流，并不解析或缓冲业务数据——它不把消息当“响应体”处理。
为什么 limit_rate 对 WebSocket 连接基本无效
一旦 WebSocket 握手完成（返回 101 状态），Nginx 就进入“隧道模式”（tunnel mode），此时：
– 不再区分 request/response，而是双向转发原始 TCP 字节流
– proxy_buffering off 是常态，limit_rate 失去作用对象
– 即使开启缓冲，Nginx 也不会对 WebSocket 帧做速率整形，只可能影响初始握手响应的发送节奏，而非后续心跳、消息等真实数据流
真正可行的单连接速率控制方式
若需约束单个 WebSocket 连接的数据吞吐，应从以下两个层面入手：
-
后端服务自身限速：在 WebSocket 服务端（如 Node.js 的
ws库、Go 的gorilla/websocket）实现发送/接收速率限制。例如按连接维度启用令牌桶，控制每秒最多发 N 帧或 M 字节。这是最准确、最可控的方式 -
利用 Nginx 的连接级资源约束间接影响：
- 用
limit_conn控制每个 IP 允许的并发连接数，防止单用户独占过多连接资源 - 配合
proxy_buffer_size和proxy_buffers调小缓冲区（如设为4k），可略微增加写阻塞概率，对突发大包有一定抑制作用（非精确限速，仅辅助） - 不推荐依赖
limit_rate，即使强行配置，也仅可能在握手响应阶段起微弱作用，对长连接期间的帧流无实质限制
- 用
不建议但偶见的“伪限速”尝试
有用户尝试在 location 中加：
limit_rate 100k;<br>limit_rate_after 1m;
这类配置对 WebSocket 连接几乎无效。它可能让握手响应变慢，甚至导致超时失败；但连接建立后，该指令不再介入数据流。反而容易引发客户端重连风暴或服务端误判。
总结：该由谁来限速、怎么限更合理
WebSocket 的数据流本质是应用层协议帧，不是 HTTP 响应体。Nginx 的角色是可靠透传，不是内容网关。
– 想控单连接带宽 → 在业务服务端做帧级限速
– 想防资源滥用 → 用 limit_conn 控并发、limit_req 控握手频率、proxy_read_timeout 防空闲耗尽
– 别指望 Nginx 的 limit_rate 能管住 WebSocket 的实时消息流
