navicat通过ssh隧道连接redis的本质是将本地127.0.0.1:6379流量经ssh加密转发至内网redis，能否连通取决于ssh隧道是否精准（ssh主机/ip、端口、远程主机三项必填准确）、稳定（进程存活、端口未占、跳板机可达redis）且端到端无阻断（sshd_config允许tcp转发、redis绑定地址匹配）。
navicat 通过 ssh 隧道连接 redis，本质是让本地 navicat 认为 redis 就在本机 127.0.0.1:6379，而真实流量经由 ssh 加密转发到内网 redis。能不能连上，不取决于 navicat 设置是否“看起来完整”，而取决于 ssh 隧道是否精准、稳定、且端到端通路无阻断。
SSH 隧道配置必须填对这三项（Navicat 内）
Navicat 的 SSH 隧道页不是“填了就行”，三个字段错一个，redis-cli -h 127.0.0.1 -p 6379 就会报 Connection refused：
-
SSH 主机名/IP：跳板机（能 SSH 登录的那台机器）的真实地址，比如
jump.example.com或192.168.10.5 -
SSH 端口：默认
22，但若跳板机改过 SSH 端口（如2222），这里必须同步改，否则隧道根本建不起来 -
远程主机：这是最容易错的——它不是跳板机地址，而是 Redis 实际监听的地址+端口：
- 如果 Redis 在另一台内网服务器（如
10.20.30.40），填10.20.30.40:6379 - 如果 Redis 就跑在跳板机本机，填
127.0.0.1:6379（别写localhost，某些系统下会走 Unix socket，Navicat 不认）
- 如果 Redis 在另一台内网服务器（如
其余字段（用户名、密码/密钥）按跳板机登录方式填即可；Navicat 会自动用它们建立隧道，不涉及 Redis 密码。
Redis 连接参数要和隧道出口严格匹配
隧道建好后，Navicat 的「常规」页里填的是“隧道另一头”的 Redis 服务信息，不是跳板机的信息：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
主机 必须是
127.0.0.1（不能是localhost，尤其 macOS 上容易失败） -
端口 必须和你 SSH 隧道的本地监听端口一致（Navicat 默认用
6379，但如果你手动改过，这里必须同步） -
密码 是 Redis 的
requirepass，不是 SSH 密码；没设密码就留空，别乱填 - 如果 Redis 绑定的是
127.0.0.1（常见于单机部署），而你隧道指向的是内网 IP（如10.20.30.40），就会连不上——此时要么改 Redis 的bind配置，要么把隧道目标改成127.0.0.1:6379（仅限 Redis 和跳板机同机）
连不通？先查这四件事（比重试十次更省时间）
Navicat 点“测试连接”失败时，别急着调 Navicat 设置。先确认底层隧道本身是否真在工作：
- 运行
ps aux | grep "ssh.*-L.*6379"（macOS/Linux）或netstat -ano | findstr :6379（Windows WSL），看有没有对应进程；没有 = 隧道根本没起来 - 用
lsof -i :6379查本地6379是否被其他程序（比如另一个 redis-server、Docker 容器）占用了 - 从跳板机上手动执行
telnet 10.20.30.40 6379（或nc -zv 10.20.30.40 6379），确认跳板机能访问 Redis —— 即使你能 SSH 登录跳板机，也不代表它能连 Redis - 检查跳板机的
/etc/ssh/sshd_config，确认AllowTcpForwarding yes；若为no，Navicat 隧道必然失败，且不会提示具体原因
Navicat for Redis 的隐藏限制你得知道
Navicat for Redis（含 Premium）对隧道连接有实际约束，不是所有 Redis 部署都能直接套用：
- 不支持 Redis Cluster 模式下的自动节点发现——你只能连上某一个 master 节点，无法看到整个集群拓扑
- 不支持 Sentinel 自动故障转移；如果填的是 Sentinel 地址，它连不上，因为 Navicat 不解析
SENTINEL get-master-addr-by-name响应 - 如果 Redis 启用了 TLS（
tls-port），Navicat 的 SSH 隧道只做 TCP 层转发，TLS 握手仍由 Redis 侧处理，只要证书信任链没问题，不影响；但 Navicat 本身不提供 TLS 证书配置入口 - 某些云托管环境（如共享虚拟主机）禁用
AllowTcpForwarding，且你无权改sshd_config，这时 Navicat 隧道必然失败，得换方案（比如用SSHTunnelForwarder写脚本中转）
真正卡住人的，往往不是 Navicat 界面操作，而是隧道两端的网络可达性、Redis 绑定策略、以及 SSH 服务端的转发许可——这些细节一旦漏查，反复重试只会浪费时间。
