Navicat SSH隧道连接失败主因是127.0.0.1与localhost混淆、MySQL绑定地址错配（需设为127.0.0.1或注释bind-address）、系统账号与数据库账号填反；SSH页填服务器OS账户，常规页填MySQL账号，主机名必须填127.0.0.1，且数据库用户须允许localhost登录。
能连上，但90%的人卡在127.0.0.1和localhost的混淆、mysql绑定地址错配、或把系统账号和数据库账号填反了。不是navicat不行，是这三处一错就静默失败。
Navicat里SSH页和常规页的账号必须分清
SSH选项卡填的是服务器操作系统账户（比如ubuntu、ec2-user、root），不是MySQL用户；常规选项卡里的用户名和密码才是数据库账号（比如app_user）。填反会导致“Access denied”或“Connection refused”，但错误提示不指向根源。
- 云服务器（如阿里云/腾讯云）默认禁用
root密码登录，得先ssh进服务器执行whoami确认实际用户名 - 私钥认证时，
ssh_user必须和私钥归属一致，否则SSH层直接拒绝，Navicat连“测试连接”按钮都点不通 - Windows版Navicat若用OpenSSH格式
id_rsa，路径必须写绝对路径（不能用~），且文件权限建议chmod 600 id_rsa
常规页主机名必须填127.0.0.1，不能填localhost
填localhost会让Navicat尝试走Unix socket（如/tmp/mysql.sock），完全绕过TCP和SSH隧道，报错Can't connect to local MySQL server；填内网IP（如192.168.1.20）则直连，流量不进隧道，被防火墙或网络策略拦截。
- 只要隧道建好了，MySQL服务监听在
127.0.0.1:3306或localhost:3306，常规页就填127.0.0.1+ 对应端口 - 如果MySQL实际跑在另一台内网机器（比如跳板机可访问的
10.10.5.20:3306），你得在SSH页填跳板机信息，常规页仍填127.0.0.1，但端口要对应你在ssh -L里指定的本地端口（如3307）
MySQL服务端配置常被忽略的两个硬性条件
即使Navicat参数全对，服务器上my.cnf和用户权限不对，隧道也穿不过去。
-
bind-address必须是127.0.0.1（或注释掉，默认即为回环），不能是具体内网IP（如192.168.1.100），否则SSH进来后无法从本机连到MySQL - 数据库用户必须允许从
localhost登录：SELECT Host,User FROM mysql.user WHERE User='your_db_user';结果里要有localhost这一行；只有%不够——因为隧道进来后，Navicat是从服务器本机发起TCP连接，等价于mysql -h 127.0.0.1 -u ... - 检查监听状态：在服务器执行
sudo ss -tlnp | grep :3306，输出应含127.0.0.1:3306，而不是*:3306或:::3306
命令行手动建隧道比图形界面更可控
Navicat的隧道是隐式启动的，出问题难定位。用ssh -L手动起一个，能立刻看到报错、验证连通性，也方便脚本化或复用到SpringBoot等场景。
- 基础调试命令（前台运行）：
ssh -L 3307:127.0.0.1:3306 ubuntu@203.101.55.88（假设跳板机公网IP是203.101.55.88） - 后台常驻命令（生产推荐）：
ssh -f -N -L 3307:127.0.0.1:3306 ubuntu@203.101.55.88（-f后台，-N不执行远程命令） - 连通后本地验证：
mysql -h 127.0.0.1 -P 3307 -u dbuser -p，成功了再切回Navicat
最易被跳过的其实是bind-address和Host = 'localhost'这两项——它们不在Navicat界面上，却决定隧道能否真正抵达MySQL进程。别只盯着客户端填什么，服务器那头的监听和授权，才是真正的闸门。
