Navicat本身不处理MOVED/ASK重定向，因其未实现集群协议的自动解析与跳转逻辑；即使选用Redis (Cluster)类型，也仅支持手动填写所有主节点地址，不自动发现拓扑、不更新槽映射、不发送ASKING命令，属伪集群支持。
Navicat 本身不处理 MOVED/ASK 重定向
navicat 不是 redis 原生客户端，它没有实现集群协议中对 moved 和 ask 错误的自动解析与跳转逻辑。当你连接一个 redis 集群节点（比如 192.168.1.10:7001），而请求的 key 落在另一个节点负责的槽位上时，redis 会返回类似 -moved 12345 192.168.1.11:7002 的响应——navicat 收到后只会报错或卡住，不会尝试重连目标地址。
这不是配置疏漏，而是架构限制：Navicat 的 Redis 支持从 16.0.15 版本起才真正可用，但它只做「单点直连」，不维护槽位映射表，也不发 CLUSTER NODES 或 ASKING 命令。
必须选对连接类型 + 手动填全所有主节点
Navicat 16.3+ 虽然提供了「Redis (Cluster)」类型选项，但它并非像 go-redis 那样自动发现拓扑，而是要求你**显式列出所有主节点地址**（不含从节点）：
- 在连接设置中，“Connection Type” 必须选
Redis (Cluster)，不能选Redis (Standalone)或Redis (Sentinel) - “Host” 栏不再填单个 IP，而是用英文逗号分隔多个主节点地址，例如：
192.168.1.10:7001,192.168.1.11:7001,192.168.1.12:7001 - 每个节点必须能被 Navicat 直连（即 7001 端口开放、防火墙放行），且集群总线端口（如 17001）无需 Navicat 访问——它不走 gossip 协议
- 密码需统一（Redis 集群通常要求所有节点 requirepass 一致；若启用 ACL，则
default用户权限必须覆盖全部主节点）
常见重定向失败的三个实际断点
即使选了 Cluster 类型、填了多地址，仍可能遇到「部分 key 查不到」「刷新键列表失败」「连接后立即断开」等问题，根源往往不在 Navicat 侧：
-
KEYS *被云厂商禁用：腾讯云 Tendis、阿里云 Tair 等兼容版默认屏蔽该命令，而 Navicat 的「Auto-refresh keys list」功能会自动触发它 → 关闭设置中的该选项即可绕过 - ACL 权限不足：升级 Navicat 只解决「能发 AUTH default "pwd"」，但
default用户若没被授予~*或read权限，连INFO都会被拒 → 用redis-cli -a "pwd" --no-auth-warning登录后执行ACL LIST确认 - 节点间时间不同步或 clock drift > 5s：会导致集群握手失败，
CLUSTER NODES返回异常，Navicat 获取拓扑时超时 → 检查各节点是否运行chronyd或ntpd
真正可靠的替代方案不是调参数，而是换工具
如果你需要频繁执行 SCAN、Pipeline、Lua 脚本，或依赖自动重定向容错，Navicat 就不是合适选择。它适合简单浏览和手动操作，不适合生产级集群交互：
- 调试阶段用
redis-cli -c -h node1 -p 7001 -a "pwd"（-c启用集群模式，自动处理 MOVED/ASK） - 图形化管理用
Another Redis Desktop Manager（ardm），支持集群视图、SSH 隧道、TLS，且重定向逻辑由底层ioredis实现，比 Navicat 更健壮 - 开发者集成用 VS Code 的
Redis Explorer插件，可直接在编辑器里跑CLUSTER SLOTS查槽位分布
Navicat 对集群的支持是「伪集群」——它靠你人工提供节点列表来模拟拓扑，不感知迁移、不更新槽映射、不重试失败请求。这点容易被界面里的「Cluster」字样误导。
