问题描述
在 Linux 环境中运行的 Java 应用，经常使用 Lettuce、Netty 等组件与 Redis 建立长连接。正常情况下，这类连接可以长期保持并重复使用，但当底层网络发生短暂抖动、连接路径变化或服务端连接被中断时，客户端可能遇到一种比较典型的现象：网络异常本身持续时间很短，但 Java 应用需要数分钟甚至更长时间才能恢复 Redis 连接。
出现这种情况时，一个容易被忽略的问题是：应用虽然配置了 TCP_USER_TIMEOUT，但该参数可能并没有真正作用到底层 Linux TCP Socket。
对于基于 Netty 的 Java 应用，需要特别关注 Linux Native Transport 的使用情况。如果应用希望通过 Netty 使用 Linux 特有的 Socket 选项，例如 TCP_USER_TIMEOUT，则需要确认应用正确引入并实际使用：io.netty:netty-transport-native-epoll, 如果缺少相应的 Native Epoll Transport，应用层设置的 TCP_USER_TIMEOUT 可能无法按预期作用于底层 TCP 连接。
最终可能出现以下现象：
短暂网络异常 → TCP 连接进入异常状态 → TCP_USER_TIMEOUT 未按预期生效 → 操作系统继续执行 TCP 重传 → 应用不能及时识别失效连接 → Redis 连接重建延迟 → 应用层持续出现连接超时。
问题解答
网络恢复了，为什么连接还会超时？
先看结论：网络恢复，不代表之前的 TCP 长连接一定能恢复。
如果客户端发出的数据持续收不到 ACK，Linux 会重传，而不是立即关闭 Socket。客户端可能因此延迟发现连接已经失效。
部分 Linux 默认设置下，失败检测可能超过 13 分钟；具体时间取决于内核配置和网络状态。下面是其中一种可能的故障链路：
不是每次网络抖动都会让旧连接失效。排查时，需要分开看 网络异常、服务端状态和客户端恢复时间：应用超时持续多久，并不等于 Redis 服务端故障多久。
命令超时和 TCP_USER_TIMEOUT：管的不是同一件事
一个等待 Redis 响应，另一个关注 TCP 数据能否送达。缩短命令超时，不一定会让失效 Socket 更快关闭。
| 对比 | Command Timeout | TCP_USER_TIMEOUT |
| 关注点 | 等待 Redis 命令响应 | TCP 数据未被确认，或因零窗口无法发送 |
| 到期结果 | 命令超时，连接不一定关闭 | 内核关闭连接并报告超时 |
| 局限 | 不能保证及时关闭失效 Socket | 不保证空闲连接被及时发现，也不是命令响应超时 |
TCP_USER_TIMEOUT 以毫秒为单位，值为 0 时使用系统默认值。它不改变重传或 keepalive 探测的发送时机。
注意：空闲连接的检测还需结合 TCP keepalive 或应用心跳；命令超时和 TCP 超时应分别配置。
如何确认 TCP_USER_TIMEOUT 真正生效？
依赖存在、native 库加载成功，都只是前提，不代表参数已经写入 Redis 连接使用的 Socket。建议沿着下面的路径逐项核对：
01 检查依赖与加载
检查 Netty 版本、CPU 架构和 native 库是否匹配。官方 Linux native 包依赖 glibc，musl 环境需特别处理。
02 确认实际 Transport
确认 Redis 连接使用 EpollEventLoopGroup 和 EpollSocketChannel，不要只看依赖树。加载失败不一定自动回退，还需查看运行日志。
03 验证 Socket 选项
确认应用或客户端版本实际设置 EpollChannelOption.TCP_USER_TIMEOUT。在测试环境中，可用 strace 捕获连接创建时成功的 setsockopt，再结合 ss 或 tcpdump 观察重传。仅凭重传现象不能证明参数已生效。
04 验证重连
模拟数据包丢失，对照 Socket 关闭时间和 Lettuce 重连日志；确认自动重连已启用，并使用退避与抖动，避免同时重连加重服务端压力。
调整前留意：超时过小可能误杀仍可恢复的连接。
tcp_retries2是系统级参数，影响范围更广；调整前应评估其他应用，不能用它代替对单个 Socket 的验证。
参考资料
当在复杂的环境中面临问题，格物之道需：浊而静之徐清，安以动之徐生。 云中，恰是如此!
