Avoid Cloud TCP KeepAlive Pitfalls with Simple Linux Kernel Tweaks

1. Introduction

Enabling SO_KEEPALIVE on a TCP socket does not guarantee timely detection of dead connections because Linux defaults net.ipv4.tcp_keepalive_time to 7200 seconds. Applications often need a shorter idle period or an additional heartbeat layer.

2. Netty keep‑alive tuning

Recent Netty releases allow the keep‑alive parameters to be set directly in the bootstrap configuration. The following examples assume a Linux epoll transport and a recent JDK/Netty version.

// Client (Linux epoll)
EventLoopGroup group = new EpollEventLoopGroup();
Bootstrap b = new Bootstrap();
b.group(group)
 .channel(EpollSocketChannel.class)
 .option(EpollChannelOption.SO_KEEPALIVE, true)
 .option(ChannelOption.CONNECT_TIMEOUT_MILLIS, 5000)
 .option(EpollChannelOption.TCP_KEEPIDLE, 30)   // start probing after 30 s idle
 .option(EpollChannelOption.TCP_KEEPINTVL, 10) // probe interval 10 s
 .option(EpollChannelOption.TCP_KEEPCNT, 3);   // abort after 3 failed probes

// Server (Linux epoll)
ServerBootstrap sb = new ServerBootstrap();
sb.group(bossGroup, workerGroup)
 .channel(EpollServerSocketChannel.class)
 .childOption(ChannelOption.TCP_NODELAY, true)
 .option(ChannelOption.SO_BACKLOG, 1024)
 .childOption(ChannelOption.SO_KEEPALIVE, true)
 .childOption(EpollChannelOption.TCP_KEEPIDLE, 60)
 .childOption(EpollChannelOption.TCP_KEEPINTVL, 10)
 .childOption(EpollChannelOption.TCP_KEEPCNT, 3);

This approach works only on recent JDK and Netty releases; older JDK 8 projects cannot apply these options.

3. Cloud‑environment pitfall: security‑group connection tracking

During a stress test of an IoT service deployed on a mobile cloud, simulated clients used the default 10‑minute heartbeat interval. The cloud security‑group’s connection‑tracking timeout was shorter, causing the security‑group to send RST packets and terminate the connections. When the number of concurrent connections approached 200 k, the connection‑tracking engine itself became a bottleneck.

The issue matches the analysis in “AWS connection‑timeout root‑cause analysis” (https://plantegg.github.io/2026/04/15/AWS-HikariCP-%E8%BF%9E%E6%8E%A5%E8%B6%85%E6%97%B6%E6%A0%B9%E5%9B%A0%E5%88%86%E6%9E%90/), which describes similar behavior where errors are swallowed instead of propagating RST.

4. Follow‑up troubleshooting steps

When an unexpected RST or stalled connection appears, first verify whether a gateway, security‑group, or load balancer sits in the path. If such a device exists, request an increase of its timeout settings. Note that load‑balancer timeout adjustments are typically HTTP‑specific; for long‑lived IoT connections they often require a support ticket.

5. Universal fix: configure Linux kernel keep‑alive parameters

Modifying the kernel parameters on the VM eliminates the cloud‑network‑induced drops without relying on application‑level settings.

cat >> /etc/sysctl.conf << 'EOF'
net.ipv4.tcp_keepalive_time = 120   # seconds of idle before probing
net.ipv4.tcp_keepalive_intvl = 30   # seconds between probes
net.ipv4.tcp_keepalive_probes = 5   # number of failed probes before abort
EOF

After reloading the sysctl configuration, connections are closed within a few minutes of a real failure, and the additional network overhead is negligible inside a data‑center or VPC.