Failed to connect to server错误是性能测试中最常见也最棘手的错误，虚拟用户（VUser）无法和目的服务器建立TCP/IP连接是一个系统性故障，需要从网络层、协议/脚本层、服务器层、环境/配置层四个方面，由外向内、由简到繁地进行排查。

文章来源：卓码软件测评

精彩推荐：点击蓝字即可
▲软件负载测试 ▲API自动化测试 ▲软件测试 ▲第三方软件测试 ▲软件性能测试 ▲软件测试机构

快速定位和排查

在深入前，先通过两个问题缩小范围：

错误范围是全部还是部分VUser？

所有/绝大多数VUser失败：指向系统性问题，如网络中断、服务器宕机、防火墙拦截、DNS失效、负载均衡器故障或脚本中使用了错误且统一的服务器地址。

零星或部分VUser失败：更可能指向脚本或数据问题，如动态会话处理不当、IP绑定冲突、或服务器端连接池耗尽。

单用户脚本回放是不是成功？

在VuGen中，以详细日志方式（Extended Log） 和生成快照的方式，单用户回放问题脚本。

失败：问题存是脚本本身，进入第二阶段诊断。

成功：问题可能由并发、参数化数据或环境压力引起，进入第三、四阶段诊断。

脚本和协议层诊断

如果单用户回放失败或错误零星出现，请按顺序检查脚本：

检查服务器地址：确定脚本中请求的主机名或IP地址是不是和当前测试环境一致。检查是不是存在硬编码IP，尤其是从录制环境迁移到测试环境时。使用 web_save_host_header 或直接修改URL函数中的主机部分。

检查关联：这是最常见的故障。未能正确关联动态的Session ID、ViewState、CSRF Token等，会导致后续请求被服务器拒绝，最后可能表现为连接失败。检查：

是不是所有必要的动态值都已做关联。

关联函数的左右边界（LB/RB）是不是过于宽泛或过于严格，导致提取了错误的值或提取失败。

关联作用域是不是正确，是不是在每次需要时都重新获取了最新值。

检查参数化数据：如果参数化文件中的某些数据（如特殊的用户名、超长字符串）导致服务器处理异常并快速关闭连接，也可能引发此错误。尝试使用简单、确定的数据进行测试。

检查Socket和Winlnet方式：对于HTTP/HTML协议，在运行时设置（Run-time Settings）-> 偏好（Preferences） 中，切换 Winlnet replay instead of Sockets 选项。Winlnet 方式使用浏览器兼容方式，而 Sockets 是默认的底层方式。某些服务器或代理配置可能和其中一种方式不兼容。

网络和操作系统层诊断

如果单用户成功但并发失败，或所有用户都失败，需排查系统层。

连通检查：

Ping：从负载生成器（Load Generator）机器ping目的服务器，排除基本IP连通性故障。

Telnet/Test-NetConnection：使用 telnet [服务器IP] [端口] 或PowerShell的 Test-NetConnection 命令，证实目的服务器的特定监听端口是不是开放并可建立TCP连接。这是最重点的一步。

网络设备和配置：

防火墙：确定负载生成器、服务器以及中间的网络防火墙、主机防火墙（如Windows防火墙、iptables） 已允许相关端口的出入站通信。临时完全禁用防火墙进行测试是快速定位的常用方法。

DNS：如果脚本中使用主机名，请在负载生成器上确定DNS分析正确且稳定。建议在负载生成器的 hosts 文件中临时配置域名和IP的映射，以排除DNS问题。

负载均衡器：如果请求经过负载均衡器（F5， Nginx等），检查其健康检查机制是不是将测试服务器标记为下线，或会话保持方法是不是干扰了测试。

负载生成器和操作系统限制：

端口耗尽：高并发情形下，LoadRunner的VUser会使用大量本地临时端口（Ephemeral Ports）。Windows系统默认的临时端口范围可能不足。需要扩大范围：

# powershell

# 以管理员身份运行CMD，将端口范围设置为1024-65534

netsh int ipv4 set dynamicport tcp start=1024 num=64511

连接限制：检查Windows的TCP半开连接数限制（已放宽，但旧系统仍需注意）。

网络适配器配置：确定负载生成器的网卡性能足够，无错误包。对于高速测试，考虑启用巨型帧（Jumbo Frame）并优化TCP参数。

服务器和应用层诊断

当连接可以建立但无法维持或在压力下失败时，需查看服务器。

服务器资源状态：

监控：使用 netstat -an | findstr :[端口] 查看服务器上的连接状态。是不是存在大量 TIME_WAIT 或 CLOSE_WAIT 状态的连接？

资源耗尽：服务器是不是因压力导致CPU、内存、或线程/进程数耗尽，从而无法接受新连接？检查服务器的监控标准。

应用服务器和Web容器配置：

连接超时：检查应用服务器（如Tomcat, Nginx, IIS）的连接超时（connectionTimeout） 和 KeepAlive 配置。过短的超时时间在慢速测试环境下可能导致连接被服务器提前关闭。

最大连接数：检查应用服务器和操作系统的最大并发连接数限制（如Tomcat的 maxConnections， Linux的 ulimit -n 和 net.core.somaxconn 参数）。在负载下，这些限制可能被击穿。

通用诊断清单和日志分析

在Controller中启用重点日志：

进入Diagnostics -> Configuration，保证启用诊断。

在VUser的运行时设置中，启用 “Extended log” 并勾选Data returned by server 和 Advanced trace。重新运行失败从日志中查找紧邻错误前的具体请求和服务器返回信息。

错误信息：

Failed to connect to server "[IP]:[port]": [10048]：一般是地址已在使用，和端口耗尽或IP绑定冲突有关。

Failed to connect to server "[IP]:[port]": [10060]：连接超时，服务器无响应，可能是防火墙丢弃、服务器过载或网络路由问题。

Failed to connect to server "[IP]:[port]": [10061]：连接被拒绝，目的端口无程序监听，或防火墙确定拒绝。

总结

解决“Failed to connect to server”的重点是系统性隔离。从一个失败的VUser脚本入手，先保证它单机可运行，再放到小规模并发中观察，进行全负载测试。每一次操作只变更一个变量，并记录结果。

问题可能涉及更特殊的中间件、加密协议（如TLS握手失败）或定制化客户端证书认证。此时需要借助Wireshark网络抓包，在负载生成器端捕获TCP三次握手的过程，这是判断连接问题在何处的武器-观察SYN包是不是发出、是不是收到SYN-ACK、连接在哪一步被重置（RST）。