沙箱支付时 proxy server 收到无效响应

结论

这类提示通常说明支付请求已经到达代理服务器，但代理没有从上游支付服务、网关或业务应用收到有效的 HTTP 响应。常见的状态码是 502 Bad Gateway。上游连接超时、TLS 握手失败、响应格式异常或沙箱服务临时故障，也可能引发同类问题。

排查时，先确定故障出现在链路的哪一段，再检查代理日志、上游服务状态、请求参数和网络配置。向服务方提交问题报告时，应附上请求时间、沙箱环境、接口地址、HTTP 状态码、请求 ID、脱敏后的请求参数和完整错误响应。不要提交密钥、签名私钥或完整的支付凭证。

常见原因

上游服务不可用

沙箱支付服务可能正在维护、重启或发生临时故障。代理服务器虽然收到了请求，但连接上游时被拒绝或重置，也可能没有收到完整响应。

接口地址或环境配置错误

重点检查生产环境与沙箱环境是否混用，例如：

• 请求发到了错误的域名或端口。
• 沙箱账号调用了生产接口。
• 回调地址指向内网、测试域名或无法访问的端口。
• 代理配置中的 upstream 地址已经变更。
• DNS 把域名解析到了错误的服务器。

代理与上游之间超时

如果支付接口的处理时间超过代理服务器的等待时间，代理可能直接返回错误。相关配置通常包括：

proxy_connect_timeout 10s;
proxy_send_timeout 30s;
proxy_read_timeout 60s;

不要仅靠不断增大超时时间来处理。还要查明上游响应缓慢的原因，例如数据库阻塞、外部接口超时或线程池耗尽。

TLS 或证书问题

代理通过 HTTPS 访问上游时，以下问题可能导致握手失败：

• 上游证书过期。
• 证书链不完整。
• TLS 版本或加密套件不兼容。
• 缺少 SNI 配置。
• 服务器时间不正确，导致证书校验失败。

上游返回了无效响应

代理要求上游返回符合 HTTP 协议的响应。如果上游提前关闭连接、返回损坏的响应头、截断响应体，或者向 HTTP 端口发送非 HTTP 数据，代理会将其视为无效响应。

请求参数或签名异常

参数有误时，支付接口通常会返回明确的业务错误。不过，部分沙箱系统对异常路径处理不完善，也可能返回代理错误。需要检查：

• 是否缺少必填参数。
• Content-Type 是否正确。
• 字符编码是否为 UTF-8。
• 金额单位和格式是否符合接口要求。
• 签名原文、字段顺序、时间戳和密钥环境是否一致。
• 请求体是否在代理转发过程中发生了变化。

定位步骤

1. 记录原始响应

先保存 HTTP 状态码、响应头和响应体，不要只保留浏览器显示的错误页面。可以使用 curl 查看完整交互：

curl -v \
  -X POST 'https://sandbox.example.com/payment' \
  -H 'Content-Type: application/json' \
  -H 'X-Request-ID: payment-test-20260913-001' \
  --data '{
    "order_id": "TEST_ORDER_001",
    "amount": 100
  }'

如果响应头中有 Request-ID、Trace-ID、Server 或网关标识，也要一并记录。示例中的域名、接口路径和参数仅用于说明，使用时应替换为实际的沙箱配置。

2. 判断故障范围

用同一组脱敏参数重复请求，并比较结果：

• 所有请求都失败：先检查服务状态、域名、网络和代理配置。
• 只有特定订单失败：重点检查请求参数、签名和订单状态。
• 偶发失败：重点检查超时、连接池、负载均衡节点和上游稳定性。
• 本机直连成功，经过代理失败：重点检查代理转发规则。
• 直连和代理都失败：问题更可能出在上游服务或请求本身。

重试时应更换测试订单号，或者先确认接口是否支持幂等，以免重复创建支付单。

3. 检查代理日志

如果代理由自己维护，应查看错误发生时间附近的 access log 和 error log。以 Nginx 为例，重点关注：

upstream timed out
connect() failed
connection refused
upstream prematurely closed connection
no live upstreams
SSL_do_handshake() failed
invalid header

还要对照以下数据：

• 客户端状态码。
• upstream_status。
• 请求总耗时。
• 上游响应耗时。
• 实际命中的 upstream 地址。
• 请求 ID 或链路追踪 ID。

可以配置包含上游信息的日志格式：

log_format upstream_log
    '$remote_addr [$time_local] "$request" '
    'status=$status upstream_addr=$upstream_addr '
    'upstream_status=$upstream_status '
    'request_time=$request_time '
    'upstream_response_time=$upstream_response_time '
    'request_id=$request_id';

