PHP无法直接建立WebSocket客户端连接，因其原生不支持协议握手与帧解析，需依赖扩展如textalk/websocket或采用“PHP→消息队列→专用WS服务”架构解耦。
PHP 无法直接建立 WebSocket 客户端连接
PHP 原生不支持 WebSocket 协议握手和帧解析，fsockopen 或 curl 发起的只是普通 TCP/HTTP 连接，无法完成 WebSocket 升级（Upgrade: websocket）流程，所以会卡在 400、403 或直接断连。
- 别用
file_get_contents或curl_exec尝试“GET ws://…”——协议不兼容，HTTP 客户端根本不懂Sec-WebSocket-Key和帧掩码 - 真要从 PHP 主动连 WS 服务，必须用支持 WebSocket 协议的扩展或库，如
ext-websocket（PHP 8.1+ 内置，但仅限服务器端）、ratchet/pawl或textalk/websocket - 生产环境更推荐“PHP 后端 → 消息队列 → Node.js/Python WebSocket 服务”解耦，避免 PHP 进程长期 hold 连接
使用 textalk/websocket 时 handshake 失败
textalk/websocket 是较轻量的纯 PHP WebSocket 客户端实现，但默认不校验 TLS 证书，且对响应头大小写敏感，常见于 Nginx 反代后。
- 如果服务端启用了 HTTPS（wss://），需显式传入
['tls' => ['verify_peer' => false]]（仅测试环境），否则抛出SSL operation failed - Nginx 配置中若用了
proxy_set_header Upgrade $http_upgrade但漏了proxy_set_header Connection "upgrade"，会导致Connection: upgrade缺失，handshake 被拒绝 - 某些代理会把
Sec-WebSocket-Accept响应头转成小写（如sec-websocket-accept），而该库严格匹配首字母大写，触发Invalid server response
PHP-FPM 环境下 WebSocket 连接被意外中断
PHP-FPM 默认配置（如 request_terminate_timeout、max_execution_time）会强制 kill 长连接进程，导致 WebSocket 心跳超时断开。
- 即使你用
set_time_limit(0)，FPM 层仍可能在 30s（默认request_terminate_timeout）后终止 worker -
ignore_user_abort(true)对 WebSocket 客户端无效——它只影响 HTTP 响应结束后脚本是否继续执行，不保活 socket - 真正可行的做法是：改用 CLI SAPI 运行 WebSocket 客户端脚本（如
php client.php），并配合supervisord管理进程生命周期
接收消息时出现 “invalid frame header” 或乱码
WebSocket 帧有固定结构（FIN、opcode、mask、payload length），PHP 客户端若未正确解析掩码（masking key）或未处理分片（fragmentation），就会解包失败。
立即学习“PHP免费学习笔记（深入）”；
-
textalk/websocket在receive()返回前已自动解掩码，但如果手动用fread+stream_socket_client实现，必须按 RFC 6455 解析第 2 字节起的 mask key 并异或 payload - 服务端发送大于 125 字节的消息会启用扩展长度字段（2 或 8 字节），未处理会导致后续字节全错位
- 部分客户端库（如旧版
gora/websocket）不支持opcode = 0x1（文本）以外的类型，遇到0x2（二进制）直接报错
WebSocket 不是 HTTP，也不是长轮询；PHP 做客户端本身就不在它的设计舒适区。真要稳定通信，优先考虑让 PHP 发消息到中间件（Redis Pub/Sub、AMQP），再由专用服务桥接 WebSocket，比硬扛连接生命周期更可控。
