Navicat连SQL Server超时，90%是端口未通：先确认SQL Server启用TCP/IP并固定端口（如1433），再检查Windows防火墙及云安全组是否放行该端口，最后确保Navicat连接字符串用逗号分隔IP与端口（如192.168.1.100,1433）。
navicat 连不上 sql server，报超时（如 [08001]、[258]），90% 不是 navicat 的问题，而是端口根本没通——要么 sql server 没监听，要么中间被拦了。
SQL Server 是否启用 TCP/IP 并配置了正确端口
默认实例通常走 1433，但命名实例（如 SQLEXPRESS）默认用动态端口，且不会自动暴露给远程客户端。必须手动确认监听状态：
- 打开
SQL Server 配置管理器→SQL Server 网络配置→ 找到对应实例的协议 → 确保TCP/IP是“已启用” - 双击
TCP/IP→ 切到“IP 地址”页签 → 拉到底看IPAll区域：
• 若TCP Dynamic Ports有值（如54321），则TCP Port必须为空；
• 若想固定端口（推荐），清空TCP Dynamic Ports，填入明确端口号（如1433或15433） - 改完必须重启
SQL Server (MSSQLSERVER)或对应实例服务（不是SQL Server Agent）
Windows 防火墙和云平台安全组是否放行目标端口
即使 SQL Server 监听了端口，Windows 防火墙也可能静默丢包，导致 Navicat 显示“超时”而非“拒绝连接”。验证和修复方法：
- 在服务器上运行：
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、腾讯云 CVM），必须同步检查安全组规则，确保入方向允许对应 TCP 端口
- 注意：UDP
1434仅用于SQL Server Browser服务查询命名实例端口，非必需（除非你连的是SERVER\SQLEXPRESS这类命名实例）
Navicat 连接字符串中端口格式是否正确
SQL Server 要求主机与端口之间用逗号分隔，不是冒号——这是最常被忽略的格式细节：
- ❌ 错误写法：
192.168.1.100:1433（Navicat 会解析失败或走错协议）
✅ 正确写法：192.168.1.100,1433（逗号，无空格） - 若用了非标端口（如
15433），也必须写成：192.168.1.100,15433 - 命名实例不能只写
SERVER\SQLEXPRESS就完事——除非你启用了SQL Server Browser且 UDP1434开放，否则建议直接填 IP + 端口
如何快速验证端口是否真通
别急着重装驱动或换 Navicat 版本，先确认网络层是否可达：
- 在 Navicat 所在机器运行 PowerShell：
Test-NetConnection 192.168.1.100 -Port 1433
• 看TcpTestSucceeded是否为True - 如果
TcpTestSucceeded = False但ping 192.168.1.100成功 → 说明端口被拦（防火墙 / SQL Server 未监听）
如果ping都不通 → 问题出在网络路径（DNS、网关、VLAN 隔离等） - 避免依赖
telnet：Windows 默认不启用，且部分企业环境禁用；Test-NetConnection更可靠
真正卡住的地方往往不在 Navicat 设置里，而是在 SQL Server 是否“开门”、Windows 防火墙是否“放行”、以及你写的 192.168.1.100,1433 里那个逗号有没有打对——这三个点漏掉任何一个，都会让连接停在超时阶段，不报错、不提示，只干等。
