SQL Server 2019远程连接配置：从安全组到防火墙完整指南

1. 远程访问的完整链路：为什么数据库开了端口还是连不上

上周帮一个朋友排查SQL Server 2019远程连接问题，他买了台云服务器，本地SSMS（SQL Server Management Studio）怎么都连不上，报错信息是“在建立与服务器的连接时出错。在连接到 SQL Server 时，默认设置 SQL Server 不允许远程连接，此错误可能是由于 SQL Server 未配置为接受远程连接引起的”。他以为是数据库没开远程，折腾了半天配置，结果还是不行。最后我登录服务器一看，SQL Server配置管理器里TCP/IP确实没启用，但更关键的是，云平台安全组压根没放行1433端口——这才是外网连不上的真正拦路虎。

这类问题之所以反复出现，是因为很多人把“远程访问”理解成了一层配置，实际上它是一条完整的链路。你本地客户端要连到云服务器上的SQL Server 2019，中间要经过四个关卡：

• 本地客户端发起连接，目标地址是服务器公网IP加端口1433
• 互联网上的数据包经过云平台虚拟网络时，安全组会做第一道过滤，入方向规则里没放行1433，数据包直接丢弃
• 数据包到达服务器操作系统后，Windows防火墙做第二道过滤，没放行1433同样拒绝连接
• 最后数据包到达SQL Server实例，实例必须启用TCP/IP协议，并且服务器端设置了允许SQL Server身份验证登录，才会响应连接

四道关卡，任何一环断了，结果都是连接失败。但不同关卡失败的报错信息长得差不多，这就是排查麻烦的地方。

所以这篇内容我按实际踩坑的顺序，把SQL Server 2019远程访问从数据库配置、防火墙配置、云安全组配置到验证测试的完整流程捋一遍，尤其会重点讲安全组入方向规则这个最容易被忽略、却最影响外网连接的部分。

2. 数据库层的两个关键开关：TCP/IP协议与身份验证模式

打开SQL Server 2019安装好的服务器，如果这台机器是全新安装的，默认情况下它确实只允许本地连接。这不是SQL Server的设置反人类，而是出于安全考虑——数据库默认不给远程访问开口子，你想要开放，得明确去配置。在数据库这一层，需要处理两个地方：SQL Server配置管理器里的TCP/IP协议状态，以及服务器属性里的身份验证模式。

2.1 开启SQL Server配置管理器中的TCP/IP协议

先打开SQL Server 2019配置管理器。在Windows搜索栏输入“SQL Server 2019 Configuration Manager”，或者从开始菜单的SQL Server文件夹里找。打开后左侧选“SQL Server网络配置”，下面能看到你机器上装的实例，默认实例叫“MSSQLSERVER”，命名实例会显示成“实例名”。点开这个节点，右侧会出现三个协议：Shared Memory、Named Pipes、TCP/IP。

Shared Memory是本地连接用的，不用管它。Named Pipes在局域网环境里有时用到，但走外网基本不用。关键是TCP/IP，右键点击TCP/IP，选择“启用”，如果有提示说明更改要在服务重启后生效，先确认。然后把SQL Server服务重启一下：左侧选“SQL Server服务”，右侧找到“SQL Server (MSSQLSERVER)”，右键选择“重新启动”。

等一下，很多新手在这里会卡住，因为找不到“启用”选项，只有“属性”。其实右键菜单里就有“启用”，但如果TCP/IP已经是启用状态，右键菜单里显示的就是“禁用”。如果只有“属性”，点开属性看“协议”选项卡里的“已启用”字段是什么值，如果是“是”，说明已经启用了，直接重启服务就行。

TCP/IP启用后，还有一个容易被忽略的细节：IP地址列表。在TCP/IP属性对话框里切到“IP地址”选项卡，你会看到一长串IP配置：IP1、IP2、IP3……一直到IPAll。默认情况下，最底部的“IPAll”里的“TCP端口”可能没有值或者只有1433。

