检测SQL Server端口最直接的方法是使用telnet或PowerShell的Test-NetConnection命令测试TCP端口连通性，并配合netstat命令确认SQL Server实际监听的端口号。
下面从端口确认、连通性测试、常见故障排查、不同场景的差异等几个层面，把“怎么检测SQL Server端口”这件事讲透，无论你是刚接触数据库的运维，还是负责云上环境的开发，都能按步骤直接操作。
怎么检测SQL Server端口是否打开
很多人一上来就telnet 1433端口，结果不通就以为数据库有问题，其实第一步应该先确认SQL Server到底在监听哪个端口，尤其是命名实例，可能根本不是1433。
用SQL Server配置管理器确认监听端口
打开SQL Server配置管理器，展开“SQL Server 网络配置”，点击“实例的协议”，右侧双击“TCP/IP”，在“IP地址”选项卡里能看到“IPAll”下的“TCP端口”，默认实例通常显示1433，命名实例这里显示的是动态端口，比如49172，这一步能帮你明确目标端口，避免瞎测。
用netstat命令查看实际监听状态
在SQL Server所在的服务器上打开命令提示符，执行：
netstat -ano | findstr 1433
如果看到“LISTENING”状态，说明SQL Server正在监听1433端口，如果是命名实例，先运行“sqlcmd -L”列出局域网内所有SQL Server实例，然后从输出里找到实例名，再去配置管理器里查动态端口。
区分默认实例与命名实例的端口差异
默认实例固定使用1433端口,命名实例默认使用动态端口，第一次启动时由操作系统分配，动态端口每次重启可能变化，这也是很多连接异常的根本原因，若要稳定连接，建议在配置管理器里为命名实例设置固定端口，例如14333，之后检测目标就是该端口。
使用命令测试SQL Server端口连通性
确认了端口号,接下来才进入真正的连通性检测，下面是几种常用方法，按使用频率排列。
使用telnet命令快速测试
在客户端命令行输入：
telnet 192.168.1.100 1433
如果屏幕出现空白光标,说明端口开放，如果提示“无法打开到主机的连接”，说明端口不通，注意Windows系统默认可能未安装telnet客户端，需在“控制面板-程序-启用或关闭Windows功能”里勾选“Telnet客户端”。
使用PowerShell的Test-NetConnection
PowerShell自带的Test-NetConnection命令更清晰，执行：
Test-NetConnection 192.168.1.100 -Port 1433
输出里的“TcpTestSucceeded”字段显示True表示端口可访问，False则表示不可达，这个命令比telnet更友好，而且不用额外安装组件，推荐优先使用。
对比telnet与Test-NetConnection的适用场景
telnet适合快速验证,一次敲一个命令，在老旧系统或Linux服务器上也常用，Test-NetConnection则能同时显示Ping结果、路由信息等，更适合Windows环境下深入排查，两者结合使用，能覆盖绝大多数检测需求，如果对端口扫描有更多要求，也可以试试Nmap的“-p 1433”参数，结果更直观。
SQL Server 1433端口不通怎么排查
检测到端口不通,先别急着下结论，按照下面几个链路依次排查，能快速定位问题。
检查SQL Server服务是否启动
登录数据库服务器,打开“服务”管理器，确认“SQL Server (MSSQLSERVER)”状态是“正在运行”，如果服务没起来，端口自然毫无反应，服务启动后重新测试，往往问题就解决了。
检查Windows防火墙是否拦截
在服务器上执行：
netsh advfirewall firewall show rule name=all dir=in
查看是否存在允许TCP 1433入站的规则，如果没有，执行以下命令添加：
netsh advfirewall firewall add rule name="SQL Server Port" dir=in action=allow protocol=TCP localport=1433
添加后再测试一次,注意防火墙策略可能由域控统一管理，本地添加可能不生效，需要联系管理员。
检查云平台安全组规则
如果你用的是云服务器,除了服务器内部的防火墙，还需要检查云平台的安全组配置，在安全组入方向规则中，必须放行来源IP、协议TCP、端口1433，很多云厂商默认只放行22和3389端口，SQL Server端口需要手动添加，这是云环境中最常见的端口不通原因。
排查端口被占用或配置错误
如果SQL Server明明在监听，但客户端还是连不上，检查是否配置了错误的端口，比如在配置管理器里设置了固定端口，但SQL Server服务没有重启，导致实际监听的还是旧的动态端口，如果服务器上有其他程序占用1433端口，netstat会显示该进程的PID，再用“tasklist”查看是哪个程序。
图形化工具辅助检测SQL Server端口
命令行能解决大部分问题,但一些人更喜欢直观的界面，可以使用以下工具。
SQL Server Management Studio的连接属性
在SSMS登录窗口输入服务器IP和端口,格式如“192.168.1.100,1433”，如果连接成功，在“视图-注册的服务器”中可以看到连接信息，SSMS本身不会直接显示端口连通性，但它能验证整个连接链路是否正常。
使用PortQry或第三方端口扫描工具
微软官方工具PortQry支持命令行和图形界面,输入目标IP和端口就能返回“LISTENING”或“FILTERED”，Nmap是另一款常用工具，执行“nmap -p 1433 192.168.1.100”，输出中显示“open”即表示端口开放。
本地与云服务器SQL Server端口检测差异
不同部署环境下,端口检测的重点和步骤有所不同。
本地服务器检测要点
本地物理机或虚拟机,主要检查Windows防火墙、SQL Server服务状态和端口配置，如果你在公司内网，还需确认路由器或交换机是否做了访问控制，本地检测通常不涉及安全组，排查链路更短。
云服务器检测要点
云服务器需要同时关注系统内防火墙和云平台安全组两层限制,以简米云为例，登录控制台找到ECS实例，查看“安全组规则”，确认入方向是否放行SQL Server端口，酷番云、华为云操作类似，行业共识认为，云环境中80%的端口不通问题源于安全组配置遗漏。
场景建议：快速判断属于哪一层问题
在客户端执行“Test-NetConnection”，如果TcpTestSucceeded为False，再在服务器本机执行同一命令，本机返回True但客户端返回False，问题多出在网络链路或安全组；本机也是False，则问题在SQL Server服务或系统防火墙。
关于SQL Server端口检测的常见问题
SQL Server端口不通一定是防火墙问题吗
不一定,服务未启动、实例使用动态端口、SQL Server网络协议禁用TCP/IP、客户端写错端口号，都会导致测试失败，建议按“服务状态-监听状态-本机回环测试-防火墙/安全组-网络链路”的顺序排查，每一步都有对应的验证方法。
如何检测命名实例的动态端口
命名实例的动态端口无法提前预知,先在服务器上用“sqlcmd -L”或SQL Server配置管理器找到当前动态端口，然后使用Test-NetConnection测试该端口，如果希望客户端连接稳定，最好在配置管理器中为命名实例设置固定端口，并重启SQL Server服务，后续检测只需针对固定端口即可。
检测SQL Server端口并不复杂，核心是先确认实际监听端口，再用Test-NetConnection或telnet测试TCP连通性，最后根据不通时的反馈逐层排查服务、防火墙和安全组，记住1433只是默认端口，命名实例和云环境往往会引入额外变量，多掌握几种检测命令，你就能在任何场景下快速判断端口状态。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/sql%e6%9c%8d%e5%8a%a1%e5%99%a8%e7%ab%af%e5%8f%a3%e6%80%8e%e4%b9%88%e6%a3%80%e6%b5%8b%ef%bc%8c%e6%9c%89%e5%93%aa%e4%ba%9b%e6%96%b9%e6%b3%95%ef%bc%9f/
