ss -tuln无输出说明workerman未成功监听端口，主因是onworkerstart异常、端口占用、缺失sockets/pcntl扩展或监听地址写为127.0.0.1；须改0.0.0.0并完整重启。
ss -tuln 看不到端口说明根本没监听
客户端 telnet 报 Connection refused，第一反应不该是改代码，而是确认内核是否真在监听。运行 ss -tuln | grep :你的端口（比如 :2345），若无任何输出，说明 Workerman 进程压根没成功 bind 端口。
常见原因包括：
-
onWorkerStart里抛了未捕获异常，导致 worker 进程启动失败——此时ps aux | grep WorkerMan只能看到master process，看不到worker process - 端口被其他进程占着，
lsof -i :2345或netstat -tuln | grep :2345能查到 PID，需kill -9清理 - PHP 缺
sockets扩展，或pcntl_fork被禁用，Workerman 启动时静默失败 - 监听地址写成
tcp://127.0.0.1:2345，但ss查的是*:2345，自然不匹配
ss 显示 127.0.0.1:端口 ≠ 外部能连
看到 127.0.0.1:2345 就以为“服务起来了”，是排查中最常踩的坑。这个地址只响应本机回环流量，硬件设备、手机、另一台服务器发包到你的真实 IP，Linux 内核直接丢弃，不进防火墙，也不进 Workerman。
必须改成 tcp://0.0.0.0:2345 或 tcp://*:2345，然后完整重启：php start.php stop && php start.php start。热重载（reload）不重建监听 socket，旧配置还在内核里。
重启后再次 ss -tuln | grep :2345，目标是看到 *:2345 或 0.0.0.0:2345。
telnet 通 localhost ≠ 客户端能连
在 Workerman 服务器上 telnet 127.0.0.1 2345 成功，只验证了 loopback 通；客户端连不上，问题一定出在中间链路。
必须从客户端机器执行真实测试：
- 嵌入式设备（ESP32/STM32）：用串口工具发
AT+CIPSTART="TCP","your-server-ip",2345 - Linux/macOS 客户端：
telnet your-server-ip 2345 - Windows 客户端：
telnet your-server-ip 2345（需先启用 Telnet 客户端功能）
不通就按顺序查：
- 云平台安全组（阿里云/腾讯云）：入方向规则是否添加 TCP + 对应端口 + 源 IP 是
0.0.0.0/0？别信截图，手动点开确认状态为「启用」 - 宿主机防火墙：
firewall-cmd --list-ports看端口是否开放；没开就加：firewall-cmd --add-port=2345/tcp --permanent && firewall-cmd --reload - Docker 场景：容器启动是否带
-p 2345:2345？容器内监听地址是否也是0.0.0.0:2345？
连上了但收不到数据，先看协议匹配不匹配
硬件模块连上 TCP socket 后立刻断开，或 onMessage 根本不触发，大概率是协议错配。
纯 TCP 设备（如大多数单片机）发的是裸字节流，但你的 Workerman 启动的是：
-
websocket://0.0.0.0:2345→ 需要 WebSocket 握手，裸 TCP 包会被直接拒绝 -
http://0.0.0.0:2345→ 需要合法 HTTP 请求头，原始hello字符串不会触发onMessage -
ssl://0.0.0.0:2345→ 没 TLS 握手，连接建立即断
确认设备侧协议后，Workerman 必须用对应协议启动。最简单验证方式：用 nc your-server-ip 2345 发纯文本，看 onMessage 是否收到——如果收不到，八成是协议不一致。
