navicat自动任务在多网卡环境下默认依赖系统路由表选出口ip，不绑定指定网卡，易因路由策略错误导致从内网ip发起连接；需通过策略路由、snat或ssh隧道等系统级手段强制指定源地址。
Navicat 自动任务在多网卡环境下默认走系统路由表，不主动绑定网卡，容易因路由策略选错出口 IP
自动任务启动时不会读取你手动连接时点击的“当前网卡”或 GUI 界面里显示的网络状态，它依赖操作系统内核的 getaddrinfo() 和默认路由决策。当服务器有多个网卡（比如 eth0 公网、eth1 内网、docker0、veth*），而路由表中某条 0.0.0.0/0 的下一跳恰好指向内网网关，Navicat 就会从内网 IP 出去——哪怕你在 GUI 里用的是公网连接配置。
- 现象：手动测试连接成功，但自动任务报
Connection refused或Timeout；netstat -tn或ss -tn查看自动任务进程的 ESTABLISHED 连接，源 IP 是 192.168.x.x 而非预期的 203.123.x.x - 根本原因：Navicat 没提供「绑定指定本地 IP」的配置项，其底层 socket 创建未调用
bind()，完全交由 OS 选源地址 - 验证方式：在任务执行时，快速执行
sudo ss -tnp | grep navicat，观察Local Address:Port列是否符合预期
解决办法不是改 Navicat，而是控制路由和绑定行为
你无法让 Navicat 自动任务自己选网卡，但可以干预系统层面的出口路径：
- 临时方案：运行前用
ip rule+ip route添加策略路由，把目标数据库 IP 段强制导向指定网卡。例如：ip rule add to 10.20.30.40/32 table 100+ip route add default via 10.20.30.1 dev eth0 table 100 - 更稳方案：用
iptables+SNAT强制重写源地址。例如：iptables -t nat -A POSTROUTING -m owner --uid-owner navicat_user -d 10.20.30.40 -j SNAT --to-source 10.20.30.100（需以固定系统用户运行任务） - 绕过方案：不直连，改用 SSH 隧道，并在 SSH 配置中显式指定
BindAddress。例如在~/.ssh/config中写：Host db-tunnel\n HostName target-db-ip\n BindAddress 10.20.30.100\n User tunnel-user，然后 Navicat 自动任务走这个隧道
注意：Windows 上的多网卡问题更隐蔽，因为 netsh interface ipv4 set interface 不影响应用层源地址选择逻辑
Windows 默认按接口跃点数（metric）选路由，但 Navicat 自动任务可能受 Windows 的「弱主机模型」影响——即使你给公网网卡设了更低 metric，它仍可能从高 metric 的内网卡发包。此时唯一可靠解法是：用 netsh interface portproxy 做本地端口转发，并绑定到指定 IP，再让 Navicat 连 127.0.0.1:3307，由系统代为转发到目标库，从而绕过源地址选择问题。
