SSH隧道连接时，主机和用户名需填跳板机的系统登录信息（如IP、root），数据库连接页主机必须填127.0.0.1以走TCP隧道，MySQL用户权限须授权给跳板机内网IP（如'10.10.5.100'）而非localhost或%。
能连上，但连不上数据库本身——绝大多数情况不是 Navicat 配置错了，而是 SSH 隧道通了，MySQL 却拒绝认证。关键得搞清“谁在连谁”“从哪来”“权限绑在哪”。
SSH 隧道配置时，主机 和 用户名 填什么？
这里填的是跳板机（或目标服务器）的登录信息，不是数据库的：
-
主机：跳板机公网 IP 或域名（比如47.98.123.45或jump.example.com） -
端口：跳板机 SSH 端口，默认22，改过就填实际值 -
用户名：你在跳板机上的系统账号，比如root、deploy，不是 MySQL 用户名 - 密码或私钥：对应这个系统账号的认证凭据；私钥若用 OpenSSH 生成（
id_rsa），Windows 下 Navicat 可能不认，得转成.ppk格式（用 PuTTYgen）
常规连接页里，主机 为什么必须填 127.0.0.1 而不是 localhost？
因为 localhost 在 MySQL 客户端语义里会强制走 Unix socket，绕过 TCP，而 SSH 隧道只转发 TCP 流量。填 127.0.0.1 才能确保走隧道。
-
主机：固定填127.0.0.1（哪怕 MySQL 实际装在另一台内网机器上，只要跳板机能访问它，隧道就能通） -
端口：填 MySQL 实际监听的端口，比如3306；如果跳板机上 MySQL 不在默认端口，或你用-L 3307:10.10.5.20:3306映射了，这里就填3307 -
用户名/密码：这才是真正的 MySQL 数据库账号，和系统账号完全无关
测试连上了，但执行查询报 Access denied for user？
这是最常踩的坑：MySQL 的用户权限是按「连接来源 IP」判断的，而经 SSH 隧道后，来源 IP 是跳板机的内网地址（比如 10.10.5.100），不是你的本地电脑 IP。
- 错误授权：
CREATE USER 'app'@'localhost'或'app'@'%'都不生效 - 正确做法：显式授权给跳板机 IP，例如
CREATE USER 'app'@'10.10.5.100' IDENTIFIED BY 'xxx'; - 别漏
GRANT ALL ON db.* TO 'app'@'10.10.5.100';和FLUSH PRIVILEGES; - 如果跳板机 IP 不固定，授权子网更稳妥：
'app'@'10.10.5.%' - 启用
skip-name-resolve时，禁止用主机名授权（如'app'@'jump-prod'），DNS 解析失败会导致权限匹配失败
连接卡住、频繁断开、提示 “connection is being used”？
这不是 Navicat 或 MySQL 的问题，是 SSH 隧道链路被中间设备静默中断了，客户端没感知。
- 现象：刚连上正常，闲置 2–3 分钟后卡死、超时、报
Lost connection to MySQL server - 根因：跳板机防火墙、云厂商安全组、NAT 设备主动回收空闲连接
- 解法一（服务端）：在跳板机
/etc/ssh/sshd_config加ClientAliveInterval 60，重启sshd - 解法二（客户端）：在本地
~/.ssh/config配ServerAliveInterval 45和ServerAliveCountMax 3 - Navicat 自身无保活机制，依赖底层 SSH 连接维持，所以必须从 SSH 层解决
真正麻烦的从来不是配通隧道，而是搞懂数据流路径：本地 Navicat → SSH 加密通道 → 跳板机网络栈 → 目标 MySQL。每一段的地址、端口、权限都得对得上，漏一个就卡在半路。
