tcp_nodelay不解决websocket握手延迟，仅作用于升级后的长连接小包推送；握手慢需排查tls、upstream复用、后端响应等环节。
tcp_nodelay 不用于解决 WebSocket 握手延迟，它对握手阶段完全无效。
握手是 HTTP 请求/响应过程（一次或几次短交互），发生在 TCP 连接建立之后、协议升级完成之前。而 tcp_nodelay on 的作用对象是已升级成功的长连接上的小数据包发送行为，它关闭 Nagle 算法，让每个 write() 调用立即发包——这仅在 WebSocket 连接建立后、开始推送心跳、行情、指令等实时帧时才起效。
所以，如果你遇到的是“WebSocket 握手慢”“连接卡在 101 响应前”“浏览器 Network 面板显示 handshake 时间长达几百毫秒”，问题一定不在 tcp_nodelay，而在以下环节：
WebSocket 握手延迟的真实根源
握手本质是一次标准 HTTP/1.1 升级请求，Nginx 需完整、准确、低延迟地转发该请求到后端。常见瓶颈包括：
- SSL/TLS 握手耗时高：尤其跨地域或未启用 TLS False Start / 0-RTT（需服务端支持）
- Nginx 与后端之间的连接复用缺失：每次握手都新建 upstream 连接，触发额外 TCP + TLS 握手
- 后端处理慢：如鉴权逻辑阻塞、证书校验耗时、进程启动延迟（冷启动）
- DNS 解析延迟或失败重试：`proxy_pass` 使用域名且未配置 `resolver` 或缓存过期
- 防火墙或中间设备干扰：SYN 包被限速、ACK 延迟、TCP 选项被篡改（如禁用 SACK）
真正影响握手性能的关键 Nginx 配置
这些设置直接决定从客户端发起 `GET /ws` 到收到 `101 Switching Protocols` 的总耗时：
-
启用 upstream keepalive：复用 Nginx 到后端的连接，避免重复建连
upstream ws_backend {
server 127.0.0.1:8080;
keepalive 32;
}
location /ws {
proxy_pass http://ws_backend;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
# 复用 upstream 连接
proxy_set_header Connection '';
proxy_http_version 1.1;
proxy_set_header Connection 'keep-alive';
proxy_socket_keepalive on;
} - 缩短 proxy_connect_timeout：默认 60s 过长，建议设为 3–5s，快速失败并重试
- 禁用不必要的头处理和重写：避免 `rewrite`、`add_header` 等引入额外 CPU 开销
- 确保 SSL 配置高效：使用 ECDSA 证书、启用 `ssl_buffer_size 4k`、关闭不必要加密套件
如何确认是否真是握手延迟？
打开浏览器 DevTools → Network → 找到 WebSocket 请求 → 点击查看 Timing 标签页：
- 若 Connect 或 SSL 阶段耗时 >100ms → 问题在网络层或 TLS 层
- 若 Waiting (TTFB) 耗时高 → 问题在 Nginx 转发或后端响应速度
- 若 Content Download 很小但 TTFB 长 → 后端处理慢，或 Nginx 未复用 upstream 连接
tcp_nodelay 的正确使用位置
它只应在 WebSocket 连接成功建立后，用于优化后续消息推送的端到端延迟。启用条件明确：
- 必须在
location /ws { ... }块中单独开启，不能放全局 - 必须已配置
proxy_set_header Upgrade $http_upgrade;和Connection "upgrade" - 必须搭配
proxy_read_timeout延长（如 86400）、proxy_buffering off - 仅对几十字节的小帧（ping/pong、状态更新）有效；大消息不受 Nagle 影响