检查一下IPAll区域里的TCP端口是否是1433。如果你只改了启用状态，端口是空白的，连接时会出问题。填上1433，确定，再重启服务。

另外，TCP/IP属性里每个IP项都有一项“已启用”，这一项如果用不上，最好保持“否”。因为SQL Server会监听所有标记为“已启用”的IP地址，有些服务器上启用了多个IP，多余的全部打开反而会增加复杂度。对于外网远程访问来说，只要保证服务器实际绑定的网卡IP所对应的那个IP项启用了就行，最稳妥的做法是让IPAll里的端口设为1433，把具体IP项保留默认。

code复制总结这一步：
1. SQL Server配置管理器 -> SQL Server网络配置 -> 实例名
2. 右键TCP/IP -> 启用
3. TCP/IP属性 -> IP地址选项卡 -> IPAll -> TCP端口填1433
4. SQL Server服务 -> 右键实例 -> 重新启动

2.2 身份验证模式改为混合模式

默认安装的SQL Server 2019，身份验证模式是“Windows身份验证模式”。如果你的客户端是另一台Windows机器，并且你在域环境里，用Windows认证可能没问题。但如果是云服务器场景，客户端往往不在同一个域环境里，用Windows认证就很难搞，所以一般来说我们会把身份验证模式改成“混合模式”，也就是SQL Server身份验证加Windows身份验证都允许。

用Windows身份验证本地登录SSMS，连接成功后，左侧对象资源管理器里右键服务器名，选择“属性”，在弹出的窗口左侧选“安全性”，然后看到“服务器身份验证”，勾选“SQL Server和Windows身份验证模式”，确定。系统会提示需要重启SQL Server服务，重启一下。

这一步也别忘了设置sa账号的密码。在对象资源管理器里展开“安全性”->“登录名”，找到sa账号，右键选择“属性”，在“常规”页里设置一个足够复杂的密码，然后在“状态”页里确认“登录”是“已启用”。

密码设置方面说句实在话，如果这台数据库直接暴露在公网上，爆破攻击几乎是必然发生的。sa账号的密码我建议至少16位混合大小写加特殊字符，不要用强密码的后半段是“123456”这种自欺欺人的操作。真正的生产环境最好别开sa，新建一个专用的低权限账号来做远程访问，这个账号只授权它需要的库表权限。

2.3 SQL Server Browser服务与命名实例

如果你用的是默认实例，连接时直接写“IP,1433”就行，不用额外考虑端口发现的问题。但如果你装的是命名实例，或者改了端口号，情况就不一样了。

命名实例的远程连接比默认实例复杂，牵涉到SQL Server Browser服务。这个服务的作用是监听UDP 1434端口，当客户端连接命名实例时，会先向1434端口广播问“我要的实例在哪个TCP端口”，然后SQL Server Browser返回具体端口号，客户端再建立真正的连接。

所以如果是命名实例远程访问，除了TCP 1433，还得在防火墙和安全组里放行UDP 1434。这又多了一层配置，也多了被攻击的暴露面。

我的建议是，如果还没装实例，远程访问就装默认实例，最省事。如果已经是命名实例了，不想动数据库，那就别依赖Browser服务，直接告诉客户端端口号，比如连接字符串写“IP,1435”，然后把防火墙和安全组的TCP端口范围放宽到1435，反而清爽。

3. Windows防火墙的精确放行：别把整台服务器裸奔

SQL Server层面配置完成后，开始处理操作系统自带的防火墙。Windows Server 2019默认是开启防火墙的，如果不放行1433端口，外部连接会被直接拦下。很多刚接触云服务器的朋友在这里有误区：我安全组都放行了，Windows防火墙开了有关系吗？答案是有关系。数据包到达操作系统后，Windows防火墙会独立于云安全组做检查，两侧都必须放行，链路才算通。

3.1 通过高级安全Windows防火墙添加入站规则

最方便的方式是使用“高级安全Windows防火墙”。在“服务器管理器”里，或者直接在Windows搜索栏输入“wf.msc”并回车，打开高级安全Windows防火墙面板。

