超时意味着请求发出去了但没人应答，拒绝连接说明目标端口明确回绝了你，排查顺序应从网络层到Redis配置层，再到Jedis代码层，多数情况下问题出在Redis的bind配置和虚拟机防火墙规则上。
先从连接过程判断故障方向
Jedis连接虚拟机上的Redis,本质是一次TCP握手加一次Redis协议交互，从你按下回车的那一刻起，连接请求要经过虚拟机网络、防火墙、Redis监听端口、Redis安全策略四道关卡，任何一道卡住，表现都不一样。
超时和拒绝的区别决定了排查起点
- 连接超时（connect timed out）：请求发出后石沉大海，通常意味着网络路由不通、防火墙丢弃了数据包，或者虚拟机IP根本不在同一网段。
- 拒绝连接（connection refused）：目标主机回了RST包，说明网络是通的，但端口没人监听，或者Redis配置了bind只允许特定IP访问。
多数情况下,拒绝连接比超时好排查，因为范围更小，如果你遇到的是超时，先把重心放在网络层，别急着改Redis配置。
网络层排查：确认虚拟机是否真的可达
本机连虚拟机,最常见的坑是虚拟机用了NAT模式而物理机无法直接访问，这种情况下，你在本机ping虚拟机IP往往是通的，但telnet端口却不通，因为NAT模式下的虚拟机对外不可见。
三步确认网络连通性
- 第一步：在本机执行
ping 虚拟机IP，确认基本网络连通，如果不能ping通，检查虚拟机网络模式是否设置为桥接模式，或者物理机与虚拟机是否在同一网段。 - 第二步：执行
telnet 虚拟机IP 6379，看端口是否开放，如果卡住不动，说明防火墙拦截或Redis没监听；如果提示拒绝连接，说明Redis进程没起来或bind配置不对。 - 第三步：在虚拟机本机执行
redis-cli ping，确认Redis服务自身正常，如果本机都返回PONG，问题大概率出在网络或防火墙配置上。
行业共识认为,telnet端口测试是区分网络问题和应用问题的最快手段，这一步能帮你缩小一半的排查范围。
防火墙规则：大多数超时的根源
Linux虚拟机默认开启firewalld或iptables,Redis的6379端口往往不在放行列表中，你需要检查并放行：
# 查看防火墙状态 systemctl status firewalld # 永久放行6379端口（以firewalld为例） firewall-cmd --zone=public --add-port=6379/tcp --permanent firewall-cmd --reload
如果你用的是云服务器（即使是虚拟机镜像），还需要检查安全组规则，近年来，相当一部分连接超时案例都是因为安全组只放行了22端口，忘了放行6379，同时检查虚拟机网卡是否启用了防火墙的docker链或selinux限制，这些隐蔽规则也容易导致连接被静默丢弃。
Redis服务端配置：拒绝连接的头号原因
排除网络问题后,拒绝连接基本指向Redis自身的监听配置，Redis默认只监听127.0.0.1，也就是仅允许本机访问，你在虚拟机外用Jedis连接，必须修改bind配置和protected-mode。
检查Redis是否监听在正确的地址上
在虚拟机执行：
netstat -tlnp | grep 6379
如果看到0.0.1:6379，说明Redis只监听了回环地址，外部连接必然被拒，需要修改Redis配置文件（通常位于/etc/redis/redis.conf或/usr/local/redis/redis.conf）：
# 将bind 127.0.0.1改为以下任意一种
bind 0.0.0.0
# 或指定虚拟机网卡IP
bind 192.168.x.x修改后重启Redis服务：
systemctl restart redis # 或直接redis-cli shutdown后再启动
protected-mode：比bind更隐蔽的坑
Redis 3.2版本之后默认开启protected-mode，即使你设置了bind 0.0.0.0，只要没设置密码且没有显式配置bind，Redis依然拒绝非本机IP的连接，你需要：
- 设置密码：在配置文件中添加
requirepass 你的密码，Jedis连接时带上密码即可。 - 或显式关闭protected-mode：
protected-mode no（不推荐生产环境使用）。
如果你是在Windows虚拟机或Docker容器里跑Redis,还有一层端口映射需要检查，Docker启动Redis时如果没有-p 6379:6379映射参数，外部同样无法访问。
确认Redis进程确实在运行
有时候你改了配置但忘了重启,或者Redis启动失败被systemd自动拉起后又崩溃，执行ps -ef | grep redis确认进程存在，再看日志（通常在/var/log/redis/redis-server.log）有没有报错，重启后务必在虚拟机本机用redis-cli -h 虚拟IP ping测试，如果返回PONG，说明监听已生效。
Jedis连接参数：代码层面的常见失误
网络通了,Redis也监听正确了，但Jedis还是连不上，就要检查连接参数的细节。
别把虚拟机内部IP和外网IP搞混
如果你在虚拟机里配置了端口转发或映射,本机连接时要用的可能是映射后的IP和端口，而不是虚拟机内部IP，用错了IP，表现就是连接超时或拒绝连接交替出现，确认连接串里的IP和端口与netstat显示的监听地址一致。
Jedis连接池配置不当也会导致连接失败
连接池耗尽时,Jedis会抛出JedisConnectionException: Could not get a resource from the pool，这种现象容易被误判为连接超时，实际是连接池的maxTotal值过小，或maxWaitMillis超时时间设置过短，排查时先看异常堆栈，别一上来就改防火墙。
连接池里设置了testOnBorrow: true时，空闲连接被回收后，池中的连接实际已失效，借用时测试失败也会抛出类似连接异常，这种情况下适当调整minIdle和timeBetweenEvictionRunsMillis能让连接更稳定。
Jedis版本和Redis版本的兼容性
老版本Jedis（2.x系列）连接Redis 6.x及以上版本，可能因为协议差异出现握手失败，Jedis 3.x及以上版本才完整支持Redis 6的RESP3协议和ACL权限控制，如果你配了ACL用户，需要在Jedis连接时显式传入用户名，否则会提示认证失败。
七类高频报错对照速查表
| 报错信息 | 故障类型 | 优先排查方向 |
|---|---|---|
| connect timed out | 网络不通或防火墙丢包 | 虚拟机网络模式、防火墙放行规则 |
| connection refused | 端口无监听或bind限制 | Redis进程状态、bind配置 |
| DENIED Redis is running in protected mode | 保护模式拦截 | 设置密码或配置bind 0.0.0.0 |
| NOAUTH Authentication required | 缺少密码 | Jedis设置密码或连接串加密码 |
| ERR max number of clients reached | 连接数满 | Redis maxclients配置 |
| Could not get a resource from the pool | 连接池耗尽 | Jedis连接池参数调整 |
| Connection reset by peer | 连接被服务端重置 | Redis超时配置、网络不稳定 |
jedis连接虚拟机redis连接超时怎么排查
当超时问题反复出现,建议按以下顺序走一遍，避免漏掉隐蔽配置：
- 本机ping虚拟机IP，不通则检查网络模式或网卡配置。
- telnet虚拟机IP 6379，卡住则查安全组和firewalld，被拒则查Redis监听地址和进程。
- 在虚拟机本机用redis-cli -h 127.0.0.1 ping，不通则说明Redis自身有问题或没监听在127.0.0.1上。
- 在虚拟机本机用redis-cli -h 虚拟网卡IP ping，不通则说明bind配置限制了网卡IP的访问。
- 修改bind配置加上虚拟机的实际IP或0.0.0.0，重启Redis，重复上一步。
- 配置密码并确认protected-mode不会拦截外部IP，在Jedis连接串中带上密码。
- 如果以上都正常，用Java代码单独跑一个Jedis实例（不走连接池），排除连接池参数干扰。
这套流程走完,绝大部分问题都能定位，网上很多教程让你直接改protected-mode no，但在生产环境或共享虚拟机里，这是不安全的做法，优先设置密码并保留保护模式，既解决问题又不降低安全性。
虚拟机redis拒绝连接排查步骤
拒绝连接在虚拟环境中有个特殊场景：Redis所在虚拟机的物理防火墙可能没开，但宿主机或中间网络设备（比如公司的网关）做了端口限制，如果你的虚拟机运行在公司的ESXi或OpenStack平台上，即使虚拟机自身防火墙放行了6379，宿主机安全策略仍可能拦截，这种情况需要联系虚拟化平台管理员确认端口策略。
另一个容易忽略的点是IPv6,如果Redis绑定了:1地址，而你的本机通过IPv4连接，地址族不匹配也会导致拒绝连接，执行ss -tlnp | grep 6379查看所有监听地址，确保IPv4的0.0.0:6379或具体网卡IP在监听列表中。
常见问题与解答
jedis连不上虚拟机redis该从哪一步查起？
先看异常类型。connection refused查Redis进程和bind配置，connect timed out查防火墙和网络隔离，不要跳过telnet测试，它能直接将问题归因到网络层或应用层。
修改bind配置后还是拒绝连接怎么办？
确认你修改的是Redis实际加载的配置文件,有的系统通过systemd启动Redis时用了不同的配置文件路径，可以用redis-cli config get bind查看当前生效的绑定地址，如果显示的还是127.0.0.1，说明你改错了文件，需要找到实际加载的配置，修改protected-mode相关配置后必须重启Redis，config set对protected-mode和bind的修改在部分版本上不持久生效，重启后会被重置。
虚拟机防火墙放行了6379但本机telnet还是超时？
检查虚拟机网卡的子网和宿主机网段是否在同一个广播域,VMware的NAT模式默认不允许宿主机外部设备访问虚拟机，需要设置端口转发规则，在VMware虚拟网络编辑器中，将NAT模式的网关端口映射到虚拟机IP的6379上，本机连接时使用宿主机IP加映射端口，注意，端口转发只对宿主机生效，跨设备访问仍可能不通。