服务进程活着，日志没有报错，端口也在监听，客户端就是连不上。curl 返回 Connection refused，或者干脆超时没有任何响应。这类问题几乎每个做服务端开发的人都撞见过，难就难在它不报错、没堆栈，现象和根因之间隔了好几层。

这篇不讲玄学，按“从近到远、从内到外”的顺序，把这类连通性故障最常见的检查点排成一份清单。下次再遇到，先按清单走一遍，大多数情况能在半小时内定位。

先说一个总原则：连通性问题先分层，再定位。链路是分层的——进程、监听地址、本地防火墙、操作系统、局域网、云厂商安全组、公网入口，问题一定在其中某一层。跳过分层、凭感觉重启服务，是最浪费时间的排查方式。

第一步：确认服务真的在监听

第一步不是看日志，而是看端口。很多“连不上”的真相是服务根本没起来，或者起了但绑错了地址。

看端口是否在监听，以及绑在哪个地址上：

ss -tlnp | grep 8080

或者

netstat -tlnp | grep 8080

重点看监听地址那一列：

0.0.0.0:8080 —— 监听所有网卡地址，内外都能连（防火墙允许的前提下）

127.0.0.1:8080 —— 只监听本机回环地址，本机能连，其他机器连不上

172.17.0.2:8080 —— 只绑了某一张网卡，从别的网卡进来的流量到不了

127.0.0.1 是最常见的坑。很多框架和脚手架默认

只绑回环地址，本地开发完全没问题，一部署到服务器、换个机器访问就断。现象就是“本机 curl 通，别处全不通”。排查时如果发现监听地址是 127.0.0.1，先查启动配置里有没有 host 或 bind 参数，把它改成 0.0.0.0。

如果 ss 里根本看不到这个端口，说明进程没起来或者崩了。这时再回头看日志和进程状态：

ps aux | grep your-service

systemctl status your-service（systemd 托管的服务）

journalctl -u your-service -n 100 --no-pager

注意一个细节：端口冲突也会导致服务起不来。服务启动失败、日志里出现 Address already in use，说明端口已被别的进程占用。用 ss -tlnp 找到占用者，确认是重复启动还是端

口规划撞车，再决定是杀进程还是改端口。

第二步：本机能不能连上

服务在监听，先在本机上验证一次，把问题范围缩小到“本机以内”还是“本机以外”。

curl -v http://127.0.0.1:8080/health

没有 HTTP 接口的服务，用 nc 测 TCP 通不通

nc -vz 127.0.0.1 8080

本机也连不上：问题在服务本身。可能是监听地址、协议不匹配（比如服务只开了 IPv6，客户端走 IPv4），或者服务虽然起了但还没初始化完、拒绝连接。检查服务日志里的启动报错和初始化状态。

本机能连、别处不能连：问题在网络层面，继续往下走。

这里顺带提一个 IPv6 的坑：ss 显示监听地址是 :::8080，说明服务绑的是 IPv6 通配地址。大多数系统上它同时接受 IPv4 连接，但如果系统关闭了 IPv4 映射（net.ipv6.bindv6only=1），IPv4 客户端就会被拒。现象是 IPv6 客户端正常、IPv4 客户端超时，查起来很隐蔽。怀疑到这一步时，用 cat /proc/sys/net/ipv6/bindv6only 看一眼，值是 1 就要警惕。

第三步：查本机防火墙和安全软件

本机通、外面不通，第一个怀疑对象是服务器自身的防火墙。Linux 上常见的有三套，按系统区分：

firewalld（CentOS / RHEL / Fedora 常见）

firewall-cmd --list-all

firewall-cmd --query-port=8080/tcp

ufw（Ubuntu / Debian 常见）

ufw status verbose

裸 iptables / nftables

iptables -L INPUT -n --line-numbers

nft list ruleset

如果确认是防火墙拦的，放行端口：

firewall-cmd --add-port=8080/tcp --permanent && firewall-cmd --reload

ufw allow 8080/tcp

除了系统防火墙，别忘了另外两个“隐形守门员”：

SELinux / AppArmor：服务进程本身能跑，但网络访问被策略拦住。现象常常是服务启动正常、日志干净，但外部连接被悄悄丢弃。临时验证可以用 setenforce 0（仅限排查，确认后要写正确的策略规则再恢复，不要长期关闭）。

云服务器安全组：这是云上最常见的断点。服务器本机防火墙全放行了，云厂商控制台的安全组还拦着，公网照样进不来。排查时一定要把“系统内防火墙”和“云厂商安全组”当成两道独立的门，分

别检查。

第四步：查中间链路

如果本机防火墙和安全组都放行了，还是不通，问题可能在中间链路。换个思路：数据包走到哪一步丢的？

