Redis命令行连接失败：如何排查cmd下redis-cli连接拒绝问题？

Question

Redis命令行连接失败（`redis-cli` 报“Connection refused”）是Windows下高频问题。常见原因有四：① Redis服务未启动（检查 `services.msc` 中 Redis Windows Service 状态，或执行 `redis-server.exe redis.windows.conf` 手动启动）；② 配置绑定地址为 `127.0.0.1` 但启用了 `bind` 或 `protected-mode yes`，导致本地回环拒绝连接（需确认 `redis.windows.conf` 中 `bind 127.0.0.1` 存在且 `protected-mode no` 仅用于开发环境）；③ 防火墙/杀软拦截6379端口；④ 客户端指定错误端口或IP（如误用 `-h localhost` 却未监听IPv6）。排查建议：先运行 `telnet 127.0.0.1 6379` 测试端口连通性；再用 `redis-cli -p 6379 ping` 验证；最后检查 `redis-server --version` 与配置文件路径是否匹配。切忌跳过日志——启动时加 `--loglevel verbose` 或查看 `redis.log` 关键错误行。

Answer 1

```html

一、现象层：精准识别“Connection refused”错误的本质

当在 Windows 命令行执行 redis-cli 时返回 Connection refused，这并非 Redis 协议级错误，而是 TCP 连接被操作系统内核直接拒绝（errno=10061），表明目标端口无监听进程或连接被主动拦截。该错误发生在三次握手阶段之前，因此与认证、密码、ACL 等逻辑层无关——这是所有排查的起点。

二、服务层：验证 Redis 进程是否存在与运行状态

• 打开 services.msc，查找服务名如 Redis Windows Service（取决于安装方式），确认其状态为 正在运行；
• 若服务未启动，右键启动；若启动失败，需进一步检查依赖项（如 Windows C++ 运行库）；
• 手动启动验证：redis-server.exe redis.windows.conf --loglevel verbose，观察控制台是否输出 * Ready to accept connections 及监听地址（如 Listening on 127.0.0.1:6379）；
• 使用 tasklist /fi "imagename eq redis-server.exe" 确认进程存活；
• 注意：Windows 下常见误将 redis-server.exe 与 redis-cli.exe 混淆执行，导致“看似启动实则未运行”。

三、配置层：深度解析绑定策略与保护模式的协同效应

配置项	典型值	影响说明	安全建议
bind	127.0.0.1	仅监听 IPv4 回环，localhost 解析为 ::1（IPv6）时会失败	开发环境可设为 127.0.0.1 ::1 兼容双栈
protected-mode	yes	当 bind 为空且无 requirepass 时，强制拒绝外部连接	生产环境必须设为 yes 并配密码；开发可临时设 no

关键验证命令：redis-server --test-memory 1 可快速校验配置语法；修改后务必重启服务（非 reload，Windows 不支持 SIGHUP）。

四、网络层：穿透防火墙、杀软与协议栈的隐式拦截

Windows Defender 防火墙默认阻止未知程序入站连接。执行以下诊断链：

1. telnet 127.0.0.1 6379 → 若提示“无法打开到主机的连接”，说明端口未监听或被拦截；
2. netstat -ano | findstr :6379 → 查看 PID 是否对应 redis-server.exe 及状态是否为 LISTENING；
3. 进入 Windows Defender 防火墙 → 高级设置 → 入站规则，搜索 redis 或端口 6379，启用对应规则；
4. 第三方杀软（如 360、腾讯电脑管家）常静默拦截，需临时禁用测试；
5. 特别注意：WSL2 或 Docker Desktop 启动的 Redis 会绑定到虚拟网卡，127.0.0.1 不可达，需改用 host.docker.internal 或宿主 IP。

五、客户端层：解构 CLI 连接参数的语义陷阱

常见误操作包括：

redis-cli -h localhost -p 6379     # ❌ localhost 默认解析为 ::1（IPv6），但 bind 仅含 127.0.0.1
redis-cli -h 127.0.0.1 -p 6379      # ✅ 明确指定 IPv4 地址
redis-cli -u redis://127.0.0.1:6379 # ✅ URI 方式更健壮

进阶技巧：使用 redis-cli --intrinsic-latency 10 可检测本地 TCP 栈延迟，排除系统级网络异常。

六、日志层：从 verbose 日志中定位根因的黄金路径

graph TD
    A[启动 redis-server --loglevel verbose] --> B{日志首行}
    B -->|“oO0OoO0OoO0Oo Redis is starting”| C[检查 bind 行]
    B -->|“Fatal error”| D[立即终止，查前5行]
    C --> E[“Listening on 127.0.0.1:6379”]
    C --> F[“Could not create server TCP listening socket”]
    F --> G[端口占用/权限不足/IPv6冲突]
    E --> H[继续验证 protected-mode 是否触发拦截]

日志文件（如 redis.log）中需重点关注：Address already in use（端口冲突）、Failed to bind to 127.0.0.1:6379（权限或地址不可用）、Protected mode enabled（即使 bind 正确也会拒绝无密码连接）。

七、版本与生态层：跨版本兼容性与部署形态差异

Windows 官方已停止 Redis 原生支持（自 3.2 起），当前主流方案有三：

• MicrosoftArchive/redis（已归档）：仅支持至 3.2，不兼容 TLS/ACL；
• tporadowski/redis（GitHub 活跃）：基于 7.x 分支编译，支持 redis.conf 全特性；
• Docker Desktop + WSL2：运行 Linux 容器版 Redis，性能与功能最完整。

验证一致性：redis-server --version 输出版本号，须与 redis.windows.conf 中注释说明的适配版本一致（如 7.0+ 配置项 io-threads 在 6.x 中无效）。

```