云服务器上workerman连不上，必须同时配置安全组和系统防火墙：安全组在云网络边界放行入方向tcp端口（如2345），系统防火墙（如firewalld）在os层同步放行同一端口，二者叠加生效，缺一不可。
云服务器上部署 Workerman，只配系统防火墙或只配安全组，都可能让服务连不上——因为这两层防火墙不互相替代，而是叠加生效的。安全组是云厂商在虚拟网络边界做的第一道过滤，系统防火墙（如 iptables 或 firewalld）是操作系统内核里的第二道过滤。任何一层拒绝，连接就断在那一步。
安全组是云环境的“网络门禁”，不是可选项
阿里云、腾讯云等平台默认创建的安全组规则是「拒绝所有入站流量」。这意味着即使 Workerman 正确监听了 0.0.0.0:2345，且 ss -tuln | grep :2345 显示正常，客户端依然会得到 Connection refused 或超时——因为数据包根本没进到服务器网卡。
- 必须登录控制台，在对应安全组的「入方向」添加规则：协议选
TCP，端口填你的 Workerman 监听端口（如2345），源 IP 段按需设为0.0.0.0/0（测试用）或具体客户端网段 - 安全组规则修改后秒级生效，无需重启 ECS 实例或 Workerman
- 注意：安全组只管「进来的包」，出方向默认放行；但如果你开了严格出站策略，
file_get_contents或cURL外调失败，也得检查出方向规则
系统防火墙是 OS 层的“最后一道闸”，常被忽略
很多用户以为配完安全组就万事大吉，结果发现本地能 telnet 通，但外网还是连不上——这时候大概率是系统防火墙在拦截。尤其是 CentOS 7+/Alibaba Cloud Linux 默认启用 firewalld，Ubuntu 20.04+ 可能启用了 ufw。
- 查状态：
sudo firewall-cmd --state（firewalld）或sudo ufw status（ufw） - 临时放行端口：
sudo firewall-cmd --add-port=2345/tcp --permanent+sudo firewall-cmd --reload - 别只信
iptables -L：firewalld 底层可能用 nftables，iptables -L看不到规则但实际生效 - Docker 容器场景下，宿主机防火墙仍会拦截映射端口（如
-p 2345:2345），必须额外放行宿主机的2345
两层防火墙的排查顺序不能乱
连不上 Workerman 时，按这个顺序验证，能快速定位卡在哪一层：
- 第一步：从客户端机器执行
telnet your-server-ip 2345—— 不通？说明问题出在安全组或网络路径（如 NAT、客户端出口限制） - 第二步：登录服务器，执行
ss -tuln | grep :2345—— 无输出？Workerman 没真正监听，或绑定的是127.0.0.1；有*:2345？继续下一步 - 第三步：在服务器本机执行
telnet 127.0.0.1 2345—— 通但外网不通？重点查安全组和系统防火墙；不通？再查 Workerman 日志末尾是否有Fatal error或未捕获异常 - 第四步：确认
ps aux | grep WorkerMan里有worker process，只有master process说明子进程启动失败，workerman.log是唯一线索
最易被忽略的一点：安全组和系统防火墙的端口放行必须完全一致——比如 Workerman 监听 2345，安全组开了 2345，但系统防火墙只开了 2346，照样连不上。两者不是“二选一”，是“缺一不可”。
