根本原因是Navicat的结构/数据同步默认走直连而非SSH隧道，需在连接设置中明确启用并配置SSH标签页；常见错误包括主机填错跳板机地址、端口未手动修正、私钥路径非绝对路径、未保存即测试等。
Navicat 里配 SSH 隧道为什么连不上？
根本原因不是 navicat 不支持，而是它只封装了 ssh 客户端能力，不接管系统级 ssh 配置。你看到“连接测试成功”但同步失败，大概率是同步动作没走隧道——navicat 的「结构同步」「数据同步」默认走的是直连（tcp），除非你在连接设置里明确启用并配置了 ssh 标签页。
常见错误现象：
- 连接测试按钮显示绿色对勾，但执行「数据同步」时提示
Connection refused或超时 - 目标库在内网，SSH 跳板机能连上，但 Navicat 同步报
Access denied for user - Mac 上用钥匙串存的密钥，迁移到 Windows 后 SSH 配置灰掉、无法编辑
实操建议：
- 双击连接 → 切到
SSH标签页 → 勾选「使用 SSH 隧道」→ 确保「主机名」填的是跳板机地址（不是最终数据库地址） - 「端口」默认是
22，如果跳板机改过 SSH 端口，必须手动改，不能依赖系统 ssh_config - 私钥路径必须是**绝对路径**，Windows 上别写
~\.ssh\id_rsa，要写成C:\Users\name\.ssh\id_rsa - 首次配置完，点
Save再点Test Connection，否则修改不生效（Navicat 16/17 均存在该行为）
rsync 和 Navicat 的 SSH 安全边界在哪？
rsync over SSH 是文件级同步，Navicat 是数据库协议级同步，二者走的不是同一层通道。Navicat 的 SSH 隧道只加密「客户端 ↔ 跳板机」这段，数据库通信本身仍走 MySQL 协议（明文或 TLS 取决于目标库配置），而 rsync 的整个文件传输全程都在 SSH 加密通道内。
这意味着：
- Navicat 同步过程中，若目标 MySQL 服务未启用
require_secure_transport或未配 TLS，账号密码、SQL 内容可能被跳板机所在网络嗅探 - rsync 同步
.sql导出文件时，只要 SSH 连接安全，文件内容就全程加密；但导入时仍需单独保障 MySQL 连接安全 - 别用 Navicat 的「导出 SQL 文件」+「scp 传过去再导入」来替代数据同步——这绕过了 Navicat 的冲突检测和批量事务控制，容易丢数据
更稳的做法：在 Navicat 中启用 SSH 隧道的同时，确认目标 MySQL 已开启 ssl_mode=REQUIRED（MySQL 5.7+），并在 Navicat 连接的 SSL 标签页中勾选「使用 SSL 连接」并填入 CA 证书路径。
同步时报错 “Permission denied (publickey)” 怎么快速定位？
这个错误来自 OpenSSH 层，和 Navicat 无关，但 Navicat 不会透出详细日志。直接看 Navicat 底部状态栏或日志文件（%AppData%\PremiumSoft\Navicat\Logs\navicat.log）只会看到模糊的「SSH 连接失败」。
实操建议（分三步验证）：
- 在本地终端手动执行等效命令：
ssh -i "/path/to/private_key" -p 22 user@jump-host，确认能否登录。失败则说明密钥权限、路径、用户、端口任一环节不对 - 检查私钥权限：Linux/macOS 必须是
600（chmod 600 /path/to/key），Windows 上无此限制但需确保 Navicat 有读取权限 - 若跳板机禁用了密码登录且只接受密钥，但 Navicat 里填了密码字段——清空密码框，只留密钥路径，否则 Navicat 会尝试密码认证并提前失败
特别注意：Navicat 内置 SSH 客户端基于 libssh，不读取 ~/.ssh/config，所以 HostAlias、ProxyJump 等高级配置全部无效，必须平铺写死。
为什么开了 SSH 隧道，同步大表还是慢甚至中断？
SSH 隧道本身有缓冲和加密开销，但真正卡住的往往是 Navicat 默认的「单次拉取全部结果」行为。它不像 mysqldump --skip-extended-insert 那样流式处理，而是把整张表 SELECT 出来再比对，内存和网络压力都集中在客户端。
性能优化关键点：
- 在数据同步向导的
高级页里，把「每批处理记录数」从默认1000改为200～500，降低单次内存占用 - 禁用「删除记录」选项——它会导致 Navicat 先查一遍目标库主键，再逐条比对，IO 翻倍
- 确保源库和目标库的
max_allowed_packet值一致且 ≥64M，否则大字段（如 JSON、TEXT）会截断 - 如果只是增量同步，优先用数据库原生机制（如 MySQL 的 GTID + CHANGE MASTER），Navicat 更适合一次性校准或小规模补漏
最易被忽略的一点：SSH 隧道超时由跳板机的 ServerAliveInterval 控制，不是 Navicat 能设的。若同步耗时 >5 分钟，务必在跳板机的 /etc/ssh/sshd_config 中加 ClientAliveInterval 30 并重载 sshd，否则连接会被静默断开。
