问题现象
和客户对接时，我们的 Java 服务请求客户的接口时不时会出现 org.springframework.web.client.ResourceAccessException: I/O error on POST request for "https://xxx.com.cn/sms/writeBack/sysDownSendInfo": Failed to connect to xxx.com.cn/xxx.251.33.151:443 的报错。
经过和客户沟通，当我们的 Java 请求他们的接口报错时，客户的 Nginx Access Log，并没有看到相关的请求日志记录。
那就有可能我们 Java 服务的请求，在客户 Nginx 服务器的 Linux 系统 TCP 层就被丢弃或者拒绝了。
排查过程
1、我们这边 Java 服务部署在了 4 台云服务器 ECS 上，服务请求外部接口时是通过 NAT 网关的 SNAT 实现的。
2、排查发现，只有其中两台服务器 C 和 D 的 Java 服务请求客户的接口会出现异常。但是 4 台服务器 LInux 系统和 Java 服务的配置都是一样的。
3、经过排除一系列的因素（服务器 LInux 系统的 iptables 配置、Java 服务的配置、tcpdump 抓包分析等）后，怀疑是客户的 Nginx 服务器所在的 Linux 系统开启了 net.ipv4.tcp_tw_recycle = 1 参数。
4、经过和客户沟通，让他们在 Nginx 服务器所在的 Linux 系统执行这个命令 sysctl -a | egrep "net.ipv4.tcp_timestamps|net.ipv4.tcp_tw_recycle|net.ipv4.tcp_tw_reuse"看下输出结果，发现他们确实是开启了 net.ipv4.tcp_tw_recycle = 1 参数。
问题原因
1、Linux 系统相关内核网络参数说明：
-
net.ipv4.ip_local_port_range = 32768 60999：表示 TCP/UDP 协议允许使用的本地端口号范围为 32768 ~ 60999 。 -
net.ipv4.tcp_timestamps = 1：开启TCP时间戳，以一种比重发超时更精确的方法来启用对 RTT 的计算，为实现更好的性能应该启用这个选项。 -
net.ipv4.tcp_tw_recycle = 1：开启 TCP 连接中 TIME-WAIT 的 sockets 快速回收功能。需要注意的是，该机制也依赖时间戳选项，系统默认开启 tcp_timestamps 机制（net.ipv4.tcp_timestamps = 1），而当系统中的 tcp_timestamps 和 tcp_tw_recycle 机制同时开启时，会激活 TCP 的一种行为，即缓存每个连接最新的时间戳，若后续的请求中时间戳小于缓存的时间戳时，该请求会被视为无效，导致数据包会被丢弃。 -
五元组（源 IP 地址，源端口，目的 IP 地址，目的端口，传输层协议）：确定一个连接，在我们这个问题场景下源 IP 地址，目的 IP 地址，目的端口，传输层协议都是固定的，只有源端口是变化的。因源端口范围为 32768 ~ 60999（net.ipv4.ip_local_port_range = 32768 60999），会存在源端口重复的可能）
2、我们这边的 Java 服务都是通过 NAT 网关的 SNAT 出去请求外部接口的，这些 Java 服务所在的不同 ECS 服务器的请求经过 NAT 网关 SNAT 的转换，源 IP 都是一样的，所以可能被对方 Nginx 服务器认为是同一个连接。若这些 ECS 的时间不完全一致，对于后端服务器来说，会发生时间戳错乱的情况，因此会导致请求对方 Nginx 服务器的数据包丢失（因为对方 Nginx 服务器开启了 net.ipv4.tcp_tw_recycle = 1 ），所以会出现请求超时的问题。
解决办法
1、客户端：修改我们的 ECS 服务器的 Linux 系统参数 net.ipv4.tcp_timestamps 参数为 0（net.ipv4.tcp_timestamps = 0）。
或者
2、服务器端：客户修改他们的 Nginx 服务器的 Linux 系统参数 net.ipv4.tcp_tw_recycle 参数为 0（net.ipv4.tcp_tw_recycle = 0）。
或者
3、4 台 ECS 服务器分别绑定不同的出口 IP（通过多个不同 IP 的 NAT 网关或者把不同的 IP 分别绑定到 ECS 服务器上）
参考：
- Linux实例常用内核网络参数介绍与常见问题处理：https://help.aliyun.com/knowledge_detail/41334.html
