Workerman 原生不支持 HTTP/2，因 PHP 缺乏标准 HTTP/2 实现，其内置解析器仅支持 HTTP/1.x；需通过 Nginx 反代实现对外 HTTP/2（listen 443 ssl http2），后端仍用 HTTP/1.1 与 Workerman 通信。
Workerman 原生不支持 HTTP/2，但可通过 Nginx 反代实现
Workerman 的 Worker 类底层基于 PHP 的 stream socket，而 PHP 标准库至今（截至 2026 年）仍未提供对 HTTP/2 帧解析的原生支持。这意味着：即使你配置了 SSL、绑定了 https:// 地址，Workerman 启动的仍是 HTTP/1.1 over TLS，不是真正的 HTTP/2。
真正能协商 HTTP/2 的，是前端反向代理——比如 Nginx。它在收到客户端 ALPN 协商请求后，可与后端 Workerman 用 HTTP/1.1 通信，同时对外暴露完整的 HTTP/2 语义（如 Server Push、头部压缩、多路复用）。
- Workerman 自身
onMessage、onConnect等回调接收的仍是原始 HTTP/1.1 请求对象，无法感知 HTTP/2 流 ID 或权重 - 如果你用
new Worker('https://0.0.0.0:443')，它只是启用了 TLS，协议版本仍由客户端和 Workerman 的底层 HTTP parser 决定，默认为 HTTP/1.1 - 浏览器开发者工具 Network 面板显示 “h2” 并不意味着 Workerman 在跑 HTTP/2，只说明 Nginx 成功完成了协议升级
为什么不能直接让 Workerman 跑 HTTP/2？
根本原因在于 PHP 缺乏标准的 HTTP/2 实现层。虽然有第三方扩展如 nghttp2（需编译安装），但 Workerman 并未集成或适配它；其内置的 HTTP 解析器 Workerman\Http\Request 是纯 HTTP/1.x 设计，不解析 SETTINGS 帧、不管理流生命周期、不处理 HPACK 编码。
- HTTP/2 要求服务端主动管理连接状态（如流优先级、流量控制窗口），而 Workerman 的事件循环模型面向无状态短连接优化，与 HTTP/2 的长连接+多路复用模型存在抽象层冲突
- 即便强行接入 nghttp2 扩展，也要重写整个 HTTP 协议栈，工作量接近重写一个 Web 服务器，违背 Workerman “专注实时通信”的定位
- 官方文档和 GitHub Issues 中明确将 HTTP/2 列为 “not planned” —— 它不是 bug，而是设计取舍
Nginx 反代 Workerman 实现 HTTP/2 的最小可行配置
这是目前最稳定、兼容性最好、也最符合生产习惯的做法。关键是让 Nginx 终止 TLS 并完成 HTTP/2 升级，再以 HTTP/1.1 转发给 Workerman。
server {
listen 443 ssl http2;
server_name example.com;
<pre class='brush:php;toolbar:false;'>ssl_certificate /path/to/fullchain.pem;
ssl_certificate_key /path/to/privkey.pem;
location / {
proxy_pass https://127.0.0.1:8282; # Workerman HTTPS worker（可选）
# 或更推荐：proxy_pass http://127.0.0.1:8080; # Workerman HTTP worker（无 TLS 开销）
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}}
- 务必启用
http2参数在listen指令中，否则 Nginx 不会响应 HTTP/2 ALPN -
proxy_pass后端用http://而非https://，避免 Workerman 多一层 TLS 解密开销 - 不需要在 Workerman 中配置证书——证书由 Nginx 管理即可，Workerman 只需监听普通 HTTP 端口（如
http://0.0.0.0:8080） - 若需 WebSocket over HTTP/2（即
wss://），Nginx 必须透传Upgrade和Connection头，且 Workerman 的Worker必须是websocket协议类型
WSS 和 HTTP/2 共存时的常见陷阱
很多人想让小程序或浏览器通过 wss:// 连上 Workerman，并期望它走 HTTP/2 底层。现实是：wss 本质是 WebSocket over TLS，它和 HTTP/2 是正交协议——wss 不等于 h2，也不依赖 h2。
- 浏览器发起
wss://连接时，TLS 握手后发送的是 WebSocket 握手请求（HTTP/1.1 GET + Upgrade: websocket），不是 HTTP/2 帧；Nginx 会按 HTTP/1.1 转发该请求到 Workerman - 即使 Nginx 启用了
http2，它也不会把 WebSocket 流“降级”或“升级”成 HTTP/2 流——WebSocket 是独立于 HTTP 版本的应用层协议 - 错误日志里出现
client sent invalid request while reading client request line，往往是因为 Nginx 把 HTTP/2 的二进制帧误当 HTTP/1.1 文本转发给了 Workerman（典型配置错误：在location /ws/下漏写了proxy_http_version 1.1）
Workerman 的 HTTP/2 支持边界非常清晰：它不处理、不暴露、也不需要理解 HTTP/2。真正在意这个协议的人，其实要的不是 Workerman 跑 h2，而是客户端能享受 h2 带来的首屏更快、连接更省、头部更小——这些完全可以通过 Nginx 达成。别在 Workerman 配置里找 http2 => true，那地方压根没有。