客户端上测：到服务器通不通

ping <服务器IP>

traceroute <服务器IP>（或 mtr，持续观察丢包位置）

telnet <服务器IP> 8080（或 nc -vz <服务器IP> 8080）

ping 不通：网络层就不通，可能是服务器禁 ping（很多云主机默认禁 ICMP，这本身不是故障）、路由问题或安全组连 ICMP 也拦了。不要只凭 ping 下结论，结合下一步看。

 ping 通但端口不通：网络层是通的，问题在传输层——端口被防火墙、安全组或中间设备过滤。结合第三步的结果，逐段确认。

traceroute 在某一跳之后全部超时：大概率是中间某台设备丢包，或者对方网络禁了 traceroute 的探测包。注意区分“某一跳超时”和“最后一跳超时”，前者未必是故障，后者才更接近目标。

如果条件允许，在服务器端抓包看真相。这是最直接的证据：

服务器上抓发往 8080 端口的包，看请求到底有没有到达

tcpdump -i any port 8080 -n

抓得到请求、没有响应：包到了服务器，问题在服务器侧——服务没响应、响应被防火墙拦、或者响应路由回不去。

抓不到任何请求：包在到达服务器之前就被丢了，问题在客户端网络、中间链路或云厂商安全组。

排查重点回到上游。

第五步：别漏了“服务能收到，但响应回不去”

还有一类容易被忽略的情况：请求到了，服务也处理了，但响应回不到客户端。客户端看到的现象同样是超时。

常见原因有三个：

1. 默认网关配错了：服务器收到了请求，但回程路由走错了网关，响应包石沉大海。多见于多网卡服务器，或者手动改过路由表的机器。用 ip route 检查默认路由是否指向正确的网关。

2. NAT / 端口映射配错了：请求经过端口转发进来，但回程没走同一条 NAT 路径，客户端收不到响应。常见于家用路由器、Docker 端口映射、云厂商的 NAT 网关场景。检查映射规则里的内外端口、协议（TCP 还是 UDP）是否一致。

3. MTU 问题：小包能通、大包超时，是 MTU 不匹配的典型症状。链路中间某台设备的 MTU 更小，又禁了 ICMP 的“需要分片”报文，发送方不知道要分片，大包就被悄悄丢弃。症状是登录页能打开、传大文件就卡死。用 ping -M do -s 1400 <目标> 逐步调小包长测试，定位 MTU 瓶颈。

第六步：域名与 DNS，别在最后才想起来

如果客户端用的是域名而不是 IP，排查清单里还要加一行 DNS：

nslookup your-domain.com

dig your-domain.com

对比：解析出来的 IP 是不是你以为的那台服务器

域名解析到旧 IP、解析到内网 IP、CDN 节点异常，这些都会让“服务明明好好的，偏偏连不上”。特别是刚做过迁移或换过服务器之后，DNS 缓存（本地、运营商、浏览器三级）可能还指着老地址。排查时先用 IP 直连测试：如果 IP 直连通、域名不通，问题就在 DNS 这一层。

一份可以照着走的排查顺序

把上面的步骤压缩成一张清单，贴在手边，下次照着走：

顺序 1：服务在监听吗，命令 ss -tlnp，异常：看日志、看端口冲突

顺序 2：监听地址对吗，看 127.0.0.1 还是 0.0.0.0，异常：改 bind 地址

顺序 3：本机能连吗，命令 curl 127.0.0.1:端口，异常：查服务自身、IPv6 映射

顺序 4：本机防火墙，命令 firewall-cmd / ufw / iptables，异常：放行端口

顺序 5：SELinux / AppArmor，命令 getenforce、审计日志，异常：写策略规则

顺序 6：云安全组，控制台核对入方向规则，异常：放行端口和来源

顺序 7：中间链路，命令 ping、traceroute、tcpdump，异常：定位丢包位置

顺序 8：回程路由/NAT，命令 ip route、映射规则，异常：修正网关与映射

顺序 9：DNS 解析，命令 dig、IP 直连对比，异常：清缓存、核对解析记录

这份清单的价值不在“全”，而在“顺序”。按顺序走，每一步都能排除一整层，问题范围越缩越小；跳着查、凭感觉查，查到最后常常是绕了一大圈才发现是第一步的监听地址问题。

最后补一句：排查完记得把根因和改动记下来。连通性故障最气人的地方不是难修，而是同一个坑半年后会换个马甲再出现。一次记录，下次五分钟。

求个关注：我是 Joy船长，正在每天认真拆一个 AI、开源或代码安全方面的真实问题。觉得这篇对你有点用，麻烦点一下关注，后面的更新不迷路，下一篇见。