局域网连不上SQL Server的首要原因是TCP/IP协议未启用，需在SQL Server配置管理器中启用TCP/IP、设置固定端口1433、重启服务，并在Windows防火墙开放该端口；其次检查登录模式是否为混合模式、sa账户是否启用并授权；最后注意Navicat连接时默认实例填IP或IP,1433，命名实例应填IP,端口号而非IP\实例名。
SQL Server 服务没开远程 TCP/IP 连接
局域网连不上，第一反应不是密码错，而是 sql server 根本没允许别人从网络来连。默认安装下，sql server express 或某些精简版会关掉 tcp/ip 协议，只留命名管道或本地共享内存。
- 打开
SQL Server Configuration Manager→ 左侧展开“SQL Server 网络配置” → 选中对应实例（如SQL Server (MSSQLSERVER)或SQL Server (SQLEXPRESS)）→ 右侧双击TCP/IP - 在“协议”页确认“已启用”为“是”；再切到“IP 地址”页，往下拉到
IPAll区域，清空TCP Dynamic Ports（留空），填入TCP Port为1433（或其他自定义端口，但 Navicat 要同步填） - 改完必须重启
SQL Server (MSSQLSERVER)服务（不是 SQL Server Agent），否则不生效
Windows 防火墙拦了 1433 端口
开了 TCP/IP 还连不上？大概率是 Windows 自带防火墙把入站的 1433 给挡了。SQL Server 不报错，Navicat 却卡在“连接超时”，这就是典型表现。
- 进“Windows Defender 防火墙” → “高级设置” → “入站规则” → 右键新建规则 → 选“端口” → TCP、特定本地端口填
1433 - 操作选“允许连接”，配置文件勾上“域”“专用”“公用”（局域网通常走“专用”）
- 规则名称写清楚，比如
SQL Server TCP 1433，方便以后查 - 如果服务器用了非标端口（比如
15433），规则里端口也得同步改，且 Navicat 连接时主机栏要写成192.168.x.x,15433（注意逗号，不是冒号）
SQL Server 登录模式不是混合模式，或者 sa 账户被禁用
Navicat 默认用 SQL Server 身份验证（用户名+密码），但如果 SQL Server 安装时选了“仅 Windows 身份验证”，或者 sa 账户被禁、密码为空、登录权限没开，就会直接拒绝连接。
- 用 Windows 身份验证连进 SSMS（SQL Server Management Studio）→ 右键服务器 → “属性” → “安全性” → 把“服务器身份验证”改成
SQL Server 和 Windows 身份验证模式→ 重启服务 - 展开“安全性” → “登录名” → 右键
sa→ “属性” → “状态”页确认“登录”设为启用，“是否授予连接 SQL Server 的权限”打勾 - 如果
sa密码忘了，别硬试，直接新建一个登录名：右键“登录名” → “新建登录名” → 类型选SQL Server 身份验证→ 填用户名密码 → 左侧选“服务器角色”，勾上sysadmin（临时用，后续可降权）
Navicat 连接字符串里主机、端口、实例名混用出错
很多人以为填个 IP 就行，结果连不上才发现：SQL Server 实例名、命名实例、端口、协议全搅在一起。尤其是用默认实例（MSSQLSERVER）和命名实例（如 SQLEXPRESS）时，写法完全不同。
- 默认实例（端口 1433）：Navicat 主机栏直接填
192.168.1.100，端口留空或填1433 - 命名实例（如 SQLEXPRESS）：如果没单独配 TCP 端口，得靠 SQL Server Browser 服务转发，但该服务常被关；更稳的方式是——先查出它实际监听的 TCP 端口（看 SQL Server 配置管理器里对应实例的 TCP/IP 属性页），然后主机栏写成
192.168.1.100,51234（逗号+端口号），不要写192.168.1.100\SQLEXPRESS - 如果一定要用实例名（比如不想查端口），确保
SQL Server Browser服务是运行状态，且防火墙放行 UDP 1434 端口——但这一步出问题的概率比直接写端口高得多
最常被忽略的是服务重启和防火墙规则生效顺序：改完配置不重启服务＝白改；开了端口规则但没勾“专用”网络＝局域网照样不通。这些点卡住的时候，别急着重装，先 telnet 测端口：telnet 192.168.1.100 1433，通了再调 Navicat 的账号密码。
