软件测试中遇到服务器连接超时需要一套由近及远的排查思路。

第一步：确定超时发生的具体形态

在排查前先确定细节，能缩小 80% 的排查范围。

是瞬间报错还是卡顿后报错？ 瞬间报错一般意味着网络根本不通（IP 不可达、端口未监听）。卡顿几秒或几十秒后报错，一般是服务端接收了请求但处理过慢，或者防火墙/负载均衡器在等待上游响应。

是所有接口都超时，还是特定某个接口？ 如果只是某一个文件上传接口超时，问题在业务思路或文件存储后端。如果登录接口都超时，问题在网络基础或服务整体挂起。

是不是仅在特定环境出现？ 本地环境连测试服务器超时，但换台机器或换个 WiFi 正常，说明是本地网络代理/VPN 问题。

第二步：网络层快速排查

这是测试人员能最快完成的独立排查。

检查基础连通性Ping和Telnet

打开终端，ping目的服务器IP。如果Ping不通且丢包率 100%，说明路由不通或服务器禁Ping。

步骤：telnet 目的IP 目的端口（或使用 nc -vz IP PORT）。

如果 Telnet 提示 “Connection refused”：端口根本没有监听，服务可能挂了或端口写错了。

如果 Telnet 提示 “Connected” 但程序里超时：说明 TCP 握手成功，问题出在应用层协议（HTTP/HTTPS 握手） 或服务端处理思路。

检查本地代理和 Hosts 配置

测试时如果开启了Charles/Fiddler或VPN，请立即关闭代理并重试。大量假性超时是因为代理软件未正确转发流量或证书证实导致TLS握手卡死。

检查系统hosts文件，确定没有把测试域名指向一个错误的旧IP。

浏览器/客户端专用排查

浏览器F12 -> Network标签：查看超时的请求具体卡在哪个阶段。

状态显示 “Pending” 或 “Stalled”：浏览器等待可用TCP连接，可能是并发数满了（HTTP/1.1 限制）。

状态显示 “（failed） net：：ERR_CONNECTION_TIMED_OUT”：网络层或防火墙丢弃了SYN包。

状态显示 “CAUTION： request is not finished yet”：服务端已收到请求但迟迟不返回数据，正在处理中。

第三步：服务端内部状态排查

如果网络层确定 TCP 端口是通的，问题就转移到了服务端应用或中间件。

检查服务是不是假死

登录服务器执行 top 或任务管理器。

如果 CPU 占用率不断 100% 且负载很高：服务端忙于计算或 GC（垃圾回收），无法响应新连接。

如果 内存几乎耗尽且频繁 Swap：服务端在处理超大对象，陷入频繁内存交换，响应极慢导致超时。

检查监听队列是不是溢出

在 Linux 下执行 ss -lnt | grep 端口号。

查看 Recv-Q 和 Send-Q 列。如果 Recv-Q 有非零积压，说明服务端 Accept 队列满了，新连接虽然到达网卡，但应用进程来不及取走，导致客户端认为连接建立但无响应。

查看应用日志（最直接的突破口）

查看报错时间段的应用日志（如 Tomcat catalina.out， Nginx error.log， 业务 log）。

常见信号词：

Too many open files（句柄数耗尽，无法建立新连接）。

Connection pool exhausted（数据库连接池满了，线程都在等数据库）。

Read timed out（服务端去调下游接口或数据库时自己超时了，导致它也没法返回给测试端）。

第四步：针对解决、临时方案

根据排查到的根因，选择对应手段。

情况一：服务端负载过高（CPU/内存爆了）

临时方案：请开发重启服务释放资源，或临时扩容一个节点。

测试规避：测试时调低并发线程数，先做功能证实。

情况二：数据库连接池满 / SQL 执行慢

临时方案：请求 DBA Kill 掉长时间运行的慢查询。

测试规避：确定是不是因为测试数据量过大（如造了 1000 万条数据未建索引），导致简单查询变成全表扫描超时。

情况三：防火墙或安全组方法变更

现象：昨天能通，今天不通。

解决：检查云服务器安全组规则，确定测试办公网络的外网 IP 是不是在入方向白名单中（常见于内网环境访问 VPN 切换出口 IP 后）。

情况四：HTTPS 证书问题（容易忽视的 TLE 超时）

现象：HTTP 接口秒通，HTTPS 接口超时。

排查：检查测试服务器时间是不是和标准时间偏差超过 5 分钟。证书有效期证实失败会导致 TLS 握手阶段静默超时。

情况五：Nginx/网关反向代理超时设置过短

情形：测试大文件导出功能，总是 60 秒准时断。

解决：这一般是 Nginx 的 proxy_read_timeout 默认值（60s）限制了。请求运维临时调大该参数至 300s 供测试使用。

第五步：动手前速查

如果不想深究底层原理，遇到超时请按此自检：

关代理、关 VPN、切手机热点 - 排除 70% 的网络环境波动问题。

看 Postman 的 Response Time - 是直接无法连接，还是一直转圈。

问开发 - 服务刚才是不是重启了？、数据库是不是锁表了？

看域名分析 - nslookup 域名，别让测试环境域名不小心分析到了生产 IP。

看限流方法 - 测试时是不是因为高频调用触发了网关的熔断降级（此时连接会直接被拒，表现为超时）。