“connection refused”错误通常因redis服务未运行或网络通路被阻断；需依次检查服务状态、端口监听、防火墙/安全组、本地连通性及配置项（如bind、protected-mode、port、requirepass）。
如果您尝试连接Redis服务器但收到“Connection refused”错误，该问题通常源于服务未运行或网络通路被阻断。以下是针对性排查与修复步骤：
一、确认Redis服务是否正在运行
服务未启动是最常见原因，此时系统无法响应任何连接请求，直接返回拒绝错误。需验证进程是否存在并处于活跃状态。
1、在Linux/macOS中执行：sudo systemctl status redis
2、若提示“inactive (dead)”或无输出，说明服务未运行；可尝试启动：sudo systemctl start redis
3、在Windows中打开任务管理器，切换到“服务”选项卡，查找名为“Redis”的服务，确认其状态为“正在运行”；若未运行，右键启动。
4、若未使用systemd，改用：ps aux | grep redis-server 检查是否存在redis-server进程。
二、检查Redis是否监听预期端口
即使服务运行，若未正确绑定端口或监听地址，客户端仍会遭遇连接拒绝。需确认6379（或自定义端口）是否真实处于监听状态。
1、执行：sudo ss -tlnp | grep :6379
2、若无任何输出，说明Redis未监听该端口——可能因配置错误、端口被占用或启动时未加载正确配置文件。
3、也可使用：netstat -tlnp | grep 6379 进行交叉验证。
4、若输出中显示监听地址为127.0.0.1:6379，则仅允许本地连接；若为*:6379或0.0.0.0:6379，表示已开放全网接口。
三、验证防火墙或安全组是否拦截入站连接
系统级防火墙或云平台安全组规则会静默丢弃未放行端口的连接请求，导致客户端超时后报“Connection refused”。
1、在RHEL/CentOS/Rocky系统中检查firewalld：sudo firewall-cmd --state 和 sudo firewall-cmd --list-ports
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
2、若6379未出现在端口列表中，执行：sudo firewall-cmd --add-port=6379/tcp --permanent && sudo firewall-cmd --reload
3、在Ubuntu/Debian系统中检查ufw：sudo ufw status verbose，若状态为active且未放行6379，则执行：sudo ufw allow 6379
4、若使用云服务器（如阿里云、腾讯云），登录控制台进入“安全组”页面，确认入方向规则中已添加TCP协议、端口6379、源IP范围（如0.0.0.0/0或指定客户端IP）。
四、使用本地命令行工具快速验证连通性
绕过应用层配置，直接测试基础连接能力，可快速区分是服务层问题还是网络层问题。
1、在同一台服务器上执行：redis-cli ping，若返回PONG，说明服务运行且本地可达。
2、若返回Could not connect to Redis at 127.0.0.1:6379: Connection refused，则问题一定出在服务未启动或端口未监听。
3、从远程机器执行：telnet
4、若telnet立即报“Connection refused”，而非超时，则说明目标主机上无服务监听该端口，即服务未运行或绑定失败。
五、检查Redis配置中的关键限制项
某些配置项会导致Redis主动拒绝连接，而非由系统内核返回拒绝，表现相同但根源不同。
1、打开redis.conf文件，定位bind行：若值为127.0.0.1且客户端非本机，则必须改为0.0.0.0或注释掉该行。
2、检查protected-mode：若为yes且未设置密码，Redis将拒绝所有非127.0.0.1来源的连接；临时解决可设为no。
3、确认port值与客户端连接时指定的端口一致；若修改过，需确保redis-server /path/to/redis.conf启动时加载了该配置。
4、检查requirepass是否启用：若设置了密码但客户端未提供，部分客户端会表现为连接后立即断开，少数场景亦触发拒绝行为，需同步校验认证参数。
