必须从网络通路、协议匹配、服务绑定三方面逐层验证：先用ss -tuln确认端口监听地址为0.0.0.0，再用telnet测试客户端到服务器公网ip的连通性，最后严格匹配ws/wss协议与服务端websocket://或ssl://配置。
Workerman服务端已配置好主动推送逻辑，但浏览器用JavaScript WebSocket连接始终失败，必须从网络通路、协议匹配、服务绑定三方面逐层验证，不能只看start.php是否显示“Start success”。
确认服务端真正在监听且可被外部访问
第一步：在服务器终端执行 ss -tuln | grep :端口号（把“端口号”替换成你实际用的，如2345），有输出才说明内核级监听已生效；没输出=Workerman子进程根本没起来。
第二步：检查输出中监听地址是 0.0.0.0:端口号 还是 127.0.0.1:端口号——如果是后者，客户端无论用公网IP、内网IP还是域名都连不上，必须改代码里$worker->listen('websocket://0.0.0.0:端口号')。
第三步：运行 ps aux | grep WorkerMan，看到至少一个 WorkerMan: worker process 才算正常；只有master process说明onWorkerStart抛了致命异常，立刻去workerman.log末尾找Fatal error。
验证客户端真实网络路径是否通畅
在客户端机器（比如你打开浏览器的这台电脑）上，直接执行：telnet 服务器真实公网IP 端口号。成功返回Connected才代表网络层打通；如果Connection refused，问题一定出在服务端监听配置或防火墙；如果超时，重点查云厂商安全组、本地防火墙、或中间NAT设备。
注意：在服务器本机执行telnet 127.0.0.1 端口号成功，完全不等于客户端能连——这只是loopback回环测试，毫无参考价值。
阿里云/腾讯云用户必须登录控制台，进「安全组」→「入方向规则」→ 添加一条：协议TCP、端口填你的端口号、源IP暂设0.0.0.0/0（测试用），保存后立即生效。
检查WebSocket协议与SSL配置是否严格匹配
方法一：普通ws连接（开发调试用）
客户端JS必须用 ws:// 开头，服务端$worker初始化必须是 websocket://0.0.0.0:端口号；若服务端用了ssl://，客户端却写ws://，会直接报错“Error during WebSocket handshake: Unexpected response code: 200”。
方法二：小程序/wss强制场景
客户端必须用 wss://域名:端口号，服务端必须用 ssl://0.0.0.0:端口号 启动，且local_cert必须指向fullchain.pem（不是cert.pem）、local_pk指向privkey.pem，路径必须为绝对路径；任何一步错都会静默拒绝连接。
方法三：反向代理穿透（Nginx常见）
若用Nginx代理wss，必须在location块里显式透传Upgrade和Connection头：
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
漏掉其中任意一行，客户端就会卡在handshake阶段。
