Navicat 15 SSH隧道配置必须填对五个字段：SSH页填跳板机IP、端口22、系统用户名、密码/私钥；常规页主机填MySQL内网地址（如10.0.1.20）、端口3306、数据库用户名和密码，且需确保跳板机能通MySQL端口、MySQL授权匹配跳板机IP并使用mysql_native_password认证插件。
Navicat 15 的 SSH 隧道配置必须填对这五个字段
Navicat 15 支持原生 SSH 隧道，但连接失败往往不是因为功能不可用，而是五个关键字段填错或逻辑错位。重点在于：**跳板机信息和数据库信息必须分属不同配置页，且「常规」页里的 Host 必须是内网地址（如 10.0.1.20），不是跳板机 IP**。
常见错误现象：Connection refused、Operation timed out、测试连接卡在「Connecting...」几秒后失败。
-
SSH页中「主机」填跳板机的公网/可访问 IP（如203.123.45.67），端口默认22，用户名是登录跳板机的系统账号（如ubuntu） - 验证方式选「密码」时，填跳板机用户的登录密码；选「公钥」时，
私钥字段必须指向本地的id_rsa（不是.pub），且跳板机~/.ssh/authorized_keys中已存入对应公钥 -
常规页中「主机」必须填 MySQL 所在机器的**内网 IP 或主机名**（如10.0.1.20），不能填跳板机 IP；端口填 MySQL 实际监听端口（默认3306） - 「用户名」和「密码」是 MySQL 数据库账号（如
root或app_user），不是跳板机系统账号 - 如果跳板机和 MySQL 服务器不在同一局域网（例如跳板机在 DMZ，MySQL 在内网），需确认跳板机上能
telnet 10.0.1.20 3306通——这是最常被跳过的验证步骤
MySQL 8.0 用户认证插件必须显式重置为 mysql_native_password
即使 Navicat 15 支持 caching_sha2_password，跳板机通道下的连接仍可能因底层驱动链路不一致而 fallback 失败。生产环境建议统一降级为 mysql_native_password，避免协议协商异常。
错误现象：Authentication plugin 'caching_sha2_password' cannot be loaded（哪怕 Navicat 版本 ≥ 15.0.12）
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 在 MySQL 命令行中执行（替换
'your_password'和'%'）：ALTER USER 'root'@'%' IDENTIFIED WITH mysql_native_password BY 'your_password';
- 若只改了
'localhost'用户，远程连接仍会失败——'%'或具体跳板机 IP（如'192.168.0.26'）必须单独处理 - 执行
FLUSH PRIVILEGES;后，建议在跳板机上手动验证：mysql -h 10.0.1.20 -u root -p，成功再回 Navicat 测试 - 不要依赖修改
my.cnf中的default_authentication_plugin：它只影响新创建用户，对已有用户无效
跳板机上必须允许从自身访问目标 MySQL 端口
很多人以为只要 Navicat 配置正确、MySQL 授权 OK 就能连通，却忽略跳板机自身的网络策略。跳板机本质是中间代理，它必须能主动发起 TCP 连接到内网 MySQL 的 3306（或自定义端口）。
典型失败场景：跳板机防火墙（ufw / iptables）默认禁止出站到非标准端口；或 MySQL 服务器 bind-address 未包含跳板机所在子网。
- 在跳板机执行：
nc -zv 10.0.1.20 3306，返回succeeded!才算通过基础连通性 - 若失败，检查 MySQL 服务端
/etc/mysql/mysql.conf.d/mysqld.cnf中：bind-address = 0.0.0.0或明确列出跳板机子网（如192.168.0.0/24） - Ubuntu 跳板机上运行：
sudo ufw status，确保无规则拦截出站3306；CentOS 检查firewall-cmd --list-all - 阿里云/腾讯云等云平台还需确认：跳板机安全组「出方向」放行目标端口，MySQL 服务器安全组「入方向」放行跳板机 IP
Navicat 连接测试失败时优先排查这三处
别一上来就重装 Navicat 或重配 MySQL，90% 的跳板机连接问题集中在三个可快速验证的点。每一步都应有明确反馈，而非凭感觉跳过。
- Navicat 的「测试连接」按钮实际做了两件事：先建 SSH 隧道，再发 MySQL 握手包。若卡在 3–5 秒后报错，大概率是 SSH 成功但 MySQL 层失败（查认证插件或账号权限）；若 1 秒内报错，基本是 SSH 层不通（查跳板机 IP/端口/密钥）
- 打开 Navicat 日志：菜单 → 「工具」→「选项」→「调试」→ 勾选「启用日志记录」，连接失败后查看
navicat.log里最近的SSH tunnel和MySQL handshake行为 - 临时关闭跳板机的 SELinux（
setenforce 0）或 AppArmor（sudo systemctl stop apparmor）：某些加固策略会拦截 sshd 对本地端口的转发行为，导致隧道建立但无法透传
跳板机连接的本质是「双跳信任链」：Navicat 信跳板机，跳板机信 MySQL。任一环节的认证、网络或策略配置偏差都会中断整条链路，而错误提示往往只暴露最后一环。最稳妥的做法，是把跳板机当作一台普通客户端，先确保它能连上 MySQL，再让 Navicat 通过它转发——这个顺序不能颠倒。
