核心是关闭Nginx响应缓冲机制：必须在location块中设proxy_buffering off;，同时禁用proxy_cache、gzip及tcp_nopush，并启用tcp_nodelay on。
要减少 WebSocket 代理卡顿，核心不是调大缓冲区，而是**彻底关闭 Nginx 的响应缓冲机制**——因为 WebSocket 是流式、低延迟协议，任何缓冲都会导致消息积压、帧错乱或毫秒级延迟突增。
必须关闭 proxy_buffering
默认开启的 proxy_buffering on 是卡顿最常见原因：Nginx 会把后端发来的多个小帧攒在内存里，等缓冲区填满或连接关闭才一次性下发。这对 WebSocket 完全不适用。
- 在 WebSocket 对应的
location块中明确写：proxy_buffering off; - 不要只在 http 或 server 级别设，必须落在具体路径块内（如
location /ws { ... }） - 若使用 Nginx Proxy Manager，还需同步检查并覆盖其默认缓冲设置
禁用缓存与压缩干扰
proxy_cache 和 gzip 会破坏 WebSocket 握手响应或帧结构，造成连接失败或解析异常：
- proxy_cache off; —— 防止 Upgrade 请求被缓存，返回 200 而非必需的 101 状态
- gzip off; —— WebSocket 帧本身支持 permessage-deflate，Nginx 层压缩会截断帧头或混淆 opcode
- 避免启用
proxy_redirect、proxy_buffer_size等与重写/分片相关的指令
精简 TCP 层缓冲行为
即使代理层不缓冲，内核 Nagle 算法仍可能合并小帧（如 ping/pong、状态更新），引发几十毫秒延迟：
- 在 location 块中添加：tcp_nodelay on;
- 同时关闭 tcp_nopush：tcp_nopush off;（避免零拷贝机制反而延迟小包）
- 该配置仅对已成功升级的长连接生效，前提是 Upgrade/Connection 头已正确透传
- 用
ss -i dst your-server-ip:port查看连接，输出含 nodelay 即生效
不建议盲目调大缓冲区
有人误以为“加大 proxy_buffers 或 proxy_buffer_size 可提升吞吐”，实际适得其反：
- 增大缓冲只会让积压更隐蔽、延迟更不可控
- WebSocket 帧边界由应用层定义，Nginx 不参与组装/拆分，缓冲区大小与帧完整性无关
- 唯一需微调的场景：极旧版 Nginx 兼容性要求下，可设
proxy_buffer_size 4k; proxy_buffers 1 4k;，但仍是“最小化”而非“最大化”
