网关日志偶尔记一条 502，上游日志里却找不到这次请求，该先对齐超时还是先查服务发现？

结论先说：网关日志偶尔记一条 502、上游访问日志里却查不到这次请求，重启网关又能顶一阵，常见方向不是后端代码崩了，而是网关到上游的长连接被两边超时各掐一刀。上游的空闲超时比网关短，连接由上游先关，网关却还把它当活连接放进池子复用，请求就落在一条已经半关的 socket 上。这类 502 的量少、分散、和流量高峰关系不大，重启只是把连接池清零，能缓解一阵，但不解决超时错配。按 2026 年常见自建网关加长连接池架构，这类问题在交付验收和上线初期出现频率不低，也容易被误判成后端不稳而互相推诿。

为什么 502 只零星出现，重启后能好一阵

网关与上游之间维持长连接池，本意是省掉每次请求的 TCP 握手开销，在上游实例只有两三台、QPS 又比较低的时候收益比较明显。但长连接有寿命：上游服务端有一套空闲超时，网关侧也有一套空闲超时，两套时间各配各的，就会出现网关以为这条连接还活着、上游已经把它关掉的窗口。重启之所以有效，是因为它把网关侧连接池整体清空，短时间内所有请求都走新建连接，自然少踩半关状态的连接；等连接重新积累并老化到超时点，问题又回来。重启能好一阵，是超时错配的一个信号，不是代码层有状态残留的证据。

• 量级特征：经验区间多在每天几次到几十次，占同接口总量千分之几以内，容易在监控大盘上被平均值抹平。
• 时间特征：低峰、间歇流量、夜间更明显，因为连接空闲得久，更容易老化到超时点。
• 分布特征：往往集中在某一台上游实例，或某几条长连接上，而不是全实例平均分布。
• 反例：如果 502 出现在流量爬坡瞬间，且量级随 QPS 同步上涨，更可能是上游进程重启、端口耗尽或健康检查误判，处理方向不同。

先把 502 拆成三段，再决定动哪一层

排查 502 时，不建议一上来就改参数。先按链路把它拆成三段，每段只问一个问题：这一次断开是谁先发起的。502 是网关给出的上游不可用结论，而不可用的原因可能发生在网关之前、网关与上游之间、或上游自身，三段的证据不同。

1. 第一段，客户端到网关：看网关自身连接数是否打满、是否被限流或熔断触发。证据是网关访问日志里请求是否到达，以及网关 worker 连接数曲线。
2. 第二段，网关到上游：这是 keep-alive 错配的高发区。证据是上游访问日志里有没有对应请求记录。网关记了 502 而上游日志里查不到这条请求，基本可以先锁定在这一段。
3. 第三段，上游自身：进程重启、健康检查摘除、容器漂移导致 IP 变化、端口 backlog 溢出，都可能表现成 502。证据是上游进程启动时间、就绪探针历史、实例列表变更记录。

三段对齐之后再动手：第二段的问题改超时与连接池参数，第三段的问题改探针与发布节奏，第一段的问题才轮到扩容或限流。少走这一步，常见代价是改了一堆参数、502 照旧，排查周期从半天拉长到几天。

参数怎么配才算对上：一组可核对的对比

核心原则只有一条：让关闭连接的主动权落在网关这一侧，而不是上游先关、网关后知。也就是网关的空闲保持时间要明显长于上游服务端的 keep-alive 超时，这样连接通常由网关主动回收，减少复用到半关连接的机会。以常见 Nginx 为例，upstream 块里的 keepalive 是每个 worker 保持的空闲连接数，不是时间；keepalive_timeout 才是时间维度，两者经常被混为一谈。

• 上游 keep-alive 空闲超时：常见落在 5 秒到 75 秒这个区间，具体看所用容器或框架的默认值。交付前建议先按官方文档核对实际生效值，不要凭印象。
• 网关侧空闲超时：经验做法是比上游长 15 到 30 秒，留出探测与回收余量，而不是相等。
• 读超时：应明显大于业务接口的 P99 耗时，经验区间在 2 到 3 倍，否则慢接口会被误判成上游不可用，制造另一批假 502。
• 健康检查间隔：不必为了掩盖 502 而调到极短。间隔过短会放大上游压力，且对半关连接帮助有限。

