PAYATHON 2026

云端 JMeter 请求 payment gateway 失败

支付阿杰

结论

问题大概率不在 User-Agent 或 Browser Compatible Headers，而是云端负载机与本机的运行环境不同。payment gateway 常见的拒绝原因包括：

  • 云端出口 IP 未加入白名单，或被 WAF、反欺诈系统拦截
  • 云服务商 IP、数据中心 IP 或请求来源地区受到限制
  • TLS 版本、密码套件、SNI 或客户端证书不符合要求
  • 云端执行时缺少 Cookie、CSRF Token、Session ID 等动态关联数据
  • payment gateway 禁止未经授权的性能测试或批量支付请求

目前缺少具体错误信息，仅凭”请求失败”无法确定原因。继续调整 headers 的意义不大。应先完整记录云端失败请求的状态码、响应体、TLS 异常和实际出口 IP。

先获取具体的失败信息

至少需要收集：

  • HTTP 状态码，例如 400、403、429、5xx
  • 响应体和响应 headers
  • JMeter 的 responseCode、responseMessage
  • jmeter.log 中的异常堆栈
  • 云端负载机的公网出口 IP
  • 请求最终连接的域名和 IP
  • 是否发生重定向
  • TLS 握手是否成功
  • payment gateway 是否返回 request ID、trace ID 或错误代码

如果只看到 JMeter 断言失败，先查看触发断言的原始响应。可以临时添加 JSR223 PostProcessor，用 Groovy 记录必要信息：

log.info("URL: ${prev.getURL()}")
log.info("Response code: ${prev.getResponseCode()}")
log.info("Response message: ${prev.getResponseMessage()}")
log.info("Response headers:\n${prev.getResponseHeaders()}")
log.info("Response body:\n${prev.getResponseDataAsString()}")

日志中不要输出银行卡号、CVV、Authorization、Cookie、支付令牌或其他敏感信息。排查结束后，应删除这些详细日志。

也可以在非 GUI 模式下保存测试结果：

jmeter -n \
  -t checkout.jmx \
  -l results.jtl \
  -j jmeter.log

云平台可能会覆盖 JMeter 的结果保存配置，因此还要检查平台提供的原始日志、失败响应和网络错误报告。

根据错误类型缩小范围

返回 403 Forbidden

优先检查：

  • 云端出口 IP 是否需要加入 payment gateway 白名单
  • WAF 是否拦截数据中心 IP
  • payment gateway 是否限制国家或地区
  • 请求是否缺少客户端证书
  • 签名中是否包含来源 IP、Host、时间戳或动态路径
  • 防重放机制是否拒绝重复的 nonce 或 transaction ID

三个不同的在线 JMeter 服务都失败，而本机可以成功，通常说明问题更可能出在来源网络、IP 信誉或安全策略，而非普通 header。

返回 429 Too Many Requests

这通常说明 gateway 或前置防护触发了限流。需要：

  • 降低线程数和启动速率
  • 为每个请求生成唯一的订单号和幂等键
  • 联系 gateway 确认沙箱环境的速率限制
  • 申请专门的压测窗口或测试配额

不要用无限重试绕过限流，否则可能导致重复扣款或进一步封禁。

返回 400 或业务错误码

重点检查请求关联和数据唯一性：

  • 登录后的 Cookie 是否正确传递
  • CSRF Token 是否从前置响应中提取
  • 支付 token 是否已经过期
  • 订单号、nonce、timestamp、signature 是否动态生成
  • 多个线程是否错误地共享了同一个支付会话
  • 请求体编码与 Content-Type 是否一致
  • 云端与本机的时钟是否存在明显偏差

如果响应会动态返回 CSRF Token，应使用提取器获取，不能把本机录制到的值写死：

JSON JMESPath Extractor
Name of created variable: csrf_token
JMESPath expression: csrfToken

在后续请求中引用：

X-CSRF-Token: ${csrf_token}

订单号等一次性字段也必须在线程之间保持唯一，例如：

def orderId = "${System.currentTimeMillis()}-${ctx.getThreadNum()}-${UUID.randomUUID()}"
vars.put("order_id", orderId)

出现 SSLHandshakeException

这类异常与 header 无关，应比较：

  • 云端使用的 JMeter 和 Java 运行时
  • gateway 要求的 TLS 版本
  • 服务端证书链是否完整
  • 云端是否经过 TLS 检查代理
  • 是否要求 mTLS 客户端证书
  • 域名、SNI 和证书名称是否匹配

