在复杂的企业网络环境或安全要求高的场景下进行压测，Gatling的网络配置非常重要。专业的配置能保证测试顺利进行，能提升测试效率和资源利用率。
代理设置：HTTP/SOCKS代理和认证
Gatling的网络请求底层使用Netty和Java的HTTP客户端，支持通过系统属性、配置文件或代码配置代理。
1. 配置方式
代码配置（推荐）：在Simulation类的setUp之前，通过HttpProtocolBuilder配置，优先级最高，最适合测试脚本的移植。
配置文件：修改gatling.conf中的gatling.http相关部分。
JVM系统属性：通过-D参数启动，适用于临时或全局设置。
2. 具体配置详解
以代码配置为例，支持HTTP和SOCKS代理：
import io.gatling.core.Predef._ import io.gatling.http.Predef._ class ProxySimulation extends Simulation { val httpProtocol = http .proxy(Proxy("proxy-host", 8080).httpsPort(8443)) // 指定HTTP/HTTPS代理主机和端口 // .socksProxy("socks-host", 1080) // 如需使用SOCKS代理，则使用此配置 .proxyAuth(ProxyAuth("username", "password")) // 如果代理需要基础认证 val scn = scenario("ProxyTest") .exec(http("request_with_proxy") .get("https://your-api.zmtests.com/data")) setUp(scn.inject(atOnceUsers(1))).protocols(httpProtocol) }在gatling.conf中，你可以设置更细致的默认值，如连接超时：
gatling { http { proxy { host = "proxy-host" port = 8080 securePort = 8443 # HTTPS代理端口 auth { username = "your-username" password = "your-password" } } } }3. 注意事项
明确代理类型，错误的代理类型（如将SOCKS误设为HTTP）会导致连接失败。
在企业内网，可能需要对特定域名（如内部服务）绕过代理。这通常需要在操作系统或JVM层面设置nonProxyHosts，Gatling代码层面不直接支持。
优先使用代码配置，保证环境的独立。
SSL/TLS证书处理
处理SSL证书错误如javax.net.ssl.SSLHandshakeException是Gatling压测中的常见问题。
1. 证书错误的根本原因
当Gatling（JVM）连接HTTPS服务时，会校验服务端证书是否由可信机构颁发且和域名匹配。使用自签名证书、内部CA签发证书或证书链不完整时，校验会失败。
2. 解决方法
方案A：将证书导入Gatling的JVM信任库永久生效
这是最标准、最安全的方法，使JVM从根本上信任该证书。
获取证书：使用浏览器或openssl命令（openssl s_client -connect target-host:443 -showcerts）导出服务器的PEM格式证书。
导入到JVM信任库：使用Java的keytool命令将其导入Gatling所使用的JVM的cacerts文件。
keytool -import -alias "my-internal-ca" -file /path/to/server-cert.pem -keystore $JAVA_HOME/jre/lib/security/cacerts -storepass changeit注意：默认密码是changeit。生产环境建议使用自定义的信任库文件，并通过-Djavax.net.ssl.trustStore参数指定。
方案B：在Gatling代码中禁用特定校验仅限测试环境
此方法仅用于临时的非安全测试环境，通过自定义HttpProtocolBuilder实现。
import io.gatling.core.Predef._ import io.gatling.http.Predef._ import javax.net.ssl._ val insecureHttpProtocol = http .disableClientSharing // 每个用户使用独立客户端，避免配置冲突 .disableWarmUp .enableHttp2 .ssl( // 关键SSL配置 _.insecure // 忽略所有证书错误（最不安全，但最方便） // 更细粒度的配置（推荐）： // .useOpenSsl() // .useInsecureTrustManager() // 使用不安全的信任管理器，效果类似.insecure // .useTrustManager(new MyCustomTrustManager()) // 完全自定义信任管理器 ) // 自定义信任管理器示例（高级） class MyCustomTrustManager extends X509ExtendedTrustManager { // 实现所有抽象方法来定义自定义校验逻辑 override def checkClientTrusted(chain: Array[java.security.cert.X509Certificate], authType: String): Unit = {} override def checkServerTrusted(chain: Array[java.security.cert.X509Certificate], authType: String): Unit = {} override def getAcceptedIssuers(): Array[java.security.cert.X509Certificate] = Array() }警告：.insecure或useInsecureTrustManager会完全禁用SSL证书验证，存在中间人攻击风险，绝对禁止用于生产环境或测试含敏感数据的系统。
开发/测试环境：对于内部服务，优先将内部CA证书导入JVM信任库。
临时调试：可使用.insecure快速验证测试脚本，但务必在最终测试前移除。
持续集成/生产压测：必须在压测机JVM中预先配置好正确的信任库。
DNS缓存优化
默认的JVM DNS缓存行为（尤其缓存失败解析）会严重影响高并发压测性能，导致大量虚拟用户等待DNS解析或因缓存失败而直接报错。
1. 问题分析
JVM默认的DNS缓存策略（由networkaddress.cache.ttl和networkaddress.cache.negative.ttl控制）在并发场景下可能引发两个问题：
缓存超时过长：DNS记录变更时，压测可能访问到旧IP。
失败缓存：一次DNS解析失败会被缓存一段时间（默认10秒），期间所有请求直接失败。
2. 优化配置方案
方案A：全局JVM参数调整
通过启动Gatling的JVM参数设置DNS缓存策略，对整个JVM进程生效。
JAVA_OPTS="-Dnetworkaddress.cache.ttl=60 -Dnetworkaddress.cache.negative.ttl=0" $GATLING_HOME/bin/gatling.sh -s YourSimulationnetworkaddress.cache.ttl：设置成功的DNS解析缓存时间（秒）。设为 60 是平衡性能和实时性的常见选择。
networkaddress.cache.negative.ttl：设置失败的DNS解析缓存时间（秒）。设为 0 表示不缓存失败，压测中临时DNS故障恢复后能立即重试。
方案B：代码层面配置
在Simulation的HTTP协议中，可以设置每个虚拟用户使用的DNS解析器，并配置缓存策略。
import io.gatling.core.Predef._ import io.gatling.http.Predef._ import java.net.InetAddress import java.util.concurrent.TimeUnit val httpProtocol = http .dnsNameResolution(dns => dns // 配置异步DNS解析器（性能更好） .asyncNameResolution() // 设置自定义的DNS缓存TTL（单位：毫秒） .cacheMaxTimeToLive(60, TimeUnit.SECONDS) // 成功解析缓存60秒 .cacheNegativeTimeToLive(0, TimeUnit.SECONDS) // 失败解析不缓存 // 也可以指定自定义的DNS服务器 .nameServers("8.8.8.8", "1.1.1.1") )方案C：操作系统级别配置
保证/etc/hosts文件包含正确的静态映射，Gatling会优先使用此映射。
调整操作系统的DNS配置（如/etc/resolv.conf），使用响应速度快的DNS服务器。
综合配置示例
将以上三项配置结合到一个专业的压测脚本中：
import io.gatling.core.Predef._ import io.gatling.http.Predef._ import java.util.concurrent.TimeUnit class ProfessionalLoadTest extends Simulation { val httpProtocol = http // 1. 代理配置 .proxy(Proxy("corp-proxy.internal", 3128)) .proxyAuth(ProxyAuth("loadtester", "testpass")) // 2. SSL配置（仅用于非生产内部测试） .ssl(_.useInsecureTrustManager) // 注意安全警告！ // 3. DNS优化配置 .dnsNameResolution(dns => dns .asyncNameResolution() .cacheMaxTimeToLive(30, TimeUnit.SECONDS) .cacheNegativeTimeToLive(0, TimeUnit.SECONDS) ) // 其他通用配置 .baseUrl("https://internal-app.zmtests.com") .acceptHeader("application/json") val scn = scenario("ProfessionalTest") .exec(http("get_endpoint") .get("/api/v1/resource")) setUp( scn.inject( rampUsersPerSec(1).to(100).during(300) ) ).protocols(httpProtocol) }总结
环境隔离：为压测准备专属的、网络环境干净的机器，避免和开发环境冲突。
配置优先级：SSL证书问题优先通过JVM信任库解决；DNS优化优先使用JVM全局参数；代理配置在代码中明确指定。
安全底线：禁用SSL证书验证（.insecure）仅作为最后手段用于非安全测试，且必须有明确的流程控制和记录。
性能验证：在进行大规模压测前，先用少量用户验证网络配置（代理、SSL、DNS）是否正确生效，观察连接建立时间和错误率。
文章来源：卓码软件测评
精彩推荐：点击蓝字即可
▲软件负载测试▲API自动化测试▲软件测试▲第三方软件测试▲软件性能测试▲软件测试机构