左侧选“入站规则”，右侧选“新建规则”，弹出的向导：

1. 规则类型选择“端口”，下一步
2. 协议和端口选择“TCP”，特定本地端口填“1433”，下一步
3. 操作选择“允许连接”，下一步
4. 配置文件三项默认全选（域、专用、公用），下一步
5. 名称填“SQL Server 1433”，描述可留空，完成

这个规则建完之后，再检查一下这个规则是否真的启用了，状态列显示“是”才行。

不过有个细节需要提醒：Windows防火墙的“允许连接”里，还有一个选项是“只允许安全连接”，这个选项要求IPsec加密，普通场景不用碰，选第一项“允许连接”就够了。

3.2 小心“作用域”这个隐藏坑

新建规则向导的第四步“配置文件”之后，还有个“作用域”页面，这个页面一般人在新手向导里看不到，但如果你后面编辑规则属性，就能看到。

作用域里的“本地IP地址”和“远程IP地址”可以限制这条规则匹配的来源IP。默认是“任何IP地址”，意思是所有来源IP都放行。如果你想让数据库只对某个IP或某段IP开放，在这里填远程IP地址是最精确的做法。

举个例子，你的办公网络IP是123.45.67.89，那就在远程IP地址里添加这个IP，其他IP全拒。这样即使安全组配错了，防火墙这一层还能兜底，实际部署中这种多层防护很有价值。

有些人图省事，直接关掉Windows防火墙，说“我安全组已经控得够严了”。这是典型的给自己挖坑。服务器又不是永远只跑数据库，还要装别的服务，Windows防火墙是操作系统层面的最后防线，真出事的时候能拦住一部分横向扩散。说实话，我见过有的服务器Windows防火墙确实被关掉了，安全组也裸奔着，结果就是被当肉鸡挖矿。

正确做法是保留Windows防火墙，只放行需要的端口。针对不同来源IP做不同的规则，效果比全开放好得多。

4. 云安全组入方向规则：外网访问的最终闸门

现在到核心部分了，这也是标题里强调的重点。前面说的SQL Server配置和Windows防火墙，都是在服务器内部做文章。而云安全组是云平台层面，作用在虚拟机外面的那一层网络过滤器。很多人买了云服务器之后，发现数据库配置对了，Windows防火墙也放行了，外网还是连不上，最后查来查去，问题出在安全组。而且安全组的生效范围在云平台网络层，比服务器内部更早拦截流量，所以排错的时候，优先看安全组反而能更快定位问题。

4.1 为什么云服务器必须配安全组

安全组是云平台为云服务器实例提供的一种虚拟防火墙，它在数据包到达操作系统之前就做了过滤。每个云服务器实例至少加入一个安全组，安全组里的规则决定了谁能访问这台服务器。

在实际场景中，你买了一台云服务器，通常云平台会给它分配一个默认安全组，这个安全组默认只放行一些基础端口，比如22（Linux SSH）、3389（Windows RDP）、80/443（Web服务），甚至有的默认什么都不放行。1433是数据库端口，不在默认放行范围内。

所以外网访问SQL Server 2019时，安全组这一层几乎是必配的，除非你自己搭建的是内网环境。这个过程在阿里云、腾讯云、华为云控制台里虽然界面各异，但核心逻辑都是一样的：创建一条入方向规则，允许TCP协议的指定端口（如1433）从特定源IP或所有IP访问。

4.2 入方向规则配置的具体步骤

以阿里云为例，操作路径如下：

进入ECS实例列表页，找到目标实例，点击“安全组”页签，或者直接进入“云安全中心”下的安全组控制台。找到实例所在的安全组，点击“管理规则”或者“配置规则”。

在“入方向”页签下，点击“手动添加”：

