网关返回 502，上游说请求正常：怎样对齐两边的一次调用

网关返回 502，而上游支持人员说“我们这边成功了”，先不要争论哪边的日志可信。两边可能在看同一业务请求的不同重试，也可能一个记录生成成功，另一个记录响应转发失败。要排查的是哪一次尝试、在哪一段、发生了什么。

这篇提供一份三层调用对照样本。样本全部为合成记录，不包含真实接口、客户或密钥；它不是 New API 内置日志的字段说明。字段缺失时要记为未知，不能猜一个上游 ID 补齐。

把业务请求与调用尝试分开

同一次用户操作，可能经历第一次调用失败、第二次调用成功。给业务操作一个 operation_id，给每次实际发送一个 attempt_id，再单独保留网关和上游各自返回的标识。三类标识解决的问题不同，不要求它们字符串相等。

RFC 9110 将 502 定义为代理或网关收到无效上游响应时的状态；它本身不能证明模型没有执行，也不能证明上游没有计费。需要一般错误分流时先看API 5xx 的处理，这里专门补定位证据。

层次	样本记录	能证明的事
客户端	op-demo / try-1 / HTTP 502	客户端没有拿到正常 HTTP 响应
网关	gw-demo-1 / 接收后读响应异常	网关这一尝试的观察
上游	up-demo-a / 返回 200	指定上游尝试产生过响应
重试	try-2 / up-demo-b / HTTP 200	是另一次尝试，不能覆盖第一次失败

样本里 try-1 同时存在上游成功和客户端失败，并不矛盾；传输过程还有网关到客户端这一段。日志只写“成功”两个字，恰恰会把这种差异藏起来。

先校时，再连记录

第一步固定时区，建议导出带偏移的时间，例如 2026-10-23T09:00:00+08:00。同时记录时钟来源和已知偏差。两台机器相差两秒时，不能仅凭时间先后断言事件因果；单机耗时优先取单调时钟测量值，不用两个墙上时间相减代替。

第二步按 operation_id + attempt_id 合并客户端与网关记录，再核对上游返回的请求标识。若平台没有暴露该标识，就把发往哪个渠道、时间范围、HTTP 状态和脱敏错误片段一起提交。时间接近、模型相同，只能作为候选匹配，不能自动确认同一请求。

第三步核对流式输出的完成状态。收到响应头、收到第一个数据片段、收到协议规定的终止标志、客户端成功写入最终结果，分别是不同事件。样本中若只有 HTTP 200，没有终止记录，应标为“完成情况未知”，不能按全文交付成功处理。

对照表怎么填

下载 CSV 后，保留原始记录只读，另建一张工作表。每条尝试占一行，填接收时刻、上游发出时刻、首个响应时刻、最后观察时刻、客户端结果；缺字段直接填“未采集”。额外记录版本和渠道别名，别把上游账号、完整地址和 Authorization Header 带给无关人员。

如果系统已接 W3C Trace Context，规范中的 trace ID 用于串联一次分布式跟踪，parent ID 表示调用方传播的上下文。不要把已有 traceparent 随意截短成自己的业务编号，也不要假定所有上游都会原样传回它。业务编号与追踪上下文可并存，映射关系由自己的应用留存。

交给支持人员的一段结论

可以写：“合成演练中 try-1 的客户端收到 502；网关记录上游标识 up-demo-a，但缺少完整终止事件。try-2 成功，属于独立尝试。请核查 try-1 在指定时间范围内的响应终止情况。”这样的表述把已知和未知分开，避免把一次重试成功写成整个链路从未出错。

实际排查先导出一小段故障窗口，找到能完整连起来的样本，再扩大范围。不要为了补证据开启无限量请求正文日志；先看能否用标识、状态、长度和时间定位。自建网关的起点见OneAPI/NewAPI 接入指南。

常见问题

没有上游 ID 就完全查不了吗？ 可以按时间范围和渠道请求协助，但关联置信度较低，应明确它是候选，不冒充精确对应。

重试成功能删除原失败记录吗？ 不建议。原失败涉及用户体验、重复调用和成本，保留尝试层记录，另给业务操作层最终状态。

这份 CSV 是真实 New API 导出格式吗？ 不是。它是独立对照模板，实际字段要按安装版本和可获得日志建立映射。

核对依据

核对日：2026-10-23。RFC 9110 的 502 定义支持状态语义；W3C Trace Context支持追踪上下文字段含义。对照表、合成时间线与排查顺序为本文设计，没有对生产 API 发起请求。