修改生产代理配置前，应先验证语法，同时确认日志不会记录支付敏感信息。

4. 检查上游连通性

应从代理服务器所在的网络测试 DNS、端口和 TLS，不要只在开发电脑上测试：

curl -v --connect-timeout 10 https://sandbox.example.com/health

检查证书和 TLS 握手：

openssl s_client \
  -connect sandbox.example.com:443 \
  -servername sandbox.example.com

如果支付服务没有公开健康检查接口，不要自行猜测 /health 路径。应使用服务方提供的检测地址，或者直接测试实际 API。

5. 核对代理转发配置

确认协议、主机名、端口、SNI 和请求头是否正确。HTTPS upstream 的常见配置如下：

location /payment/ {
    proxy_pass https://sandbox_backend;
    proxy_ssl_server_name on;
    proxy_set_header Host sandbox.example.com;
    proxy_set_header X-Request-ID $request_id;

    proxy_connect_timeout 10s;
    proxy_send_timeout 30s;
    proxy_read_timeout 60s;
}

这只是通用示例。Host、超时时间和路径改写方式必须符合实际支付接口的要求，不能直接照搬。

6. 对照上游应用日志

如果 upstream 是自己的业务服务，可以用请求 ID 串联代理日志和应用日志：

• 代理日志中有请求，应用日志中没有：检查网络、负载均衡、TLS 和端口配置。
• 应用收到了请求，但没有完成响应：检查异常堆栈、超时和资源使用情况。
• 应用正常返回，代理仍然报错：检查响应头、响应长度、连接关闭方式和代理协议。
• 应用调用第三方沙箱时超时：保存第三方请求 ID，再联系支付服务方排查。

处理建议

如果确认是沙箱服务短暂异常，可以在接口支持幂等的前提下进行有限次数的重试，并采用退避策略。例如：

async function requestWithRetry(sendRequest, maxAttempts = 3) {
  let lastError;

  for (let attempt = 1; attempt <= maxAttempts; attempt += 1) {
    try {
      return await sendRequest();
    } catch (error) {
      lastError = error;

      if (attempt === maxAttempts) {
        break;
      }

      const delayMs = 500 * 2 ** (attempt - 1);
      await new Promise((resolve) => setTimeout(resolve, delayMs));
    }
  }

  throw lastError;
}

实际使用时，只应重试网络错误以及 502、503、504 等可能自行恢复的故障。参数错误、签名错误或明确的业务拒绝不应反复重试。支付请求还应携带服务方支持的幂等键，避免产生重复订单或重复扣款。

提交问题报告时需要附带的信息

问题报告应包括：

• 问题发生的准确时间和时区，例如 2026-09-13 14:32:18 UTC+8。
• 明确注明使用的是沙箱环境。
• 请求方法、接口域名和路径。
• HTTP 状态码、响应头和完整错误响应。
• 支付平台返回的请求 ID、Trace ID 或错误编号。
• 脱敏后的请求参数。
• 订单号或商户请求号。如果属于敏感信息，可以只保留末尾几位。
• 问题是否必现，以及首次和最近一次发生的时间。
• 重试次数、重试间隔和每次结果。
• 客户端出口 IP。仅在服务方需要核对白名单时提供。
• 代理服务器类型和相关版本。
• 相关的代理错误日志和应用日志。
• 直连与经过代理的测试结果。
• 最近是否修改过域名、证书、网络、代理或支付配置。

可以按以下格式整理：

环境：Sandbox
发生时间：2026-09-13 14:32:18 UTC+8
请求方法：POST
接口地址：https://sandbox.example.com/payment
HTTP 状态码：502
Request-ID：xxxxxxxx
问题频率：连续 3 次均失败
直连测试：失败/成功/未测试
代理测试：失败
最近配置变更：无/具体变更内容
错误响应：完整响应内容
相关日志：脱敏后的代理日志和应用日志

安全注意事项

问题报告中不要包含：

• API Secret。
• 私钥或证书私钥。
• 完整的签名原文，以及任何可用于重放请求的数据。
• 用户密码、验证码或访问令牌。
• 完整银行卡号、安全码和身份证件号码。
• 未脱敏的个人信息。
• 含有敏感参数的完整浏览器截图或网络抓包。

如需提供抓包、请求体或日志，应先完成脱敏，再通过支付服务方指定的安全渠道提交。不要通过公开工单、论坛或即时通讯群传输支付密钥和完整交易凭证。

备注：内容仅供参考。