WebSocket反向代理单核CPU打满本质是事件处理瓶颈，因未调优导致连接事件集中于单线程/epoll实例；需配置多worker绑定CPU、禁用内容解析、启用TCP优化及连接分流。
WebSocket 反向代理在高并发压测下出现单核 CPU 打满，本质不是“代理慢”，而是反代层成了事件处理瓶颈。常见于 Nginx、Traefik 或自研网关在未调优状态下承载 WebSocket 长连接时，把大量连接事件（如心跳、小包推送、连接建立/关闭）集中压到一个工作线程或单个 epoll 实例上，导致该核持续 100% 占用，其他核闲置。
检查并调优反代的事件模型
多数反代默认使用单进程单线程（如 Nginx 默认 worker_processes 1），或虽配置多 worker 但未启用连接分发机制，所有 WebSocket 连接都落到同一个 worker 上。
- Nginx：确认 worker_processes auto; 并设置 worker_cpu_affinity auto;，确保每个 worker 绑定独立 CPU 核
- 开启 use epoll;（Linux 下默认，但显式声明更稳妥）
- 禁用 multi_accept off; 改为 on，让单次事件循环尽可能多地 accept 新连接
- 调整 worker_connections 65535; 并同步提升系统级文件描述符限制（ulimit -n 200000）
避免反代层参与 WebSocket 帧解析与业务逻辑
反代应严格做“透传”，不解析、不修改、不重序列化消息体。一旦在反代层做 JSON 解析、日志脱敏、鉴权校验等操作，就会把异步 I/O 模型拖回同步阻塞路径，CPU 必然打满。
- 禁用 Nginx 的 sub_filter、lua-resty-websocket 等可能触发内容重写/解析的模块
- 鉴权尽量前移到 TLS 层（如 JWT 在 TLS handshake 后通过 ALPN 或 SNI 传递），或由后端服务统一处理
- 日志记录仅记录连接元信息（$remote_addr、$status、$upstream_connect_time），不记录 $request_body
启用 TCP 层优化与连接复用策略
高频短消息（如心跳 ping/pong、状态变更通知）若未优化传输层，会因 Nagle 算法、延迟确认等机制堆积小包，加剧单核调度压力。
- 在 upstream 中添加 proxy_set_header Upgrade $http_upgrade; 和 proxy_set_header Connection "upgrade";，确保协议升级正确，避免降级为轮询 HTTP
- 对 upstream socket 启用 proxy_socket_keepalive on;（Nginx 1.15.3+），复用后端连接减少握手开销
- 在 upstream server 配置中加 setsockopt TCP_NODELAY on;（需 Nginx 补丁或使用 OpenResty），禁用 Nagle 算法，降低小包延迟
分流长连接与短连接流量
压测中常混入 HTTP 接口调用和 WebSocket 连接请求。若共用同一反代入口，短连接请求会干扰长连接的事件循环稳定性。
- 按 path 或 host 拆分路由：例如 /ws/ 走专用 WebSocket worker_group，/api/ 走常规 HTTP group
- 为 WebSocket 分组单独配置更激进的超时：proxy_read_timeout 86400;、proxy_send_timeout 86400;
- 启用连接数限流：limit_conn ws_zone 10000;（配合 limit_conn_zone $binary_remote_addr zone=ws_zone:10m;），防止单 IP 恶意占满单 worker
