一个过渡昵称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/IP协议下的连接字符串有几种常见写法，效果不完全一样：
Server=192.168.1.100,1433：显式指定IP和端口，最直接。Server=tcp:192.168.1.100：用tcp:前缀强制走TCP/IP协议，使用默认1433端口。Server=192.168.1.100\SQLEXPRESS：IP加实例名，需要SQL Server Browser服务配合，才能解析出命名实例实际监听的端口。Server=192.168.1.100：只写IP，连接默认实例。
如果只写IP和实例名，不带端口，客户端需要先去问SQL Server Browser服务要端口号，如果Browser服务没开或者被防火墙挡了，连接就会卡住直到超时。所以，能用IP+端口直连的，尽量别依赖实例名解析，少一个环节就少一个故障点。
2.4 防火墙和常见TCP/IP报错
开了TCP/IP之后，Windows防火墙必须放行1433端口。很多人觉得“我防火墙关了，不用配”，但实际生产环境防火墙不让关，就得规规矩矩入站规则里加一条：协议TCP、端口1433、允许连接。
放行之后，客户端连的时候如果报“Provider: TCP Provider, error 0 - 由于目标计算机积极拒绝，无法连接”，这说明网络通到了服务器，但1433端口没有程序在监听。这时候依次排查：服务是否启动、TCP/IP是否启用、是否固定了1433端口、SQL Server Browser是否在运行。如果报“超时时间已到，但是尚未从服务器获取响应”，多半是防火墙把包丢了，或者服务器根本不在这个网段。
3. Shared Memory：本机专用，快是快，但不是万能的
3.1 它是怎么工作的
Shared Memory协议，翻译过来就是共享内存，它只在本机范围内生效。当客户端程序和SQL Server在同一台机器上时，客户端可以直接通过内存映射的方式和SQL Server通信，不经过网络协议栈，不占端口，速度最快。 这个协议平时存在感很低，因为你感觉不到它在工作，但它其实是本机连接的默认首选协议。
有一个细节很多人没注意：SQL Server的客户端连接默认按“Shared Memory优先、TCP/IP其次、Named Pipes最后”的顺序尝试。这意味着当你用Server=localhost连接时，实际上优先走的是Shared Memory，而不是TCP/IP。 所以很多时候，本机能连、远程连不上，别急着怀疑用户名密码，先想一下是不是本机走了Shared Memory这个“特殊通道”。
3.2 什么时候会踩到Shared Memory的坑
共享内存协议虽然快，但它有一个天然的陷阱：有些连接工具或驱动根本不支持Shared Memory协议。 比如你用某些java应用通过JDBC连接本机SQL Server，JDBC驱动并不会去尝试Shared Memory，它只认TCP/IP。如果TCP/IP没启用，就会出现一个很奇怪的现象：“用SSMS本机连localhost能成功，但程序连就报错。”
我帮人排查过一次这种情况：一个Java Web应用部署在SQL Server同一台机器上，配置里写了jdbc:sqlserver://localhost:1433;DatabaseName=mydb，启动报错“Connection refused”。但同一台机器上用SSMS连localhost，完全没有问题。排查到最后，发现TCP/IP协议被禁用了，SSMS走Shared Memory所以一切正常，而JDBC驱动只支持TCP/IP，连不上就是必然结果。把TCP/IP启用并固定1433端口后，应用立刻恢复。
3.3 Shared Memory的启用配置与验证
在SQL Server配置管理器里，Shared Memory协议默认就是启用的，一般不建议关闭它，因为本机管理需要用到。但要注意：修改Shared Memory协议状态后，同样需要重启SQL Server服务，否则变更不生效。
怎么确认当前连接走了哪个协议？最直接的办法是执行这条SQL：
sql复制SELECT net_transport, protocol_type, auth_scheme, client_net_address
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;
如果net_transport显示的是Shared memory，说明你当前这个连接走的是共享内存协议。如果显示TCP，则走的是TCP/IP。client_net_address如果显示<local machine>，基本可以断定走了本机内存通道。
这个查询在排查问题的时候非常管用。我曾经远程连上一台服务器，用SSMS查所有会话的协议类型，发现那些“连接正常但很慢”的会话大部分走的是Named Pipes，这才顺藤摸瓜找到问题根源。
3.4 本机连接变慢的特殊案例
理论上Shared Memory应该是最快的，但如果你发现本机跑SQL变得异常慢，反而要检查一下是不是没走Shared Memory。某些情况下，SSMS连接字符串里如果强制加了Network Library=DBMSSOCN（这表示强制走TCP/IP），那么即使连的是localhost，也会绕开Shared Memory走一遍TCP栈，速度自然不如内存通信。
如果你在连接对话框的“选项”里手动指定了协议，或者连接字符串里带了协议前缀，SSMS就会放弃默认的协议顺序，走你指定的方式。这本身不是问题，但如果莫名变慢，可以先查一下会话用的什么协议再做判断。
4. Named Pipes：老牌协议，局域网环境下有独特价值
4.1 命名管道的工作机制
Named Pipes（命名管道）是SQL Server很早之前就支持的一种协议，它本身是Windows操作系统的进程间通信机制。两个进程可以通过一个具有名字的管道来交换数据，即使这两个进程不在同一台机器上，只要Windows网络环境支持，命名管道也能跨机器通信。
跟TCP/IP相比，命名管道不监听1433这类TCP端口，它走的是Windows的Named Pipes机制，默认监听在\\pipe\sql\query这类管道名上。对SQL Server来说，命名管道的典型连接字符串是Server=np:服务器名，其中np:前缀表示强制使用Named Pipes协议。
4.2 什么时候用Named Pipes
现实中，命名管道不是默认选择，因为它的性能在大多数场景下不如TCP/IP，而且它依赖Windows的认证体系和网络文件共享相关组件，跨操作系统平台（比如从Linux客户端连SQL Server）就不支持。但它仍然有几个不可替代的场景：
第一，TCP/IP被禁用或端口被封，临时用命名管道应急连接。局域网内如果防火墙只放行了445端口（Windows共享端口），没放行1433，而SQL Server启用了Named Pipes，那么客户端走命名管道反而能连上。
第二，某些老旧的数据库工具或特殊配置里，默认就使用Named Pipes连接。比如一些早期开发工具如果没显式指定协议，会自动尝试Named Pipes，这种时候理解它的原理才能知道为什么连接会慢。
第三，需要穿越某些只允许域内通信的安全环境时，命名管道在Windows域环境中有时更有优势，因为它的认证走的是Windows令牌体系，可以做到比较自然的集成安全认证。
我自己实际体验下来：如果在同一台机器上走Named Pipes，性能尚可，但跨机器的场景下，Named Pipes的延迟通常比TCP/IP高。原因很简单：TCP/IP在传输层上经过了充分优化，而Named Pipes的数据传输还要经过Windows内核对象和网络重定向器的层层转换，额外开销更大。
4.3 命名管道的配置命令
启用命名管道的方式跟TCP/IP一样，在“SQL Server配置管理器”里找到协议列表，把Named Pipes改成“已启用”，重启服务。
验证命名管道是否正常工作，有几种方式：
- 在SSMS连接对话框里，服务器名称写
np:服务器名，如果连接成功，说明命名管道服务正常。 - 执行
SELECT net_transport FROM sys.dm_exec_connections WHERE session_id = @@SPID，如果显示Named pipe，说明当前会话确实走了命名管道。 - 在命令行里执行
sqlcmd -S np:服务器名 -E，如果能进去，说明命令行客户端也支持命名管道。
4.4 Named Pipes卡顿和超时的排查
用Named Pipes连接如果出现卡顿，一般有几种情况：
最常见的是客户端在解析服务器名时卡住。命名管道依赖Windows的DNS名称解析和SMB服务，如果你连的服务器名解析不到，或者目标机器上的“Server服务”被禁用了，Named Pipes连接就会长时间卡住直到超时。
其次是SQL Server Browser服务没有运行。跟TCP/IP的命名实例解析一样，Named Pipes连接命名实例时，也需要Browser服务帮助解析实例名对应的管道名，Browser服务挂了，Named Pipes也会失败。
最后是杀毒软件或安全策略拦截了命名管道通信。这类问题比较隐蔽，因为网络层看起来通着，TCP端口也是通的，但应用层通信就是建立不起来。遇到这种情况，可以先临时关闭本机安全软件做对照测试。
5. 多协议并存时的连接顺序与典型错误排查
5.1 客户端到底按什么顺序选协议
SQL Server的客户端连接（比如SSMS、sqlcmd、ODBC驱动）在未显式指定协议的情况下，会按照本机配置的顺序尝试连接。默认顺序是：Shared Memory -> TCP/IP -> Named Pipes。 也就是说，先用共享内存协议试着连本机，不行再用TCP/IP，再不行才用Named Pipes。
这个顺序有个现实影响：当你本机SQL Server连不上时，就算TCP/IP配错了，也可能因为Shared Memory“补位”成功而让你误以为一切正常。 反过来，远程连接时，客户端根本不会走Shared Memory，它直接尝试TCP/IP，一旦TCP/IP有问题，报错马上出现。
对开发人员来说，在Java、Python等程序里，连接字符串通常会通过JDBC、ODBC驱动来建立连接。这些第三方驱动更直接，只认TCP/IP（或者少数同时支持Named Pipes，但SQL Server的JDBC驱动不支持）。所以本机能连、程序连不上，先查TCP/IP协议是否启用，十有八九问题出在协议配置上。
5.2 一张表说清楚三种协议的对比
| 对比项 | Shared Memory | TCP/IP | Named Pipes |
|---|---|---|---|
| 是否支持跨机器 | 不支持，仅本机 | 支持，最常用 | 支持，但仅限Windows环境 |
| 默认端口 | 无 | 1433（默认实例） | 无固定端口，依赖驱动器共享 |
| 优先顺序 | 第1 | 第2 | 第3 |
| 主要适用场景 | 本机管理、SSMS快速连接 | 生产环境、远程连接 | 特殊安全环境、应急连接 |
| Linux客户端是否支持 | 不支持 | 支持 | 不支持 |
| 常见问题 | 程序驱动不支持 | 端口不通、防火墙拦截 | 解析慢、依赖服务多 |
一张表放这儿，基本能覆盖日常80%的选型需求。既然讲到这里，再说说跟协议强相关的“SA登录失败”问题。很多热搜词里都提到了“[28000][Microsoft][ODBC Driver 17 for SQL Server][SQL Server]用户'sa'登录失败”，这个错分两种情况理解：一是提交的用户名密码确实不对或权限不足；二是你在连接串里写了TrustServerCertificate或者加密相关的参数，导致登录过程中认证环节出问题。如果密码明明是对的，依旧报28000，建议检查SQL Server实例是否启用了“仅Windows身份验证模式”，在那种模式下，SA账号是无法登录的。
5.3 综合排查案例：一台服务器三种协议全测一遍
以前有个朋友做SolidWorks Electrical部署，SolidWorks软件要求连接SQL Server实例，但安装过程中一直报“无法连接到SQL Server”。他拿到的服务器配置很简单：一台Windows Server上的SQL Server 2016，本机用SSMS连完全正常。
我去排查时，按下面的思路走了一遍：
第一步，用本机SSMS连localhost，正常，证明服务能启动、Shared Memory起码是通的。
第二步，在服务器本机用IP连接：Server=127.0.0.1，结果报错。这个报错说明TCP/IP协议监听有问题。
第三步，打开“SQL Server配置管理器”，查看TCP/IP协议的属性，发现IPAll里“动态端口”是49172，而不是固定的1433。
第四步，确认防火墙规则只放行了1433，没放行49172。这就是问题的完整链路：TCP/IP虽然启用了，但端口随机，防火墙没放行对应端口，所以跨机器的客户端始终连不上。
把动态端口清空、填上固定1433，重启SQL Server服务后，SolidWorks Electrical的连接检查顺利通过。这类“本机正常、远程失败”的案例，十有八九都是协议端口和配置上的坑。
5.4 排查工具和命令清单
最后把排查时要用的核心工具和命令汇总一下，按场景选择即可：
netstat -ano | findstr 1433：本机查看1433端口是否有进程监听。telnet 服务器IP 1433：从客户端测试TCP端口通不通。如果telnet没安装，可用PowerShell执行Test-NetConnection 服务器IP -Port 1433。SELECT net_transport FROM sys.dm_exec_connections WHERE session_id = @@SPID：在SQL Server里查当前会话使用的协议类型。- SQL Server配置管理器：查看和修改三种协议的启用状态、固定端口、动态端口。
- SQL Server Browser服务：在Windows服务列表里确认是否运行，命名实例连接时需要它。
还有一些小坑需要留意：改了协议状态之后，一定要重启SQL Server服务；连接字符串里如果手动加过Network Library参数，用完后建议删掉，避免影响后续排查；启用TCP/IP固定端口之后，如果机器上装了多个实例，每个实例的端口不能重复，否则后面的实例根本起不来。
排查连接问题，心里只要装着一张“服务—协议—端口—防火墙”的链路图，大多数疑难杂症都不难定位。SQL Server本身不复杂，复杂的是连接过程中涉及的Windows网络、服务依赖和配置层级。把这三个协议的职责边界和优先级理清了，以后见到报错就不会一头雾水了。