我真的只需要帮助来理解下面的图片，但我会提供背景信息。
我们有一个应用程序配置为在端口 8080 上使用代理，并且需要 Internet 访问。在一天中的随机时间，该应用程序无法连接并死机。我们正在尝试找出原因。我们已经排除了 FW 和代理 URL 规则（它在工作时总是命中相同的 URL，但无论如何都会失败）。我认为问题与网络有关，与代理本身的性能问题有关。为了查明原因，我一直在发生这种情况时进行网络捕获。
如果您查看下图，您会发现这是删除了 IP 详细信息的片段。源为“42”的第一行是客户端计算机通过代理 (IP 35) 在端口 8080 上发出 TLS 请求。注意：它通常有效并请求相同的 URL/IP，但这是它失败的一次。底部窗口是第一行绿线的详细信息。
突出显示的部分“下一个序列号”与 35 返回的最后一个数据包的 ACK 相匹配（倒数第二行）。这实际上是 35 回复客户端，表明它已收到发送给它的所有数据（这意味着设备已启动，因为它确认已收到数据（意味着没有 FW 或网络问题））。请注意，它没有发回任何数据。此后，客户端立即发出 TCP RST。这是我的解释，但我希望有人能验证一下，因为我的 TCP 技能有点生疏。
客户端正在向代理发送某种形式的请求，但由于某种原因，代理没有响应（在应用程序层）。由于代理确实使用 TCP ACK 回复，这意味着在网络层一切正常。这意味着当数据通过网络堆栈传递到代理本身时，是代理断开了连接。为什么会这样我还不知道，但我正在寻找澄清，以便我可以与代理团队交谈并告诉他们需要调查此事（他们认为这不是代理的问题）。
支持我的观点的其他证据是，您在图像中看到的 RST 之前的前 4 行重复多次。同样，这意味着客户端正在重新发送它所拥有的任何请求，但从未得到响应；然后它最终放弃并发出重置。
代理前面显然有一个负载均衡器，代理实际上是几台机器。我感觉其中一台在后端有问题，而 LB 不会从池中移除节点，因此可能会将数据发送到黑洞。
我正在寻求第二种意见，根据捕获的情况，上面我所作的总结是否准确？
答案1
此后，客户端立即发出 TCP RST
不是立即。客户端在服务器发送最后一个 ACK 后 30 秒发送 RST。
... 您在图片中看到的 RST 之前的前 4 行重复了很多次
这些不是相同的行。它们的 ACK 值不同。
我的解释是，客户端正在发送具有更大有效负载的请求（因此服务器会发送多个 ACK 来确认这一点），然后期望代理发回响应。 30 秒后没有响应，客户端将放弃并使用 RST 关闭连接。
目前还不清楚为什么代理没有发送响应。这可能是代理的问题。但也可能是上游服务器的问题，服务器只是将问题传播给客户端。
但请注意，解释可能是错误的。没有提供太多上下文和数据包捕获，因此这更像是一种有根据的猜测。