Linux TCP 连接建立失败的常见原因

连接失败主因有四：一是防火墙或安全组丢弃SYN包；二是服务未监听外网地址（如仅绑定127.0.0.1）；三是syncookies启用导致NAT环境下ACK丢失；四是TIME_WAIT占满端口或本地端口耗尽。

连接被防火墙或安全组拦截

Linux 主机上 iptables、nftables 或云平台安全组规则，会直接丢弃 SYN 包，导致客户端收不到 SYN+ACK。现象是客户端 tcpdump 只能看到发出的 SYN，服务端抓包看不到任何入向 SYN。

• 检查本地防火墙：sudo iptables -L -n -v 或 sudo nft list ruleset，重点关注 INPUT 链中是否有拒绝 TCP 目标端口的规则
• 云服务器务必确认安全组是否放行目标端口（不仅是协议和端口，还要检查源 IP 范围）
• 若使用 ufw，运行 sudo ufw status verbose 查看实际生效策略

服务进程未监听或绑定错误地址

netstat -tlnp 或 ss -tlnp 显示服务没在目标端口 LISTEN，或只绑定了 127.0.0.1（即 localhost），无法响应外部连接。

• 确认服务配置中监听地址不是 127.0.0.1:8080，而应为 0.0.0.0:8080 或具体外网 IP
• 某些服务（如 Nginx、Redis）默认只监听本地，需显式修改配置项，例如 Redis 的 bind 行要删掉或改成 bind 0.0.0.0（注意配合 protected-mode no）
• 若服务启动失败但没报错，检查日志：journalctl -u your-service-name -n 50

Syncookies 启用但客户端异常丢包

当连接请求洪峰到来时，内核可能启用 net.ipv4.tcp_syncookies=1（默认开启），此时不维护半连接队列，改用加密 cookie 回复 SYN+ACK。但如果客户端网络路径中存在 NAT 设备或中间件篡改 TCP 序列号，SYN+ACK 可能被丢弃或 ACK 无法返回，连接卡在 SYN_SENT。

node-connect

诊断Android、iOS及macOS配套应用的OpenClaw节点连接与配对故障，适用于二维码/设置码/手动连接失败或本地Wi-Fi问题时。

下载

• 临时关闭 syncookies 测试：sudo sysctl -w net.ipv4.tcp_syncookies=0（仅用于排查，生产环境不建议长期关闭）
• 更稳妥的方式是调大半连接队列：net.ipv4.tcp_max_syn_backlog=65535，并确保应用层 listen() 的 backlog 参数足够（如 Node.js 的 server.listen(port, host, backlog)）
• 注意：syncookies 关闭后，若队列溢出，内核会直接丢弃 SYN，表现为客户端超时而非拒绝

TIME_WAIT 占满端口或本地端口耗尽

主动断连方（通常是客户端）大量处于 TIME_WAIT 状态，且复用同一源 IP+端口频繁连接同一服务，可能导致新连接因“地址已在使用”被拒绝（connect(): Address already in use）；或本地 ephemeral 端口范围太小（默认 32768–60999，仅约 28K），并发连接数高时迅速耗尽。

• 查看当前连接状态分布：ss -ant | awk {print $NF} | sort | uniq -c | sort -nr
• 调整端口范围：echo net.ipv4.ip_local_port_range = 1024 65535 | sudo tee -a /etc/sysctl.conf
• 不推荐盲目缩短 net.ipv4.tcp_fin_timeout，更安全的做法是启用端口复用：net.ipv4.tcp_tw_reuse = 1（仅对客户端有效，且要求时间戳开启）

真正难定位的，往往是多个因素叠加：比如服务绑定了 localhost，同时防火墙又 DROP 了所有外网请求，而日志里只显示“Connection refused”，没人去查 ss -tlnp。