Navicat通过SSH隧道连内网数据库需三者对齐：SSH选项卡填跳板机信息（公网IP、22端口、系统用户名），数据库页主机必须为127.0.0.1，MySQL用户权限须授权给跳板机内网IP（如'10.10.5.100'），而非localhost或%。
Navicat 通过 SSH 隧道连内网数据库，**不是填对了就能通，而是“跳板机、隧道、MySQL 权限”三者必须对齐**。最常失败的原因不是 Navicat 配错了，而是你本地以为在连 MySQL，其实 Navicat 先连跳板机、再靠跳板机去连 MySQL——而 MySQL 根本没给跳板机开权限。
Navicat 的 SSH 选项卡里，主机和端口填谁的？
填跳板机（堡垒机）的信息，不是数据库的：
-
主机：跳板机的公网 IP 或域名（如jump.example.com），不能是内网数据库地址 -
端口：跳板机的 SSH 端口，默认22；若改过（比如10022），必须填实际值 -
用户名：你在跳板机上的系统账号（如root或ops），不是 MySQL 用户名 - 认证方式选「密码」或「公钥」：
私钥文件必须是.ppk格式（Windows 下 Navicat 不认 OpenSSH 的id_rsa），可用 PuTTYgen 转换
数据库连接页的主机为什么必须是 127.0.0.1？
因为 SSH 隧道已把你的本地流量“送进”跳板机内部，此时 Navicat 认为它正在跳板机本机发起连接。填其他地址（比如数据库真实内网 IP 或域名）会导致直连失败：
-
主机名/IP地址固定填127.0.0.1（哪怕 MySQL 实际跑在另一台内网机器上） -
端口填 MySQL 在跳板机视角下可访问的端口：如果 MySQL 就装在跳板机上，填3306；如果 MySQL 在10.10.5.20:3306，且你用ssh -L 3307:10.10.5.20:3306映射过，这里就填3307 -
用户名和密码是 MySQL 用户凭证，不是跳板机系统账号
MySQL 报 “Access denied for user” 或根本连不上？先查权限绑定在哪
MySQL 的用户授权是按「来源 IP」判断的，而经 SSH 隧道后，来源 IP 是跳板机的内网地址（比如 10.10.5.100），不是你本地电脑的公网或局域网 IP：
- 执行
SELECT User, Host FROM mysql.user;，确认该用户 Host 字段匹配跳板机内网 IP（如'myuser'@'10.10.5.100'），不是'localhost'或'%'（%在某些安全策略下也不生效） - 如果 MySQL 只监听
127.0.0.1，需修改bind-address为0.0.0.0或跳板机内网 IP，并重启服务 - 跳板机上运行
telnet 10.10.5.20 3306（替换为目标数据库 IP），不通就说明网络层或防火墙阻断，隧道再正确也白搭
连接卡住、频繁断开、提示 “connection is being used”？这是隧道链路被静默回收
SSH 隧道本身无心跳保活，中间设备（云厂商安全组、企业 NAT、跳板机防火墙）会主动清理空闲连接，但 Navicat 不感知，仍发包导致异常：
- 临时解法：Navicat 连接参数 → 「高级」→ 勾选「保持连接活跃」，设间隔 30–60 秒
- 根治法：在跳板机的
/etc/ssh/sshd_config中加两行：TCPKeepAlive yes和ClientAliveInterval 30，然后systemctl restart sshd - 命令行建隧道时加
-o ServerAliveInterval=30参数，例如：ssh -L 3307:10.10.5.20:3306 -o ServerAliveInterval=30 user@jump-host
bind-address、用户 Host、以及中间网络设备对长连接的回收策略，这三处任一出问题，都会让 Navicat 显示“连接成功”却查不出任何数据。 
