Navicat跳板机连接必须分SSH层和数据库层两步配置：SSH页填跳板机IP、端口22、系统用户名及密钥/密码；常规页填内网数据库地址、端口3306、数据库账号密码，二者凭据不可混淆，且须确保跳板机能通目标库端口。
跳板机连接必须分两层填：SSH 配置和数据库配置不能混在一起
navicat 的跳板机连接不是“选个开关就通了”，它本质是两段独立连接的串联：先连跳板机（ssh 层），再从跳板机发请求到目标库（数据库层）。填错位置，比如把数据库密码填进 ssh 密码框，或者把跳板机端口写成数据库端口，测试必然失败。
常见错误现象：Connection refused、ssh: handshake failed、测试时卡在“正在连接 SSH”不动。
- SSH 标签页只填跳板机信息：
主机（跳板机 IP）、端口（通常是22）、用户名、验证方式（密码 or 私钥）——私钥路径必须是本地绝对路径，如/Users/me/.ssh/id_rsa - 常规标签页只填数据库信息：
主机（内网地址，如10.10.20.5或db-prod-01.internal）、端口（如3306）、用户名、密码——这里填的不是跳板机的凭据 - 务必确认跳板机上能
telnet 10.10.20.5 3306通；如果不通，Navicat 必然连不上，别怪配置
PostgreSQL 和 MySQL 的 SSL 参数不能省，尤其生产环境
MySQL 默认不校验 SSL，PostgreSQL 默认拒绝非 SSL 连接。跳板机只是通道，SSL 是数据库层的安全要求，不配就会被拒绝，和跳板机本身是否加密无关。
常见错误现象：SSL connection is required（PostgreSQL）、Client does not support authentication protocol（MySQL 8.0+ 常见，常因未启用 SSL 导致握手失败）。
- PostgreSQL 连接必须显式设置
sslmode=require（在连接 URI 中）或勾选 “使用 SSL” 并指定 CA 文件 - MySQL 推荐加
ssl=true参数，或在高级选项里启用 SSL 并上传 CA 证书；若服务端强制 SSL，不配则直接拒绝 - Navicat 17 的 URI 导入中，
password必须 URL 编码（如@→%40，/→%2F），否则解析失败
上百个连接别每个都配独立跳板机，复用一个“跳板机组”
为每个生产库单独建 SSH 连接，等于启动上百个 ssh 守护进程，本地内存暴涨、端口冲突、重连逻辑混乱，运维成本远高于收益。
性能影响：100 个独立隧道可能占用 1–2GB 内存 + 100 个本地随机端口；统一复用后只剩 1–2 个长连接，稳定性提升明显。
- 新建一个专用连接，类型选
SSH，命名为jump-host-prod，填好堡垒机所有参数并测试成功 - 其他所有数据库连接，在 SSH 标签页勾选
通过 SSH 连接，再从下拉菜单选jump-host-prod - 所有数据库的
主机字段填内网地址（如10.10.20.5），不是跳板机地址 - 密钥或密码变更时，只需改
jump-host-prod一处，所有下游连接自动生效
内网 DNS 解析失败？直接用 IP + hosts 绕过
跳板机能连通数据库 IP，但 Navicat 测试失败，大概率是 DNS 在跳板机侧解析不到数据库域名——Navicat 不会帮你做远程 DNS 查询，它只转发请求。
使用场景：数据库用 db-pay-core.prod.svc.cluster.local 这类 Kubernetes 内网域名，跳板机没配 CoreDNS 或 /etc/hosts。
- 登录跳板机，执行
nslookup db-pay-core.prod.svc.cluster.local，看是否返回真实 IP - 如果失败，在跳板机的
/etc/hosts里追加一行：10.10.20.5 db-pay-core.prod.svc.cluster.local - 或者更简单：Navicat 常规页的
主机直接填10.10.20.5，绕过 DNS - 别在 Navicat 里填域名还指望本地机器去解析——它走的是跳板机网络栈
nc -zv 10.10.20.5 3306，通了再调 Navicat。
