在复杂的企业网络环境或安全要求高的场景下进行压测，Gatling的网络配置非常重要。专业的配置能保证测试顺利进行，能提升测试效率和资源利用率。

代理设置：HTTP/SOCKS代理和认证

Gatling的网络请求底层使用Netty和Java的HTTP客户端，支持通过系统属性、配置文件或代码配置代理。

1. 配置方式

代码配置（推荐）：在Simulation类的setUp之前，通过HttpProtocolBuilder配置，优先级最高，最适合测试脚本的移植。

配置文件：修改gatling.conf中的gatling.http相关部分。

JVM系统属性：通过-D参数启动，适用于临时或全局设置。

2. 具体配置详解

以代码配置为例，支持HTTP和SOCKS代理：

scala

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-target-api.com/data"))

  setUp(scn.inject(atOnceUsers(1))).protocols(httpProtocol)

}

在gatling.conf中，你可以设置更细致的默认值，如连接超时：

text

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文件。

bash

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实现。

scala

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进程生效。

bash

JAVA_OPTS="-Dnetworkaddress.cache.ttl=60 -Dnetworkaddress.cache.negative.ttl=0" $GATLING_HOME/bin/gatling.sh -s YourSimulation

networkaddress.cache.ttl：设置成功的DNS解析缓存时间（秒）。设为 60 是平衡性能和实时性的常见选择。

networkaddress.cache.negative.ttl：设置失败的DNS解析缓存时间（秒）。设为 0 表示不缓存失败，压测中临时DNS故障恢复后能立即重试。

方案B：代码层面配置

在Simulation的HTTP协议中，可以设置每个虚拟用户使用的DNS解析器，并配置缓存策略。

scala

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服务器。

综合配置示例

将以上三项配置结合到一个专业的压测脚本中：

scala

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.company.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）是否正确生效，观察连接建立时间和错误率。