Origin of the problem: wrong keepalived time setting

The server sets the http_keepalived time to 1s, and the client time is greater than the server. The client responds that some requests have no response. Checking the service log, some http requests are not received at all, but the client does record the sending, so I have to capture the packet to see where it is discarded

Server: python+flask+gunicorn Client: java

So what is the process of sending this RST? Is it related to the application layer? Or is it some characteristics of the container? I have read some posts and experiments and there are related records, but the root cause is still not clear. Welcome to discuss and advise!

Packet capture analysis:

After the server conn expires, close is called, and the client responds to ack. At this time, the server enters the fin_wait2 stage; then the server receives a new http request on this connection. The server directly responds to RST to the client, forcing the connection to be disconnected. In theory, this state can accept data packets;

Code analysis:
The process of receiving and processing each state is found in kernel tcp_rcv_state_process func. At this time, sock should not have RCV_SHUTDOWN at all. Receiving fin ack is to update socket SEND_SHUTDOWN;

case TCP_FIN_WAIT2:
        /* RFC 793 says to queue data in these states,
         * RFC 1122 says we MUST send a reset.
         * BSD 4.4 also does reset.
         */
        if (sk->sk_shutdown & RCV_SHUTDOWN) {
            if (TCP_SKB_CB(skb)->end_seq != TCP_SKB_CB(skb)->seq &&
                after(TCP_SKB_CB(skb)->end_seq - th->fin, tp->rcv_nxt)) {
                NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPABORTONDATA);
                tcp_reset(sk, skb);
                return 1;
            }
        }
        fallthrough;