Workerman无法原生处理wss协议，必须通过Nginx反向代理终结TLS并透传Upgrade/Connection头，否则握手失败；直接启用SSL会导致CPU飙升、事件循环卡死或静默降级。
不是 WSS 协议本身拖慢了 Workerman，而是你让 Workerman 去“硬扛” TLS 握手和加密解密——它根本干不了这事。
Workerman 无法原生处理 wss:// 请求
Workerman 的 Websocket 协议层只解析 WebSocket 帧，不处理 HTTPS/TLS 握手、证书校验、SNI、ALPN 协商等环节。所谓“启用 wss”，如果直接在 Worker 构造时写成 wss://0.0.0.0:443 或强行加 SSL 参数，会导致：
- Workerman 启动失败（抛出
SSL operation failed类错误）或静默降级为 http - 即使勉强跑起来，每个连接都要 PHP 层做 OpenSSL 加解密，CPU 爆满、事件循环卡死
- 微信小程序实际发来的是标准
wss://升级请求，但 Workerman 没法正确响应101 Switching Protocols+Upgrade: websocket头
Nginx 反向代理配置漏掉关键头字段
WSS 流量必须由 Nginx 终结 TLS 并透传 WebSocket 协议升级信号，否则握手在代理层就断了。常见遗漏点：
- 没写
proxy_set_header Upgrade $http_upgrade→ 客户端发的Upgrade: websocket被丢弃 - 没写
proxy_set_header Connection "upgrade"→ Nginx 默认把Connection头删掉，导致后端收不到升级指令 -
proxy_http_version 1.1缺失 → HTTP/1.0 不支持 upgrade 机制 - 证书链不全（
fullchain.pem漏中间证书）→ 微信校验失败，直接拒绝连接，表现为fail net::ERR_CONNECTION_REFUSED
并发下降的真正瓶颈在系统层和 event 扩展
你以为开了 wss 就变慢，其实是 TLS 终结前移后暴露了原有瓶颈：
- 没装
event扩展：Workerman 默认用stream_select，单进程撑不过 1000 连接，QPS 断崖下跌 -
ulimit -n仍为默认 1024：Nginx 和 Workerman 共享文件描述符限制，新连接被内核直接拒绝 -
somaxconn过小（如 128）：SYN 队列溢出，客户端重试超时，看起来像“连不上”或“频繁断开” - Workerman 自身
Worker::$maxConnection没显式设大：默认 1000，远低于 Nginx 转发能力
onMessage 里混入同步阻塞操作
TLS 终结后，WebSocket 连接数可能激增，原本不明显的业务卡点立刻放大：
- 在
onMessage回调里调用file_get_contents、sleep、未设 timeout 的cURL - 执行慢 SQL 且没走连接池，PDO 等待锁表，整个事件循环停摆
- 日志写入没异步化（比如直接
error_log到磁盘），高并发下 IO 成瓶颈
这些操作不会降低理论并发上限，但会让 RT 暴涨、连接堆积、CPU 跑满——你看到的“并发下降”，其实是有效吞吐崩溃了。
