Nginx 默认支持 WebSocket 二进制帧代理，但需配置 proxy_http_version 1.1、透传 Upgrade 和 Connection 头、关闭 proxy_buffering、调大 proxy_read_timeout/proxy_send_timeout，否则易导致连接中断、数据截断或协议降级。
Nginx 默认支持 WebSocket 代理，但对二进制帧（Binary Frame）的传输需满足特定配置条件，否则可能出现连接中断、数据截断或协议降级为文本帧等问题。
WebSocket 协议升级必须完整透传
Nginx 要正确代理 WebSocket，需显式处理 Upgrade 和 Connection 头部，确保客户端发起的协议升级请求不被过滤或改写：
- 必须设置
proxy_http_version 1.1—— WebSocket 基于 HTTP/1.1 的 Upgrade 机制 - 必须传递
Upgrade $http_upgrade和Connection "upgrade"，且不能被其他指令覆盖（如proxy_set_header Connection ""会破坏升级） - 若上游服务使用自定义 WebSocket 实现（如基于 Netty 或 ws 库），需确认其接受并响应标准 Upgrade 流程
二进制帧本身无需额外配置，但依赖 TCP 层完整性
Nginx 对 WebSocket 数据帧（包括文本帧和二进制帧）不做解析或修改，只要连接保持长连接、未触发超时或缓冲限制，二进制数据即可透明转发：
- 二进制帧（opcode = 2）与文本帧（opcode = 1）在 Nginx 视角下无区别，均作为原始字节流转发
- 关键限制来自
proxy_buffering off和proxy_buffer_size设置：若开启缓冲且二进制包超过缓冲区大小，可能引发分块粘包或截断 - 建议显式关闭代理缓冲：
proxy_buffering off，避免 Nginx 尝试缓存整个消息体
超时与连接稳定性直接影响大二进制流传输
长连接空闲或大文件分片上传过程中，Nginx 默认超时参数极易导致连接意外关闭：
proxy_read_timeout和proxy_send_timeout应设为较大值（如3600），否则接收/发送间隔稍长即断连proxy_timeout（非标准指令，勿误用）不存在；真正生效的是proxy_read_timeout（等待上游响应数据的时间）- 若前端使用浏览器 WebSocket API 发送 ArrayBuffer，需确保分片逻辑与服务端匹配，Nginx 不参与分片控制，仅保证帧顺序和完整性
验证二进制支持是否生效的方法
不依赖日志，直接通过行为判断：
- 用浏览器控制台执行
ws.send(new Uint8Array([0x01, 0x02, 0xFF]))，观察服务端是否收到原样字节数组 - 抓包检查 WebSocket Frame：Wireshark 过滤
websocket，确认 Frame Type 显示BINARY且 Payload 与发送一致 - 若服务端返回
400 Bad Request或连接立即关闭，大概率是 Upgrade 头未透传；若数据错乱或长度不符，优先检查缓冲与超时设置
