WebSocket代理不解析消息体，Nginx无法直接过滤帧大小，只能通过限制握手请求头、禁用缓冲、设置超时等配置提升可控性，实际消息体校验须由后端应用完成。
WebSocket 代理本身不解析消息体内容，Nginx 默认也不会对 WebSocket 消息的大小做限制或过滤。所谓“对消息体的大小过滤”，实际需结合协议特性与 Nginx 的相关配置协同实现——核心在于控制 HTTP 升级请求阶段的头字段、缓冲区行为，以及后端服务配合完成真正的消息体校验。
理解 WebSocket 代理中“消息体大小”的真实含义
WebSocket 建立连接时，客户端先发送一个 HTTP Upgrade 请求（含 Upgrade: websocket 等头），Nginx 仅代理该握手过程；一旦升级成功，后续帧数据（Text/Binary）直接透传，Nginx 不拆包、不解析、不校验 payload 长度。因此，“过滤消息体大小”无法在 Nginx 层直接针对 WebSocket 帧做拦截，只能：
- 限制握手阶段的请求头大小（防止恶意超长 header）
- 控制读写缓冲区，间接影响大帧传输稳定性
- 通过
proxy_buffering off和超时设置，避免因缓冲引发的截断或延迟 - 将实际的消息体长度校验逻辑交给后端应用（如 Node.js/Python 服务收到帧后检查
payload length）
关键 Nginx 配置项与作用
以下配置虽不直接“过滤 WebSocket 消息体”，但能提升安全性与可控性：
- proxy_http_version 1.1;：必需，支持 HTTP/1.1 才能正确处理 Upgrade
- proxy_set_header Upgrade $http_upgrade;：透传 Upgrade 头，否则握手失败
- proxy_set_header Connection "upgrade";：显式设置 Connection 头为 upgrade
- client_header_buffer_size / large_client_header_buffers：限制握手请求头总大小（例如设为 4k～8k），防 header flooding
- proxy_buffering off;：禁用缓冲，避免 WebSocket 帧被缓存或分段，保障实时性
- proxy_read_timeout / proxy_send_timeout：建议设为较大值（如 3600），防止空闲连接被误断
真正实现“大小过滤”的合理分工
若业务要求拒绝超过 1MB 的单条 WebSocket 消息，应由后端服务完成：
- Node.js（ws 库）：监听
message事件前检查data.length，超限则socket.close(4001, 'Payload too large') - Python（websockets）：在
recv()后判断len(message)，主动关闭连接并返回错误码 - Nginx 可配合返回 4XX 错误页（如 413 Request Entity Too Large），但仅适用于 HTTP 阶段，对已升级的 WebSocket 连接无效
补充：防范常见误配置风险
以下问题常导致 WebSocket 消息异常，易被误认为“大小过滤失效”：
- 未关闭
proxy_buffering→ 大帧可能被截断或延迟送达 -
proxy_buffer_size过小（默认 4k）→ 升级响应头过大时触发 502 -
client_max_body_size对 WebSocket 无效（只作用于 HTTP POST/PUT），不必设置 - 防火墙或中间设备（如 ELB、CDN）可能限制 WebSocket 帧大小，需单独排查
