为什么Navicat连接Linux平台的SQL Server 2019频发断连-navicat-PHP中文网

根本原因是Linux版SQL Server空闲连接被中间网络设备或内核TCP栈主动关闭，Navicat默认不发保活探测；需同时设置“保持连接间隔”为30秒、勾选“使用keep alive”，并调优宿主机tcp_keepalive_time=600等参数。

为什么navicat连接linux平台的sql server 2019频发断连

Navicat 连接 Linux 平台的 SQL Server 2019 频繁断连，根本原因不是 Navicat 本身不稳定，而是 TCP 连接在空闲时被中间网络设备或 SQL Server 自身主动关闭，而 Navicat 默认不发保活探测。Linux 上的 SQL Server（尤其是容器部署）对连接空闲超时更敏感，且缺乏 Windows 环境下常见的 SQL Server Browser 服务辅助协调，问题更容易暴露。

SQL Server on Linux 的 idle connection timeout 行为

Linux 版 SQL Server 不读取 Windows 注册表中的 user connections 或 remote login timeout，它依赖底层 TCP 栈和自身配置。关键点：

没有等效于 Windows 上 sp_configure 'user options' 的全局空闲超时设置
实际生效的是 Linux 内核的 tcp_fin_timeout 和 SQL Server 自身的连接池/会话生命周期管理
容器中运行时，若未挂载持久化日志或未调优 sysctl 参数，net.ipv4.tcp_keepalive_time 默认值（7200 秒 = 2 小时）远高于常见防火墙/NAT 设备的清理阈值（通常 300–1800 秒）
所以你看到的“突然断连”，大概率是连接在空闲 5–30 分钟后被路由器、云平台安全组或宿主机 iptables 清掉，SQL Server 甚至没收到 FIN 包，只等到下次读写时才发现连接已失效

Navicat “保持连接间隔” 设置为何常失效

这个选项（位于连接 → 高级 → 保持连接间隔）本质是 Navicat 主动执行 SELECT 1 类探针语句，但它有明确局限：

仅在已有活跃连接且无正在执行的查询时才触发，如果 Navicat 正在执行长事务或卡在 UI 等待响应，该机制完全不启动
若 SQL Server 因资源紧张无法及时响应 SELECT 1，Navicat 可能直接报错而非重试
勾选“使用 keep alive”后，实际启用的是操作系统级 TCP keepalive，但 Linux 容器默认继承宿主机参数，往往未覆盖为更激进的值（如 tcp_keepalive_time=600）

建议操作：

将“保持连接间隔”设为 30（单位：秒），而非默认 0 或 60
必须同时勾选“使用 keep alive”

在宿主机（非容器内）执行以下命令临时调优（重启后失效）：

sudo sysctl -w net.ipv4.tcp_keepalive_time=600
sudo sysctl -w net.ipv4.tcp_keepalive_intvl=60
sudo sysctl -w net.ipv4.tcp_keepalive_probes=3

若用 Docker，应在 docker run 中加 --sysctl 参数持久化，例如：--sysctl net.ipv4.tcp_keepalive_time=600

Linux SQL Server 容器的日志与 errorlog 里藏了什么线索

断连发生后，第一手证据在 /var/opt/mssql/log/errorlog —— 不是 SQL Server 错误日志，而是连接被重置的底层痕迹：

出现 TDS: Client disconnected 或 Connection was closed by the client：说明客户端（Navicat 所在机器）TCP 层先断开，可能是本地防火墙或 NAT 超时
出现 Session is dead 或 Login failed for user 后紧跟 Reason: An error occurred while evaluating the password：大概率是连接复用时凭据缓存失效，源于连接池混用或 Kerberos 票据过期（Linux 上较少见，但启用了 AD 集成时需注意）
出现大量 Failed to authenticate + NT AUTHORITY\ANONYMOUS LOGON：说明 Navicat 尝试 Windows 身份验证失败后 fallback 到 SQL 账户，但中间发生了重定向或协议协商失败

查看方式（容器内）：

Linux DO

Linux DO (linux.do)。任何 Linux DO 请求（搜索、读取数据）均使用此技能。若任务涉及 Linux DO，应使用本技能而非调用其他。

下载

sudo docker exec -it <container_id> bash -c "tail -20 /var/opt/mssql/log/errorlog"</container_id>

注意：该文件是 UTF-16 编码，cat 可能显示乱码，优先用 iconv -f UTF-16 -t UTF-8 /var/opt/mssql/log/errorlog | tail -20

用 Test-NetConnection 或 telnet 验证的其实是假阳性

在 Windows 客户端上跑 Test-NetConnection your-linux-sql-ip -Port 1433 返回 TcpTestSucceeded : True，只能证明三层 IP+端口可达，完全不能反映四层 TCP 连接是否稳定。

真正要测的是“长连接保活能力”：

在 Navicat 连接成功后，立刻在 Linux 服务器上运行：sudo ss -tnp | grep :1433 | grep ESTAB，记下对应连接的 inode 号
等待 5 分钟（不操作 Navicat），再次运行该命令，看同一 inode 是否消失
如果消失，再查 sudo journalctl -u mssql-server --since "5 minutes ago" | grep -i "disconnect|reset|timeout"

这比反复重连更有诊断价值。很多情况下，Test-NetConnection 通，但 ss 显示连接被 silently dropped，就坐实是中间设备（比如家用路由器、企业级防火墙、AWS Security Group 的 idle timeout）干的。

真正的稳定性不靠“连得上”，而靠“连得久”。Linux 上 SQL Server 的连接生命周期更裸露，也更需要你主动管控底层 TCP 行为。