navicat ssh隧道连接失败主因是混淆ssh系统账号与mysql数据库账号，且常规页主机误填为服务器ip而非127.0.0.1；ssh页填系统用户名/密码或私钥，常规页主机必须为127.0.0.1、端口为mysql监听端口、用户名密码为mysql账号。
能连上，但连不上——绝大多数失败不是因为配置错，而是搞混了两套账号密码，或者填错了 主机 字段。
SSH隧道里填的用户名和密码是服务器系统的，不是MySQL的
这是最常踩的坑。Navicat 的 SSH 选项卡里所有字段，只负责“登录到远程服务器”，跟 MySQL 完全无关：
-
主机填的是跳板机/目标服务器的公网 IP 或域名 -
端口默认是22，除非你改过 SSH 服务端口 -
用户名是你在服务器上能ssh user@ip登录的那个系统账户（比如root、ubuntu） -
密码或私钥文件对应这个系统账户，不是数据库账户
很多人在这里填了 MySQL 的 root 密码，结果测试连接失败，其实根本没走到数据库那步。
常规选项卡里的主机必须写 127.0.0.1 或 localhost
一旦 SSH 隧道建立成功，Navicat 就相当于“已经坐在服务器本地”了，所以：
-
主机必须填127.0.0.1（推荐）或localhost，不能填服务器公网 IP 或内网 IP -
端口填 MySQL 实际监听的端口，一般是3306；如果改过，就填你my.cnf里配置的port -
用户名和密码是 MySQL 用户，比如app_user、backup，和系统账户完全独立
填错 主机 是第二高发问题，错误提示通常是 Connection refused 或 Can't connect to MySQL server，但 SSH 测试却显示成功。
测试连接失败时，先分清是哪一层断了
Navicat 的“测试连接”按钮会按顺序验证：SSH 连通性 → MySQL 连通性。但它不告诉你卡在哪一层：
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- 如果点“测试连接”弹出
Authentication failed或Permission denied，问题在 SSH 层（密钥权限不对、密码错、用户没 shell 权限） - 如果弹出
Access denied for user或Unknown database，说明 SSH 已通，问题出在 MySQL 层（账号没授权、库不存在、host 限制） - 如果弹出
Connection timeout或长时间无响应，大概率是网络层：本地防火墙拦了出站22端口，或服务器防火墙没放行 SSH，或 MySQL 没监听127.0.0.1
建议手动验证：先用终端 ssh user@host 看能否登录；再登录后执行 mysql -u dbuser -p -h 127.0.0.1，确认 MySQL 能本地连。
用密钥认证时，私钥格式和权限必须合规
Navicat 支持 OpenSSH 格式（id_rsa）和 PuTTY 格式（.ppk），但容易出问题：
- Windows 下用 Git Bash 或 WSL 生成的
id_rsa，要确保文件权限不是全局可读（chmod 600 id_rsa），否则 Navicat 会拒绝加载 - 如果只有
.ppk，需用 PuTTYgen 转换为 OpenSSH 格式，或直接在 Navicat 中选“公钥”并指定.ppk文件路径 - 密钥密码（passphrase）不是空的，就必须在 Navicat 的密钥密码框里填，漏填会导致
Permission denied (publickey)
密钥方式比密码安全，但配置稍繁琐；一旦配好，就不用每次输密码，也避免密码被日志或抓包捕获。
真正卡住人的地方，往往不是技术本身，而是没意识到 Navicat 在 SSH 选项卡和常规选项卡里分别模拟了两个完全独立的身份：一个是 Linux 系统用户，一个是 MySQL 数据库用户。填混了，就永远在“已连接”和“连接失败”之间反复横跳。
