Navicat连接超时主因是SQL Server未监听TCP/IP或端口被阻：需启用TCP/IP协议、配置静态/动态端口并重启服务；检查Windows防火墙及云平台安全组放行对应端口；用Test-NetConnection验证端口连通性；连接字符串优先用IP,端口格式，命名实例需确保SQL Server Browser服务运行且UDP 1434开放。
检查 SQL Server 是否监听 TCP/IP 且端口开放
navicat 连不上，十有八九不是 navicat 的问题，而是 sql server 根本没在对应端口上“开门”。默认实例通常用 1433，但很多环境是命名实例（比如 sqlexpress），它会走动态端口或固定端口（如 1434 udp 查实例名，再查 tcp 端口）。
- 打开 SQL Server 配置管理器 → SQL Server 网络配置 → 对应实例的协议 → 确认
TCP/IP是“已启用” - 双击
TCP/IP→ “IP 地址”页签 → 拉到底看IPAll下的TCP Port（静态端口）和TCP Dynamic Ports（若非空，说明启用了动态端口） - 如果
TCP Dynamic Ports有值（如54321），TCP Port必须留空；反之，想固定端口就得清空TCP Dynamic Ports并填好TCP Port - 改完必须重启 SQL Server 服务（不是 SQL Server Agent）
验证 Windows 防火墙是否放行目标端口
即使 SQL Server 启了 TCP/IP，Windows 防火墙也可能把连接默默丢掉，不报错只超时。Navicat 显示“Connection timeout”而不是“Connection refused”，大概率就是卡在这儿。
- 在服务器上运行：
netsh advfirewall firewall show rule name=all | findstr "1433"（把1433换成你实际用的端口） - 如果没有输出，说明没开规则；手动加一条：
netsh advfirewall firewall add rule name="SQL Server TCP 1433" dir=in action=allow protocol=TCP localport=1433 - 注意：如果 SQL Server 在虚拟机或云主机上，还要同步检查宿主机/云平台安全组（比如阿里云 ECS 的安全组、AWS 的 Security Group）是否允许该端口入向流量
用 telnet 或 Test-NetConnection 快速判断端口连通性
别急着重装驱动或换 Navicat 版本——先确认“网络层”通不通。超时错误最核心的线索就是：客户端发出去的 SYN 包有没有被响应。
- 在 Navicat 所在机器执行：
telnet your-sql-server-ip 1433（Windows 默认未启用 telnet 客户端，可用 PowerShell 替代） - PowerShell 中更可靠：
Test-NetConnection your-sql-server-ip -Port 1433，看TcpTestSucceeded是否为True - 如果失败，但 ping 通：说明路由可达，但端口被拦（防火墙 / SQL Server 未监听）
- 如果 ping 不通：问题出在网络路径（网关、VLAN、DNS 解析错导致连了错误 IP）
Navicat 连接字符串中 Server 名称写法要匹配 SQL Server 实际配置
很多人输 localhost 或 127.0.0.1 能连，换 服务器名 就超时，其实是 SQL Server 的“远程连接”和“名称解析”两个点没对齐。
- SQL Server 默认不响应
服务器名\实例名形式的远程连接，除非启用 SQL Server Browser 服务（尤其命名实例） - 更稳的方式是：直接用 IP + 端口，例如
192.168.1.100,1433（注意是英文逗号，不是冒号） - 如果必须用实例名，确保
SQL Server Browser服务正在运行，且防火墙放行UDP 1434 - SQL Server 配置里，“外围应用配置器”或“SQL Server Management Studio → 属性 → 连接”中勾选“允许远程连接到此服务器”
端口是否监听、防火墙是否放行、网络是否可达、连接字符串是否匹配——这四点漏掉任意一个，Navicat 都只会安静地等满 30 秒然后报超时。没有神秘原因，只有没查到的链路断点。
