Nginx 不参与 WebSocket 二进制分片处理，仅透明转发原始帧；需配置 proxy_http_version 1.1、proxy_buffering off、gzip off、proxy_read_timeout/proxy_send_timeout 足够大，并启用 tcp_nodelay on，以确保分片帧按序原样传递。
Nginx 代理 WebSocket 服务时不参与、也不干预二进制分片处理，它只负责透明转发原始 WebSocket 帧（包括分片帧），前提是配置正确。分片逻辑完全由客户端和服务端控制，Nginx 的角色是“无感透传”。
二进制分片在 WebSocket 协议中的本质
WebSocket 允许将大数据拆成多个帧发送：
- 首帧 opcode = 2（BINARY），FIN = 0
- 中间帧 opcode = 0（CONTINUATION），FIN = 0
- 末帧 opcode = 0（CONTINUATION），FIN = 1
Nginx 不解析 opcode 或 FIN 标志，只要 TCP 连接稳定、缓冲未干扰、超时不触发，这些帧就会按序、原样抵达后端。
关键配置决定分片能否可靠传递
-
必须关闭代理缓冲：
proxy_buffering off;
否则 Nginx 可能攒多个分片帧一起发出，破坏帧边界，导致服务端收到粘包或错序 -
禁用 gzip 压缩：
gzip off;（尤其在 WebSocket location 内）
WebSocket 帧本身不可压缩，开启 gzip 会尝试重写 payload，引发校验失败或连接中断 -
设足够大的超时值：
proxy_read_timeout 86400; proxy_send_timeout 86400;
防止大文件分片间隔稍长（如网络抖动或服务端处理延迟）被误判为空闲连接而断开 -
确保
proxy_http_version 1.1已启用
HTTP/1.0 不支持 Upgrade，握手失败则根本无法进入分片传输阶段
常见分片异常与定位方式
- 若前端发送
Uint8Array后端只收到部分字节 → 检查proxy_buffering是否为off，并确认proxy_buffer_size未意外启用缓存 - 若出现
invalid frame header或incomplete frame错误 → 抓包看 Wireshark 中 WebSocket Frame Type 是否始终为 BINARY，Payload 是否连续完整；若出现 TEXT 帧混入，说明 Upgrade 头未透传，协议已降级 - 若分片间延迟突增（毫秒级毛刺）→ 查
tcp_nodelay on;是否启用，避免 Nagle 算法合并小帧
Nginx 对二进制分片既不组装也不拆解，它的任务就是守住连接、保帧序、不改数据。配置到位，分片就自然可靠。