在受控测试中，可以增加 Java TLS 调试参数：

jmeter -Djavax.net.debug=ssl,handshake \
  -n -t checkout.jmx \
  -l results.jtl \
  -j jmeter.log

这类日志非常详细，可能包含证书和连接信息，不适合长期保存或公开上传。

如果 payment gateway 要求 mTLS，需要在云端负载机上安全配置客户端证书。复制 HTTP headers 无法代替客户端证书。

连接超时、重置或 DNS 失败

检查：

  • 云平台是否允许访问目标域名和端口
  • payment gateway 是否主动丢弃来自云服务商网络的连接
  • DNS 是否解析到了不同区域或不同网关节点
  • IPv4 与 IPv6 的路径是否不同
  • 云端是否必须通过代理访问外部网络
  • 云端节点与 gateway 之间是否存在防火墙或路由限制

测试必须从实际负载机发起。在本机使用相同 headers，只能证明本机网络路径可用，无法验证云端路径。

核对 JMeter 会话和请求关联

支付流程通常不是一条可以独立重放的 HTTP 请求。检查 Test Plan 是否包含：

  • HTTP Cookie Manager
  • 必要的 HTTP Cache Manager
  • CSRF Token、payment token、session ID 等提取器
  • 每个线程独立使用的订单和支付数据
  • 重定向处理
  • 正确的 Content-Type
  • 与服务端要求一致的字符编码
  • 动态签名和时间戳生成逻辑

如果本机单线程成功，云端多线程失败，还需要在本机使用与云端相同的线程数、Ramp-up、循环次数和数据文件复现。共享 CSV 行、固定 token 和重复订单号等问题，往往只会在并发运行时出现。

从云端节点做最小化对照测试

如果平台允许，可以从实际负载节点发送一个不会产生真实扣款的健康检查或沙箱请求：

curl -v --connect-timeout 15 \
  https://sandbox.example-payment-gateway.com/health

如需确认出口 IP，可以访问企业自有的诊断端点，由该端点记录客户端 IP。不要通过不受控制的公共服务传输支付相关信息。

如果最小请求也失败，应优先排查 DNS、TLS、网络策略或 IP 限制。如果最小请求成功，而完整支付请求失败，再检查鉴权、会话关联、签名和业务数据。

与 payment gateway 和云平台确认

向 payment gateway 支持团队提供：

  • 准确的失败时间和时区
  • 云端出口 IP
  • gateway 返回的 request ID 或 trace ID
  • HTTP 状态码和经过脱敏的错误信息
  • 使用的是沙箱还是生产环境
  • 是否经过 NAT、代理或负载均衡器

同时确认：

  • 是否允许来自数据中心或公有云的请求
  • 是否需要配置 IP 白名单
  • 是否限制来源国家或地区
  • 是否要求 mTLS
  • 是否存在 WAF、反机器人或反欺诈拦截
  • 是否允许进行负载测试
  • 是否提供专用沙箱和压测端点

还需要向 JMeter 云服务商确认实际出口 IP 是否固定。很多平台的负载节点使用动态 IP，只把某一次执行时看到的地址加入白名单，之后可能仍然失败。

注意事项

除非已经获得 payment gateway 和业务方的明确授权，否则不要直接对真实支付端点进行高并发测试。更安全的方式是使用沙箱、支付模拟器或内部 mock 服务，并把性能测试重点放在自己的下单系统上。

浏览器兼容 headers 只能影响部分 HTTP header 的生成方式，无法解决 IP 白名单、WAF、TLS、mTLS、地区限制或会话关联问题。把云端 headers 复制到本机后仍然可以成功，也进一步说明差异很可能不在 headers。

建议按以下顺序排查：

  1. 获取完整错误码、响应体和 jmeter.log。
  2. 确认云端公网出口 IP，并检查白名单、WAF 和地区限制。
  3. 检查 TLS 握手和客户端证书。
  4. 检查 Cookie、CSRF Token、支付 token、签名及唯一业务数据。
  5. 从实际负载节点发起最小化的沙箱请求。
  6. 携带失败时间、出口 IP 和 request ID 联系 gateway，查询服务端拦截记录。

拿到第一个失败请求的具体状态码和异常堆栈后，才能判断问题发生在网络层、TLS 层、HTTP 层还是支付业务层。

备注：内容仅供参考。