connection refused 表示 redis 未监听 127.0.0.1:6379，主因是服务未启动、bind 配置错误或 protected-mode 触发静默退出；应先用 ps 和 ss -tlnp 确认进程与端口监听状态，再查日志定位具体失败原因。
本地连接 Redis 报 Connection refused，大概率不是网络问题，而是 Redis 进程根本没在监听 127.0.0.1:6379 —— 常见于配置改错、保护模式触发静默退出，或服务压根没启动。
redis-cli ping 返回 Connection refused 怎么办
这说明客户端连不到 Redis 进程的 TCP 端口，不是密码错、也不是超时，是“门都没开”。优先排查以下几点：
- 执行
ps aux | grep redis，确认redis-server进程是否存在；没有就说明服务没启，用redis-server /etc/redis/redis.conf或systemctl start redis启动 - 有进程但依然连不上？立刻检查日志：
journalctl -u redis -n 50 --no-pager（systemd）或查看/var/log/redis/redis-server.log，常见报错如Can't assign requested address或直接静默退出，往往因bind配置非法（比如写了bind ::1 127.0.0.1但系统禁用 IPv6） - 别信“服务状态 active”就万事大吉——有些 systemd unit 文件里没加
Type=notify，Redis 启动失败后 systemd 仍显示 active。最稳验证方式：在服务器上跑telnet 127.0.0.1 6379，通了再redis-cli ping
redis.conf 里 bind 和 protected-mode 怎么配才让本地连得上
默认配置下，bind 127.0.0.1 + protected-mode yes 是安全的，但前提是它真被读取到了。容易踩的坑：
-
bind行被注释掉（# bind 127.0.0.1）→ Redis 默认不绑定任何地址，只监听 IPv6 的::1（若系统启用），导致127.0.0.1连接失败 -
bind写成bind 0.0.0.0却没关protected-mode→ 启动时校验失败，Redis 直接退出，systemd 日志里可能只有一行Aborting server due to PROTECTED MODE enabled... - 同时写了
bind 127.0.0.1和bind ::1，但系统关闭了 IPv6 →redis-server初始化 socket 失败，进程起不来 - 修改完
redis.conf忘记 reload：用systemctl restart redis（不是reload），因为 bind/port 变更必须重启进程
requirepass 没设但连 redis-cli 提示 NOAUTH
这不是密码错了，是 protected-mode yes 且 bind 配置缺失/无效时的副作用。Redis 在这种状态下会拒绝所有非回环连接——哪怕你连的是 127.0.0.1，只要它没成功绑定该地址，就会进保护逻辑。
- 先确认绑定是否生效：
ss -tlnp | grep :6379或netstat -tuln | grep :6379，输出里必须含127.0.0.1:6379或*:6379，不能只有[::1]:6379 - 如果只有 IPv6 地址，临时解决：注释掉
bind ::1，保留bind 127.0.0.1，重启服务 - 不想设密码又想确保本地可连，最简方案是明确写死
bind 127.0.0.1并保持protected-mode yes，这是设计预期行为，不是 bug
Docker 或 WSL 环境下 localhost 不等于 127.0.0.1
在 Docker 容器里跑 Redis，宿主机用 localhost 连不上，是因为容器网络隔离；WSL2 中 localhost 被映射到 Windows 主机，而 Redis 若只绑 127.0.0.1，它实际监听的是容器/WSL 自身的 loopback，不是宿主机的。
- Docker：启动时加
-p 6379:6379，且redis.conf中bind必须包含容器内网 IP（如bind 0.0.0.0）或显式指定 bridge 网络地址，不能只留127.0.0.1 - WSL2：要么在 WSL 里把 Redis 绑到
0.0.0.0并配防火墙放行，要么宿主机连 WSL 的实际 IP（cat /etc/resolv.conf查nameserver行） - 两者共性：
redis-cli -h 127.0.0.1 -p 6379在容器/WSL 内部能通 ≠ 宿主机localhost能通，必须分清“谁的 localhost”
真正卡住人的地方，往往不是 bind 写错，而是改完配置后没意识到 Redis 启动失败会静默退出，或者日志被重定向到别的地方。盯住 ps 和 ss -tlnp 输出，比反复猜配置管用得多。
