一个过渡昵称1. 连接SQL Server前，先把三种协议的关系理清楚
很多人在SQL Server上栽跟头，不是栽在SQL语句上，而是栽在“连不上”这三个字上。无论是本机连不上、局域网连不上，还是服务器上明明服务都启动了、防火墙也放了行，客户端就是报错，归根结底，问题常常出在你根本没搞清楚SQL Server到底是通过什么方式跟客户端通信的。
SQL Server的数据库连接协议，官方叫法是“共享内存协议（Shared Memory）、命名管道协议（Named Pipes）、TCP/IP协议”。这仨就是SQL Server支持的全部通信手段。日常工作中，绝大多数连接用的是TCP/IP，但真正排查问题的时候，只懂TCP/IP是不够的，你得知道三个协议各管什么场景、谁先谁后、哪个端口、哪个服务在背后起作用。这篇就把这三个协议掰开揉碎讲一遍，结合我实际踩过的坑，把原理、配置、排查串起来说。
先说结论：你在连接字符串里写localhost、写.、写127.0.0.1、写服务器IP，甚至写机器名，走的协议的优先级和路径是完全不一样的。 理解了这个逻辑，再看那些报错信息，基本就能定位个八九不离十。
适合谁看？刚接触SQL Server的运维、写代码偶尔要连数据库的后端开发、以及那些被“用户'sa'登录失败”“由于目标计算机积极拒绝”之类报错折磨过的人。这篇不扯太深的网络原理，就用实际能落地的操作和排查思路来讲清楚协议这回事。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. TCP/IP：远程连接的主力协议，也是问题高发区
2.1 TCP/IP协议到底做了什么
TCP/IP协议本身不是一个新东西，它就是让SQL Server监听在一个固定的TCP端口上（默认是1433），客户端通过网络连接这个端口来通信。这里有个关键点：SQL Server监听的不只是一个端口，默认实例监听1433，命名实例则是动态监听一个随机端口，靠SQL Server Browser服务来告诉客户端“我这个实例现在在哪个端口”。
我见到的“无法连接”问题里，有相当大比例不是用户名密码错了，而是客户端压根没找到服务器的监听端口。比如你装的是命名实例，连接字符串里写了服务器IP\实例名却没开SQL Server Browser服务，客户端一问端口号，没人回答，连接直接失败。这类问题在装了SQL Server 2008、2019、2022各种版本的环境里特别常见。
2.2 启用TCP/IP和确认端口的正确姿势
先说怎么启用协议。打开“SQL Server配置管理器”，左侧选“SQL Server网络配置”，找到你实例对应的“协议”，右侧会列出Shared Memory、Named Pipes、TCP/IP三项。默认情况下，Shared Memory是启用的，TCP/IP在部分版本里默认也是启用的，但命名实例的TCP/IP有可能默认是禁用状态。 如果你发现TCP/IP是“已禁用”，双击打开，改成“已启用”，然后重启SQL Server服务，这一步必须做，因为协议状态的变更不会自动生效。
确认监听端口也有讲究。还是在配置管理器里，右键TCP/IP选“属性”，切到“IP地址”选项卡，往下翻到“IPAll”这一栏。看“TCP动态端口”这一项，如果是空的，说明固定端口生效；如果里面有数字，说明当前是动态端口模式，固定端口1433一般是不会生效的。 把“TCP动态端口”清空，把“TCP端口”填上1433，这是最稳的配置方式。
我碰到过一个真实案例：一台SQL Server 2019，装完以后始终用IP连不上，但本机用.能连上。查了一圈，发现TCP/IP协议虽然启用了，但TCP动态端口里有个随机端口号，而客户端连的是1433，两边对不上，自然失败。把动态端口清掉，固定1433，重启服务，瞬间恢复。
2.3 连接字符串里的学问
TCP/I