Workerman客户端连接超时或拒绝连接是网络链路层问题，需依次排查：确认ss -tuln显示0.0.0.0:端口监听、ps aux看到worker进程、客户端telnet服务器IP端口、云安全组放行、conntrack表未满（conntrack -C接近nf_conntrack_max即为瓶颈）、DNS解析正确且路由可达。
Workerman客户端连接超时或拒绝连接，不是代码写错就能复现的问题，而是网络链路中某一层直接切断了握手请求——可能是防火墙静默丢包、云平台安全组未放行、服务端根本没监听到公网地址，也可能是内核 conntrack 表已满导致 SYN 包压根没送达 Workerman 的 socket。
先确认服务端是否真在对外监听
别信 start.php 输出的 “Start success”，那只是 master 进程起来了。执行 ss -tuln | grep :端口（把“端口”替换成你实际用的数字），有输出才说明内核正在监听。
如果只看到 127.0.0.1:端口，没有 *:端口 或 0.0.0.0:端口，说明 Workerman 绑定的是本地回环地址，外部客户端永远连不上——必须改成 $worker->listen('tcp://0.0.0.0:端口') 或 'tcp://*:端口'。
再查子进程：运行 ps aux | grep WorkerMan，至少要看到一行包含 WorkerMan: worker process。只有 master process 没有 worker，大概率是 onWorkerStart 里抛了未捕获异常，去 workerman.log 最末尾找 Fatal error 或 Exception。
检查客户端能否真正触达服务端IP和端口
在客户端机器上直接执行：telnet 服务器公网IP 端口。这一步不能跳过，服务器上 telnet 127.0.0.1 端口 通 ≠ 客户端能连。
云服务器（阿里云/腾讯云等）必须进控制台检查「安全组」，入方向规则里明确添加 TCP 协议 + 对应端口 + 源 IP（测试阶段可设为 0.0.0.0/0）。
本地开发用 Docker 时，除了 -p 端口:端口，还得确保容器内监听的是 0.0.0.0:端口，不是 127.0.0.1:端口；宿主机 Windows/macOS 防火墙也常默认拦截外来连接，Windows 上临时关闭「Windows Defender 防火墙」，macOS 查 pfctl -sr 或系统偏好设置 → 防火墙。
排查 conntrack 表满导致的静默丢包
现象很典型：Workerman 进程正常、ss -tuln 显示监听、客户端 telnet 超时或卡住、dmesg -T 刷屏出现 nf_conntrack: table full, dropping packet——这不是 Workerman 的问题，是内核在 TCP 握手阶段就把 SYN 包丢了。
第一步验证：运行 conntrack -C，结果接近或等于 cat /proc/sys/net/netfilter/nf_conntrack_max 就是瓶颈。
第二步定位：执行 conntrack -L | awk '{print $4}' | sort | uniq -c | sort -nr | head -5，如果大量显示 TIME_WAIT 或 UNREPLIED，说明短连接密集且 conntrack 条目滞留。
第三步救急：执行 sysctl -w net.netfilter.nf_conntrack_max=131072 临时扩容，同时调大哈希桶数避免冲突：sysctl -w net.netfilter.nf_conntrack_buckets=32768。
【注意】清空 conntrack 表（conntrack -F）会丢失所有 NAT 和已有连接状态，可能导致客户端重连风暴，生产环境慎用。
检查服务端本地端口资源是否耗尽
这个错误只发生在客户端侧：报 Cannot assign requested address，意味着本机临时端口用完了。一台 Linux 默认可用临时端口约 2–3 万个（范围由 /proc/sys/net/ipv4/ip_local_port_range 决定）。
修改内核参数：编辑 /etc/sysctl.conf，追加一行 net.ipv4.ip_local_port_range = 10000 65535，然后执行 sysctl -p 生效。
如果是因为大量短连接快速断开后堆积 TIME_WAIT 占用端口，还需开启快速回收：sysctl -w net.ipv4.tcp_tw_reuse=1，并缩短超时：sysctl -w net.ipv4.tcp_fin_timeout=30。
验证 DNS 和路由路径是否正确
客户端用域名连接时，先执行 nslookup 域名 或 dig +short 域名，确认解析出的 IP 是服务器真实公网 IP，而不是内网地址（如 192.168.x.x 或 10.x.x.x）。
若解析正确但依然不通，用 mtr -r 服务器IP（Linux）或 tracert 服务器IP（Windows）看丢包发生在哪一跳——卡在中间 ISP 或云厂商边界网关，说明是网络策略限制，不是服务端问题。
客户端和服务端不在同一局域网时，严禁使用 127.0.0.1 或 localhost 作为连接地址，必须填服务器公网 IP 或已正确解析的域名。
