从数据包捕获文件（pcap）中，在 TCP 握手期间观察以下内容
客户端向服务器发送 SYN 请求， 服务器以 SYN 数据包而不是 SYN+ACK 响应， 客户端以乱序数据包消息响应， 服务器终止与 RST 数据包的 TCP 握手
这是随机发生的，并非总是如此。 TCP 连接确实建立了，但有时连接建立失败并出现上述观察到的模式。
客户端托管在 AWS 中，而服务器是 CDN 网络
【问题讨论】：
如果套接字在 TIME_WAIT 上并且附加了新的 syn，内核将检查 SYN 的 SEQ 编号是否大于或小于为此套接字接收的最后一个 SEQ。
您可以查看此帖子/答案：https://serverfault.com/questions/297134/server-not-sending-a-syn-ack-packet-in-response-to-a-syn-packet
通常，如果一个 SYN 被发送并且另一个 SYN 在没有 ACK 的情况下被接收，则通常只是线路上的 ACK 丢失（尤其是在您的情况下）。当您从 A（客户端）到 B（服务器）的路由很短并且您从服务器到客户端的数据包路径特别长并且穿越可能无法保证数据包在更远距离上可靠传输的网络时，这种情况很普遍。如果您在线路上丢失了 ACK，您往往会发现来自客户端的 RST 消息，本质上是要求服务器重新启动。
另一种可能性是某种请求。通常，客户端将使用 len: xx 推送 PSH、ACK 信号，其中 x 是请求长度的数字。服务器通常会以 ACK 响应，告诉客户端它已收到其请求并且服务器正在处理（此 ACK 通常为空。）然后它将向客户端推送一个 PSH、ACK - len: xx 数据包以让客户端知道它已经接受了它的请求，这个数据包将包含信息。
使用 wireshark 监控这些信息（非恶意）通常有助于了解您的情况，只要确保学习（如果您还不知道）如何过滤您的数据包，否则您将有很多要挖掘的信息（通常）。
我还会尝试向有问题的服务器发送一个数据包，您可以跟踪它以查看它是否被引导离开人迹罕至的路径。如果您的数据包正在跳过循环以到达目的地，那么它极有可能在返回的路上做同样的事情。 如果您愿意，可以尝试使用 tcpdump(linux) 或 tracert(windows)。
希望这会有所帮助！
【讨论】：