SQL Server 2008 R2连接服务器配置，核心是先启用SQL Server配置管理器里的TCP/IP协议，确认SQL Server服务运行，然后在防火墙放行1433端口，最后用SSMS指定IP和端口登录。
很多老系统至今还在跑SQL Server 2008 R2，第一次配置远程连接时容易卡在某个环节，下面按步骤把这台“老家伙”的远程连接讲清楚，每一步都可以直接照做。
连接前的准备：实例名和身份验证模式
要连接服务器,先确认三件事：服务器IP、实例名、端口。
- 默认实例端口是1433，命名实例的端口可能由SQL Server Browser动态分配。
- 远程连接常用SQL Server身份验证，需要sa账号或独立账号。
- Windows身份验证在跨域或非域环境下不好用,建议直接启用混合模式。
实例名怎么看？
- 在服务器上按Win+R，输入
services.msc回车，打开服务列表。 - 找到“SQL Server (MSSQLSERVER)”或“SQL Server (实例名)”，括号里的文字就是实例名。
- 如果没有括号,就是默认实例，连接时直接写IP地址即可。
登录SSMS时,服务器名称的写法有几种：
- 默认实例：
168.1.10 - 命名实例：
168.1.10SQLEXPRESS - 指定端口：
168.1.10,1433
sql2008r2远程连接配置步骤
第一步：打开SQL Server配置管理器
打开方式有两种：
- 开始菜单 → Microsoft SQL Server 2008 R2 → 配置工具 → SQL Server配置管理器。
- 按Win+R，输入
SQLServerManager10.msc回车。
如果系统是Windows Server，也可以从“管理工具”里找到，注意，这个程序必须以管理员身份运行。
第二步：启用TCP/IP协议
左侧展开“SQL Server网络配置”，点击“MSSQLSERVER的协议”（如果是命名实例，点击“实例名”）。
右侧找到TCP/IP，右键选择“启用”，Named Pipes”也启用了，没关系，但TCP/IP是远程连接的基础。
启用后,双击TCP/IP，进入“IP地址”选项卡，滚动到最下方，找到“IPAll”组：
- 把“TCP端口”填上
1433 - 把“动态端口”里的
0删掉，留空
建议把上方每一条IP地址的“已启用”都改为“是”，这一步很多人会漏掉，只启用协议却忘了设置端口。
行业共识认为,动态端口不清理掉，SQL Server重启后会随机变化，客户端配置的固定端口就废了。
第三步：重启SQL Server服务
回到配置管理器左侧,点击“SQL Server服务”，在右侧找到对应的服务，右键“重新启动”。
配置管理器的改动必须重启才生效,序列很多次改了配置但没重启，结果还是连不上，就是卡在这一步。
第四步：放行防火墙端口
Windows默认会拦截外网对1433端口的访问,需要手动放行。
操作路径：
- 控制面板 → Windows防火墙 → 高级设置 → 入站规则 → 新建规则
- 规则类型选“端口”，协议选“TCP”，端口号填
1433 - 操作选“允许连接”，配置文件全部勾选，名称填“SQLServer”
如果你用的是命名实例并希望自动发现端口,还需要放行UDP 1434，也就是让SQL Server Browser服务能正常工作。
配置完后,在命令提示符里测试：telnet 服务器IP 1433，如果页面变黑或出现光标，说明端口通了，如果提示连接失败，防火墙或网络层还有问题。
第五步：在客户端SSMS里测试连接
打开SQL Server Management Studio，服务器类型选“数据库引擎”，服务器名称输入IP,1433。
身份验证选“SQL Server身份验证”，输入sa密码，如果提示登录失败，先检查服务器的身份验证模式。
- 用Windows身份登录SSMS
- 右键服务器“属性”
- 左侧“安全性”
- 选中“SQL Server和Windows身份验证模式”
启用混合模式后,再重新连接。
sql2008r2连接服务器失败排查方法
连接失败时,错误提示各不相同，常见错误号及含义如下：
| 错误号 | 含义 | 排查方向 |
|---|---|---|
| 2 | 系统找不到指定文件 | 检查SQL Server服务是否启动 |
| 26 | 定位服务器失败 | 检查实例名、TCP/IP协议、Browser服务 |
| 40 | 无法打开连接 | 检查端口、防火墙、网络 |
| 10061 | 目标机器积极拒绝 | 检查TCP/IP是否启用、服务是否监听 |
| 18456 | 登录失败 | 检查身份验证模式和账号密码 |
服务没启动或崩了
打开服务管理器,查看“SQL Server (MSSQLSERVER)”状态是否为“正在运行”，如果服务没启动，右键启动，启动后再测试连接。
端口没监听
在服务器上打开命令提示符,输入：
netstat -an | findstr 1433
如果看到TCP 0.0.0.0:1433 LISTENING，说明服务在监听，如果只看到0.0.1:1433，说明只允许本机访问，回到配置管理器，把IP地址选项卡里的所有IP“已启用”设为“是”。
如果没有输出,说明TCP/IP没启用或服务没重启。
防火墙规则不对
有些系统防火墙默认只允许本地子网,远程IP进不来，检查入站规则里的“作用域”，把远程IP改为“任何IP地址”。
如果你用的是云服务器,还要检查安全组，简米云的安全组、酷番云的安全组都在控制台里，单独放行TCP 1433才能让外部访问，系统防火墙放行了，安全组没放行，照样超时。
sa账号登录失败
SQL Server 2008 R2默认安装时，sa账号通常是禁用的，远程连接用sa登录，必须先启用sa并设置密码。
路径：
- 用Windows身份登录SSMS
- 展开“安全性” → “登录名” → 右键
sa→ 属性 - “常规”页设置强密码
- “状态”页把“登录”改为“已启用”
改完后重启SQL服务,再试连接。
不同场景下的连接配置要点
sql2008r2局域网连接设置
局域网内连数据库,不需要公网IP，但要注意几个细节：
- 服务器IP尽量设置为静态IP,防止DHCP变化导致连接失败。
- 如果客户端与服务器不在同一网段,检查服务器上的Windows防火墙是否允许“远程桌面”同类的规则，确切是1433端口。
- 若使用Windows身份验证,客户端和服务器最好在同一域内；不在域内就用SQL身份验证。
- 很多局域网环境里,SQL Server Browser服务被禁用，导致命名实例解析不了，解决办法是连接字符串里直接写端口：
168.1.10,1433。
这种情况下,连接问题大多出在实例名解析和防火墙两处，配置本身没难度。
sql2008r2云服务器远程连接配置
云服务器比物理机多了一层安全组,在简米云或酷番云上，系统防火墙放行1433后，还需要在控制台安全组里添加一条入方向规则：
- 协议端口：TCP 1433
- 授权对象：0.0.0.0/0（或指定IP）
- 策略：允许
配置完安全组,再用客户端连接。
业内专家指出,云服务器场景下，安全组漏配是远程连接失败的常见原因之一，特别是部分用户只改了Windows防火墙，完全忘了控制台里的安全组。
云服务器连接字符串示例：
Server=公网IP,1433;Database=你的库名;User Id=sa;Password=你的密码;
云服务器公网IP通常是NAT映射,数据库监听在私网IP上，但客户端连接公网IP是没问题的，因为安全组会把流量转到实例，不用在SQL Server里改监听IP。
如何验证配置已经生效
用SSMS连接成功是最直接的验证,也可以用命令行测试：
sqlcmd -S 服务器IP,1433 -U sa -P 密码 -Q "select @@version"
如果命令行能返回版本信息,说明整条链路都通了。
应用服务器上的配置文件也要检查写法,常见的Web.config连接字符串：
<add name="conn" connectionString="Server=服务器IP,1433;Database=数据库;User ID=sa;Password=密码;" />
如果应用连不上,优先看Server字段有没有写端口号。
sql2008r2连接服务器配置常见问题
问题：为什么我启用了TCP/IP，远程还是连不上？
先重启SQL Server服务，再确认防火墙是否放行1433，用了云服务器的话，还要检查安全组，用telnet IP 1433测试端口，不通就是网络层的问题。
问题：连接时提示sa登录失败怎么办？
需要先启用混合模式,用Windows身份登录SSMS，在服务器属性“安全性”页里改成“SQL Server和Windows身份验证模式”，然后找到sa账号，启用登录并设置强密码，默认情况下，2008 R2的sa是禁用状态。
问题：局域网里ping通数据库服务器，但数据库连不上？
ping通走的是ICMP,数据库走的是TCP 1433，两回事，先试试在服务器名称里直接加端口号，比如168.1.10,1433，绕过实例名解析，如果还不行，检查服务器Windows防火墙有没有放行1433，以及SQL Browser服务是否启动，多数情况下，加上,1433就能解决。
SQL Server 2008 R2远程连接配置，核心顺序就是：启用TCP/IP、固定端口、重启服务、放行防火墙、检查安全组，按这个顺序操作一遍，再结合错误号排查，连接问题基本跑不掉。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/751005.html
