Nginx 不能加速 WebSocket 协议本身，但可通过四大配置优化交互效率：延长 proxy_read_timeout 和 proxy_send_timeout 防误杀连接；upstream 启用 keepalive 复用后端 TCP 连接；关闭 proxy_buffering 和 gzip 避免帧级延迟；调优内核参数（如 tcp_keepalive_time、somaxconn）支撑高并发长连接。
Nginx 本身不处理 WebSocket 数据内容，也不参与帧级编解码，所以它不能“加速”WebSocket协议本身的传输速率。但它作为反向代理，能显著减少通信延迟、避免连接中断、提升吞吐稳定性，从而让后端 WebSocket 服务的数据交互更高效、更可靠。关键不在“提速”，而在“不拖慢”和“不掉链”。
以下是直接影响数据交互效率的 4 个核心配置方向：
proxy_read_timeout 和 proxy_send_timeout 要足够长
WebSocket 是长连接，空闲时不会断开，但 Nginx 默认超时很短（60秒），容易误杀连接。
-
proxy_read_timeout：控制 Nginx 等待后端响应数据的最长时间（如心跳、消息推送）。 -
proxy_send_timeout：控制 Nginx 向后端发送请求后等待 ACK 的时间。
建议设为 300～600 秒，甚至更高（如 3600）；若业务有明确心跳间隔（如每 30 秒 ping/pong），可设为该值的 2～3 倍。
开启 keepalive 连接池（upstream 级）
避免每次 WebSocket 请求都新建 TCP 连接到后端，降低握手开销和 TIME_WAIT 压力。
- 在
upstream块中添加keepalive 32;（数字表示保活连接数） - 对应 location 中需加
proxy_http_version 1.1;和proxy_set_header Connection '';（关闭自动关闭）
这样 Nginx 与后端之间复用连接，尤其在高并发短消息场景下效果明显。
关闭缓冲与压缩，避免额外延迟
WebSocket 数据通常是二进制帧或小文本消息，Nginx 默认缓冲+gzip会引入排队和 CPU 开销。
-
proxy_buffering off;（禁用响应缓冲，数据到达即转发） -
proxy_buffer_size 128k;（仅保留最小 header 缓冲） -
gzip off;或至少确保gzip_types不包含application/octet-stream（常见于 WebSocket 二进制帧）
调整内核与系统级参数（配合 Nginx）
Nginx 的长连接能力受限于底层 TCP 栈：
-
net.ipv4.tcp_keepalive_time = 600（连接空闲 10 分钟才发 keepalive 探针） -
net.core.somaxconn = 65535（提升连接队列上限） -
fs.file-max和 worker_rlimit_nofile 需匹配预期并发连接数（如 10w+ 连接需设为 200000）
这些不是“魔法加速”，而是清除瓶颈——让 WebSocket 连接稳得住、传得顺、不卡顿。真正决定数据速率的，仍是网络带宽、后端处理能力和客户端逻辑，Nginx 的角色是做一条通畅、低损、不设障的管道。
