Shirone

症状一：服务起来了，但端口不通#

先在本机确认监听状态：

1
ss -tlnp | grep 8080

ss 是 netstat 的现代替代（更快、信息更全）。选项：-t TCP、-l 监听中、-n 数字端口、-p 显示进程。输出看两点：

• Local Address 是 0.0.0.0:8080（监听所有网卡）还是 127.0.0.1:8080（只听回环）。外网连不上而本机 curl 通，八成是服务只监听了 127.0.0.1，改配置绑到 0.0.0.0 或具体网卡。
• 进程列显示的服务名是不是你预期的那个——端口被别的程序占用的情况并不少。

本机监听正常，再从外部测连通性：

1
# 在客户端执行
2
curl -v telnet://服务器IP:8080     # 或 nc -vz 服务器IP 8080

连接超时（timeout）= 中间有设备丢包，查防火墙/安全组；连接拒绝（refused）= 包到了但没人接，回到上一步查监听。这个「超时 vs 拒绝」的区分是最有价值的判断。

防火墙检查（在服务器上）：

1
sudo iptables -L -n | grep 8080     # 或 nft list ruleset
2
sudo firewall-cmd --list-ports      # firewalld 系
3
# 云服务器还要检查控制台的安全组规则

症状二：整体网络不通#

分层验证，从近到远：

1
ip addr                    # 网卡有没有拿到 IP
2
ip route                   # 默认网关是否存在
3
ping -c 4 网关IP            # 局域网通不通
4
ping -c 4 223.5.5.5        # 出网通不通（用 IP 排除 DNS 干扰）
5
ping -c 4 example.com      # DNS 是否正常

哪一步失败就停在哪一层：网关不通查网线和交换机，IP 通而域名不通去查 DNS（参考本系列 DNS 一文），都通但应用不通回到症状一。

症状三：能通但慢、丢包#

ping 只能告诉你「到终点丢不丢」，定位「在哪一跳开始丢」用 mtr（My Traceroute）：

1
mtr -rwbzc 100 目标IP     # 发 100 个包，输出报告模式

报告里逐跳显示丢包率和延迟。判读要点：从某一跳开始丢包率显著升高且延续到终点，那一跳附近就是问题点；中间某跳丢包但终点不丢，多半是该设备限速响应 ICMP，属误报。mtr 同时给出 Best/Wrst/Avg 延迟，看抖动比看平均值更有用。

带宽是否跑满用 iperf3 两台机器对测；实时看网卡流量用 iftop 或 nload。

症状四：玄学问题，上抓包#

「间歇性断连」「应用说收到了乱码」这类问题只能靠看报文。tcpdump 常用模式：

1
# 抓与某主机的 HTTP 流量并显示内容
2
sudo tcpdump -i any -nnA 'host 203.0.113.5 and port 80'
3

4
# 只看 TCP 标志位（找 RST、重传）
5
sudo tcpdump -i any -nn 'tcp[tcpflags] & tcp-rst != 0'
6

7
# 写到文件，回头用 Wireshark 分析
8
sudo tcpdump -i any -nn -w /tmp/issue.pcap 'port 3306'

生产环境抓包务必加过滤条件并限制数量（-c）或文件大小（-C/-W），避免打满磁盘。.pcap 文件传到本地用 Wireshark 打开，「Follow TCP Stream」能把一条连接的完整会话重组出来，排查应用层问题极其高效。

决策速查表#

小结#

排错的通用节奏是：先本机（监听、防火墙）→ 再链路（ping/mtr）→ 最后报文（tcpdump）。每用一个工具都要能回答「这个结果排除了什么可能性」，工具才不会白用。

延伸阅读#

• man 8 ss、man 8 mtr、man 8 tcpdump
• iperf3 官方文档
• Wireshark User’s Guide