1. 授权策略：允许
2. 优先级：100（数字越小优先级越高，默认100就行，说明一下即可）
3. 协议类型：自定义TCP
4. 端口范围：1433/1433
5. 授权对象：这里很关键，根据自己的需求选择。如果你希望所有人都能访问，可以填0.0.0.0/0，这是公共IP段通配写法；但更安全的做法是填你自己的公网IP，比如183.92.4.125/32，这样只有你所在网络能连数据库
6. 描述：SQL Server 2019远程访问

填完保存，这条规则就生效了。

腾讯云控制台在“云服务器”->“安全组”里，操作流程类似，但“授权对象”的填写格式相同。华为云的“虚拟私有云VPC”->“安全组”也一样。

需要注意，不同云平台的端口范围写法略有差异，有的要求填“1433/1433”，不能单独填“1433”。填写时看一下控制台的示例提示。

4.3 授权对象到底该填什么

这是我看新手配置安全组时犯得最多的错误：授权对象一律填0.0.0.0/0，然后数据库端口就裸奔在全世界面前。SQL Server的1433端口一旦完全公开，接下来的事情就变成了撞库、爬虫扫描、暴力破解，几乎每天都有来自全球的扫描流量来敲门。

如果你非要填0.0.0.0/0，至少应该配合前面SQL Server层的账号安全策略做防护：强制复杂密码、不开sa、启用SQL Server审核日志。但这终究是被动防守，更主动的做法是只对可信IP放行。

怎么查看自己的公网IP？直接在搜索引擎搜索“IP地址”，或者用“ipconfig”命令看本机出口公网IP（但实际场景里你的出网IP可能和本机网卡IP不一样，最靠谱的是在客户端电脑上打开浏览器访问“https://myip.ipip.net”这类网站看出口IP）。然后填入授权对象，格式：183.92.4.125/32。

如果你不确定IP会变，可以放一个稍微宽一点的段，比如183.92.0.0/16，但段越宽，暴露面越大。权衡下来，如果是个人学习环境，填0.0.0.0/0问题也不大，只要密码够复杂；如果是公司生产环境，我强烈建议精确到IP或IP段。

这里有一个我从运维前辈那里学来的技巧：只对当前无法确定来源范围的场景放行大IP段，而对于有固定出口IP的办公室环境，用IP白名单比什么防火墙都管用。

4.4 实例绑定了多个安全组时的规则叠加逻辑

如果一台ECS实例绑定了多个安全组，所有安全组的规则会叠加生效，逻辑是“或”的关系。也就是说，只要其中任一安全组允许了某个IP访问1433端口，那这个IP就能连进来。

这个机制其实很方便，你可以创建不同的安全组来管理不同的服务。比如建一个“SQLServer远程访问组”，专门放1433端口的规则，然后把某几台数据库实例都加入这个组，比在每台机器上单独改安全组要高效得多。

但要注意，当多个安全组规则冲突时，不同云平台的策略可能不同。有的平台是“拒绝优先”，有的平台是“允许优先”。建议不要依赖冲突规则来管理，保持安全组规则简洁清晰，每台实例绑定的安全组不超过2到3个，排错和理解成本都会低很多。

5. 验证与常见问题排查：从telnet到SSMS全流程

配置完以上所有层级后，开始验证。验证的步骤有先后顺序，按照链路从外到内逐步检查，哪一步不通，就能定位到哪一层。

5.1 第一步：telnet测试端口连通性

在本地电脑上打开命令提示符（Windows），输入：

code复制telnet 服务器公网IP 1433

这时有几种情况：

如果屏幕黑一下，然后变成全黑或者显示一个光标，说明端口通了，telnet连接成功。
如果提示“正在连接...无法打开到主机的连接，在端口1433: 连接失败”，说明这一层还没通。按顺序排查安全组、Windows防火墙、SQL Server是否监听。

实际上telnet在Windows 10/11系统上默认是没安装的，第一次运行会提示“telnet不是内部或外部命令”。需要先在“控制面板”->“程序”->“启用或关闭Windows功能”里勾选“Telnet客户端”，或者用PowerShell的Test-NetConnection替代：

powershell复制Test-NetConnection 服务器公网IP -Port 1433

