8. 网络超时和连接失败怎么排查
网络超时和连接失败，是接口测试、自动化测试、App 测试和性能测试中非常常见的问题。很多同学看到 timeout、connection refused、connection reset，就直接说“网络不好”或“后端挂了”，这不够专业。测试工程师需要区分不同错误背后的含义：是连接没建立成功，还是连接建立后服务端迟迟不返回？是端口没监听，还是防火墙拦截？是服务处理慢，还是数据库、第三方接口慢？
面试中问网络超时和连接失败，重点不是让你背网络协议，而是看你能不能按层次排查。一个好的回答应该包括：确认 URL 和环境、检查网络连通、检查端口监听、区分连接拒绝和超时、查看服务日志、分析接口耗时、排查依赖服务和网关配置。这样才能体现真实项目经验。
一、常见错误类型
1. Connection refused
连接被拒绝。通常说明目标主机可达，但目标端口没有服务监听，或者服务主动拒绝连接。
常见原因：
- 服务没启动；
- 端口写错；
- 服务监听在其他端口；
- 端口被防火墙拒绝；
- 容器端口映射错误；
- 服务刚重启，还未就绪。
2. Connection timeout
连接超时。通常表示客户端尝试建立连接，但在规定时间内没有成功。
常见原因：
- 网络不通；
- IP 或域名错误；
- 路由不可达；
- 防火墙丢弃请求；
- 安全组未开放；
- 服务所在网络不可达。
3. Read timeout
读取超时。通常表示连接已经建立，但服务端迟迟没有返回响应。
常见原因：
- 后端处理慢；
- 数据库慢；
- 第三方接口慢；
- 线程阻塞；
- 大文件处理耗时；
- 锁等待或死锁；
- 服务负载过高。
4. Connection reset
连接被重置。可能是服务端主动关闭连接、网关断开、服务重启、连接池异常等。
二、第一步：确认请求信息
排查前先确认基本信息：
- URL 是否正确；
- 域名或 IP 是否正确；
- 端口是否正确；
- 协议是 HTTP 还是 HTTPS；
- 请求方法是否正确；
- 是否访问了正确环境；
- 是否使用了代理；
- 是否是所有人都失败。
很多所谓网络问题，其实是地址写错、环境选错、端口错或代理配置错。
三、第二步：确认网络连通性
可以用基础工具初步判断。
1. ping
ping api.example.com
能判断域名是否解析、主机是否可达。但有些服务器禁 ping，所以 ping 不通不一定代表服务不可达。
2. curl
curl -v http://ip:port/api/health
curl -v 可以看到连接过程、状态码和响应头。
3. telnet 或 nc
telnet ip 8080
nc -vz ip 8080
用于测试端口是否可连接。
如果端口连不上，要查服务和网络。
四、第三步：检查服务进程和端口
在服务器上查看服务是否启动：
ps -ef | grep java
查看端口是否监听：
ss -lntp | grep 8080
如果端口没有监听，接口一定访问不了。要看启动日志，确认是否端口冲突、配置错误、服务启动失败。
如果是 Docker：
docker ps
docker logs 容器ID
如果是 K8s：
kubectl get pods -n test
kubectl logs pod名称 -n test
五、第四步：区分网关和后端问题
很多项目请求链路是：
浏览器 -> Nginx/网关 -> 后端服务 -> 数据库/Redis/MQ
接口访问失败，不一定是后端服务本身问题。可能是 Nginx、网关、负载均衡、DNS、服务注册、转发路径问题。
排查方法：
- 直接访问后端服务端口；
- 查看网关日志；
- 查看 Nginx access/error 日志；
- 确认 upstream 配置；
- 确认服务注册是否正常；
- 对比内网访问和外网访问。
如果直接访问后端正常，但通过域名失败，问题可能在网关或 Nginx。
六、第五步：查看服务日志
网络超时不一定是网络问题。Read timeout 经常是后端处理慢。
日志中重点看：
- 请求是否到达服务；
- 处理耗时；
- 是否调用数据库；
- 是否调用第三方接口；
- 是否有慢 SQL；
- 是否线程池耗尽；
- 是否有超时异常；
- 是否有连接池异常。
如果日志完全没有请求，说明请求可能没到服务。要查网关、网络、端口、域名。
如果日志有请求但处理很久，要查后端逻辑和依赖服务。
七、项目场景：接口 Connection refused
现象：Postman 请求接口提示 Connection refused。
排查：
- 确认 URL 和端口；
- 登录服务器查看服务进程；
ss -lntp | grep 端口；- 发现端口未监听；
- 查看启动日志；
- 发现服务启动失败，数据库配置错误；
- 修复配置并重启；
- 接口恢复。
结论：Connection refused 更偏服务端口或服务状态问题。
八、项目场景：接口 Read timeout
现象：请求已发出，等待很久后超时。
排查：
- 抓包或 Postman 记录请求耗时；
- 查看服务日志是否收到请求；
- 日志显示调用第三方支付接口耗时很长；
- 查看第三方接口响应或 Mock 服务；
- 设置合理超时时间和错误提示；
- 回归异常场景。
结论：Read timeout 更偏服务处理慢或依赖慢。
九、项目场景：只有部分用户超时
如果不是所有人都失败，要考虑：
- 用户网络差异；
- 地域网络；
- 代理配置；
- DNS 缓存；
- 某个网关节点异常；
- 某个后端 Pod 异常；
- 用户数据触发慢 SQL；
- 特定账号权限或数据量过大。
这类问题要收集用户、时间、网络、请求、TraceId 和日志。
十、自动化测试中的超时
自动化脚本常见超时原因：
- 接口响应慢；
- 测试环境不稳定；
- 脚本超时时间设置过短；
- 前置数据准备慢；
- 服务刚发布未就绪；
- 并发执行导致环境压力过大。
不要一看到自动化超时就改大超时时间。要先判断是系统慢还是脚本等待策略不合理。
十一、面试回答模板
如果面试官问“网络超时和连接失败怎么排查”，可以这样回答：
我会先区分错误类型。如果是 connection refused，通常说明目标端口没有服务监听或服务拒绝连接，我会确认 URL、IP、端口、服务进程和端口监听。如果是 connection timeout，可能是网络不通、防火墙、安全组或路由问题，我会用 curl、telnet、nc 等工具验证连通性。如果是 read timeout，说明连接可能建立了，但服务端响应慢，我会查看服务日志、数据库、第三方接口和资源指标。排查时会按请求信息、网络连通、进程端口、网关转发、服务日志、依赖服务的顺序定位。
十二、常见追问
追问：Connection refused 和 timeout 区别？
Connection refused 通常是目标端口无服务或被拒绝；timeout 是连接或响应在规定时间内没有完成。
追问：Read timeout 怎么定位？
看服务是否收到请求，查看处理耗时、慢 SQL、第三方接口、线程池、资源和日志。
追问：ping 不通是否一定网络不通？
不一定。有些服务器禁 ping，要结合 curl、telnet、nc 或实际接口访问判断。
追问：接口偶发超时怎么办？
收集时间点、TraceId、用户、请求参数、后端日志和监控，查看是否某个节点、Pod、数据库或第三方依赖异常。
十三、练习清单
- 区分 connection refused；
- 区分 connection timeout；
- 区分 read timeout；
- 用 curl 测接口；
- 用 telnet 或 nc 测端口；
- 用 ss 查看端口监听；
- 查看服务日志耗时；
- 判断网关和后端问题；
- 分析一次自动化超时；
- 准备网络超时面试回答。
网络超时和连接失败不能一句“网络不好”带过。测试要按连接、端口、服务、网关、日志和依赖分层排查，才能给出专业判断。
配套刷题：
