JedisConnectionException需分层排查：客户端配置、网络通路、服务端状态、连接池使用四层缺一不可；依据Caused by精准定位——ConnectException查存活与防火墙，SocketTimeoutException查Redis卡顿或超时设置，Could not get resource查池耗尽或close缺失，Broken pipe查空闲连接未清理。
JedisConnectionException 不是单一故障，必须按链路分层定位——从客户端配置、网络通路、服务端状态到连接池使用，漏掉一层就可能反复踩坑。
看 Caused by 精准锁定问题阶段
同一异常名，背后原因完全不同，堆栈末尾的 Caused by 才是关键线索：
-
java.net.ConnectException: Connection timed out→ TCP 握手失败，重点查 Redis 是否存活、bind 配置是否监听外部地址、防火墙是否放行 6379 端口 -
java.net.SocketTimeoutException: Read timed out→ 连接已建好但没收到响应，检查 Redis 是否卡住（slowlog get 10）、是否存在大 key、或客户端socketTimeout设得太小（如低于 2000ms） -
Could not get a resource from the pool→ 连接池耗尽，不是 Redis 问题，而是本地池子撑不住或连接没释放 -
Broken pipe (Write failed)→ 服务端已关闭连接（比如timeout 3600），但客户端还在复用旧连接，典型空闲连接未清理
检查连接池是否真的耗尽
这是最常被误判为“Redis 挂了”的假超时场景：
- 用
netstat -an | grep :6379 | grep ESTAB | wc -l查本机 ESTABLISHED 连接数，若接近maxTotal（Jedis 默认 8），说明池子太小或连接泄漏 - 确认每次
jedis.get()后是否都调用了jedis.close()；用try-with-resources最稳妥，否则连接永不归还 - 如果用了
JedisPool，检查maxWaitMillis是否设得太小（如 100ms），高并发下等不及就直接抛异常 - 观察
redis-cli CLIENT LIST输出里的idle字段：大量连接 idle 超过服务端timeout值（如 3600），说明它们随时会被踢，但客户端仍可能复用
验证 Redis 服务端真实状态
别信“它应该没问题”，登上去看：
- 执行
redis-cli -h，重点关注-p -a INFO clients connected_clients和maxclients：若两者相等，新请求必然排队或失败 - 执行
redis-cli CLIENT LIST | awk '{print $2}' | cut -d= -f2 | cut -d: -f1 | sort | uniq -c | sort -rn，看哪些 IP 建了异常多连接，大概率是某台应用机器泄漏了连接 - 运行
redis-cli ping看是否返回PONG；再用ss -tlnp | grep 6379确认 Redis 确实在监听目标端口 - 检查
config get maxclients和config get timeout，前者决定上限，后者决定空闲连接存活时间
绕不开的网络与基础配置
很多超时根本没走到 Redis 逻辑里，卡在连接建立前：
- 检查 Redis 配置文件中
bind行：若只写了127.0.0.1，远程客户端连不上；需改为0.0.0.0或具体内网 IP（注意安全） - 确认
protected-mode是否为no（当bind不是 127.0.0.1 且没设密码时，Redis 会强制开启保护模式并拒绝外部连接） - Linux 上用
systemctl status firewalld或ufw status查防火墙；Windows 上查“高级安全 Windows 防火墙”是否放行 6379 - 用
telnet测试端口可达性，比6379 ping更准——ping通不代表端口开放
真正难排查的，往往不是 Redis 挂了，而是连接池里混进了被服务端静默关闭的“僵尸连接”。这类问题在低流量时段不暴露，一到高峰就批量报错，务必结合 CLIENT LIST 的 idle 和客户端的 testOnBorrow 配置一起看。
