proxy_limit_rate对WebSocket完全无效，因其仅作用于HTTP响应体发送阶段，而WebSocket升级后数据帧绕过Nginx发送逻辑，须在应用层按连接ID实现独立限速。
WebSocket 连接无法用 Nginx 的 proxy_limit_rate 限带宽——它根本不起作用。 这个指令只对 HTTP 响应体生效，而 WebSocket 升级后走的是原始 socket 帧流，Nginx 不再参与数据帧的发送控制。真要限制单连接下行带宽，必须在应用层做，且需按连接 ID 独立限速。
为什么 proxy_limit_rate 对 WebSocket 完全无效
Nginx 在收到 Upgrade: websocket 请求并返回 101 Switching Protocols 后，就将该 TCP 连接“移交”给后端进程（如 Node.js、.NET 或 Java 服务）。后续所有 send()、broadcast()、心跳帧都绕过 Nginx 的响应体缓冲与发送逻辑，proxy_limit_rate 所依赖的 ngx_http_send_special() 路径压根不触发。
常见误操作包括：
- 在
location /ws/块里加proxy_limit_rate 100k;—— 配置能 reload，但对实际消息推送零影响 - 配合
proxy_buffering off;试图“让流量裸奔好限速” —— 只会让内存拷贝更频繁，不改变速率 - 用
limit_req拦握手阶段请求 —— 这只能控建连频次，不能控建连后的每秒发包量
Node.js 中基于 socket ID 的令牌桶限速
每个 ws 实例有唯一 socket.id（或可自建 connectionId），限速必须绑定这个维度，否则共享桶会导致误杀或漏放。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 用
rate-limiter-flexible创建 per-socket 限流器：new TokenBucket({ capacity: 50, fillRate: 50 / 1000 })表示每毫秒最多 0.05 条，即每秒 50 条 - 每次
ws.send()前调用limiter.remove(1)，失败则ws.close(1008) - 避免在
ws.on('message')回调里直接await limiter.remove()—— 若未try/catch，异常会吞掉连接，改用limiter.remove().catch(() => ws.close()) - 注意：
ws.send()是异步但不返回 Promise，真正需要 await 的是限流器本身
.NET 8+ 使用 RateLimiter 绑定连接生命周期
SignalR 默认不提供 per-connection 限速钩子，必须在 IHubContext.Clients.Client(connectionId).SendAsync() 之前插入手动控制。
- 用
RateLimiter的TryAcquire()非阻塞判断，避免线程挂起；失败时返回Result.Rejected并记录connectionId - 限流器 key 必须是
connectionId，而非userId—— 同一用户多设备登录时，每个连接需独立配额 - 不要复用同一个
RateLimiter实例全局共享，而应通过IServiceProvider按 scope 解析，或用ConcurrentDictionary<string ratelimiter></string>动态管理 - 搭配
WebSocketOptions.KeepAliveInterval设置为 30s，防止限速器长期持有已断开连接的资源
Java Spring WebFlux + WebSocket 的背压适配
Spring 的 WebSocketSession.send() 返回 Mono<void></void>，天然支持响应式背压，但默认不启用。关键不是“限速”，而是让发送链路感知下游消费能力。
- 用
session.sendMessage(message).onErrorResume(e -> Mono.empty())避免因客户端接收慢导致OutOfMemoryError - 在发送前插入
Flux.fromArray(messages).throttleFirst(Duration.ofMillis(20))，强制最小间隔 20ms，等效于 50 条/秒 - 若用
Resilience4j RateLimiter，务必设置timeoutDuration = 0，否则超时会抛RequestNotPermittedException中断整个 Mono 流 - 不要在
@MessageMapping方法里做限速 —— 那是入站消息处理，此处要控的是出站session.send()
最易被忽略的一点：带宽限速 ≠ 消息条数限速。64KB/条的消息发 10 条/秒就是 6.4MB/s，而 1KB/条发 100 条/秒才 0.1MB/s。实际部署前，必须用真实消息体大小乘以目标 QPS，换算成字节率，再反推令牌桶参数。运营商按毫秒级采样限流时，哪怕平均值合规，瞬时 burst 仍可能触发熔断——这时就得上分片发送或内容压缩，而不是只调大令牌容量。
