nginx 没有 proxy_limit_rate 指令；实际可用的是 limit_rate 和 limit_rate_after，用于按连接限制响应体向客户端发送速率，不支持 websocket 限速，该场景需在应用层实现。

proxy_limit_rate 是 Nginx 用于限制响应体（response body） 向客户端发送速率的指令，但它不适用于 WebSocket 连接。

原因很直接：WebSocket 建立后，通信不再走 HTTP 的“请求-响应”模型，而是升级为全双工的二进制/文本帧流。Nginx 在完成 Upgrade 协议切换后，本质上是将连接“移交”给后端（如 ASP.NET Core、Node.js 等），后续数据帧绕过 Nginx 的响应体处理逻辑，因此 proxy_limit_rate 完全不生效。

换句话说：
✅ proxy_limit_rate 可控的是普通 HTTP 接口返回大文件时的下载速度；
❌ 对 WebSocket 的 send()、broadcast()、心跳帧、消息推送等下行流量无任何限速作用。

---

那该怎么限制 WebSocket 单连接下行带宽？

真正有效的限速必须落在应用层（后端服务），由业务代码或框架自身控制。以下是常见路径：

• SignalR（.NET）

  

  aperture: the L402 aware reverse proxy

  安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。

  下载
  • 使用 IHubContext.Clients.All.SendAsync(...) 时，无法通过中间件统一限速；
  • 需在业务逻辑中做节流（throttling）：例如用 TimeSpan.FromMilliseconds(100) 控制每条连接每秒最多发 10 条消息；
  • 或结合 Channel<t></t> + RateLimiter（.NET 8+）对每个连接 ID 绑定独立限流器。

• Node.js（ws / Socket.IO）

  • 对每个 ws 实例维护一个发送队列 + setInterval 控制出包频率；
  • 使用 rate-limiter-flexible 按 socket.id 限流；
  • 若用 Socket.IO，可监听 socket.emit() 前拦截并判断是否超限。

• Java（Spring WebFlux + WebSocket）

  • 在 WebSocketSession.send() 调用前接入 Flux 的 onBackpressureBuffer() + sample() 或 throttleFirst()；
  • 或使用 Resilience4j RateLimiter，以 session ID 为 key。

---

Nginx 能做什么？（辅助角色）

虽然不能限带宽，但 Nginx 可协助做以下事情：

• ✅ 设置 proxy_read_timeout 和 proxy_send_timeout，防止长连接空闲僵死；
• ✅ 用 limit_conn（配合 limit_conn_zone $binary_remote_addr zone=ws:10m;）限制单 IP 并发连接数；
• ✅ 用 limit_req 控制握手阶段（/ws/ 路径）的 HTTP 请求频次，防恶意建连；
• ❌ 不要用 proxy_buffering off + proxy_limit_rate 试图“凑合限速”，它不会影响 WebSocket 数据帧。

---

小结建议

• 别在 Nginx 层尝试用 proxy_limit_rate 管 WebSocket 下行带宽——它不起作用；
• 限速逻辑必须下沉到后端服务，按连接维度（如 socket ID / connection ID）做独立速率控制；
• 优先使用成熟限流库（如 .NET 的 RateLimiter、Java 的 Resilience4j、Node 的 rate-limiter-flexible）；
• 配合 Nginx 的连接数限制和超时设置，提升整体稳定性。