websocket单帧实际大小受限于浏览器、服务端和nginx三者中最严者：chrome约32mb、safari约8mb、tomcat默认8kb、nginx需调优proxy_buffer_size等参数，推荐分片传输而非硬扩单帧。
WebSocket 客户端发送的单帧报文大小，实际受限于 Nginx 的缓冲区配置，而非直接提供类似 client_max_body_size 那样的“最大报文限制”指令。Nginx 本身不解析 WebSocket 帧内容，但会在代理过程中对原始 HTTP 请求头、升级响应及后续帧流做缓冲控制——一旦缓冲区不足，就会截断、丢帧甚至主动关闭连接。
关键限制点：proxy_buffer_size 和 proxy_buffers
Nginx 在 WebSocket 握手阶段（即初始 HTTP GET 请求）会读取并缓存请求头；握手成功后，虽进入透传模式，但部分版本或高负载下仍可能对首段数据做临时缓冲。真正影响客户端大报文能否完整抵达后端的，是以下两个参数：
-
proxy_buffer_size：用于缓存后端响应的首行和响应头，默认通常为 4KB。若后端返回的 101 响应头过大（比如带超长 cookie 或自定义 header），可能触发
400 Bad Request或握手失败 -
proxy_buffers：控制 Nginx 缓存后端响应体的缓冲区数量和大小（如
proxy_buffers 8 128k）。虽然 WebSocket 数据本不该被缓存，但某些旧版 Nginx 或开启proxy_buffering on时，大帧可能卡在缓冲区里，导致延迟或粘包
必须关闭缓冲并调大 buffer_size
为支持客户端发送较大帧（例如 1–10MB 级别），需显式关闭代理缓冲，并确保 header 缓冲足够容纳握手请求：
- 添加 proxy_buffering off; —— 强制禁用所有响应体缓冲，避免帧堆积
- 将 proxy_buffer_size 设为略大于客户端可能携带的最大请求头（如含 JWT Token 的 Authorization 头），建议至少 8k 或 16k
- 移除所有
proxy_buffer_size以外的缓冲相关指令（如proxy_busy_buffers_size），防止干扰
后端与浏览器才是真正的瓶颈
Nginx 层面调优只是基础，实际能传多大，取决于三者中最严的一环：
- 浏览器限制：Chrome 实测单帧上限约 32MB，Safari 仅约 8MB，且大帧易触发内存压力导致静默断连
-
后端框架限制：Spring Boot + Tomcat 默认
textBufferSize=8KB，需显式配置maxTextMessageSize和maxBinaryMessageSize - Nginx 代理链路：若中间还有 CDN 或其他反代（如 Cloudflare），它们往往有更严格的帧大小限制（常见 1–4MB），且不开放配置
推荐做法：分片传输 + 客户端校验
与其硬扩单帧上限，不如从协议层规避风险：
- 前端发送 >1MB 数据前，先按 512KB 分片，加序号与总片数字段，由后端拼接
- 服务端收到首帧后立即返回
ACK，客户端再发下一帧，实现流控 - 在 Nginx 日志中开启
error_log /var/log/nginx/ws_error.log debug;，观察是否出现upstream sent too big header或client intended to send too large chunk类错误，精准定位瓶颈环节
