ping 通 ≠ 端口通
ping 走的是 ICMP（网络层），端口通不通要看 TCP（传输层）——两层各管各的，一层通不代表另一层通。先确立基线意识：遇到“连不上”，第一件事是分层确认到哪一层断了，再往下查。
$ ping 10.0.0.20 # 网络层：主机活着吗
$ telnet 10.0.0.20 6379 # 传输层：端口开着吗（或 nc -zv）
$ curl -v http://10.0.0.20:8080/health # 应用层：服务对吗
# telnet 卡住的两种长相：
# Connection refused → 到达了，但没进程听（监听问题）
# 长时间沉默后 timeout → 包根本没到（防火墙/路由问题）端口不通的十种可能（按频率排序）
| 序 | 原因 | 一句话确认 |
|---|---|---|
| 1 | 服务没起来/崩了 | ss -lntp 看监听是否存在 |
| 2 | 绑了 127.0.0.1 | ss 显示 127.0.0.1:8080 而非 0.0.0.0 |
| 3 | 本机防火墙 | iptables -L -n / firewall-cmd --list-all |
| 4 | 云安全组没放行 | 控制台看入方向规则 |
| 5 | 端口写错/协议写错 | UDP 服务用 TCP 测当然不通 |
| 6 | K8s NetworkPolicy 拦截 | kubectl describe netpol |
| 7 | VPC/安全域隔离 | 不同网段路由可达吗 |
| 8 | DNS 解析到错误 IP | dig 对比，测 IP 别测域名 |
| 9 | 中间 LB 规则/健康检查摘除 | 看 LB 后端健康状态 |
| 10 | conntrack 表满 | dmesg 看 table full 报错 |
第 2 条值得单独喊话：本机 curl 得通、别人连不上，九成是服务绑了 loopback。Spring Boot 默认 server.address 不配就是 0.0.0.0，但 Redis、MySQL 的配置文件里 bind 127.0.0.1 是出厂默认。
间歇性超时：更阴险的四类
偶发问题比持续问题难十倍，按四类收拢：一，连接池排队——借连接等待超过阈值（第十六篇、十八篇的案例），特征是服务端响应快、客户端总耗时长；二，空闲连接被回收——LB/数据库先关了连接，业务拿到手就 reset，特征是失败集中在低峰期后第一波请求；三，丢包重传——ss -i 看 retrans 计数、抓包看 tcp.analysis.flags，特征是耗时恰好是 200ms/1s 这类重传量级；四，GC 或定时任务——STW 期间连接积压，特征是超时点和 GC 日志对得上。
万能流程：分层剥洋葱
用户报「慢/连不上」
├─ 1. 复现路径固定：curl -w 看耗时分解（DNS/建连/TLS/首字节）
├─ 2. 哪段最慢 → 定位到层
│ DNS 慢 → dig 对比解析器（第十四篇）
│ 建连慢 → 握手抓包，查防火墙/队列（第四篇）
│ TLS 慢 → time_appconnect，查版本/会话复用（第十二篇）
│ 首字节慢 → 服务端内部，别怀疑网络了
│ 传输慢 → ss -i 看窗口重传，抓包分析（第六、七篇）
└─ 3. 抓包定罪 → 修复 → 复测留档流程的价值在于每次都走同一条路：肌肉记忆比灵感可靠，留档的案例库比人脑可靠。下一篇收官：一张全景地图，把二十篇串成一个整体。
评论 (0)