Django+Gunicorn+Nginx(Kubernetes ingress)下POST接口随机502（连接重置）问题

Nginx打印的recv() failed (104: Connection reset by peer) while reading response header from upstream，并非Nginx主动拒收请求，而是Nginx等待上游返回响应头的过程中，被对端直接发送TCP RST包强制重置连接。结合已完成的测试（将POST接口响应调整为短长度后故障依旧复现），可以完全排除Nginx因响应大小限制触发拒收的可能性。

• 部署架构：K8s集群通过Nginx Ingress暴露服务，上游为Gunicorn托管的Django应用
• 差异化表现：同一API同时支持GET、POST请求，GET接口完成1000次压测无任何异常，POST接口仅压测300次就出现随机502
• 已排除干扰项：长响应触发Nginx拦截的假设不成立

按实际排查中出现的概率从高到低排序：

• Gunicorn worker连接队列过载
  POST请求通常携带请求体，Gunicorn需要完整读取整个请求体后，才会将请求转发给Django业务层处理，单请求的处理链路耗时比无请求体的GET请求高30%~50%。压测并发上升时，未被处理的请求会在worker的backlog队列堆积，一旦堆积量超过队列实际承载阈值，Gunicorn会直接通过RST包丢弃新进入的连接，不会返回标准的错误响应。很多人会误以为backlog配置值越高越稳，但实际worker处理POST请求的耗时上升时，队列的真实承载能力会比配置值低一个数量级，很容易在压测初期就触发溢出，故障出现的随机性极强。
• Nginx与Gunicorn的keepalive超时配置不匹配
  当Nginx开启了与上游Gunicorn的长连接复用时，若Gunicorn设置的keepalive_timeout值小于Nginx侧的上游连接空闲超时阈值，Gunicorn会先主动标记并关闭空闲连接。如果Nginx刚好把一个新的POST请求分配到这个已经被Gunicorn标记为关闭的连接上，Gunicorn收到请求时会直接发RST包重置连接。由于GET请求处理链路短，往往在连接被标记关闭前就完成了交互，因此很少触发这类随机故障。
• K8s节点conntrack表项老化误判
  K8s节点上的kube-proxy通过conntrack表记录所有TCP连接的转发规则，当POST请求携带请求体时，请求的传输和处理时长比GET请求更长，连接空闲时间更容易超过conntrack的表项老化阈值。一旦表项老化，kube-proxy会把新的请求转发给已经终止的旧Pod实例，旧Pod收到不属于自身的请求时，会直接发RST包重置连接，最终触发Nginx读取到连接重置的报错。
• Gunicorn请求解析阶段的无日志断连
  部分版本的Gunicorn在处理POST请求时，如果请求头长度超过--limit-request-line/--limit-request-fields的默认阈值，不会返回标准的414类错误，而是在解析阶段直接关闭连接、发送RST包，这类断连不会在Gunicorn的访问日志中留下记录，排查时很容易被忽略。

• 在上游Gunicorn Pod和Nginx Pod之间抓包，确认RST包的发送源是Gunicorn本身、还是节点上的kube-proxy，直接定位断连的责任主体
• 临时调整Gunicorn配置：将worker数量提升至节点CPU核心数的2倍、关闭worker的keepalive超时，对比502的出现频率变化
• 调整Nginx上游配置：暂时关闭与上游的长连接复用，每个请求新建独立TCP连接，观察随机502是否消失

内容的提问来源于stack exchange，提问作者jayaprakash k