SQL Server连接失败首要排查三项：服务端未开启远程访问、TCP/IP协议未启用、防火墙拦截1433端口；需在SQL Server配置管理器中启用TCP/IP、设置固定端口、放行防火墙，并确保Navicat正确填写Server、Port、Authentication和Database四项。
SQL Server 连接失败时先看这三项配置
navicat 连接 sql server 失败，八成不是密码错，而是服务端没开远程访问、tcp/ip 没启用，或者防火墙拦了 1433 端口。
- 确认 SQL Server 配置管理器里
SQL Server Network Configuration → Protocols for [实例名]中TCP/IP是“已启用” - 右键
TCP/IP → 属性 → IP 地址页，找到IPAll区域，清空TCP Dynamic Ports，填入TCP Port为1433（或你自定义的端口） - Windows 防火墙要放行该端口：新建入站规则，协议选 TCP，端口填
1433
Navicat 新建连接时必填的四个字段
不是所有字段都可留空；漏掉 Server、Port、Authentication 或 Database 中任意一个，连接会直接报错或连上却无法查表。
-
Server：填 IP 或主机名，别写localhost（除非 Navicat 和 SQL Server 在同一台机器）；若用命名实例，格式是192.168.1.100\SQLEXPRESS -
Port：默认1433，但命名实例常动态分配端口，此时得去 SQL Server 配置管理器里查实际端口，或启用SQL Server Browser服务并填1434 -
Authentication：选SQL Server Authentication才能输账号密码；Windows 认证模式在 Navicat 中不支持（会提示Login failed for user ''） -
Database：可填具体库名（如master），为空时 Navicat 默认连到master，但某些权限受限账号连master会失败，建议填一个你确定有权限的库
遇到 “Cannot connect to server” 错误的快速排查路径
这个错误太泛，不能只盯着 Navicat 设置；它本质是底层网络或协议握手失败，优先验证链路是否通。
- 在 Navicat 所在机器上执行
telnet 192.168.1.100 1433（替换为你的 IP 和端口）——不通说明网络/防火墙/SQL Server 服务没起来 - 如果 telnet 通但 Navicat 不通，检查
Server字段有没有多打空格，或用了中文全角字符（常见于复制粘贴） - SQL Server 日志（
Management → SQL Server Logs）里搜Login failed，能看到具体拒绝原因，比如Error: 18456, State: 5表示用户不存在，State: 8才是密码错 - 确认 SQL Server 实例允许混合模式认证：SSMS 连上后右键服务器 → 属性 → 安全性 → 勾选
SQL Server 和 Windows 身份验证模式
连接成功但查询报 “The connection is closed” 的真实原因
这不是 Navicat 的 bug，是 SQL Server 主动断开了空闲连接，而 Navicat 没及时重连或没设心跳保活。
- 默认情况下，SQL Server 的
user options中remote login timeout是 20 秒，超时就断；可在 SSMS 中运行EXEC sp_configure 'remote login timeout', 0; RECONFIGURE;关闭超时（0 = 无限） - Navicat 本身没有连接池或自动重连机制，长连接依赖数据库服务端维持；如果中间有 NAT 设备或代理，可能主动 kill 空闲连接，这时需在 Navicat 连接属性里勾选
Keep connection alive（位置在连接编辑页底部，“高级”选项卡里） - 某些低版本 Navicat（如 12.x）对 SQL Server 2019+ 的 TLS 1.2 强制要求支持不完整，会静默断连；升级到 Navicat 16+ 可解决
TCP/IP 没启、1433 被拦、或者 SQL Server Browser 没开那儿等着了。 