这个命令返回结果里，TcpTestSucceeded字段显示True就代表连通了。相比较telnet，PowerShell的方式在win10、win11上零配置就能跑，优先级更高。

还有一个更直观的办法：在服务器本地用命令查看SQL Server是不是真的在监听1433。管理员权限打开命令提示符，输入：

code复制netstat -an | findstr 1433

如果看到TCP 0.0.0.0:1433或TCP [::]:1433处于LISTENING状态，说明SQL Server确实在监听。如果只看到127.0.0.1:1433，说明实例只绑定了回环地址，外部访问肯定不通，需要检查TCP/IP属性里的监听所有选项。

5.2 第二步：SSMS连接测试与常见报错

telnet通了之后，用SSMS连接服务器。服务器名称填公网IP，如果是默认实例直接写“IP”，如果改了端口写“IP,端口号”注意是英文逗号。身份验证选“SQL Server身份验证”，填登录名和密码，连接。

常见的错误如下：

错误一：“在与 SQL Server 建立连接时出现与网络相关的或特定于实例的错误。未找到或无法访问服务器。”这个报错代表数据包根本没到达SQL Server实例，重点查网络连通性，包括安全组、防火墙。

错误二：“用户 'sa' 登录失败。”这个报错说明网络链路已经通了，但身份验证没过。检查登录名密码、账号是否被禁用、是否启用了SQL Server身份验证模式。

错误三：“因为数据库正在恢复，无法访问。”这个比较少见，说明数据库实例处于恢复状态，等一会儿再连。

错误四：“连接被服务器上的安全策略拒绝。”检查登录账号是否被锁定，SQL Server的登录触发器是否拦截了远程连接。

5.3 常见问题速查表

5.4 我踩过的几个坑

第一个坑是SQL Server配置管理器里启用了TCP/IP之后忘了重启服务。这个坑太经典了，改了配置不重启，服务还是跑的原来的监听状态，然后连不上就开始怀疑安全组配置。检查顺序很重要，修改任何SQL Server网络配置，都伴随服务重启这一步。

第二个坑是阿里云安全组填端口范围时，控制台要求填“1433/1433”，很多人直接填“1433”，保存后报错。这类界面提示往往很明确，但人就是不看，导致反复出错。

第三个坑是Windows防火墙默认拒绝来自公网的ping请求。你通过ping测不通服务器，就以为服务器网络有问题，其实是ICMP默认被拦了。别用ping作为连通性判断依据，直接用telnet或Test-NetConnection测1433。

第四个坑是腾讯云的“安全组”和“网络ACL”是两个独立的东西，有些用户配置了安全组，但网络ACL里依然拦截了流量。如果你在腾讯云或华为云上同时配置了网络ACL和安全组，两层都要检查。

第五个坑是关于云平台的安全组规则默认拒绝所有流量，你要是只加了出方向规则忘了加入方向规则，那服务器外网连接一样不通。有的云平台默认允许所有出方向流量，但入方向默认拒绝，这点一定要确认。

6. 实战演练：从零到外网连接成功的完整日志

前面章节是按层拆分的原理讲法，很多读者可能感觉步骤有点散，我再用一个完整案例串一下。

假设现在我有以下环境：

• 云服务器：某云平台Windows Server 2019，公网IP假设是47.98.123.45
• 数据库：SQL Server 2019 Developer版默认实例
• 本地客户端：Windows 10 + SSMS 19
• 场景：在本地通过SSMS连接服务器上的SQL Server

分步操作：

第一步，先远程桌面登录服务器，用Windows账号登录。在服务器上打开SQL Server配置管理器，启用TCP/IP，确认IPAll的TCP端口是1433。重启SQL Server服务。

第二步，用SSMS本地连接服务器上的实例（服务器本机可以直接Windows认证连），改服务器属性为混合身份验证模式，重启服务。查看sa账号状态，确认是启用的，重置密码为一个高强度的密码。

第三步，在服务器上打开高级安全Windows防火墙，新建入站规则放行TCP 1433。

