Navicat 16 SSH隧道需独立配置，SSH页填跳板机系统账号（如ops、22端口），常规页主机必须填127.0.0.1且MySQL权限须授权给跳板机内网IP（如'10.10.5.100'），否则报Access denied；连接卡顿多因中间设备静默断连，需服务端配置ClientAliveInterval保活。
Navicat 16 的 SSH 隧道本身不支持“多用户共享隧道”或“团队级跳板代理”，它只做单连接隧道绑定。所谓团队安全跳板访问，实际是每人独立配置、权限隔离的 SSH 连接，而非共用一个隧道实例。
SSH选项卡填谁的信息？不是数据库，是跳板机系统账号
很多人一上来就在“常规”页填数据库 IP，结果连不上——根本没走到 MySQL 那步。Navicat 的 SSH 隧道必须先连通跳板机，才能转发流量。
-
主机：填跳板机的公网 IP 或域名（如jump-prod.example.com），绝不能是内网数据库地址 -
端口：填跳板机的 SSH 端口，默认22；若运维改成了2222，这里必须同步改 -
用户名：你在跳板机上的 Linux 账号（如ops、deploy），不是 MySQL 用户名 - 认证方式选「密码」或「公钥」：
私钥文件必须是.ppk格式（Windows 下 Navicat 不识别 OpenSSH 的id_rsa）；可用 PuTTYgen 转换
常规页主机必须是 127.0.0.1，不是 localhost
填 localhost 会强制走 Unix socket，绕过 TCP 层，而 SSH 隧道只转发 TCP 流量——这是最常导致“连接成功但查不了表”的底层原因。
-
主机名/IP地址固定填127.0.0.1（哪怕 MySQL 实际跑在10.10.5.20上） -
端口填跳板机视角下可访问的 MySQL 端口：如果 MySQL 在跳板机本机，填3306；如果通过ssh -L 3307:10.10.5.20:3306映射过，这里就填3307 -
用户名和密码是真正的 MySQL 凭据，和跳板机系统账号完全无关
MySQL 报 Access denied for user？权限必须绑跳板机内网 IP
你本地发起的连接，经隧道后对 MySQL 来说来源 IP 是跳板机的内网地址（比如 10.10.5.100），不是你的笔记本 IP。授权不匹配，再正确的 Navicat 配置也白搭。
- 执行
SELECT User, Host FROM mysql.user;，确认目标用户 Host 字段是'myuser'@'10.10.5.100'或子网形式'myuser'@'10.10.5.%'，不是'localhost'也不是'%' - 建用户 + 授权要两步：
CREATE USER 'myuser'@'10.10.5.100' IDENTIFIED BY 'xxx';+GRANT SELECT ON db.* TO 'myuser'@'10.10.5.100';+FLUSH PRIVILEGES; - 如果 MySQL 启用了
skip-name-resolve，禁止用主机名授权（如'myuser'@'jump-prod'），DNS 解析失败会导致权限不生效
连接卡住、频繁断开？不是 Navicat 问题，是 SSH 隧道被静默回收
闲置 2–3 分钟后突然卡死、报 Lost connection to MySQL server，大概率是中间设备（云厂商安全组、企业 NAT、跳板机防火墙）主动清除了空闲 TCP 连接，而 Navicat 没收到 FIN 包，还在等响应。
- 服务端（跳板机）加保活：
echo "ClientAliveInterval 60" >> /etc/ssh/sshd_config，然后systemctl restart sshd - Navicat 本身不提供 KeepAlive 配置项，所以必须靠服务端驱动；客户端侧无法补救
- 若跳板机 SSH 版本较老（如 OpenSSH KexAlgorithms 配置才能握手成功，否则卡在
Expected key exchange group packet from Server
真正难的不是填对那几个字段，而是厘清数据流向：本地 Navicat → 跳板机 SSH → 跳板机网络层 → 内网 MySQL。每一段的权限、绑定、可达性都得单独验证，缺一不可。