可核对对比：方案 A 把网关空闲超时调到比上游短，结果是网关频繁主动断开、握手次数上升，吞吐略降，但半关连接窗口较小；方案 B 把网关空闲超时调到远长于上游，握手省了，但半关连接窗口被拉长，502 更容易冒出来。按 2026 年常见交付经验，配置对齐变更窗口通常 30 到 60 分钟，观察期 1 到 2 天；若靠抓包走安全审批，常见区间 2 到 5 个工作日。省下的握手开销，通常换不回一次线上 502 的排查成本。

交付现场怎么落：约束条件、做法和代价

在项目里常见的情况是：约束条件比较硬，客户生产环境不允许白天重启网关，日志只保留 7 天左右，抓包申请要走到安全审批，一轮下来常见 2 到 5 个工作日。做法上，先把上游实例的 keep-alive 超时统一调低、把网关空闲超时抬高，形成单向对齐，再错峰 reload；同时把 502 按实例维度打成独立看板，替代抓包作为主要证据。这样做的原因是，现场往往拿不到完整抓包，实例维度的曲线更容易和发布、探针、连接数变化对上。

结果上，502 常见从每天几十次的区间降到个位数区间，但过程中如果 reload 时机没和客户值班同步，可能出现十几秒断连，被记一次小事故。这类事在以项目交付为主的团队里反复出现，经验是：配置对齐本身不难，难的是把变更窗口和证据链一起交付给对方。经验区间上，先做看板再加错峰变更，通常比直接改参数更容易在验收会上说清楚。

适用场景与不适用边界

适合处理的场景：自建或可控网关、上游是多实例常驻服务、网关与上游之间维持长连接池、流量偏稀疏且 502 呈零星分布。这几条同时成立时，超时对齐的收益比较直接。

不必上的场景：上游是无状态短连接调用、函数计算类按请求拉起的环境，或者 502 量级与流量曲线高度同步，那更偏向容量问题而不是连接问题。如果一次请求链路里没有可复用的长连接，调空闲超时就是在改一个不存在的开关，除了增加维护负担，效果有限。另外，如果上游日志能查到对应请求，优先查上游自身和实例变更，不要只盯网关超时。

几个容易踩的坑

• 只靠重试兜底：对查询类请求可以缓解，但对下单、支付这类非幂等操作，自动重试可能把一次失败变成两次扣款。
• 直接关掉长连接：短期 502 可能减少，代价是握手次数上升、低配机器上端口与 CPU 压力变大。
• 只在其中一台网关改配置：多网关部署时配置不一致，问题会变成概率性复现，更难定位。
• 把健康检查间隔调到几秒一次：看似更灵敏，实际是给上游加了一份稳定负载，对半关连接帮助有限。

常见问题

重启后能好半天，是不是说明代码有内存泄漏？

不一定。重启清掉的是网关侧长连接池，内存泄漏清的是堆内存；若重启后内存曲线没有明显回落，优先怀疑连接老化，而不是先改代码。

502 只在半夜低峰出现，是上游在定时重启吗？

有可能，但更常见是低峰连接空闲时间长、更容易撞上超时点。先核对上游进程启动时间和实例变更记录，再判断是不是超时错配。

加自动重试是不是就能绕过 502？

只适合查询类且幂等的请求。写操作重试前要先有幂等键，否则一次 502 可能变成两笔业务，重试反而放大问题。

上游是容器，Pod 重建会不会也表现成 502？

会，属于链路第三段。服务发现或 DNS 缓存未及时更新时，网关可能把请求打到已销毁的地址上，特征是新旧实例交替期集中出现。

如果手上正有这类零星 502，建议先做一件事：把最近一周的 502 按上游实例和时间点拉出来，确认网关记了 502 时，上游日志里是否查得到这条请求。查不到就先对齐超时，查得到就去查上游自身和实例变更。这套顺序适用于长连接池加常驻上游的架构，短连接与按需拉起的场景不适用。