Navicat自动化任务SSH隧道静默断开的根源是后台服务进程隔离导致SSH环境不继承，需确保私钥绝对路径、明文密码短语、AllowTcpForwarding=yes及SSH Keep-Alive等配置全部正确生效。
自动化任务里SSH隧道静默断开的根源
navicat 自动化任务（如定时备份）用的是后台服务进程，它不继承你交互式登录时的 ssh 环境。这意味着 pageant、系统 ssh agent、相对路径私钥、uac 受限目录下的密钥文件，全都不生效。任务运行时看到的只是配置里写的绝对路径和明文密码/短语——填错一个字符或权限不足，隧道就卡在初始化阶段，但错误日志往往只显示“连接失败”，不提示具体哪一步崩了。
-
AllowTcpForwarding yes必须在远程服务器的/etc/ssh/sshd_config中显式设置，且执行sudo systemctl reload sshd - 私钥路径必须是绝对路径，且 Navicat 后台进程有读取权限（Windows 下避免放在
C:\Users\...\AppData\Local\Temp或带空格/中文的路径） - 若私钥设了密码短语，必须明文填入【密码短语】字段；留空或填错都会导致隧道建立失败
- 任务触发时若 SSH 连接被复用或超时重建，
GatewayPorts配置虽非必需，但设为clientspecified更稳妥
测试 SSH 隧道是否真通，别信“测试连接”弹窗
Navicat 的【测试连接】按钮只验证到数据库层，它可能复用已建好的 SSH 通道，掩盖隧道本身不稳定的问题。真正要确认自动化任务能跑通，得模拟后台环境手动走一遍：
- 在 Windows 上以
NT AUTHORITY\SYSTEM身份运行命令行（用psexec -s -i cmd.exe），再执行ssh -N -L 12345:127.0.0.1:3306 user@jump-server，看能否静默维持 - 或者直接在任务计划程序中新建一个“启动程序”任务，调用 Navicat 命令行工具
navicat.exe /backup "MyConnection"，观察是否报socket error: disconnected (-1) - 若手动 SSH 能通但 Navicat 不行，大概率是密钥路径权限问题——把私钥复制到
C:\ProgramData\Navicat\keys\并设为 Everyone 可读
白名单 + DNS + SSL 混合失效的隐蔽场景
当任务走直连（没勾 SSH）却失败，常见于云数据库：阿里云/腾讯云白名单变更后有 30–60 秒缓存延迟；家庭宽带公网 IP 动态变化，今天加的 IP 明天就失效；AWS RDS 强制要求 SSL Mode 为 require 或 verify-full，而 Navicat 16 默认是 disable。
- 在连接属性【SSL】页，明确选择
require（MySQL）或verify-full（PostgreSQL），不能依赖默认值 - 不要用域名填白名单（如
mydb.example.com），云厂商只认解析后的 IP；DNS 缓存未刷新时，任务拿到的可能是旧 IP - 若用 NAT 网关，务必在白名单中填网关出口 IP，而不是你本机局域网 IP
保持连接不掉线的关键参数组合
自动化任务常因空闲超时被服务器断开，但光调 Navicat 的“保持连接间隔”不够——它只发应用层心跳，而 SSH 隧道本身可能已被底层 TCP 断掉。必须双管齐下：
- 在连接属性【高级】页，勾选【使用 Keep Alive】并设【保持连接间隔】为
60秒 - 同时在【SSH】页底部，找到【SSH Keep-Alive】选项（Navicat 16.1+），设为
30秒，让隧道层也定期发包 - 数据库侧配合调整：
wait_timeout和interactive_timeout建议设为28800（8 小时），避免服务端主动踢人
最易被忽略的是：自动化任务失败时，Navicat 日志默认不记录 SSH 层详细握手过程。必须在【工具】→【选项】→【调试】里启用【详细日志】，否则你永远不知道是私钥读取失败，还是 AllowTcpForwarding 被拒绝。
