建连失败排查流程
把建连失败拆成可观测的几步：本机是否发出请求、路径上对端是否收到、对端是否回应、客户端是否收到回应。每一步对应不同的抓包证据与不同的怀疑对象，按顺序走一遍，比同时怀疑所有环节要高效得多，也更容易得到可复核的结论。
基本信息
| 适用场景 | 连接建立失败或超时的系统化排查 |
|---|---|
| 所需材料 | 两端抓包、服务监听状态、中间设备会话表 |
| 核心原则 | 每一步只回答一个问题 |
| 结论要求 | 写明证据来自哪一侧以及哪个时间窗 |
| 常用手段 | 抓包、端口探测、监听查看命令 |
典型使用场景
- 新上线服务的调用方报连接失败
- 跨网络访问超时，需要划清责任边界
- 负载均衡新增节点后部分请求失败
- 发布变更后连接建立成功率下降
- 跨云或专线场景的连接间歇性失败
建议顺序
建议顺序
1) 客户端抓包确认是否发出请求及是否重传
2) 服务端抓包确认请求是否到达
3) 核对监听状态、访问策略、路由与会话表
4) 判断回应形态：无响应、拒绝还是握手完成
5) 复测并留存两份抓包，注明时间窗步骤对照
| 观测点 | 证据 | 结论方向 |
|---|---|---|
| 本机发出请求 | 客户端抓包 | 应用与路由选择正常 |
| 对端收到请求 | 服务端抓包 | 路径无丢弃或策略拦截 |
| 对端回应拒绝或握手 | 双向抓包 | 服务状态与队列情况 |
| 客户端未收到回应 | 客户端抓包 | 返回路径存在丢弃 |
每一步只回答一个问题，避免用一次抓包去解释所有现象。
结论中写明证据来自哪一侧、时间窗多长，便于他人复核。
补充要点
- 同时抓两端是最高效的方式，一次就能定位断点在路径还是端口
- 存在地址转换时要在转换前后都有样本，否则五元组对不上
- 复现失败要记录尝试次数与失败比例，偶发问题尤其需要
- 把每次排查的结论与证据归档，同类故障再次出现时可快速比对
临时端口耗尽、连接队列溢出这类资源问题也表现为建连失败，抓包时留意请求的分布是否均匀。