第四步，回到云平台控制台，找到实例的安全组，添加一条入站规则：协议TCP、端口1433/1433、授权对象0.0.0.0/0（如果是测试环境）、描述“SQLServer远程”。

第五步，回到本地电脑，运行PowerShell:

powershell复制Test-NetConnection 47.98.123.45 -Port 1433

返回TcpTestSucceeded : True。

第六步，打开SSMS，服务器名称填47.98.123.45，身份验证选SQL Server身份验证，输入sa和密码，连接成功。

这个流程走完大概需要10分钟，但你要是不看这篇内容，可能一天都折腾不明白。

如果你连这都配好了还是连不上，再回头看看是不是网络ACL的问题。有的云平台默认会创建一个默认网络ACL，如果你在绑定了网络ACL的子网里，ACL的默认规则可能是拒绝所有流量，就会在安全组之前把流量拦掉。在控制台找你子网绑定的网络ACL，看里面有没有放行1433的入站规则。

7. 不同云平台安全组操作差异速查

配置过多个云平台之后，发现这些平台的安全组机制大方向相同，但细节有差异。做了一张速查表：

这里只列出主流平台，实际操作时以控制台界面为准。但记住一个原则：安全组是白名单逻辑，默认拒绝所有入方向流量，你只放行需要放行的东西。

还有一点值得注意，如果你用的是轻量应用服务器而不是云服务器ECS，安全组设置入口会更隐蔽。轻量应用服务器一般没有独立的安全组控制台入口，而是在实例的“防火墙”页签里配置。规则基本上一样，也是放行TCP 1433端口。

8. 数据库暴露到公网后的安全加固清单

如果你只是练手，配好了能连就行。但如果要放业务数据，必须做安全加固。SQL Server直接暴露公网本身就是一件风险很高的事，以下是我建议至少做到的安全措施：

第一，绝不使用简单密码。如果实在要用sa，密码至少16位，混合大小写、数字、特殊字符。建议用密码生成器生成，不要用自己姓名缩写加生日这种。

第二，使用最小权限账号。创建一个只具有特定数据库db_datareader和db_datawriter权限的账号用于远程连接，不要用sa做远程访问。

第三，限制授权对象。安全组里的授权对象精确到你的办公IP段，而不是0.0.0.0/0。

第四，启用SQL Server审核。在服务器属性 -> 安全性 -> 审核里，设置为“仅限失败的登录”。这样SQL Server会记录失败的登录尝试，日常检查Windows事件日志里的SQL Server日志，及时发现暴力破解的痕迹。

第五，修改默认端口。如果你不确定怎么改，在SQL Server配置管理器TCP/IP的IPAll里修改TCP端口为其他端口，比如14330，然后本地和防火墙同时改成新端口。这样可以规避大量针对默认端口的扫描流量。

第六，网络层隔离。在云平台里，如果条件允许，把数据库部署在私有网络（VPC）的子网内，只允许应用服务器所在网段访问，不直接对公网开放。这比任何防火墙配置都更安全，因为数据库就不存在于公网可达的路径上。

最后分享一个经验

SQL Server 2019远程访问配置这件事，本质上没什么高深技术，但它牵涉的层级多，每一层都可能出问题。你按照安全组 -> Windows防火墙 -> SQL Server网络配置 -> 身份验证 -> 客户端测试这个顺序排查，命中率最高。如果你跳着来，忽而看这个忽而看那个，反而容易越搞越乱。

我在实际配置中体会比较深的一点是，云服务器安全组这个环节，对很多从传统机房转过来的运维来说是反直觉的——以前自己管服务器防火墙就好，上云之后多了个云平台层面的过滤层，而且过滤顺序还在操作系统之前。只要把这条链路的顺序记牢，配置SQL Server远程访问就再也不是什么难事。另外，无论只是个人测试还是生产环境，记住一个原则——数据库端口做到最小暴露，安全组授权对象精确到IP段，数据库账号权限最小化，这三点比任何辅助工具都管用。