nginx 不实现 websocket 协议逻辑，仅通过 http/1.1 升级机制完成握手并透传原始 tcp 流；它精准识别 upgrade 和 connection 头部、转发 101 响应、零帧解析数据、依赖超时与路由粘性维持连接，不校验 sec-websocket-accept、不处理 wss 加密、不提供连接数监控。
Nginx 本身不实现 WebSocket 协议逻辑，而是通过 HTTP/1.1 协议升级机制完成握手，并透传后续的原始 TCP 流。它的“处理”本质是精准识别、无损中转与连接生命周期管理，而非解析帧或维护 WebSocket 状态。
协议升级阶段：守门员式头部校验与透传
Nginx 在请求进入时检查两个关键头部：
- Upgrade: websocket —— 表明客户端意图升级协议
- Connection: Upgrade —— 配合完成 HTTP 到 WebSocket 的切换
只要这两个字段存在且合法，Nginx 就会触发 101 Switching Protocols 响应（由后端实际生成，Nginx 转发），并停止按 HTTP 模式解析后续流量。它不计算 Sec-WebSocket-Accept，也不验证密钥，只做通道守门人。
数据传输阶段：纯 TCP 层透传，零帧解析
握手成功后，连接降级为裸 TCP 连接。Nginx 不解析 WebSocket 帧结构（如 FIN、opcode、mask、payload length），也不重分片、不缓冲、不重写数据体。它把整个 socket 连接当作字节流管道：
- 所有 ping/pong、text/binary 帧原样转发
- 不干预心跳间隔，也不主动发 ping
- 不校验帧掩码（客户端必须掩码，服务端可不掩码，Nginx 不关心）
连接维持与负载均衡：靠超时控制与路由粘性
Nginx 不维护 WebSocket 连接状态表，但通过三类配置间接支撑长连接稳定性：
- proxy_read_timeout / proxy_send_timeout：防止空闲连接被内核或中间设备断开，默认 60 秒太短，生产环境常设为 86400（24 小时）
- upstream 的 ip_hash 或 sticky cookie：确保同一连接的所有帧始终打到同一台后端，避免因轮询导致连接中断
- keepalive 指令（在 upstream 中）：复用 Nginx 到后端的连接池，减少后端建连压力，但不影响客户端到 Nginx 的连接
限制与边界：Nginx 不做什么
理解它的“不作为”比知道它“做什么”更重要：
- 不实现 WebSocket 服务端逻辑（如广播、房间管理、消息序列化）
- 不支持 WSS（加密 WebSocket）的证书终止 —— SSL 终止在 Nginx，但加密解密发生在 TLS 层，WebSocket 帧仍以明文形式在 Nginx 与后端间传输
- 不提供连接数监控指标（如活跃 ws 连接数），需依赖后端或 stream 模块 + 日志分析
- 不处理跨域（CORS）—— 这是后端响应头的事，Nginx 只转发
