Spring Boot Redis 2.7.3：LettuceConnectionFactory偶发连接拒绝及Channel疑问

配置信息 #

使用的LettuceConnectionFactory配置如下：

@Bean
@Primary
public ReactiveRedisConnectionFactory connectionFactory(@Value("${spring.redis.host}") String host,
                                                        @Value("${spring.redis.port}") int port) {
    return new LettuceConnectionFactory(host, port);
}

报错信息 #

频繁遇到连接拒绝错误：

java.net.ConnectException: finishConnect(..) failed: Connection refused

完整堆栈信息：

io.netty.channel.AbstractChannel$AnnotatedConnectException: finishConnect(..) failed: Connection refused: [HOST]/10.16.66.12:6379
Caused by: java.net.ConnectException: finishConnect(..) failed: Connection refused
    at io.netty.channel.unix.Errors.newConnectException0(Errors.java:155) ~[netty-transport-native-unix-common-4.1.75.Final.jar!/:4.1.75.Final]
    at io.netty.channel.unix.Errors.handleConnectErrno(Errors.java:128) ~[netty-transport-native-unix-common-4.1.75.Final.jar!/:4.1.75.Final]
    at io.netty.channel.unix.Socket.finishConnect(Socket.java:320) ~[netty-transport-native-unix-common-4.1.75.Final.jar!/:4.1.75.Final]
    at io.netty.channel.epoll.AbstractEpollChannel$AbstractEpollUnsafe.doFinishConnect(AbstractEpollChannel.java:710) ~[netty-transport-classes-epoll-4.1.75.Final.jar!/:4.1.75.Final]
    at io.netty.channel.epoll.AbstractEpollChannel$AbstractEpollUnsafe.finishConnect(AbstractEpollChannel.java:687) ~[netty-transport-classes-epoll-4.1.75.Final.jar!/:4.1.75.Final]
    at io.netty.channel.epoll.AbstractEpollChannel$AbstractEpollUnsafe.epollOutReady(AbstractEpollChannel.java:567) ~[netty-transport-classes-epoll-4.1.75.Final.jar!/:4.1.75.Final]
    at io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:470) ~[netty-transport-classes-epoll-4.1.75.Final.jar!/:4.1.75.Final]
    at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378) ~[netty-transport-classes-epoll-4.1.75.Final.jar!/:4.1.75.Final]
    at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986) ~[netty-common-4.1.75.Final.jar!/:4.1.75.Final]
    at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) ~[netty-common-4.1.75.Final.jar!/:4.1.75.Final]
    at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) ~[netty-common-4.1.75.Final.jar!/:4.1.75.Final]
    at java.lang.Thread.run(Unknown Source) ~[?:?]

重连日志 #

报错前存在大量重连尝试：

[channel=0xe9b4a42f, /172.16.0.213:37882 -> [HOST]/10.16.66.12:6379, last known addr=[HOST]/10.16.66.12:6379] Reconnect attempt 1, delay 1ms
[channel=0x43ff8ced, /172.16.0.213:37908 -> [HOST]/10.16.66.12:6379, last known addr=[HOST]/10.16.66.12:6379] Reconnect attempt 2, delay 2ms
[channel=0xe9b4a42f, /172.16.0.213:37882 -> [HOST]/10.16.66.12:6379, last known addr=[HOST]/10.16.66.12:6379] Reconnect attempt 3, delay 4ms
[channel=0xe9b4a42f, /172.16.0.213:37882 -> [HOST]/10.16.66.12:6379, last known addr=[HOST]/10.16.66.12:6379] Reconnect attempt 4, delay 8ms
[channel=0xe9b4a42f, /172.16.0.213:37882 -> [HOST]/10.16.66.12:6379, last known addr=[HOST]/10.16.66.12:6379] Reconnect attempt 5, delay 16ms
[channel=0x43ff8ced, /172.16.0.213:37908 -> [HOST]/10.16.66.12:6379, last known addr=[HOST]/10.16.66.12:6379] Reconnect attempt 6, delay 32ms
[channel=0xe9b4a42f, /172.16.0.213:37882 -> [HOST]/10.16.66.12:6379, last known addr=[HOST]/10.16.66.12:6379] Reconnect attempt 7, delay 64ms
[channel=0xe9b4a42f, /172.16.0.213:37882 -> [HOST]/10.16.66.12:6379, last known addr=[HOST]/10.16.66.12:6379] Reconnect attempt 8, delay 128ms
[channel=0x43ff8ced, /172.16.0.213:37908 -> [HOST]/10.16.66.12:6379, last known addr=[HOST]/10.16.66.12:6379] Reconnect attempt 9, delay 256ms      
[channel=0xe9b4a42f, /172.16.0.213:37882 -> [HOST]/10.16.66.12:6379, last known addr=[HOST]/10.16.66.12:6379] Reconnect attempt 10, delay 512ms
[channel=0x43ff8ced, /172.16.0.213:37908 -> [HOST]/10.16.66.12:6379, last known addr=[HOST]/10.16.66.12:6379] Reconnect attempt 11, delay 1024ms
[channel=0xe9b4a42f, /172.16.0.213:37882 -> [HOST]/10.16.66.12:6379, last known addr=[HOST]/10.16.66.12:6379] Reconnect attempt 12, delay 2048ms
[channel=0x43ff8ced, /172.16.0.213:37908 -> [HOST]/10.16.66.12:6379, last known addr=[HOST]/10.16.66.12:6379] Reconnect attempt 13, delay 4096ms
[channel=0xe9b4a42f, /172.16.0.213:37882 -> [HOST]/10.16.66.12:6379, last known addr=[HOST]/10.16.66.12:6379] Reconnect attempt 14, delay 8192ms
[channel=0x43ff8ced, /172.16.0.213:37908 -> [HOST]/10.16.66.12:6379, last known addr=[HOST]/10.16.66.12:6379] Reconnect attempt 15, delay 16384ms

用户疑问 #

请问像channel=0xc8069021, /172.16.2.223:36912这样的channel是什么？为何重连时它的IP会变化？

1. Channel是什么？ #

日志里的channel=0xe9b4a42f这类标识，是Netty框架中标记网络连接实例的唯一ID，对应Netty的Channel对象——这是Netty处理网络通信的核心组件，负责管理客户端与Redis服务器之间的TCP连接，包括数据读写、连接状态维护等操作。

后面的/172.16.0.213:37882是客户端发起连接时使用的本地IP和端口，[HOST]/10.16.66.12:6379则是Redis服务器的地址和端口。

2. 重连时IP变化的原因？ #

你看到的IP变化其实是客户端本地IP的变化，常见原因有两个：

• 客户端多网卡：如果应用部署在有多块网卡的服务器上（比如同时有内网、外网网卡，或者容器环境配置了多个网络接口），每次发起新连接时，操作系统会随机选择一个可用的本地IP作为源IP，导致重连时显示的客户端IP不同。
• 连接重建机制：Lettuce在连接断开后会创建全新的Channel实例发起重连，每次新连接都会由操作系统分配新的本地端口，若此时客户端有多个IP可用，系统可能选择不同的IP绑定到新连接上，从而出现IP变化的情况。

另外需要注意，当前核心问题是Redis连接被拒绝，建议先排查：

• Redis服务器是否正常运行，端口6379是否对外开放
• 客户端与Redis服务器之间的网络是否通畅（比如防火墙、安全组是否拦截请求）
• Redis是否配置了绑定IP限制（比如只绑定127.0.0.1，导致外部无法访问）

内容的提问来源于stack exchange，提问作者Jonathan