直接开启tcp_nodelay on可缓解websocket卡顿，但仅当作用于已升级的长连接、保持长连接未中断、且推送小数据包时才有效；需在location块精准配置并验证nodelay生效。
直接开启 tcp_nodelay on 能缓解 WebSocket 卡顿，但必须确保它作用在已升级的长连接上，否则无效。关键不在“开没开”，而在“有没有真正起作用”。
WebSocket 卡顿常是 Nagle 算法在“攒包”
Nagle 算法默认启用，会把连续发出的多个小帧（比如 ping/pong、订单状态更新、行情点位）缓存起来，等收到 ACK 或凑够一整包再发——这带来 20–200ms 不等的不可控延迟。用户感知就是“消息明明发了，对方却卡半秒才收到”。tcp_nodelay on 的作用，就是关掉这个等待逻辑，让每个 write() 调用的数据立即发出去。
只对三类情况有效，缺一不可
-
连接已完成 WebSocket 升级：Nginx 必须识别这是 ws/wss 连接，配置中必须包含
proxy_set_header Upgrade $http_upgrade;和proxy_set_header Connection "upgrade";。若漏掉，流量仍走普通 HTTP 流程，tcp_nodelay完全不触发。 -
连接保持长连接且未被中断：需设置
keepalive_timeout 65;（建议 ≥65s），同时后端和客户端也维持连接；若proxy_read_timeout过短（如默认 60s），Nginx 主动断连，长连接就不存在，tcp_nodelay失去作用对象。 - 推送的是小数据包：单次发送几十到几百字节（如 JSON 行情、控制指令、心跳帧）时效果最明显；若一次推 5KB 快照，内核本就会立即发包，Nagle 压根不介入，调优无意义。
精准配置，避免全局误用
不要在 http 块里盲目加 tcp_nodelay on，应聚焦 WebSocket 路径单独启用：
推荐写法（放在 location 块内）：
location /ws {
proxy_pass http://backend;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
tcp_nodelay on;
proxy_buffering off; # 防消息卡在 Nginx 缓冲区
tcp_nopush off; # 关闭零拷贝，避免小包被合并延迟
proxy_read_timeout 86400; # 配合后端每 30 秒 ping，保活静默连接
}
验证是否真生效，别只看配置
- 用
ss -i dst :端口查看活跃连接，输出中出现nodelay字样才表示成功启用； - 浏览器 DevTools → Network → 找 WebSocket 连接 → Frames 面板，观察同一批消息的“发送时间”与“接收时间”差值，稳定在 10–50ms 区间才算达标；
- 若仍出现 >100ms 的跳变，问题大概率不在这里——要排查后端响应慢、网络抖动、或客户端未禁用 Nagle（Node.js 需对每个 socket 调用
setNoDelay(true)）。
