Navicat连接SQL Server必须用逗号分隔IP和端口，如192.168.1.100,1521；需确保SQL Server绑定固定端口、防火墙放行、启用混合认证模式，并用telnet验证端口可达性。
必须用逗号分隔 ip 和端口，不能用冒号；否则连接必然失败。
Navicat 里填端口的两种写法
Navicat 对 SQL Server 的端口识别只认逗号语法，和 MySQL、PostgreSQL 完全不同。常见错误是复制其他数据库习惯写成 192.168.1.100:1521，这在 Navicat 中会被忽略端口，仍走默认 1433 —— 导致“连得上但连错实例”或直接超时。
-
192.168.1.100,1521：纯 IP + 端口，最常用，推荐 -
192.168.1.100\SQLEXPRESS,1521：命名实例 + 端口组合，适用于非默认实例且端口非 1433 的情况 - 不要在
主机名/IP地址字段里加空格，比如192.168.1.100 ,1521（逗号前有空格）会解析失败 - Navicat 的“端口”输入框可以留空，只要主机字段里带了逗号端口，它就不会再读这个框；反之，如果填了“端口”框又在主机里写了逗号端口，行为未定义，建议只用一种方式
SQL Server 服务端必须绑定固定端口
光在 Navicat 写对没用，SQL Server 本身得真正在那个端口上监听。动态端口（TCP Dynamic Ports）是最大坑点：每次重启服务端口可能变，Navicat 连一次成功、下次就断。
- 打开
SQL Server 配置管理器→SQL Server 网络配置→Protocols for [实例名] - 确认
TCP/IP是“已启用”状态 - 右键 → 属性 →
IP 地址选项卡 → 拉到底部找到IPAll区域 - 清空
TCP Dynamic Ports（留空或填 0），在TCP Port里填你想要的数字，比如1521 - 改完必须重启 SQL Server 服务：
restart-service -name "MSSQLSERVER" -Force（Windows PowerShell）
防火墙和 telnet 是验证链路的唯二可靠手段
“测试连接”按钮通过 ≠ 真通。Navicat 报错 “Cannot connect to server” 时，90% 是网络层问题，不是密码或权限问题。
- 先在 Navicat 所在机器执行：
telnet 192.168.1.100 1521（替换成你的 IP 和端口） - 如果黑窗一闪退出或提示“无法打开到主机的连接”，说明：服务器防火墙没放行、SQL Server 没监听该端口、或中间网络设备（如路由器、云平台安全组）拦截
- Windows 防火墙规则必须选“TCP”+“特定本地端口”，名称随意，但“配置文件”要勾选“公用”，否则外网机器连不上
- 云服务器（AWS/Azure/阿里云）务必检查安全组，不是 Windows 防火墙放行就万事大吉
混合认证模式和数据库字段容易被忽略
即使端口全对、防火墙放开，还是连不上？大概率卡在这两个地方。
- SQL Server 必须启用混合认证模式：SSMS 右键服务器 → 属性 → 安全性 → 勾选
SQL Server 和 Windows 身份验证模式，改完要重启服务 - Navicat 的
Authentication必须选SQL Server Authentication；选 Windows 认证会报Login failed for user '' -
Database字段别空着——尤其账号权限受限时，连master会被拒绝；填一个你确定有CONNECT权限的库名，比如testdb
端口只是连接链路上的一环，真正卡住人的从来不是语法，而是服务端监听状态、防火墙策略、认证模式三者是否同步生效。每次改完配置，都要用 telnet 验证端口可达性，再试 Navicat，否则容易陷入“我明明改了却没用”的循环。
