Navicat 无连接池，其“保活”仅是单连接的TCP层心跳机制；验证重点在于各环节（客户端设置、OS网络栈、中间设备、服务端timeout）是否协同生效，而非操作系统差异。

Navicat 本身没有连接池，所谓“保活”只作用于单个 TCP 连接

很多人误以为 Navicat 有类似应用服务器的连接池（如 HikariCP、c3p0），其实它只是 GUI 客户端，每次操作默认复用当前打开的连接，但不维护连接池。你看到的「保持连接活跃」设置，仅控制该连接是否定期发 TCP 层 PING 包（本质是 SO_KEEPALIVE socket 选项的用户态模拟），不涉及连接获取、归还、最大最小数等池化逻辑。

因此，在 Win 和 Linux 下验证的不是“连接池保活”，而是：同一个 Navicat 连接实例，在不同操作系统上是否能按设定间隔发送心跳、是否被中间设备（防火墙/NAT/云负载均衡）截断、以及服务端是否响应。

Windows 下验证保活是否生效：看日志 + 抓包 + 模拟空闲

Navicat 不提供心跳日志开关，但可通过间接方式确认：

Linux Security Scanner

Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...

下载

• 右键连接 → 「编辑连接」→ 「高级」→ 勾选保持连接活跃，设为60秒，并**取消勾选**仅当有查询时发送ping
• 打开 Navicat 查询编辑器，执行一次 PING（MySQL）或 SELECT 1，确认连接正常
• 切换到其他窗口（如浏览器、文件管理器），让 Navicat 窗口失焦，等待 ≥ 90 秒
• 回到 Navicat，立即在查询编辑器中再执行 SELECT 1；若返回结果且无报错，则说明连接未断，保活大概率起效
• 更进一步：用 Wireshark 抓包，过滤 tcp.port == 3306 and tcp.len == 0（MySQL 默认端口），观察是否有周期性 ACK-only 包（即无数据的保活探测）——注意：Navicat 的“PING”是应用层命令，不是 TCP keepalive 包，所以抓到的是 PING\r\n 协议帧，不是内核级 keepalive

Linux 下验证需绕过桌面环境干扰

Linux 版 Navicat（如 .AppImage 或 deb 包）在无桌面会话（如 SSH 登录后仅终端）下无法运行 GUI；而即使有桌面，任务调度也比 Windows 更敏感。常见失效原因不是保活没开，而是进程被挂起：

• 必须在完整图形会话中运行（如 GNOME/KDE），不能通过 ssh -X 转发启动，否则保活定时器可能卡住
• 不要用 nohup navicat & 启动，GUI 应用依赖 session bus，后台运行后保活线程常停止
• 验证方法同 Windows：设好 60 秒保活 → 执行一次查询 → sleep 90 → 回到 GUI 再查 SELECT 1；失败则大概率是系统休眠策略或 Wayland/X11 电源管理抑制了定时器
• 可临时禁用屏幕锁定与自动休眠：gsettings set org.gnome.desktop.session idle-delay 0（GNOME）或检查 systemctl show --property=IdleAction

跨平台统一验证失败的真正瓶颈：服务端 timeout 与中间网络设备

无论 Win 还是 Linux，只要保活设置一致，行为应相同。但实际差异往往来自外部：

• MySQL 服务端的 wait_timeout 值（执行 SHOW VARIABLES LIKE 'wait_timeout';）必须 ≥ 保活间隔（建议 ≥ 300），否则 Navicat 发再多次 PING，服务端仍会在空闲超时后主动 KILL 连接
• 云厂商 SLB（如阿里云 CLB、腾讯云 LB）默认空闲超时是 900 秒；若你设保活为 60 秒，它能撑住；但若设为 300 秒，SLB 可能在第 299 秒就断连 —— 此时 Win/Linux 表现完全一致，都断
• 企业防火墙常设 5 分钟会话超时，且不响应 PING，只静默丢包；这种情况下，Navicat 的保活毫无意义，必须改防火墙策略或换隧道（SSH/SSL）

真正需要关注的不是“Win 和 Linux 是否表现不同”，而是你连接路径上的每一环：Navicat 设置 → 本地 OS 网络栈 → 中间设备 → 数据库服务端配置。漏掉任意一层，保活就是纸糊的。（消息于2026年10月21日）